Altova Mailing List Archives

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

From: Mark Baker <distobj@---.--->
To: Mike.Champion@--------------.--- (--------, ----)
Date: 10/10/2001 11:21:00 AM
> > 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). "

Right.  As long as the methods are potentially applicable to all resources.
But even then, GET/PUT/POST/DELETE are extremely generic, and it's not often
that new methods are required.  Even some methods that have been created
(such as WebDAV's LOCK) could have used other extension mechanisms.

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

Agreed.  The RPC use of SOAP misuses both HTTP and RPC; HTTP POST is used
to tunnel a new protocol (rather than adopt POST semantics), and URIs are
used as a universal RPC dispatch pointer, e.g.
Hardly what the architects of the Web had in mind when they created them.

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

I think the distinction is quite profound.  They are very different
architectural styles.  One was designed to do what it's being used for,
and has been massively successful doing (even if current practice isn't
strictly by the REST book), and the other has failed at least four times
in the past decade in attempts to see it deployed over the Internet.

Mark "Web services; you're soaking in them!" Baker


These Archives are provided for informational purposes only and have been generated directly from the Altova mailing list archive system and are comprised of the lists set forth on Therefore, Altova does not warrant or guarantee the accuracy, reliability, completeness, usefulness, non-infringement of intellectual property rights, or quality of any content on the Altova Mailing List Archive(s), regardless of who originates that content. You expressly understand and agree that you bear all risks associated with using or relying on that content. Altova will not be liable or responsible in any way for any content posted including, but not limited to, any errors or omissions in content, or for any losses or damage of any kind incurred as a result of the use of or reliance on any content. This disclaimer and limitation on liability is in addition to the disclaimers and limitations contained in the Website Terms of Use and elsewhere on the site.