Cart
|
[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: Doing Web services right
 Mike Champion wrote: >> CGI defines an interface between applications/scripts and websevers. >> It has nothing to do with the Web's client/server contract; that's >> defined already by HTTP/SMTP/FTP and so on. > > > Sorry, I just don't buy that. For GET (and PUT/DELETE in theory but not > widespread practice) HTTP defines a reasonable and useful contract. But > much of the real Web that really works is a bunch of arbitrary stuff > POSTED from HTML forms or whatever, and the "CGI" details are the > interface that matters if you are writing a form to work with existing > back end code or back end code to process a form. My point was that this > interface is no more late bound than a "Web service". I'm not saying CGI isn't real or important. Just that it's incidental to client server contract (POST is not incidental). Where CGI matters, 'architecturally', is hooking up back-end apps and scripts to web servers, not clients to back end apps. >> The difference is that most (all?) successful Internet systems are >> keyed off protocols. As protocols they have semantics that make them >> distinct from the 'protocol neutral' architecture implied by >> SOAP/WSDL; something imvho needs to downgraded to 'transport neutral' >> in the long term - there ain't no getting away from protocols if we're >> serious about interoperating applications. > > That is the REST dogma, and I buy it as far as the synergy between HTML > links and HTTP GET is concerned. I don't think it's REST dogma (but I may be wrong there). All I'm suggesting is that it's (imho) good that SOAP gets you transport neutrality. I'm less sure about protocol neutrality (being that it's true for SOAP, or desirable for SOAP based apps). > And as far as 'transport neutral' is concerned, I very strongly suspect > that many successful websites are forwarding that information collected > over HTTP (by GET, POST, or whatever) to backoffice systems that are > linked by all sorts of proprietary protocols that most of us have only > the dimmest awareness of. Sure. But it's a good thing that the details of people's backend systems are hidden by behind protocols and shared data formats rather than API gateways, because it drives you towards dataflow architectures. You wouldn't want to go from this: client [--protocol --] server [-- gateway --] backend where there are preserving transformations of data along the way, to this: client [--] [------------ gateway -------------] backend 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. Think of it as the retreat from Moscow after a few terrible winters in the API wars - working from code outwards is what we know doesn't work so well for application integration and is precisely backways methodologically. Integration becomes more a matter of data and transformations, and less a matter of APIs and function calls. Especially so in a world where the backend and the clients are own by different people. For n-tiered system we now have to push the code back to where it belongs What SOAP seems to offer that is valuable, is a way for web servers to act as connectors for backend systems. So this: client [---------protocol ----------] server [--] backend might be a better description of its practical if not quite architectural significance. In other words using SOAP gets us two (at least) useful things. First it can help eradicate bogus exposures of code-faces in check, second it allows a dataflow to move across different transports. But it does not remove the need for protocols, data, and transformations. Note that we still want all the OO and procedural goodness when it comes to building the applications themselves and extending them (via plugins and whatnot). Where clients are other backends, you have: [backend-] ws client [--- protocol ---] ws server [-backend] Thus my issue with comparing SOAP with CGI as in the same style architecturally, sorry it's not shorter. 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). > The whole point of SOAP for many such users is > indeed to "get away from the protocols" and just ship the data around > without regard to language, platform, or vendor, or the underlying > protocol. That's what XML is good for, and why the Web services people > latched onto it. [much to the annoyance of Mr. St. Laurent and Mr. > Harold :-) ] 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. For example reliable delivery is becoming a hotspot where WS vendors are happy to compete on specs+tools (granted it's a step up from apis+tools), for now. Maybe it's too early to standardize, or maybe the thinking is that layers over SOAP/WSDL are valuable enough not to commoditize. But I do feel claims about protocol neutrality are borrowing trouble. Bill de hÓra 
|
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
|
|||||||||
