RE: REST, Conversations and Reliability

+1
   jeff
At 09:20 AM 7/19/02, David W. Levine wrote:

>At 12:24 AM 7/18/2002 -0400, Champion, Mike wrote:
>
>
>
>> > -----Original Message-----
>> > From: Burdett, David [mailto:david.burdett@commerceone.com]
>> > Sent: Wednesday, July 17, 2002 10:07 PM
>> > To: 'Paul Prescod'; David Orchard; www-ws-arch@w3.org
>> > Subject: RE: REST, Conversations and Reliability
>> >
>> >
>> >
>> > Chris, as chair, is it possible for a vote to be taken to
>> > determine whether
>> > we base our architecture on SOAP or base it on REST?
>>
>>We would be doing the industry a dis-service to frame it that way.  Clearly
>>SOAP 1.2 has learned a lot from REST.    On the other hand, REST will not
>>make an impact until it has the kind of tool and vendor support that SOAP
>>has, and the best way to do that is probably to leverage SOAP as much as
>>possible.
>>
>>Our challenge --which is a big one, but we KNEW that when we signed up for
>>the job, eh? -- is to describe a set of architectural components and
>>relationships that learn from the SOAP world of program-to-program
>>communication and the Web world of robust and scaleable hypertext.
>>
>>Paul Prescod talked about starting with a SOAPy orchestration framework aand
>>having it "enhanced by applying some REST discipline."  That's the spirit we
>>need here in order to succeed. I honestly haven't looked at either the BEA
>>framework or Paul's critique well enough to have a substantive opinion, but
>>I like the idea of "enhancing" one perspective with the discipline of the
>>other.  "Enhancing" the Web with SOAP-based reliabilty, transaction,
>>orchestration, description, etc. might be another way to envision the way
>>forward.
>>
>>It seems clear that the industry won't accept a WSA that doesn't  leverage
>>SOAP, and the W3C staff/director/TAG clearly won't accept a WSA that doesn't
>>build on the Web.  We have to collectively un-think the thought of one or
>>the other winning, and visualize how they can enhance each other.
>>
>>Sorry if this sounds like the drivel on those motivational posters one sees
>>in most offices these days, but that's the simple reality as I see it!
>
>
>I've been following this discussion from a distance, and I think that this 
>set of comments
>really is important. There are several key observations here that I'd like 
>to poke at and
>in some cases amplify.
>
>One major task which the W3C has to get right, if it intends to matter in 
>the standardization
>of web services is the rationalization of the various best practices from 
>several rather diverse
>communities. SOAP isn't going away, it will certainly evolve, but it is at 
>the heart of too many
>key sets of tooling from too many vendors, and it solves enough real world 
>problems that it isn't
>going to be made to simply vanish. At the same time, REST, in many ways, 
>is a distillation of many
>of the key attributes that have helped the web succeed and thrive since 
>its early days. There isn't
>a simple one to one correspondence between the problems that the web set 
>out to solve and the
>problems that the web-services architecture work tries to solve, but 
>there's a huge overlap, and we
>would be foolish to ignore REST. Take it as gospel, no, but using it as a 
>useful tool when trying to
>chose between various alternatives, absolutely.
>
>A lot of recent messages have been asserting in various ways that OMA 
>isn't the right model for
>web services. I think, as in many things, its important to realize that 
>OMA as a catchphrase
>covers a multitude of different underlying bits of work. The OMG spent a 
>lot of energy on OMA,
>and it shows. But... and this is important. There's good, bad, and 
>downright ugly mixed together
>in that OMA model. Simply treating OMA and related concepts as one large 
>blob that one has to
>swallow hole, or reject hole isn't constructive. Pointing out specific 
>parts of the OMA world that
>look problematic is a far more useful model. Finding the synthesis points, 
>where changes to the
>OMA model, or changes in how one approaches REST to better solve some of 
>these problems
>would strike me as far more likely to lead to genuine progress.
>
>This leads directly to a very specific technical point, which I think 
>sometimes gets misplaced in
>all the various discussions which tie things to specific models. Much of 
>the essence of invoking
>a service over the web is identical, no matter which model is used. At the 
>end of the day, a chunk
>of code on machine A goes through a set of interfaces, which causes some 
>bits to flow to
>machine B. Those bits get picked up, looked at, and eventually, if they 
>are consistent with the
>services available on machine B, some code is invoked, the bits get 
>further examined, arbitrary
>processing occurs and some response is generated, which gets back to 
>machine A.
>This happens whether the programs are using pure HTTP GET, SOAP 1.x, pure 
>OMG, sun RPC, or a
>handcrafted protocol on top of sockets. In that sense, all of this becomes 
>a remote procedure invocation,
>at some level. The devil is in the details. The challenge is not to say 
>"this is blanket bad" but rather
>to say "this specific behavior is brittle in the following ways." or "This 
>could be better if we allowed X to
>occur as well as Y."
>
>As one final example, it was pointed out that returning WSDL as a response 
>to an HTTP get on a
>SOAP URI is undesirable because it doesn't directly map to REST. The 
>underlying question is
>in what specific ways is this undesirable, and how can the desired effect 
>be achieved. Simply saying it
>doesn't conform to REST doesn't allow for a deeper discussion of why the 
>current best practice is to
>return the WSDL, and why that is undesirable. If we want to get a nice 
>synthesis between approaches,
>we have to look at those underlying issues, and address them.
>
>- David W. Levine
>
>
>
>
>
>

--
Jeff Mischkinsky                    jeff.mischkinsky@oracle.com
Consulting Member Technical Staff   +1(650)506-1975 (voice)
Oracle Corporation                  +1(650)506-7225 (fax)
400 Oracle Parkway, M/S 4OP960
Redwood Shores, CA 94065 USA

Received on Saturday, 20 July 2002 20:18:56 UTC