[
Lists Home |
Date Index |
Thread Index
]
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.
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
3. the version of HTTP in use.
Given this message an HTTP server knows exactly what to do. It looks for
a resource with the name "/index.html" and returns a representation of
it. Intermediaries know exactly what this message needs. The client and
server need *no further configuration* at the protocol level in order to
talk to each other. I can use a stupid command line client like "wget"
and a complicated dynamic server like IIS and they just work together.
HTTP not only says how to represent errors but also says what precise
errors to trigger if the resource doesn't exist or authorization is
refused or ...
Plus, HTTP *guarantees* that the request will have a response path so it
is possible to build on HTTP as an abstraction without caring whether it
is delivered over TCP or UDP or Jabber or whatever. So applications can
be coded in a manner that is interoperable with any transport. SOAP
doesn't make those guarantees so your application needs to know what
transport protocol you are using under SOAP.
But that's just the simplest message. HTTP has a bunch more semantics
than that. Cache invalidation, etags, conditional operations, etc. Take
a browse through the spec. It is an application protocol because it
describes how an application can manipulate named data objects. So does
FTP. So does SMTP. Anyhow, one very concerete (if somewhat circular) way
to define "application protocol" is "a protocol with its own port
number". Since SOAP does not define a port number we could say that it
does not even claim to be an application protocol!
> ...
>
> 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.
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.
> 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.
>
> ...
>
> > 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. ;-)
The majority of HTTP's headers depend upon the semantics defined by the
HTTP methods. I will be very curious to see what kind of headers SOAP
evolves without reference to named data objects.
Paul Prescod
|
