W3C home > Mailing lists > Public > www-ws-arch@w3.org > July 2002

SOAP and the Web (was RE: Late binding)

From: Champion, Mike <Mike.Champion@SoftwareAG-USA.com>
Date: Mon, 1 Jul 2002 09:01:31 -0600
Message-ID: <9A4FC925410C024792B85198DF1E97E403735CBC@usmsg03.sagus.com>
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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:40:57 UTC