[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message] Re: What is SOAP?
The fact that we are even asking such a fundamental question should raise red flags. Most people really do NOT have any understanding what SOAP is. This is very reminicent to the difficulty years ago trying to get people to understand what HyTime was. In both cases the problem was that the specification is actually three or four bundled specifications with radically different usage models. I've raised this with the SOAP group to defeaning silence: http://lists.w3.org/Archives/Public/xmlp-comments/2002Feb/0005.html I'm not just complaining about SOAP. I have spent effort trying to fix it but it is at this point a transport truck going down a hill and I'll bet that Microsoft, Sun, IBM and others have all got a hand on the wheel. Amy Lewis wrote: > >... > > Since then, I've had to read the various specifications and mailing > lists in support of an implementation effort. SOAP-as-specified isn't > RPC, isn't reliant on HTTP, doesn't change current usage patterns for > services (and isn't particularly accessible to amateurs). I'm trying to extract a virtue for SOAP from your message. The closest I can get is: "it isn't all those bad things." > SOAP-as-specified isn't even an application protocol. Of course it isn't. RPCs are never semantically application protocols and nothing "even more general" than an RPC could be. > ... You don't > discover this by reading the spec, btw, you discover it by having read > application protocol specs, and then reading the SOAP spec, and > noticing what's left out. A lot is. SOAP isn't really able to run > over TCP (or UDP, or T/TCP, or any other transport-level protocol). Why couldn't a SOAP binding for TCP work just as well as one for HTTP? http://www.xav.com/perl/site/lib/SOAP/Transport/TCP.html Yes, you have to define some binding issues, just as you do when you bind it to HTTP! > ... It > needs an application protocol, with existing connection semantics and > plugin style architecture, in order to work at all. SOAP is very innovative in this way. What is the virtue of all of this innovation? When SOAP was "just" RPC it was at least clear what it was for. > ... > SOAP *is* an extensible message format for data exchange. It's a > formalization of what the data looks like between two application > protocols, I wouldn't say that this is SOAP's strength at all. After all, almost everybody agrees that Section 5 encoding is an abomination and once you remove that and the RPC conventions then the only thing you are *guaranteed* about a SOAP message is that it has an Envelope element and a Body element. XML has an equivalent guarantee: every document will have at least one element. In the general case, SOAP guarantees no more interoperability than raw XML does. > with some semantics for processing (associated largely with > headers and faults). This is the only thing SOAP brings to the table, in my view. > ... SOAP+WSDL is a means of describing typed message > exchange patterns (request/response, one-way from client, notification > from server, alert/response). (I'll agree that WSDL is unreadable, if > you'll agree that URL-encoded parameterized URLs are ... but I can read > both, without much difficulty) Why would you read URL-encoded parameterized URLs? WSDL is the documentation (machine and hopefully human readable) for a system. Parameterized URLs are something generated at runtime. Historically the HTTP+query params equivalent for WSDL was HTML forms, which are quite readable. After some nagging on my part it looks like XForms will also be usable. More recently I've been working on something specific to XML based web services: * http://www.prescod.net/wrdl.html <input> <query name="name" type="xsd:string"/> <query name="items" type="xsd:integer"/> </input> I think that's quite readable...don't see why I need seven layers of obfuscation as in WSDL. > As part of the specification, SOAP also suggests a means by which > object-oriented geeks can map an object graph into an XML tree, > suggests how to bind SOAP over the most available and useful protocol > (HTTP), and suggests how messages of certain patterns can emulate RPC. It doesn't suggest. It specifies: * http://www.w3.org/TR/soap12-part2/#NE69 >... > POST to a single URL, differentiating by content, probably violates > REST principles. It's extremely common in practice. SOAP offers, in > the main, a standardization of what that looks like--the data that your > servlet or component ought to eat, and what kind of syntax the response > ought to contain. I see. SOAP standardizes the mechanism that people use to violate the Web's architecture. Maybe the W3C should work on a protocol that standardizes the anonymous exchange of copyrighted materials because I'm told that's quite popular also. 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
|