RE: REST, Conversations and Reliability

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

Received on Friday, 19 July 2002 12:21:18 UTC