RE: [xml-dev] Web Service: SOAP or {HTML + Servlets}?

["Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>]

> -----Original Message-----
> From: Francis Norton [mailto:francis@redrice.com]
> Sent: Wednesday, October 10, 2001 6:51 AM
> To: Roger L. Costello
> Cc: xml-dev@lists.xml.org
> Subject: Re: [xml-dev] Web Service: SOAP or {HTML + Servlets}?
> 
 
> I agree with you preference for document-based transactions over
> parameter-based transactions (in my darker moments I tend to 
> mutter that those who push parameter-based SOAP 
> "just don't get it").

I think I agree: SOAP is a wire format, not a "protocol" --  SOAP 1.2 is not
an acronym, and explicitly separates out RPC as a use case -- so it should
be useful for document-based transactions as well as RPC. 

I've seen very little discussion of what seems to be like an alternative
paradigm to RPC for "document-based transactions" : Tuple Spaces / TSpaces /
JavaSpaces / XML Spaces. See
http://www.almaden.ibm.com/cs/TSpaces/: 
http://www.sun.com/jini/specs/jini1.1html/js-title.html
http://uncled.oit.unc.edu/XML/XMLSpaces.html 
http://www.acm.org/conferences/sac/sac00/Proceed/FinalPapers/CM-41/ 

Sun's document probably states the basic approach most clearly: 

"Many distributed algorithms can be modeled as a flow of objects between
participants. This is different from the traditional way of approaching
distributed computing, which is to create method-invocation-style protocols
between participants. In this architecture's "flow of objects" approach,
protocols are based on the movement of objects into and out of
implementations of JavaSpaces technology." 

Change "object" to "SOAP messages" and "JavaSpaces technology" to "temporary
XML repositories" and that's pretty much what I see as the document-based
transaction alternative.  

This seems like a better architecture for multi-way "web service"
transactions over unreliable connections (e.g., to mobile devices) than RPC.
Why does this idea have so little mindshare?  Am I missing something here,
or might this be the Next Big Thing after the limitations of RPC in a
high-latency, unreliable networking environment become obvious?