OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Mike Champion wrote:
> [...]
> 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.  

We can generalize even further and say that the tuples are arbitrary
documents--could be a SOAP message, a Purchase Order, anything.


> 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?  

I agree with your assessment. While an RPC paradigm is useful within an
enterprise, it makes less sense on the internet for the reasons you mention.
Further, point-to-point protocols are inherently less flexible and more
coupled than a network shared memory model. Tuple spaces offer a simple,
loosely coupled, asynchronous model that, in many ways, parallels the
minimalist architecture of the Web (as Mark Baker pointed out). Although
programmers may be more comfortable with an RPC paradigm within an
enterprise, interactions over the internet more naturally follow a document
exchange pattern. Web service RPCs will surely prove useful within an
enterprise, however, given security and connectivity concerns, they will be
less accomplished on the internet. There a tuple spaces model holds more
promise.

Rogue Wave has direct experience of this. We created an XML tuple space
implementation as the basis of a bid-ask marketplace (an e-procurement
application). It worked beautifully. We found the simplicity, time/space
decoupling, and multicast-like quality of the tuple spaces model ideal for
document-centric interactions over the internet. 

-Patrick


---
Patrick Thompson
Rogue Wave Software, Inc.
thompson@roguewave.com