[
Lists Home |
Date Index |
Thread Index
]
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@simonstl.com]
Sent: Thursday, April 25, 2002 7:05 PM
To: Paul Prescod
Cc: xml-dev; spolsky@panix.com
Subject: Re: [xml-dev] 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>
|
