[
Lists Home |
Date Index |
Thread Index
]
> -----Original Message-----
> From: Paul Prescod [mailto:paul@prescod.net]
>
> Aaron Skonnard wrote:
> >...
> >
> > 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
>
> HTTP supports the first two and doesn't need the last two.
>
> > If HTTP is an application protocol, I don't see how SOAP can't
> > be one.
>
> Let's look at the simplest possible HTTP message:
>
> GET /index.html HTTP/1.1
>
> It declares three things.
>
> 1. what method to use. The HTTP specification has tons to
> say about the semantics of the "GET" method including its
> idempotency, cachability and safety.
The SOAP operation is identified by the qualified name of the payload
element.
> 2. what URI you want to get. If you read the HTTP spec
> you'll find that there is a ton in there about the
> interpetation of that and of course behind that is the entire
> body of Web standards
A SOAP service is also identified by a URI (any transport).
> 3. the version of HTTP in use.
The version of SOAP is identified by the SOAP namespace.
<snip/>
> > ...
> >
> > 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
> > standard headers emerge.
>
> I agree, and think that this would be where SOAP could
> provide great value if it didn't get there by tearing down
> the interoperability we have already built around URIs and
> operations upon them. Two steps backwards, one step forward.
I think "tearing down" is dramatic. SOAP embraces HTTP and tries to
clearly codify its use to help ensure interoperability. This is where
you'd like to see REST come in, right?
> > HTTP wouldn't be much of a protocol either if you throw out all the
> > headers.
>
> I guess that's why HTTP defines a bunch of headers.
> ;) So should SOAP.
That's exactly what's happening through layered specifications like
WS-Security proposed by Microsoft, IBM, and Verisign. There are many
other proposals on the table from different organizations.
-aaron
http://staff.develop.com/aarons
|
