OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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

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.

Definitely.

>   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. http://foo.com/rpc.
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