In my previous post, I reported that the REST approach to web services, while largely equivalent to the XML/SOAP/WSDL/UDDI approach, differs from it in that it trades many SOAP messages for many URIs. REST advocates claim that the advantages of this approach are: a set of REST requests can be spread across many servers, which means that REST services are scalable; that REST obviates the need for special service discovery mechanisms like UDDI; that REST supports server side caching; and that less specific client side software is needed: one browser can access any REST service.
One large part of the debate in the web services community over SOAP vs REST has to do with business process choreography [1, p. 2] (more typically called workflow): coordination of long running business processes over many services and potentially more than one organization. A standard way of conducting choreography is critical because the complexity of coordinating API and data format specifications among many entities quickly becomes unruly.
Imagine that there is a a complicated action which requires many services or service components to be invoked in a particular order, such as placing an order and receiving an order confirmation.
In the REST paradigm, the initial requestor of the service is stepped through the complicated process by the REST server, which includes the URI for the next sub-task of the action in the response from the last sub-task. The REST server publishes a well-known starting URI to which the initial requestor first goes. HTTP GETing from this URI causes the process to start on the server side -- a context is set up on the server for the initial requestor -- and the REST server responds with the URI of the first sub-task. The initial requestor then HTTP POSTs its request to that URI, and the REST server responds appropriately, and includes the URI of the next sub-task in that response, and so on until the action is complete. It looks something like this:
Coordination of the XML syntax of the messages passed between requestor and REST server must be negotiated beforehand.
In the SOAP paradigm, the SOAP server presents a single URI facade to the initial requestor, through which all communications travel (this facade is itself a web service, and Erl calls it an orchestration [2, p. 364]). Choreography is handled via message types as defined by the WSDL records for the action. The SOAP server publishes a WSDL record for a BPEL4WS process which describes the different message types it will accept, and their syntax. The initial requestor interacts with the orchestration service via SOAP messages, and what message it will send next is dictated by the orchestration service.
The BPEL4WS web services orchestration language is one of the primary choreography mechanisms for SOAP/WSDL/UDDI based web services. It depends on the WS-Coordination and WS-Transaction standards to do its work.
References
; ; ; "Developing web services choreography standards: the case of REST vs. SOAP", Decis. Support Syst., Vol. 40, No. 1 (2005) pp. 9-29.
; Service-Oriented Architecture : Concepts, Technology, and Design, Prentice Hall, (2005).