MEST, an operation, and the role of contracts

The discussion on MEST started again thanks to a recent entry by Jim. Mark makes some valid observations in his comment to Jim’s entry. I would like to clarify a couple of things:

MEST is an architectural style and as such it is not tightly associated to SOAP. The relationship between MEST and SOAP is similar to the one which exists between REST and HTTP. One is an architectural style while the other an implementation technology. The use of the specific implementation does not guarantee that the principles of the architectural style are met. As an example, refer to my WS-Web application which demonstrates how the REST principles could be implemented using SOAP. It’s just that one piece of technology enables or makes it easier to apply certain architectural principles.
In the past we’ve talked about the single ‘ProcessMessage’ or ‘ProcessThis’ operation at the architecture level (no implication that there is a WSDL-specific operation). The idea was that the only assumption we should make about the components in our architecture is that they could send and receive messages for processing. However, it seemed that the concept of an operation with uniform semantics confused the discussion. So, we decided not to put so much emphasis on it but the concept is still very much alive.

With MEST, we advocate that there are no application domain-specific operations exposed and there are no abstractions like ‘interfaces’. There is the assumption, however, that the components behave in a uniform manner throughout all applications (i.e. they send and receive messages). When we designed SSDL, for example, we had MEST in mind: the default value of the /ssdl:msgref/@action is ‘urn:ssdl:v1:ProcessMessage’ 😉 We couldn’t ignore wsa:Action since it’s here to stay despite what we think about it. However, we can at least use it in a way that does not break the MEST principles. When implementing a Web Service application according to these principles, the wsa:Action of a SOAP message should always be ‘urn:ssdl:v1:ProcessMessage’ with its uniform, MEST-defined semantics. Dispatching of the message is left to the implementation. An implementation has other ways of determining the actions that must be performed as a result of receiving and processing a message.

Unlike REST and object-oriented paradigms, in MEST you don’t bind directly to state and/or interfaces when building distributed applications. In fact, there is no concept of an interface and no data/state/representation of state is directly exposed. Applications bind to protocols and contracts. Scalability and loose-coupling are achieved through the relaxation of the common assumptions which span across components and the fact that there is no explicitly exposed state. This probably means more complexity imposed on the implementation of the components (just a suggestion at the moment… no experimental results) but I envisage a set of declarative- and semantics-based design and programming tooling emerging to allow the composition of interesting, large-scale, loosely-coupled, distributed applications.

We have already started describing all the above using architectural elements (data, connectors, components) in the paper which was promised long time ago but we still haven’t found the time to complete it 🙁 Also, I have written a position paper on “MEST vs REST” and why I don’t consider the Web as the best platform for building internet-scale applications even though the Web is a hypermedia application which itself scales (obviously). I haven’t talked about this position paper until now since it has been submitted to HPTS and I am waiting for feedback and comments. However, it seemed appropriate to mention it here. I am not optimistic about its acceptance since it was written at the very last minute but I found that having a deadline to meet and forcing myself to write it was a good way to capture some of my current thinking. I am sure it will spark some interesting discussions when it’s polished and made available for comments to a wider audience 🙂