Bill de h ra made a comment on Stefan Tilkov‘s post about our “How to GET a Cup of Coffee” article…

Q205: “I feel that I have learned a lot from the discussions with the REST folks and together with Jim we hope to move that understanding forward to service-oriented computing with our upcoming MEST paper.” http://savas.parastatidis.name/2005/03/12/505b74f7-d5d3-4b94-95d4-65129ce2bf2b.aspx

Q205: “MEST – Embraces the SOAP processing model as its fundamental architectural constraint. The SOAP processing model is prevalent throughout the architecture of applications built using this style. SOAP messages flow from sender through intermediates to ultimate recipients which are applications. Applications deal with SOAP messages as a first-class constructs and are utterly agnostic about how messages are transported from semantic viewpoint.” http://jim.webber.name/2005/04/16/26e0bdcf-65de-4cce-9c0b-1f35bc43620e.aspx

Q308: “In fact, we’ll show how Web techniques can be used with all the dependability associated with traditional EAI tools, and how the Web is much more than XML messaging over a request/response protocol”

What happened to MEST and “processThis”? And why doesn’t the example use SOAP? I think if we’re going to be looking to experts for guidance, some rationale on an architectural shift would be good to see 😉

Jim posted a reply with his view. Here are mine…

As far as I am concerned, the main ideas around MEST, especially the concepts of message-orientation, multi one-message-based  interactions, declarative distributed computing, luck of directly bindable state, etc. still thrive when building large-scale distributed applications (at least some mixture of them :-). Just have a look at how Amazon, Google, Microsoft, etc. build their 100s-of-thousands-of-nodes infrastructure and services. The goal behind MEST, an architectural style like REST, was to capture the architectural tenets of service-oriented distributed systems that concentrated on messages exchange. We used Web Services as the natural set of technologies to explain how those tenets could be realized. We even came up with SSDL to explain some of the thinking.

We really wanted to imitate REST‘s attempt to abstractly capture the architectural principles of the Web and HTTP, which focus on resources. Our “sandbox” at the time was full of services and messages and the ecosystem of Web Services technologies represented the “toolbox” available to us to demonstrate the ideas. We came up with “MEST” (MESsage Transfer) as a way to indicate REST‘s influence in our thinking.

Do I believe that the MEST ideas are still valid? Absolutely. Do I see the ideas taking off as part of an ubiquitous ecosystem of Web-Services-(i.e. SOAP-based)-supported technologies on the Internet? Most likely not. As Jim suggested, the middleware vendors have focused too much on hiding the message-oriented nature of the technologies behind object-oriented tooling, forgetting years of discussions around the issues related to hiding remoteness of operations (Waldo’s paper). The Web has emerged as the most attractive platform for application integration and hosting (perhaps until the next “big thing” 🙂

So, has there been an “architectural shift” as Bill suggests? I personally don’t feel that I have “shifted” as much as Jim has :-)[1] Has there been a clear winner in the technology space? Oh yes! The Web seems to rule.[2] So, how do we bring the MEST ideas of application conversations, state machines, declarative computing to the Web? How can we discuss about good practices and good use of the technology toolsets available to us?

As technologies I believe we need to monitor what is going on around us and provide ideas, feed the discussions, adapt. As I said in the past… provided we are informed, we should use the right tool for the right job. At this point in time, the focus is on the Web. I am sure something else will come up in the future.

If you notice carefully in this later article, the idea of conversation state is apparent throughout. There is an implicit state machine representing the possible steps during a particular conversation. Wouldn’t it be nice if we could declaratively describe such a state machine and return it as a resource? Wouldn’t it be nice if we could GET the series of available HTTP-based interactions with an endpoint in a way that is understood by our middleware platform? The article demonstrates how an application could be implemented but if we had a common language to describe the possible state transitions (e.g. “SSDL for the Web”), then we could further improve the development experience. Yes, the state machine description cannot be static and there is no reason it has to be. But I divert into deep technical thinking now 🙂

Architectural thinking evolves, adapts to the environment, makes use of the best tools, the best techniques, the best material. If it didn’t, we would have been still constructing pyramids (well, it seems that in Las Vegas they are still doing that :-). The same is true with software architecture. As Software Philosophers, we should never stop thinking, reason about the world, share our opinions and questions 🙂 So, keep it coming everyone.

Thanks Bill! It’s been a long time since I felt I wanted to blog about this topic 🙂

[1] Here’s where I disagree with Jim, which must be a first for us (at least in public since we disagree in private ALL THE TIME 🙂

[2] I admit that I thought SOAP, when used correctly, would become the basis for distributed applications on the Internet. I was wrong!