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.