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


Help: OASIS Mailing Lists Help | MarkMail Help



   Re: [xml-dev] Doing Web services right

[ Lists Home | Date Index | Thread Index ]

On Wed, 12 Mar 2003 14:09:18 +0000, Bill de hÓra <bill.dehora@propylon.com> 

> in other words, what we want are dataflow architectures to work their way 
> in from the Internet to the systems code, not for the systems code and 
> associated idioms (including object oriented programming) to spill out 
> across the Internet....
> Integration becomes more a matter of data and transformations, and less a 
> matter of APIs and function calls.

Ah yes, the Propylon dogma :-)  I fully agree.  SOAP, HTTP, REST, XSLT, 
XQuery, whatever are alternative, often complementary ways ways to do this 
and shouldn't be thought of as paradigms within which solutions must be 

> The dogma I see comes in two forms. One, when people say you don't need 
> SOAP/WSDL at all, that it has no architectural value or significance for 
> application integration over an d above the Web. Two, when people say you 
> can blow out the data formats from the code, the tools will take care of 
> it. (there's a huge amount of misunderstanding on the ground on how to 
> use and build a WS. WS are not about sending a Java linked list to a Perl 
> script using SOAP as a serialization and HTTP POST as the delivery 
> mechanism, but you wouldn't know that from some fora).

I think I agree -- SOAP is neither the evil "end of the web as we know it" 
nor the panacea that lets us forget about the nasty networking stuff and 
just think about objects and methods.  It's a convention for *data* 
interchange (that also supports some RPC conventions that are sometimes 
useful but considerably over-emphasized at present).  The real value will 
come if/when standardized headers defining information needed by 
intermediaries that support encryption, identity/authentication, 
authorization, multi-protocol routing, delivery confirmation / retry 
management (AKA "reliable messaging"), multi-message choreography, etc. 
come into widespread use. Those features could be exploited by RESTful, 
RPC-ish, or dataflow/transformation architectural styles.

> The thing is, to do anything interesting, are the users being burdened 
> with reinventing protocols? As Geoff Arnold pointed out recently, API and 
> protocol design require very different mindsets and approaches. Just 
> shipping data around, really means just shipping data around /with/ 
> service level agreements.

To be honest, this is something I'm having a hard time coming to grips 
with.  The RESTifarians make a strong point that every WSDL file defines a 
new "protocol", and that ordinary users can't be expected to grasp the 
subtleties of protocol design.  Getting back to my original point, that 
seems like saying that the specific message format that a CGI (or 
ASP/JSP/etc.) backend expects is a "protocol."  True in the literal sense 
of the word "protocol" in English, but I'm not sure it means anything more 
than "the minimal expectation by the server of the information content 
needed to do its job" (which is my understanding of the position that folks 
including Walter Perry and Sean McGrath advocate).  It is VERY TRUE that 
the Web services industry has given WSDL users immense lengths of rope with 
which they can hang themselves by generating tightly-coupled, RPC-style 
code for both sides from the WSDL file.  I'm not convinced, however, that 
that's anything but a temporary abberation that the industry will move 
beyond once the well-known scalability problems of tightly coupled systems 
are exposed once again.


News | XML in Industry | Calendar | XML Registry
Marketplace | Resources | MyXML.org | Sponsors | Privacy Statement

Copyright 2001 XML.org. This site is hosted by OASIS