- From: Champion, Mike <Mike.Champion@SoftwareAG-USA.com>
- Date: Mon, 1 Jul 2002 09:01:31 -0600
- To: www-ws-arch@w3.org
> -----Original Message----- > From: Mark Baker [mailto:distobj@acm.org] > Sent: Sunday, June 30, 2002 9:09 PM > To: Newcomer, Eric > Cc: www-ws-arch@w3.org > Subject: Re: Late binding > > > How do you know that the existing architecture of the Web > can't be used for what Web services are trying to achieve? > Shouldn't the burden of > proof be on Web services proponents to demonstrate this? Here's the way I see it: The Web as it exists has proven robust and massively scalable for human-centered information exchange, but unproven for application-to-application data exchange. SOAP/WSDL as it exists has is at least very promising, with numerous practical implementations, for application-to-application data exchange, but its robustness and scalability to the Internet is unproven. Our mission is to define a reference architecture that exploits the best features of both. We can't debate "SOAP" (or "RPC" or "SOAP as practiced") vs "The Web" any longer; what we can do is figure out how to make them work together better than existing practice indicates. For example, we have requirements to add reliability, security, orchestration, transactions, etc. to what the web and SOAP practice is today. An obvious way to do this is with SOAP headers, e.g. to define the encryption methods used to secure a message. Whether that message is a "document" or a "serialized object" seems (to me, anyway) irrelevant; whether it is part of a RESTful MEP or something else seems irrelevant. Whether it is transferred over HTTP or transported over multiple proprietary intermediaries seems irrelevant. In other words, the point of (one major part, anyway) of SOAP is the idea of an envelope with headers that can be tacked on to indicate meta-information for reliability, security, transaction, etc. processing that has nothing to do with the body of the message itself. I simply don't see how that is at odds with REST, the "web architecture", etc. Am I missing something? Is there any reason we can't move ahead with a SOAP-based mechanism to define the WSA?
Received on Monday, 1 July 2002 11:02:09 UTC