World Wide Webber


My Books
REST in Practice: Hypermedia and Systems Architecture
Now available on Rough Cuts
Developing Enterprise Web Services by Sandeep Chatterjee and Jim Webber
Amazon:
US, UK, Canada, Germany, France
Now available: Korean Edition

My Bookshelf
Programming Clojure by Stuart Halloway

RESTful Web Services by Leonard Richardson and Sam Ruby
REST/MEST Same, Same but Different
Posted: 16 April 2005 @ 08:19 UT from Sydney, Australia

Mark's comment to my last post got me thinking about REST and MEST again*. Let's set a couple of things straight here:

  1. REST - Maintains that the distributed hypermedia model as exemplified by the WWW is the key architecture for creating loosely coupled distributed systems. Resources with uniform addressing and interfaces form the key software artefacts in RESTful systems. Resources and their uniform interfaces are exposed to the application level and this model permeates the whole stack. The application understands that the way in which a resource is accessed is semantically significant.
  2. 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.

Both of these are valid architectural styles for Internet-scale computing, and share a common philosophy insofar as they both look to promote sensible architectural constraints for systems. Now, I happen so subscribe to the MESTian view since I like the transport agnosticism that SOAP provides, and I believe that the SOAP processing model is quite suitable for Internet scale computing. Mark conversely subscribes to the RESTifarian viewpoint and points to the Web as a good example of a scalable, extensible, RESTful system.

There's no animosity between these two camps (I think), and indeed MEST owes much to REST. But as Bill and DaveOnote, there is animosity between the REST and Web Services camps. OK, so it used to really nark me when the REST camp got on its high horse but through that needling I came to realise that Web Services was indeed in a pretty poor state (and WSDL 2.0 does little to help). Nonetheless it doesn't mean that you have to be a RESTifarian if you don't like the patterns and practices coming out of some parts of the WS community, you too can become a MESTian.

[*] I was going for a run at the time, so this whole post might just be the result of my brain being jiggled up-and-down for an hour. Just so you know...

Comments:
#
Ok Jim, I agree with most of the above - the value of hypermedia, the SOAP processing model, etc.. - but I suppose it always seems to come back to interface constraints, since I believe they are *mandatory* for Internet scale services. I don't see anything above, nor in Kenny's document, that suggests that an interface constraint was in effect for what you suggested was MEST-inspired. But I've always understood from you and Savas that it was, the so-called "ProcessThis" semantic. I assume Indigo supports wsa:Action, which is, at least on request messages, the "operation" in the IDL-sense of the word. So unless its value is constrained to always be "http://example.org/op/ProcessThis" on requests, I don't see how what Kenny described can be MESTful. Damn, just when I thought we were in synch!! 8-O So, does MEST adopt an interface constraint, or not? P.S. "Use the SOAP processing model" wouldn't make for a very good architectural constraint IMO, since it's not specific about how that relates to the relationships betweeen components, connectors, and data, and a specific technology too (architectural styles are best described independent of any specific technology - imagine if "Pipe and Filter" were defined to only use BER?! 8-). I think what you want to say is that MEST adopts the layered constraint, since the SOAP processing model is highly layered. I think you probably also want self-description.
#
Mark, you're right. I just forgot that I always set wsa:action (where I have to) to be urn:process:message or leave it out where I can. So if I apply MEST constraints to Indigo, it's a MEST platform :-) Jim
#
Awesome, Jim. So back to your comments about Kenny's post; I agree that you can use Indigo in this way, but Indigo itself doesn't constrain you to using MEST, so therefore I wouldn't have called it "MESTful", anymore than I'd call some wood and nails a house.
#
OK Mark, you're sort of right again. Indigo is MEST-amenable in the same way that WSE 2.0 is MEST-amenable and in the same way that JAX-RPC is NOT MEST-amenable. Of course I can use the Web in a non-RESTful way so nah nah nah nah :-) Jim
#
Who mentioned the Web? 8-)
Trackbacks:
-
It's been some time since I last blogged. Partially this is down to a lot of work and travel in China working with some very interesting clients on large-scale Web Services applications. Needless to say the MESTian philosophy prevails in those engagem...
-
Savas and I have a paper in Microsoft Architect Journal 5 on Web Services and High-Performance computing. Plenty of MESTian goodness and not a single mention of the dreaded WS-RF either.Coincidentally my buddies Anna and Ian also have a paper on evalu...
-
The ACS Web Services SIG is heading into its spring session, continuing with a talk I'm giving on SSDL on the 7th September.I haven't been able to get to many meetings this winter (yes - it's winter down here, not that you'd know it with Sydney being ...
-
It's been a while since we've had a good old-fashioned dust-up from the Web Services suck pantomime (hint: oh no they don't). Mark (who else?) writes:The concept of a "SOAP binding" is prima facie broken because it necessarily requires treating underl...
-
I caught up (physically) with Mark Potts (where's your blog gone?) for the first time in about three years last night. We had some fine Italian food down on Stanley Street and a few beers while talking about all things Web Services and (of course) sys...
Author Name:
Email:
Author URL:
Comment:
Antispam:
Please type the following string (note that if the strings don't match, your comment will be lost... sorry!): 'QQAX'.
 
Recent entries

Recent comments

Feeds:
RSS 2.0 Atom