- From: Champion, Mike <Mike.Champion@SoftwareAG-USA.com>
- Date: Fri, 9 Aug 2002 14:10:29 -0600
- To: www-ws-arch@w3.org
> -----Original Message----- > From: Mark Baker [mailto:distobj@acm.org] > Sent: Friday, August 09, 2002 3:51 PM > To: Christopher B Ferris > Cc: www-ws-arch@w3.org > Subject: Re: Choreography and REST > > > I'd encourage you to take some time to consider exactly how you might > form a solution to this (or any other) problem within the > constraints of > REST. If, after you've done that, you've decided it isn't > suitable for > your needs, then by all means don't use it. [speaking as a WG member, not as a co-chair] I'm having a little trouble following what the Choreography proposal does or does not have to do with REST. It seems to be a declarative language for specifying, a priori, the message patterns required to implement a relatively complex set of web services transactions. It's layered on SOAP and WSDL, so to whatever extent SOAP and WSDL support REST, the Choreography proposal supports REST. Chris gave quite a clear explanation of why this kind of thing is useful. What have I missed up to this point? Paul Prescod seemed to be making a couple of points that I picked up on. First, the *implementation* of a "choreographed" web service could be done effectively with a shared "state" resource, perhaps analogous to a file handle in programming languages. Second, he seemed to be saying that one wouldn't need a special choreography language *if* one already had a RDF/DAML-based language for declaring the semantics of business processes. I think I agree ... but the trouble is we don't have such a thing, or at least the people making the Choreography submission (not to mention the BPEL4WS folks!) don't seem to believe we do. I found Paul's discussion of using REST principles to coordinate multi-part web services quite persuasive, but the rest of his (and this) discussion seems to be more about specialized choreography/coordination languages vs generalized semantic description languages, not about REST per se. Again, have I missed some important point?
Received on Friday, 9 August 2002 16:11:03 UTC