- From: Mark Baker <distobj@acm.org>
- Date: Tue, 11 Nov 2003 09:04:45 -0500
- To: public-ws-chor@w3.org
> Again, however, the core > argument seems to be that you can do RESTifarian choreography, and at worst > a choreography language doesn't add much. Further standardization for RESTful choreography *is* necessary, just not a whole lot of it, because REST already defines an application model. As Web services don't define an application model, I can understand why solutions in this space are so complex in comparison. > I personally disagree; without a > choreography language, how does the "engine" know how to perform a > particular sequence of GET/PUT/POST/DELETEs? Because of the implicit nature of the uniform semantics, much sequencing is performed simply by the successive exposure of URIs. e.g. GET on uri1 will return a document with a link to uri2, and a GET on that will return a link to uri3, etc... If you combine that with link metadata, then it can be generalized for other operations, e.g. GET on uri1 returns; <post-document-here accept-type="application/foobar+xml" href="uri2"/> And a POST to uri2 might return; <PurchaseOrder href="uri3"/> etc.. The value of implicit operations here can't be overstated. It permits a "choreography" to be declared as a state machine, as I did in that example, where clients are exposed only to the states of the state machine that they can discover. In other words, there's no need to share a description of the choreography up front, as it's discovered dynamically. When combined with statelessness, it also permits Web site admins to delegate parts of their application model by integrating with somebody else's, for example, to permit a third party to manage payment services. As the Web site has no dependency on the specifics of the state machine of the service provider, integration consists primarily of substituting their payment service URI for the third party payment service URI. That's not really telling anybody anything they couldn't observe just by ordering a book on Amazon. But knowing it can be automated might be valuable to the WG. Mark. -- Mark Baker. Ottawa, Ontario, CANADA. http://www.markbaker.ca
Received on Tuesday, 11 November 2003 09:02:51 UTC