[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: Web Service: SOAP or {HTML + Servlets}?
> 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
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|