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

[Bill de hOra <bdehora@interx.com>]

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

You're spot on. Similar arguments can be made for WebDAV metadata; I
believe this is the sensible way to access and publish RDF data on the
web.

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

It's too simple dude. Middleware and distributed computing needs to be
complex and arcane. 

More seriously, coordination languages have a different history. They
come from parallel computing. Distributed objects as the name implies
comes from object oriented serial computing: RPC is all about faking a
single process on a network, however brittle and self defeating that
might seem. Most technical people I know were reared on serial computing
so RPC has better purchase for them. People tend to adopt extensions of
what they know despite the effects on their mental health :)

Check out www.crudlets.org for what you can achieve in a middleware
scenario without the morass of distributed object middleware :)

>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 think when you come to appreciate coordination languages (like Linda)
or multi-agent technology (where nodes can come in and off the network
dynamically and communicate using messages) and their combinations, it's
difficult to take RPC seriously for open networks. RPC has too much
baggage and is too brittle. But it is hard to sell anything else to
people; yet it does have its uses. Message oriented middleware like JMS
and MQSeries are a nice middle ground as are event driven pub/sub
systems, they lets people get stuck into asynchronicity and parallelism
in a gentle way. Nonetheless it must be pointed out that while
operations on tuplespaces are parallel and conceptually simple,
distributing and federating tuplespaces requires more thought as does
making them efficient when the communications overhead is high.

regards,
Bill de hÓra

--
InterX 
bdehora at interx.com 
dehora at acm.org 
+44(0)20-8817-4039 
www.interx.com