The MEST architectural style

MEST is for service-orientation and Web Services what REST is for resource-orientation and the Web.

The above quote is taken from the paper that Jim and I have just completed. We decided to finally write down our ideas on ProcessMessage, service-orientation, and Web Services. The paper was submitted to a conference so we won’t know what our academic peers will think about it until after few months time.

We have both agreed that we shouldn’t call our architectural style ProcessMessage after all. Instead, we decided to call it MEST (MESsage Transfer) so as to recognise the big influence REST had in this work and our thinking in general. So, after all the blog entries and the discussions with the community, we have finally arrived to the MEST architectural style of which ProcessMessage is part.

The approach we have taken for MEST is to say that the architecture consists only of services and messages. Applications are designed through the explicit transfer of messages and the message-based conversations that are formed. Services are not callable entities. However, we recognise some benefits of the “remote call” abstraction (familiarity, past-history, widely used programming language construct, etc.) so we decided to introduce ProcessMessage as a single, logical operation that each service should support for those who like ‘operations’, ‘methods’, ‘calls’. ProcessMessage is an asynchronous operation and corresponds to a one-way message. We haven’t changed the semantics of ProcessMessage from our previous writing…

A call to the ‘ProcessMessage’ operation represents the transfer of a message from a sender to a recipient with a request to process that message.

I am excited about this paper albeit not confident about its acceptance due to the conference’s low acceptance rate and because our past experience says that academic papers we write about our ideas get rejected (or perhaps we weren’t choosing the right conferences, or even and more likely our papers are not of good quality 🙂