Notes on service-orientation and currest state of WS-* specs, or… I think I am going to join the REST of them

Where is the Web Services world going to? I originally thought (wished) that Web Services technologies would be governed by the principles of service-orientation. I thought we were trying to realise an architecture where the focus was the service and the messages being exchanged, where policies and contracts allowed us to reason about the interactions between those services. However, it seems to me that the majority of architects out there can’t break away from the paradigms of the past and the terminologies that we have been using until today which has an effect on how we form the future.

Why do I say this? Well, I’ve been following the recent postings in the WSDL WGmailing list and the discussion on whether the “operation” names of a service’s “interface” should be distinguishable and whether “consumers” should be aware of the dispatch of an operation at the service side. I’ve also been monitoring the discussions on the WS-RF mailing list and the focus of that technical committee on resources and their attempt to elevate them into principal entities in the architecture. 🙁

Let’s examine these closely…

Terminology affecting our view of the architecture

The terms “consumer”, “server”, “client”, “server” have often been used (and still are) in our architectural related discussions. Unfortunately, these terms may suggest a slave-master or an initiator-reactor relationship. There is an inherit coupling between the two actors (the one initiating the interaction and the one that reacts to the stimulus). The terms are not necessarily bad until their meaning in English has an impact on the definition of the architecture.

Traditionally, we have been building distributed systems using remote procedure calls or distributed objects where the sort of coupling implied by a client-server relationship exists since we have the caller of a procedure/method call requesting the execution of some code, some action and in many cases expecting a result or notification of successful completion. Semantically, the caller is aware of the fact that an operation is performed at the other side and it knows which operation it is.

In service-orientation, I think of the architecture as consisting of only services and messages. The promise of loose coupling comes from the fact that there are no assumptions about any kind of relationship between the services or any common understanding of their inner workings. For example, if one was to expose the dispatch mechanism used for the implementation of a service, it would become difficult to evolve that service since a coupling between the initiators of the dispatching process and the implementation of that service would exist.

I believe that the fascination with “operations” and “interfaces” in the WSDL working group will lead to the above problem. Services exchange messages; those messages do not represent a method or procedure invocation unless you are implementing RPC or distributed objects using angle brackets. Imposing that view of the world to everyone, I think is bad.

The architecture: Only services and messages

How do we move away from the past? My proposal is to think of the architecture as only consisting of services and messages. There are no clients, no consumers, and no callers; there are only services exchanging messages. A message sent to a service is effectively a request to that service to process a document, the contents of the message. We shouldn’t assume that the message sent represents an operation, a method, or anything else at the service side. We are just conveying information. Any entity/actor in the architecture that may receive a message is a service. Even a “reply” is a request from the service-receiver to the service-sender and is correlated somehow to the original message (e.g., by using a synchronous communication channel or through unique identifiers). It should be apparent how this architecture could be considered loosely coupled, even more flexible than REST (IMHO of course). We still haven’t found a good name for it but Jim and I refer to it as the “processThis” architecture.

Mark Baker described the “processThis” approach to service-orientation, without explicitly naming it, in one of his recent posts to the WSDL WGmailing list (I am not sure whether it was his intention but his description matches what we’ve been talking about). I am surprised that the REST people get it while Web Services proponents don’t. After all, Web Services are supposed to build on the principles of service-orientation. Could it be because Jim‘s and my ideas are closer to those expressed by the RESTferians? Could it be that despite the objections I have to the elevation of the transport protocol semantics to application protocol status, it is the only group of architects out there who get the fact that there are no operations in the traditional sense? Or is it because REST promotes only those few operations implied by the transport protocol as the only ones to be used? But still, those operations are not treated as RPC calls.

No, there is no one application protocol with a collection of operations that rules them all. There are only the semantics of the message exchange patterns that an application defines 🙂 Nevertheless, I feel closer to Mark and the rest of the REST folks than ever 😉 Hey… I am lost at the moment and I need to feel that I belong somewhere… I’ll get over it soon 🙂 … but despite what the title of this post says, I don’t think I’ll be joining the RESTferians, at least not yet.

What about resources?

Well, REST focuses on resources, it promotes them to first class citizens in the architecture and it’s honest about it. That’s what REST is all about and it’s good at it.

WS-RF on the other hand is not honest. It elevates resources to major actors at the architectural level, since they can send and receive messages, through the way they use particular Web Services specifications (i.e., the use of reference properties in WS-Addressing). This is bad because a particular use of the underlying technologies, developed to support a particular architecture, are misused to realise a completely different architecture, one which has resources that can receive messages. Perhaps REST would have been more appropriate for the requirements of the Grid community since resources are part of the architecture.

Phew… that was a long post. I have some few more thoughts that I will probably write in a different post.

If you reached all the way down here, many thanks! I am very interested in your comments/views/corrections/disagreements.