[
Lists Home |
Date Index |
Thread Index
]
4/21/2002 9:46:44 PM, Paul Prescod <paul@prescod.net> wrote:
>
>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.
OK. I think I was a bit carried away by the analogy, and the possibility
of higher level protocols putting in headers to do this kind of stuff.
And as Dare suggested, I was a bit caught up in the vision of what
SOAP can be rather than what it is today. Sorry! And thanks for the reality check ...
>
>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?
That's a good point. Nevertheless, a) They will get the SOAP tools from IBM or one
of the legion of companies jumping on the SOAP bandwagon.
b) My sense of the political and psychological reality is that there are a fair
number of people who think it safer/more practical to plug in a SOAP message
translation node into their propritetary architectures than to put them
"on the Web." c) Presumably the WS-I exists to fill in a lot of the gaps in
the "standards" with profiles and conventions that offer pragmatic interoperability
across platforms, tools, and "transport" (let's not go there ...) protocols.
>
>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?
Uhh, no, but this is a bit out of my depth, so I wouldn't argue one way or the other.
All I'm doing by jumping in to this thread is giving my sense of why rational
people at MS, IBM, BEA, and many many other companies think SOAP "adds something."
They think that when the hype cycle has run its course and SOAP has reached the
"plateau of productivity", that the reality will resemble the vision of
the envelope metaphor, and tools will exist to
route/verify/encrypt/collate/translate SOAP messages from MQ to MS to JMS
to wireless, etc. That's not anywhere near as exciting as Steve Ballmer's much more
psychedelic visions :~) but it achieves the very pragmatic goal of shoving a lot
of ad hoc stuff down into the common infrastructure. REST has the opportunity to
gain mindshare to the extent that people can plausibly argue that the goal of
shoving the "ad-hoc stuff" into a standardized infrastructure can be achieved more
quickly, reliably, securely, and interoparably by embracing HTTP rather than
abstracting it away. The Google thing has provided a great opportunity to
do this for a very simple use case, it will be very interesting to see if a
REST "truth squad" can do the same for something like Microsoft's Global Web Services
Architecture as its details becomes public.
|
