[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Doing Web services right
On Wed, 12 Mar 2003 14:09:18 +0000, Bill de hÓra <bill.dehora@p...> wrote: > > 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 crafted. > > 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.
|
PURCHASE STYLUS STUDIO ONLINE TODAY!Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced! Download The World's Best XML IDE!Accelerate XML development with our award-winning XML IDE - Download a free trial today! Subscribe in XML format
|