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


Help: OASIS Mailing Lists Help | MarkMail Help



   RE: [xml-dev] XML "tuple spaces" alpha technology demonstrated

[ Lists Home | Date Index | Thread Index ]

> -----Original Message-----
> From: Gavin Thomas Nicol [mailto:gtn@rbii.com]
> Sent: Wednesday, December 26, 2001 11:44 PM
> To: Champion, Mike; xml-dev@lists.xml.org
> Subject: Re: [xml-dev] XML "tuple spaces" alpha technology 
> demonstrated
> I'm not sure what the real value is 
> though... how do you  imagine such spaces being used? Perhaps for service
lookup in 
> web service  registries?

XML "spaces" are conceptually a shared memory between two (or more)
applications separated by time and/or space, thus precluding a synchronous
data exchange.  A web service *registry* is more permanent, so is well
handled by conventional web and database technologies.  A web service
*invocation* is what I imagine XML spaces  being used for.  

Let's say I'm in a car or on a train somewhere, and need to make a hotel
reservation via my Palm, cellphone, or whatever.  This being a multi-part
transaction -- the reservation service needs to find me a hotel with an
empty room, look up my credit card from whatever authenticated identity I
used in the reservation, then validate the credit information -- it may take
some time to complete.  In that time, I may well have lost the connection to
the cellphone network, a server might have crashed, or any number of the
numerous ways in which Murphy's Law gets enforced might occur.  Thus, an
RPC-style web service invocation would be somewhere between unreliable and
impossible. If, however, the various parties to the transaction exchange
data via XML "spaces", various things simply work better or more easily.
Security is enhanced, since I'm not just sending confidential information
around the Web and hoping that it is protected; I'm writing it into a
"space" that only allows authorized agents to read from it.  Error recovery
is much simpler; each party to the transaction simply does one read or one
write, which either succeeds or fails.  If it fails, it retries later, no
2-phase commits over heterogeneous databases and unreliable connections to
handle somehow. Similarly, you don't have to deal with SOAP intermediaries
(one of the most difficult and contentious parts of that protocol), every
party to the transaction is communicating directly with the "space".

To be perfectly honest, I haven't decided for myself whether this is simply
a design pattern for using XML databases and/or WebDAV servers in the "2 way
web" or if it is a distinct layer on top of either.  The RogueWave people
(who have actually implemented an XML space!) tell me it's not as trivial as
it first looks.  The Linda-esqe coordination protocol needs to be
implemented, and the real-time authentication/authorization/encryption
issues are non-trivial even on top of a "real" DBMS.  I'm inclined to think
that a proof of concept implementation on top of WebDAV or an NXDB would be
trivial, but that an industrial strength application would benefit from
Ruple, JXTA-spaces, or whatever.


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS