Does SOA need MEST on top of REST? |
 |
By Rich Seeley, News Writer
10 Sep 2007 | SearchWebServices.com |
|
|
From the people who brought you Guerrilla SOA comes Message Exchange State Transfer (MEST) to compete for service-oriented architecture (SOA) developers' attention with Representation State Transfer (REST) and good old SOAP.
|
|
|
|
|
SOA does not, and never has, required a particular communications paradigm or technology stack.
Neil Ward-Dutton
Research Director, Macehiter Ward-Dutton
|
|
|
|
|
|
|
|
|
|
MEST is how Guerrilla SOA will get done, according to Jim Webber, Ph.D., SOA practice lead for the ThoughtWorks Inc., the leading proponent of the guerrilla approach. Meanwhile, Savas Parastatidis, MSc., PhD. and technical computing architect at Microsoft, has written a definition of MEST that also compares and contrasts it with REST.
Parastatidis sees REST as being primarily about resources at the end of URLs where MEST would be the paradigm for the basic message in a business applications, such as an invoice requiring an action in a basic accounting system.
"We would like to see MEST become for service-orientation and Web Services what REST is for resource-orientation and the Web," writes Parastatidis.
Tony Baer, principal analyst at onStrategies, noted that REST and MEST are closely related. MEST "applies RESTful-like approaches," which "are used for requesting data, in place of more complex SOAP messages" in SOA message exchanges, he said.
Joe McKendrick, analyst for Evans Data Corp., in his ZDNet blog translated Webber's view of MEST this way: "In MEST, Jim explained, a message will contain two things: the business payload (purchase orders, invoices, etc.) and the metadata that contains the processing context for the payload. 'The MEST idea is that I'm delivering you a message. You're going to set the context of processing that message, examine that message, and process that message. End of story.' "
Well, not quite the end of the story because in SOA, as in life, every story has at least two sides.
Neil Ward-Dutton, research director, Macehiter Ward-Dutton, wonders why SOA needs another acronym for the basic message transfer concept, which has been around since IBM invented MQSeries.
"It's nothing new," Ward-Dutton argues. "Ask IBM re: what used to be called MQ Series, has been around since the 1980s and certainly doesn't need a new acronym. Not rocket science. SOA does not, and never has, required a particular communications paradigm or technology stack."
Perhaps anticipating such a critique, Parastatidis in his definition acknowledged that MEST is not "a big revelation."
"Message queuing systems allowed you to reason in terms of one-way messages," he writes. "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."
In explaining the basics of MEST, Parastatidis lists four key points:
- MEST is not an application protocol in the same way that REST is not one either;
- It is based on the transfer of a message and the processing of the contents of that message in application-specific ways;
- The behavior of what happens with the contents of a message is defined through protocols (description of complex message-exchange patterns);
- MEST attempts to describe service-oriented architectures in terms of services and messages and a set of architectural principles.
Will MEST be the next big buzz word in SOA? Stay tuned.
|
|
|
|
