[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: Doing Web services right

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

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


Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!

Buy Stylus Studio Now

Download The World's Best XML IDE!

Accelerate XML development with our award-winning XML IDE - Download a free trial today!

Don't miss another message! Subscribe to this list today.
First Name
Last Name
Subscribe in XML format
RSS 2.0
Atom 0.3

Stylus Studio has published XML-DEV in RSS and ATOM formats, enabling users to easily subcribe to the list from their preferred news reader application.

Stylus Studio Sponsored Links are added links designed to provide related and additional information to the visitors of this website. they were not included by the author in the initial post. To view the content without the Sponsor Links please click here.

Site Map | Privacy Policy | Terms of Use | Trademarks
Free Stylus Studio XML Training:
W3C Member
Stylus Studio® and DataDirect XQuery ™are products from DataDirect Technologies, is a registered trademark of Progress Software Corporation, in the U.S. and other countries. © 2004-2013 All Rights Reserved.