Cart
[Home] [By Thread] [By Date] [Recent Entries]
4/21/2002 9:46:44 PM, Paul Prescod <paul@p...> 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.
|
