This recent post by Dare Obasanjo (whom I am hoping to get the chance to meet when I get to Microsoft) reminded me that I need to start preparing my MEST vs REST arguments for HPTS. I now know that because of my position paper on why service-orientation, and particularly MEST, is better suited for building large-scale, distributed applications when compared to the REST architectural style, there is going to be someone from Amazon to support the resource-oriented thinking. This is very very cool since I love participating in technical or architecture-related discussions when there is someone to support the opposite view (what’s the point of the discussion otherwise, right?:-). It is going to be so much fun especially given that many great computer (or computing) scientists with in-depth knowledge of and experience in distributed computing are going to be there.

Dare feels that modelling a distributed application around the concept of resources doesn’t always feel natural when it comes to offering a service to the outside world. I would also like to highlight the issue of identity, address (dispatch endpoint), and state. In REST (and in many object-oriented systems), these three are coupled. In MEST we don’t need them so we get rid of them; we only build around the concept of a message and a service (no resources as architectural building blocks). State no longer exists as a bindable architectural block; abstractions like ‘operation/method/procedure’, ‘client’, ‘server’, etc. disappear. By doing so, we hope the architectural style encourages loosely coupled and scalable solutions without any of the state-management-related problems. Effectively we introduce a level of indirection and we leave the issue of state management to the applications (e.g. what happens when the order id in the received document refers to an order that no longer exists). This issue also relates to the ongoing discussion on whether there should be one application protocol to rule them all (i.e. HTTP) or whether we should have a message processing model and composable infrastructure protocols, all with well defined semantics, on top of which we can build arbitrary message-oriented applications. The world around us is a set of services that communicate with one another by exchanging messages. We talk to services about resources. We don’t talk to resources directly. Why can’t we build our systems in the same way?

I think that a fundamental problem in understanding the differences between the MEST and REST architectural styles is peoples’ perception that these are technologies. Service-orientations and service-oriented architectures are often confused with Web Services. Similarly, the Web and HTTP are confused with REST. Some of the comments in Dare‘s post demonstrate this confusion. As I tried to show in the past (apologies for linking to the same post again and again), one could build an application according to the REST or CRUD principles by using Web Services technologies. I am sure one could build a service-oriented application using HTTP and break every single principle of REST on the way.

As I prepare my arguments for HPTS I will post them here for you to scrutinise.