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

["Champion, Mike" <Mike.Champion@SoftwareAG-USA.com>]

> -----Original Message-----
> From: Mark Baker [mailto:distobj@acm.org]
> Sent: Wednesday, October 10, 2001 9:31 AM
> To: Mike.Champion@SoftwareAG-USA.com
> Cc: xml-dev@lists.xml.org
> Subject: Re: [xml-dev] Web Service: SOAP or {HTML + Servlets}?
> 
 
> 
> The choice to deprecate the expansion of the acronym didn't 
> have anything
> to do with SOAP not being a protocol.  SOAP *is* a protocol,

That's right, thanks for the correction. I was referring to the separation
of the SOAP messaging framework from the bindings to underlying transport
protocols and various use cases such as RPC, but obviously SOAP is still a
"protocol".  And thanks for the REST / Tuple Spaces links

> As manifested in HTTP and URIs, it remains the Current Big Thing.  

Hmmm... "It's also important to note a key difference between TupleSpaces
and REST; that a tuple space has a single fixed interface, whereas REST
suggests that an extensible interface is a good tradeoff, so long as the
method extensions remain generic (i.e. are applicable to all resources). "
http://internet.conveyor.com/RESTwiki/moin.cgi/RestArchitecturalStyle

I guess it still seems to me that "SOAP as RPC" and "SOAP as a single fixed
interface in a Tuple-Spaces-like thing" are different architectures (or at
least different design patterns) for web services.  Obviously they both
leverage HTTP and URIs, but the overwhelming bulk of the SOAP hype that I've
seen implies RPC.  

Are you saying that this RPC vs "SOAP-spaces" distinction is more or less
trivial (or already internalized by most web-services architects), and
that's why the "spaces" notion has little mindshare?