[
Lists Home |
Date Index |
Thread Index
]
Rich Salz wrote:
>
>...
>
> > But SOAP isn't an app protocol. Agreeing to use SOAP is the networking
> > equivalent of "agreeing to use XML" or "agreeing to use Unicode" only it
> > actually implies far less practical interoperability than either of
> > those statements...
>
> I disagree with this on two points. First, SOAP is doing a harder
> problem, so saying it's just like "use XML" is a gross simplification,
> like comparing "use ASCII" to "use HTTP."
It's just like XML and ASCII because it has very low-level semantics,
not application semantics. That's why I say it is not an application
protocol. That's why I'm surprised you say that SOAP/WSDL/... services
are a good idea because "It's great to have common data syntax,
networking protocols, why not app protocols?" I don't understand what
this has to do with SOAP. SOAP is not an app protocol.
> ... Second, from my corner of the
> world interop is pretty darn good.
Okay, here's a SOAP message, please tell me what SOAP says it means:
<env:Envelope xmlns:env="http://www.w3.org/2001/12/soap-envelope";>
<env:Body>
<qqweqw>
<ffwews>32</ffwews>
<xxwwee>43</xxwwee>
<xxwwee>98</xxwwee>
</qqweqw>
</env:Body>
</env:Envelope>
If you give me an HTTP or DNS or for that matter IP message, I think
that I will be able to tell you much more about what it means according
to the HTTP, or DNS or IP specs than you will be able to tell me about
the message above (but no, I won't actually decode an IP datagram!).
Those protocols have pretty sophisticated semantics and the semantics
are hard-coded so that every client and server understands them. When I
put an IP packet out there everyone knows whether it is a TCP or UDP
packet and exactly what that means!
But if you use SOAP, and especially if you use the document style of
SOAP, you need a ton of negotiation. In fact, SOAP guarantees very
little above and beyond what XML guarantees. That's why I say that
agreeing to "use SOAP" ensures a miniscule degree of interoperability.
Unicode gets you from bits to characters. XML gets you from characters
to the infoset. SOAP gets you from the infoset to...what exactly?
Actually I think I know the answer to the question but it involves a
usage model for SOAP that is quite at odds with the deployed SOAP
services I've seen out there.
>...
> They started before SOAP was available. I understand they plan to migrate
> to SOAP. They like the web-services soap/wsdl/schema stuff.
Of course. They are experiencing success! The perfect time to switch
strategies. ;)
The nice thing is that you can just wrap up your XML messages in SOAP
envelopes and bodies and you don't have to change anything else. You'll
be 100% buzzword compliant without improving interoperability one whit.
Paul Prescod
|
