Re: SOAP and the Web (was RE: Late binding)

Mike,

On Mon, Jul 01, 2002 at 09:56:41AM -0600, Champion, Mike wrote:
> >  HTTP GET.  It can't carry SOAP envelopes or headers. 
> 
> In PRINCIPLE, the URI could encode the SOAP headers [yes, I 
> know about the holy principle of opaqueness but I don't buy it ...
> so burn me as a heretic!] XMLP also discussed other mechanisms
> of using SOAP with GET, and deferred them (to WSA and WSD)
> for analysis/standardization.  This may not prove to be 
> practical, but it isn't an a priori show-stopper IMHO.

Yes, David Orchard and Tim Bray started down this path.  There are many
issues with it, but something useful could emerge, I agree.  But I don't
see it being anything approaching a general solution, which IMO the
Web services architecture needs, especially when you look at the
complexity of header structures used by specs like WS-Security.

> Anyway, this says more about the limitations of GET than
> SOAP, nicht war?  <grin>  One alternative is obviously POST ...
> but seriously, what is the RESTically correct aproach to the
> transaction/reliability/security/etc. problem? Multiple
> PUT/GETs to establish a shared context within which to interpret
> messages and transaction/transmission state?

Sorta. 8-)

I like to call "GET" the principle reliability feature of REST, because
it allows a client to receive a reliable view of the state of some
remote resource.  If the GET fails, you don't need an elaborate
reliable messaging mechanism to queue the GET and keep retrying - you
just invoke it again!

Of course, GET doesn't solve all your reliability problems, but it
does solve many, and it also demonstrates that you don't need reliable
messaging because not all HTTP messages need to be reliably received
(specifically, no idempotent messages do, because you can just reinvoke
them if they fail).  All you need to do is to build an extension to make
an idempotent version of POST, which is trivial (if you start with RFC
2774, or SOAP).

> >  For example, see HTTPR as
> > a proposed solution for reliability.  It completely disregards the
> > state transfer based architecture of the Web, and as a result, is a
> > really poor solution for it.
> 
> Could someone elaborate on this statement?  I have no opinion on HTTPR one
> way or
> the other at the moment ... I understand the desire of the MS and IBM people
> to guarantee reliability in the infrastructure (either via SOAP-based
> protocols or
> HTTPR) rather than having each application have to deal with it.  Isn't
> this just abstracting the "transfer" part away from the application so that
> it can deal with resources and their state without continually checking to 
> see if the last message got through?  Again, what's the RESTically correct
> approach here?  If it is "learn to stop worrying and love the intrinsic
> unreliability of the Web," I'm not sure if you will win many friends in the
> web services community :~)

It's actually not far from "learn to love intrinsic unreliability", in
that unreliability is exposed to the developer.  This is a good thing,
as Jim Waldo et al discussed here;

http://research.sun.com/techrep/1994/abstract-29.html

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@acm.org
http://www.markbaker.ca        http://www.idokorro.com

Received on Monday, 1 July 2002 15:13:18 UTC