[
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."
Paul Prescod wrote:
> 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.
If you drop the SOAP encoding rules (section 5), which many now consider
to be deprecated by XML Schema, SOAP essentially codifies the following:
1. Framing and extensibility (via headers)
2. Standard representation for errors
3. Binding for sending messages over HTTP
4. Binding for mapping messages to RPC
If HTTP is an application protocol, I don't see how SOAP can't be one.
...
> 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?
SOAP as it sits today doesn't give you much in terms of interoperability
benefit simply because there are no standard headers. We're still trying
to agree on the framing and extensibility mechanism before we charge
down that path. The real interoperability benefit will come over time as
standardize headers emerge.
HTTP wouldn't be much of a protocol either if you throw out all the
headers.
...
> 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.
Prepared to take advantage of extensions as they emerge is the way I
like to think of it. ;-)
-aaron
http://staff.develop.com/aarons
|
