[
Lists Home |
Date Index |
Thread Index
]
I'll try to keep this short, although terseness is not one of my noted
virtues. Advance apologies.
Four months or so ago, I probably would have agreed with the
evaluations of Bruce Schneier in Crytpo-gram, and of Paul Prescod here.
SOAP-as-marketed (and -hyped) is an RPC mechanism running over HTTP
(only) in order to defeat firewalls and allow high-school dropouts to
expose insecure ecommerce services on a shoestring budget. Grant you,
I'm not delivering the peroration as convincingly as the PR flacks, but
it's interesting that this is a world in which those promises are
attractive.
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).
SOAP-as-specified isn't even an application protocol. 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). It
needs an application protocol, with existing connection semantics and
plugin style architecture, in order to work at all. HTTP fulfils the
role best, because HTTP has traditionally hidden all sorts of
interesting cruftiness behind a single URL (servlets, ISAPI, NSAPI, CGI
... you *can* program these things so that every access has a unique
URL, but I don't know anyone who does so reliably, and I do know
several applications that provide a single access point,
differentiating only by supplied parameters, POST-only). SMTP is also
usable, and so is JMS, or Jabber (SOAP::Lite runs over Jabber), or a
number of other possibilities. All of those possibilities are less
attractive for sales and development because none of them offer the
equivalent of servlets/ISAPI/NSAPI plugin functionality.
SOAP *is* an extensible message format for data exchange. It's a
formalization of what the data looks like between two application
protocols, with some semantics for processing (associated largely with
headers and faults). 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)
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.
None of these specifications change current usage patterns as applied
to "web applications," which already carried application-specific
information that potentially caused state changes on the server, and
could easily carry RPC, using name-value pairs as parameters. SOAP
formalized, offered extensions (because a tree is potentially more
expressive than a bag), and divided the message into a 'main' part (the
body) and auxiliary bits (optional headers).
Message format and message exchange patterns. Typing and
standardization of content for application protocols over which it is
delivered.
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.
Amy!
--
Amelia A. Lewis amyzing@talsever.com alicorn@mindspring.com
The law, in its majestic equality, forbids the rich as well as the poor
to sleep under bridges, to beg in the streets, and to steal bread.
-- Anatole France, "Le Lys Rouge"
|
