RE: REST, Conversations and Reliability

Hi,

At the risk of flooding everyone's inboxes yet again on this topic, I want to say that this is one of the best summaries of the problem I've seen, and I agree with the suggestions within it on how best to proceed.

I have often heard it said that Web services are "CORBA for the Web."  As a representative of the "CORBA company" this is a tempting concept to fully endorse.  I also expect that someone from a "REST company" (if there is such a thing) is tempted to fully endorse the concept that Web services are best implemented using existing Web technologies.  The truth, as I've been saying for a while now, seems clearly in the middle.

For example, CORBA over the Web doesn't work because IIOP doesn't exist over the Internet. There are reasons for this, having to do with the REST concepts that drove the success of HTTP.  Fundamentally, CORBA concepts have to be re-designed to work with HTTP.  At least that's one way of looking at things, from the CORBA perspective.  The Web doesn't have IIOP, it does have HTTP, so OMA has to be adapted and changed to reflect this reality.

Similarly, REST doesn't include many of the concepts and services defined within OMA, and SOAP and WSDL already exist.  REST has to be adapted and changed to reflect this reality.

Using a GET to obtain a WSDL file on which to base a SOAP message sent via POST is a convention that many Web services toolkits successfully use.  It doesn't matter whether or not this violates REST, except to the extent that it becomes a practical matter.

Many of the REST folks correctly point out that Web services as defined won't scale as well as current Web hypertext usage.  However, this avoids the very real question of whether they have to.  Web services are based on a different usage model, and it might very well be the case that private agreement among Web services publishers and consumers is sufficient -- Web services may not have to scale to the entire Web to be successful, as Web page publication does.  

These are the things we need to figure out to create a successful Web services architecture, which in my mind also is one of the most important next steps in Web services evolution.  

As a last point, I'd say that Web services are still evolving.  The market is in a bit of a backlash against them at the moment, since they were over-hyped.  And it's therefore not entirely clear where Web services are going, or how they will evolve.  The "killer app" has yet to appear.  So I believe we have to be open to change as well as to compromise as our work progresses.  In this spirit I think it will help us to get a draft out soon, even if it might be controversial, and even if everyone on the WG is not able to completely agree.

Eric

-----Original Message-----
From: Jeff Mischkinsky [mailto:jeff.mischkinsky@oracle.com]
Sent: Saturday, July 20, 2002 8:21 PM
To: David W. Levine; Champion, Mike; www-ws-arch@w3.org
Subject: 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 Sunday, 21 July 2002 10:44:56 UTC