Steve in his “Gudge, Mark, app protocols, and transport independence” post continues the very interesting discussion with Mark and Gudge. Mark mentioned MEST in his “Gudge responds to the wsa:To issue” post and so Steve asks for clarification on what MEST is all about. So, here it goes…
I have to start by saying that I totally agree with Steve‘s ideas about the truth being in the contents of the message. I wouldn’t have it any other way. The semantics of an interaction should only be inferred by the contents of the message and not by any external factors. Moreover, I support that while the truth is found in the contents of the messages, it is also the protocols that are of great importance when we build distributed applications. I see protocol-based integration as the way to build interesting distributed applications. Service or distributed application behaviour is exposed only through the well-defined protocols (i.e. complex message exchange patterns) that are put in place.
Fundamental to MEST is the concept of message transfer (hence the name) between services. We observed that due to the popularity of the procedural and object-oriented programming paradigms people were more comfortable with the procedure call or method invocation abstraction respectively. The semantics of making a procedure/method call, a request-response pattern of interaction, are familiar to everyone. While the concept of a message and an event has been around for a long time, we have been used to building applications (distributed or not) using the ‘call’ abstraction. Remoteness is very often hidden by tooling (e.g. RPC, CORBA stubs, wsdl.exe, WSDL2Java, etc.).
So, we recognised the simplicity of the REST architectural principles for resource-oriented architectures and we wondered whether we could come up with a set of architectural principles for designing and building service-oriented applications (perhaps using Web Services technologies). That’s how MEST came into life. It turned out that MEST was even simpler than REST, with even fewer assumptions about what is available underneath our distributed applications. The goal was to describe an underlying architecture with uniform semantics that we could all use as a common baseline for our architecture-related discussions. Is MEST an application protocol? No, because MEST is not a protocol, in the same way that REST is not a protocol. Does MEST care about the difference between transport/application protocols? Not really since the transfer of a message and its processing is the only truth.
In MEST, we see a service-oriented application as a collection of services that interact through the exchange of messages. The messages can be grouped into interesting message exchange patterns or protocols. But, how is communication achieved? We need to define the semantics of how a message is transferred from one service to the other. This is where the ProcessMessage() operation is needed.
We wanted to use people’s familiarity with the concept of a ‘call’, ‘method’, ‘operation’ (see WSDL) to describe the semantics of what ‘message transfer’ meant. So, we combined the concept of a one-way message and the implicit request to process that message (extract the content and do something with it) into a logical operation called ProcessMessage. We thought that if people wanted to describe distributed applications in terms of operations, we could give them one but define its semantics in such a way that we can get what we want: one-way messages.
In traditional remote procedure calls or remote method invocations we always have request-response semantics, even if no result is expected (i.e. ‘void’). This is because of the semantics of the ‘call’ abstraction (see also “Building blocks of architectural paradigms”)… knowledge of the ‘end of execution’ is communicated back. It’s the communication of this information that is modelled out of ProcessMessage. A request-response pattern will have to be modelled explicitly in a service-oriented architecture. We only describe the architecture of a distributed application in terms of one-way messages.
We never suggested that there is a big revelation, something deeply fundamental behind all the above. Message queuing systems allowed you to reason in terms of one-way messages. Service-bus architectures are doing exactly the same. Event-based programming models are built around the same concept. Our intention behind MEST is to use terminology familiar to the REST camp to describe the service-oriented architectures and provide an architectural framework for those building Web Services applications.
What does MEST say about the difference between transport/application protocols? Well, since MEST is only interested in the transfer of a message and creates an isolation layer between what exists underneath and the application above, any differences are irrelevant. Application protocols like HTTP are used to implement the semantics of MEST but their semantics are irrelevant to MEST. The ProcessMessage logical operation would be implemented by using HTTP POST, SMTP DATA, FTP PUT, TCP send/receive(), etc. The semantics of these operations are orthogonal to the semantics of ProcessMessage. For example, the request/response nature of HTTP POST does not have any effect on how we reason at a higher level, above MEST, about the transfer of a message. The message is still one-way. How the implementation is going to use the HTTP POST response is of no consequence to MEST. HTTP POST is only used for the implementation and is completely hidden from our architecture. Please, note that all this doesn’t mean that, for example, we have one WSDL operation called ProcessMessage as some have suggested to me. That’s definitely not the case.
To conclude:
We would like to see MEST become for service-orientation and Web Services what REST is for resource-orientation and the Web.
I hope I haven’t confused matters even more 🙂
See "BrainExpanded - Introduction" for context on this post. Notes and links Over the years,…
This is the first post, in what I think is going to be a series,…
Back in February, I shared the results of some initial experimentation with a digital twin.…
I am embarking on a side project that involves memory and multimodal understanding for an…
I was in Toronto, Canada. I'm on the flight back home now. The trip was…