[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: RE: What does SOAP really add?

• To: xml-dev@l...
• Subject: Re: RE: What does SOAP really add?
• From: Mike Champion <mc@x...>
• Date: Sun, 21 Apr 2002 17:31:25 -0400
• In-reply-to: <79107D208BA38C45A4E45F62673A434D073715AC@r...>

4/21/2002 4:42:47 PM, "Henrik Frystyk Nielsen" <henrikn@m...> 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 :~) 

• Follow-Ups:
  • Re: What does SOAP really add?
    • From: Paul Prescod <paul@p...>

• References:
  • RE: What does SOAP really add?
    • From: "Henrik Frystyk Nielsen" <henrikn@m...>

• Prev by Date: RE: What does SOAP really add?
• Next by Date: RE: What does SOAP really add?
• Previous by thread: RE: What does SOAP really add?
• Next by thread: Re: What does SOAP really add?
• Index(es):
  • Date
  • Thread