savas parastatidis

Resources vs services as the building blocks in architectures & where are the consumers?

In the post where I almost announced my move to the REST camp (Mark, thanks for the membership card, I hope you get well soon :-), I talked about services and messages as the only building blocks for building distributed applications according to the principles of service-orientation. I also suggested that there are no consumers, clients, or servers. Please allow me to further expand on these two topics after having read some comments:

Where are the consumers?

In his "Consumers, Services, Messages" post, Stefan disagrees with my argument about the lack of consumers in service-oriented architectures and notes that "some UI code that uses a service is more of a consumer than a service of its own". I agree that some application code may be seen as consuming a service. However, this is a role which is specific to the application and does not exist in the service-oriented architecture. Let me explain what I mean through an example:

If some UI code was written to exchange messages with a service in a transport independent manner, then there is a chance that a protocol like SMTP is used. SMTP does not support a request/response message exchange over an established communication channel. As a result, the "consumer" code, or the underlying middleware on which it is built, must be able to receive a reply-message and correlate it to a previously sent request-message. In order to be able to participate in an interaction with other services, it must be a service itself.

In my discussions all I am doing is apply this observation to the description of the "ProcessMessage" architectural style where only services and messages exist and where you don't need to worry about the roles that are assigned to application-specific actors. Services exist to receive messages. The way those messages are dispatched and processed by the service logic is hidden behind that service's boundaries. Furthermore, the roles (like "client", "consumer", "server") that applications build on top of the fundamental building blocks (services and messages) are not part of the "ProcessMessage" model.

Sometimes the tooling completely hides the underlying architecture from the developers so that the details are abstracted and, therefore, it may become difficult to make the distinction between the actual architectural building blocks and the programming abstractions. For example, the most popular tooling at the moment out there presents services to application developers as classes. Even in Indigo, where the message plays such an important role, there are going to be object-oriented abstractions for building and interacting with Web Services. That doesn't mean of course that services are objects (why do I always go there? 🙂

I totally agree with Stefan though that it's really interesting how the language influences our understanding of the architecture.

What about resources? (REST and *REST*)

I am talking about an architecture which only has services and messages, so where are the resources? Well, they are not explicitly modelled. There are no resources in the architecture but that doesn't mean that they don't exist behind the service boundaries.

Robert O'Brien pointed me to Dr. Rohit Khare's work on the ARRESTED architectural style. I read the "Extending the REpresentational State Transfer (REST) Architectural Style for Decentralized Systems" paper which I found extremely interesting. Very good read.

However, I don't think that I am talking about the same architectural style because unlike REST and AR-REST-ED, I am talking about an architecture where resources are not explicitly modelled. I felt that because AR-REST-ED had to deal with state (representation of state), it was necessary to introduce additional semantics and constraints into the architecture. This is not the case in the "ProcessMessage" style and service-orientation in general because state is not explicitly modelled. When distributed coordination/synchronisation is required, appropriate protocols are introduced.

Now, I have just read the paper so I may have not understood everything and I may be wrong and unfair in my comparison. I am looking forward to comments/corrections.

Events and objects as the programming abstraction for building service-oriented applications

The ARRESTED paper reminded me a discussion that Jim and I had a week or so ago. We were talking about programming abstractions for building service-oriented applications. We both agreed that the most appropriate programming model is event-driven with messages being represented as objects. According to the "ProcessMessage" model, a service receives a message and the logic processes it. The arrival of the message should really be represented as an event and not as a method invocation. We are going to write more about this and also do some coding to test the approach. The ARRESTED paper also promotes events (notification) albeit in order to meet the state-related requirements imposed on the architecture.

12 responses to “Resources vs services as the building blocks in architectures & where are the consumers?”

  1. MikeD
    I think a ProcessMessage architectural model is valid. It’s been used in many places – the first location I encountered it was within Microsoft Windows 3.0 via the PostMessage()/SendMessage() and GetMessage()/PeekMessage() APIs. I believe this is also the model taken by JMS – merely sending and receiving messages.
  2. Mark Little
    There’s certainly nothing new about onMessage (or whatever you want to call it) as a programming abstraction. As you say, JMS uses is, so do servlets. It has its place in the grand scheme of things, but it hasn’t surplanted other styles. (At some level, however, everything is a doWork(any) style – look at TCP).
  3. Savas Parastatidis
    Hey guys! I agree that there is no revolutionary with the “ProcessMessage” approach or the event-based mechanisms. However, I still believe that it’s interesting to reason about the architecture of distributed applications in those terms. I am talking about an architectural style (a la REST, object-orientation) and then about how that architectural style is better represented at the programming model. No suggestion that there is something new there but I still find it interesting when talking about the architecture. The fact that some people see the architecture of internet-scale applications in a different manner (e.g., REST, WS-RF, CORBA, etc.) makes it an interest topic for discussion. Don’t you think?
  4. Mark Baker
    “onMessage” (or whatever we want to call this – I like “state transfer”) hasn’t supplanted other styles? Where exactly have you been looking, Mr. Little? 😎 Look on the Internet. It’s absolutely pervasive there, and has been ever since email was first created 30+ years ago.
  5. Mark Little
    Mr. Baker, I wasn’t considering the rather narrow view of distributed systems that you are taking. Next time I’ll wear my blinkers as well.
  6. Mark Little
    Missed the smiley in that 😉
  7. Mark Little
    Savas, I agree it’s interesting and you know my thoughts on this w.r.t. loosely coupled versus closely coupled systems. My point is that it’s definitely an abstraction thingy, because at some point (going back to the TCP example) everything is a processThis, but actually it’s even more fundamental: it’s process byte blob. We (programmers, users, whatever you want to call “us”) impose narrowing abstractions on this for good reasons (well, usually good reasons). The thing is that there are always different ways of slicing the cake and there’s often no single choice that is better than another for all use cases. As a “user”, I’m happy to look at all possible styles and make an informed choice; but next time I come to write an application I’ll do the same again. As they say in investment circles: past performance is no indicator of future performance. It’s always nice to listen to extremes of the arguments though 😉
  8. Jim Webber
    FWIW, the latest WS-GAF work has an event-based API and it is neat. You send a message out explicitly (via methods which have names like SendRegistrationMessage) and subscribe to receive particular events (RegisteredEvent, ChemicalContainerMovedEvent, etc). I find this style of API to be a very natural fit with the underlying processMessage architectural style. It also allows us to use arbitrary transports since correlation is done higher up the stack (in fact in WSE 2.0 for us, but that doesn’t matter). Jim
  9. Mark Baker
    Whoa, Jim, I thought the whole point of processMessage was that processMessage *was* the method. Why do you need other methods?
  10. Savas Parastatidis
    Mark, Jim is talking about the tooling and not the architecture, the way we design the applications. Instead of presenting to the developer the services as objects, we are thinking of using an event-based programming model.
  11. Mark Baker
    I hear you saying that there’s a local API for submitting a registration message, but that gets mapped to a “processMessage” semantic across the network. That sounds reasonable good from a separation-of-concerns POV, except that I don’t understand why you’d need an API specific to submitting registration messages when you’ve presumably already got one for sending generic messages; “submit”, or what-not. Perhaps a pointer to this WS-GAF would help me understand?
  12. Jim Webber
    Mark: To clarify, the global architecture is based on “processMessage” however the API that we ship to 3rd parties to hook into our system is 1/2 methods (SendRegistrationMessage) and 1/2 events (RegisteredMessageReceived). This is a really natural hook for application code to bind to the underlying architecture.