[
Lists Home |
Date Index |
Thread Index
]
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
|
