[
Lists Home |
Date Index |
Thread Index
]
Mike,
> I think of the various XML spaces as being at the layer above SOAP -- they
> provide an additional layer of services that doesn't come for free in HTTP
> or SOAP,
How do they not come for free in HTTP? HTTP is an extensible services
layer. Some of its existing methods are replacements for coordination
semantics such as those provided by Linda, plus it's extensible so that
new semantics can be added.
But I agree that with SOAP, you're starting with nothing unless you're
using it in a way that leverages this capability of HTTP (which, as you
know, I've been a staunch supporter of in the XML Protocol WG).
> and a Linda-like coordination protocol would have about the same
> architectural relationship to SOAP as RPC has.
>
> Specifically, the various
> "spaces" implementations offer the basic read/GET and write/PUT operations
> that HTTP does, but also:
>
> - "take" (GET and DELETE in an atomic operation),
Sure. So why not define an HTTP "TAKE" method rather than trying to use
POST (via SOAP) to mean take? POST has a very specific meaning ("accept
as a subordinate"), and trying to change it to mean something else is
not a good idea for many reasons, especially when HTTP already provides
a means for defining new application semantics (a new method).
> - associative lookup (XML databases such as Tamino do this with XPath on top
> of HTTP, but it's not part of HTTP or WebDAV at present)
> - "leases" (automatic cleanup of entries that nobody "takes" after a
> specified period of time)
> - security (Ruple adds digital signature support for encryption an
> non-repudiability).
>
>
> Wouldn't using raw HTTP as the coordination protocol require some more
> sophisticated application-level logic to provide analogous services?
It depends what you're coordinating. HTTP, through the coordination
methods defined in RFC 2616 (GET, PUT, POST, DELETE), currently
coordinates the management of a consistent view of resource state over
a network. This is a very general model; even tuple spaces can be seen
as a special case.
> As
> Gavin has noted, this is not easy for ordinary developers to grok, so a
> "spaces" service layer on top of HTTP makes sense to me.
I'm suggesting that doing it "beside" HTTP makes better sense than doing
it "on top of".
MB
--
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA. mbaker@planetfred.com
http://www.markbaker.ca http://www.planetfred.com
|
