Re: W3C Schema: Resistance is Futile, says Don Box
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
PURCHASE STYLUS STUDIO ONLINE TODAY!
Purchasing Stylus Studio from our online shop is Easy, Secure and Value Priced!
Download The World's Best XML IDE!
Accelerate XML development with our award-winning XML IDE - Download a free trial today!
Subscribe in XML format