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

> -----Original Message-----
> From: Mark Baker [mailto:distobj@acm.org]
> Sent: Monday, July 01, 2002 11:39 AM
> To: Champion, Mike
> Cc: www-ws-arch@w3.org
> Subject: Re: SOAP and the Web (was RE: Late binding)
> 
> 
>  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.

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?

 
>  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 :~)

Received on Monday, 1 July 2002 11:57:16 UTC