[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] RE: SOAP and the Web
Simon said: "Did you get anyone defending SOAP on its technical merits?" Only Mike Deem and Andrew Dubinsky have stepped up to this challenge so I thought I'd chip in with why I recommend SOAP to my customers. However, I have to say that I agree with Paul Prescod and Bill de hÓra that this is not going to fly for the Web the way it is being hyped, rather it's a solution for application integration. First, what I recommend SOAP for. Every company I work with has a huge problem of application integration and is spending a lot of money on it. The reality of integration is that it is a massive problem of managing semantics and needs to be attacked with a simple strong architecture. The key is loose coupling because it must never be the case that a change to one interface causes knock-on changes to other interfaces (there could easily be 50,000 of them). This is the 'syntax problem' - how to keep adapters stable. We also have to make the output of one application the input of another. There is almost no chance that this can be done without transformation (thank heavens for XSLT). This is the semantic problem. We have to centralize the semantic transformations in order to keep the adapters stable. This means we have to send the message to a destination which will decide what to do with it: transform it here; send it elsewhere for transformation; or both; enrich the message; route it based on content or (better) the envelope (like the postal service). To do this, the adapters (end points) and the brokers (intermediaries) absolutely have to agree on a single envelope (this is how IBM's MQ works too). SOAP does exactly what is needed for this problem. The fact that it is cross-vendor, cross-language and cross-platform and supported by over 100 free toolkits and is a component of every major package (in plan), major application server (again, in plan) and tool is a huge win. Secondly, why I don't think SOAP will support ad hoc interactions on the Web. We've been struggling for 30 years to make printers dynamically attachable and still success is mixed. I just upgraded my printer driver and now it won't print. If we can't interface printers, the idea that one application can dynamically discover another and know what to do with its interface is very far fetched. The only thing that might be agreed on is data types. That is why REST is probably the only way this could ever work - it is running at a higher level of abstraction (data type are a 'meta' thing) where there is far less variation and far more possibility of agreement. The approach outlined above to application integration only works because interactions are mediated and semantics is specified by people in advance. Note that all the examples given to support SOAP over the web end up relying on a person (to choose the interface etc). Direct application interactions without intermediaries cannot work with a SOAP approach because they would be tightly coupled and unstable. John F Schlesinger SysCore Solutions -----Original Message----- From: Simon St.Laurent [mailto:simonstl@s...] Sent: Thursday, April 25, 2002 7:05 PM To: Paul Prescod Cc: xml-dev; spolsky@p... Subject: Re: SOAP and the Web Did you get anyone defending SOAP on its technical merits? You and Mark Baker seem to present more technical defense than any of the "advocates", which has me thoroughly confused. (Don Box did bring up a common framing format[1], but I'm having a hard time seeing the format mitigating the overall approach.) On Thu, 2002-04-25 at 18:45, Paul Prescod wrote: > Here are the major categories of responses I've gotten to the article: > > * "Performance doesn't matter dummy" -- as if I didn't say in the > article: "performance is a minor issue compared to linking." -- Joel is > a stand-out because he said performance DOES matter -- for Google if not > for the rest of us. > > * "It's all just syntax -- it doesn't matter" -- as if I didn't show > things that could be done with the HTTP-way but *not with* the SOAP way. > > * "The big companies have chosen. Alternate views at this point are > just confusion." -- that would be fine if the technique that the big > companies have chosen weren't fundamentally bankrupt. > > * "It's the tools dummy" -- as if I didn't show that the .NET Framework > (i.e. Visual Studio) has *quite good support* for HTTP-based web > services. [1] - http://lists.xml.org/archives/xml-dev/200204/msg00770.html -- Simon St.Laurent Ring around the content, a pocket full of brackets Errors, errors, all fall down! http://simonstl.com ----------------------------------------------------------------- The xml-dev list is sponsored by XML.org <http://www.xml.org>, an initiative of OASIS <http://www.oasis-open.org> The list archives are at http://lists.xml.org/archives/xml-dev/ To subscribe or unsubscribe from this list use the subscription manager: <http://lists.xml.org/ob/adm.pl>
|
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
|