[
Lists Home |
Date Index |
Thread Index
]
4/21/2002 4:42:47 PM, "Henrik Frystyk Nielsen" <henrikn@microsoft.com> wrote:
>
> I would
>therefore strongly encourage you to continue the discussion there
>although I realize that it is annoying to have to argue ones point with
>folks who don't see it that way.
FWIW, I'd disagree -- Simon's question is really at the XML FAQ level, and quite appropriate
for XML-DEV. xml-dist-app would certainly be the place to discuss the details of SOAP 1.2.
Anyway, I see the SOAP value proposition as:
1 - The obvious analogy is an envelope for snail mail. It keeps a bunch of stuff in a
coherent package, it has an address and return address, and and provides some high-level
description of the contents. Automating sorting equipment would presumably not be possible
unless there were conventions for where the address goes, which is the return address, what
size the envelope is, where the postage goes, etc. SOAP does that for electronic messages;
whether the automatic routing, sorting, authentication/authorization, charging, encryption,
etc. "equipment" gets produced is speculative, but without something *like* SOAP, it would be
impossible.
2 - it's a standard because people use it and and people use it because it's a standard.
Much like XML, it doesn't do a whole lot, but it does what it does well enough to be a LOT
better than ad hoc solutions. Of course many competent markup specialists could produce
something as good or better ... but the same is true of XML syntax. Its pervasiveness allows
us to forgive a lot of flaws and limitations and sheer boringness.
3 - The intermediary mechanism seems like a bit of an afterthought, until one actually has to
think about how to get messages to from a legacy mainframe application to a Java PDA on a
train or plane somewhere. There are an awful lot of hardware and software connections
between producers and consumers of web applications / services, and the assumption that every
node speaks HTTP to its neighbors is unrealistic. Maybe every device SHOULD be on "the web",
but it isn't. SOAP attempts to deal with that, it a platform / protocol / message
architecture-neutral way.
4 - The trend in SOAP really is to make it less of a "SOAP-RPC on steroids" and more of a
generic, transport-neutral, message architecture-neutral, low-level but theoretically
interoperable protocol. Sure, there are only a handful of interesting, interoperable SOAP-
based services, but the W3C and WS-I are working are working to resolve some real technical
issues that have made this difficult. Whether resolving the technical issues exposes even
nastier business issues and "web architecture" issues that kill the whole idea, or whether
this finally leads to the New Age of Web Services, is definitely To Be Determined.
I totally agree that all this adds up to a POTENTIALLY powerful nerd-level tool rather than
something that will be "bigger than the PC." Even if it is bigger than the PC someday, it
will have gone though the classic hype cycle because of it's recent over-promotion and the
"trough of despair" that will almost certainly produce. So, I'm sympathetic to where Simon
is coming from, but see more value to SOAP than he does... but far less than Mr. Ballmer and
other evangelists suggest :~)
|
