In a new article, Jim Webber, Savas Parastatidis and Ian Robinson show how to drive an application's flow through the use of hypermedia in a RESTful application, using the well-known example from Gregor Hohpe's Starbucks does not use Two-Phase-Commit" to illustrate how the Web's concepts can be used for integration purposes.
While many people have grasped the utility of REST for simple cases, the authors show how to get more value out of the REST core concepts, specifically the "hypermedia as the engine of application state" principle. They show how links, included within resource representations retrieved from the server, can enable the client to find out which possible transitions are available from a particular point in the overall application flow.
A really, really excellent article at InfoQ.
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 ;)