[
Lists Home |
Date Index |
Thread Index
]
Mike Champion wrote:
>
>...
>
> 1 - The obvious analogy is an envelope for snail mail. It keeps a bunch of stuff in a
> coherent package, it has an address and return address, and and provides some high-level
> description of the contents.
SOAP does not, AFAIK, does not have a well-defined, interoperable
concept of either forward address nor a return address. The forward
address is expressed in the HTTP header.
> ... Automating sorting equipment would presumably not be possible
> unless there were conventions for where the address goes, which is the return address, what
> size the envelope is, where the postage goes, etc. SOAP does that for electronic messages;
> whether the automatic routing, sorting, authentication/authorization, charging, encryption,
> etc. "equipment" gets produced is speculative, but without something *like* SOAP, it would be
> impossible.
But how does SOAP:
* express the forward address
* express the return address
* express the size of the envelope
* help with routing
* help with sorting
* do authenticatoin/authorization
* do charging
* do encryption
Of these, HTTP at least handles:
* forwarding
* size
* proxying (which is related to routing)
* authentication
* encryption (through https)
> 2 - it's a standard because people use it and and people use it because it's a standard.
> ...
I'll buy this part of your argument when you convince me it does
*something in particular* in a standard way. The only thing I've seen
that it does reliably and interoperably is RPC over HTTP.
> 3 - The intermediary mechanism seems like a bit of an afterthought, until one actually has to
> think about how to get messages to from a legacy mainframe application to a Java PDA on a
> train or plane somewhere. There are an awful lot of hardware and software connections
> between producers and consumers of web applications / services, and the assumption that every
> node speaks HTTP to its neighbors is unrealistic. Maybe every device SHOULD be on "the web",
> but it isn't. SOAP attempts to deal with that, it a platform / protocol / message
> architecture-neutral way.
Is it really the case that adding SOAP to a mainframe is easier than
installing an HTTP server and thus putting it "on the web" (or at least
on "a web")? If the particular mainframe variant hasn't got an HTTP
server after all of these years, when will it get an interoperable SOAP
implementation?
Futhermore, SOAP anticipates the need to route but I don't see anything
in it that specifies an interoperable way to do routing. Do you feel
that a SOAP message could be interoperably routed from HTTP to JMS to
SMTP to HTTP using only features of the SOAP specification?
> 4 - The trend in SOAP really is to make it less of a "SOAP-RPC on steroids" and more of a
> generic, transport-neutral, message architecture-neutral, low-level but theoretically
> interoperable protocol.
Do you really think it is possible for a protocol to be entirely and
truly transport, topology and message-architecture neutral? A "protocol"
that doesn't care how it is transmitted, whether it will return a result
etc. sounds more like a "file format" than a protocol to me. i.e. MIME
expressed in XML.
Paul prescod
|
