Re: Web-friendly SOAP

 Paul,
 I have to ask myself what is the web and what is SOAP. 
 I believe the web can be sufficiently defined as "the current 
wide-spread implementation of the Web architecture, mainly 
based on REST principles". I like such web.
 I believe SOAP can be defined as a message protocol. The only 
ties between SOAP and the web are in the SOAP HTTP binding.

 Talking to Mark Baker, I think we agreed that what we ultimately
want is "SOAP over TCP, REST over SOAP". Let me explain: 
 REST has proved to be a scalable distributed application 
architecture -> REST is good.
 The current implementation of REST is HTTP - a protocol capable 
of data and metadata to a URI. HTTP is built on TCP and it uses 
MIME syntax for metadata and data. This has limitations (compared 
to XML syntax).

 SOAP (with a TCP or other low-level binding and WITH SUPPORT FOR
ATTACHMENTS) can be used in a different implementation of REST.
The mapping from HTTP to SOAP would be the following:
 1) HTTP method and version maps to the Body element QName.
 2) Resource URL (URI?) maps to an attribute value of that 
element.
 3) HTTP headers map to SOAP headers.
 4) HTTP payload maps to the contents of the HTTP method element 
or to an attachment, depending on the content type. 
 An example:

--------------- HTTP 1.0 example
PUT /foo HTTP/1.0
X-Jacek-header: bar; variant=b2
Content-type: text/xml

<some>
  <xmlData/>
</some>
----------------

--------------- SOAP/REST version of the example above
<soap:Envelope>
  <soap:Header>
    <ns:Jacek-header>
      <b2ns:bar/>
    </ns:Jacek-header>
  </soap:Header>
  <soap:Body>
    <rest:Put url="/foo">
      <some>
        <xmlData/>
      </some>
    </rest:Put>
  </soap:Body>
</soap:Envelope>
-----------------------

 This is possibly the High Goal of combining SOAP and REST (REST
would become the subset of SOAP applications). It can be
formulated like this:
 "We have an all-purpose transport protocol (TCP), over it a 
structured message protocol (SOAP) and over it applications of 
various kinds, including RPC applications and REST."

 Before SOAP, we had something like this:
 "We have an all-purpose transport protocol (TCP) and over it
applications of various kinds, including RPC applications and
REST."

 With SOAP 1.1 and people's mindsets unaware of REST principles)
the situation is IMHO like this:
 "We have an all-purpose protocol (HTTP), over it a structured 
message protocol (SOAP) and over it applications of various 
kinds, including RPC applications."
 I believe it is apparent that HTTP was shifting from an 
application protocol to an all-purpose protocol in people's minds 
(incl. mine), which is bad for the application - the Web.

 If we want to reach the high goal from the current situation, we
have to educate people on 1) why HTTP is not an all-purpose
protocol, 2) how REST architecture can be applied to various
distributed problems.
 With the current XMLP WG work on making the HTTP binding we seem 
to be going in the wrong direction of saying that:
 "We have an all-purpose protocol (TCP), over it an app protocol
(HTTP) representing an application (REST) which may use a
structured message format (SOAP) for the payloads."
 This is moving HTTP to its rightful position of an app protocol, 
but it is also moving SOAP to the wrong place.

 If we agree on the high goal above, I believe we should not 
produce an HTTP binding of SOAP at all, or as a secondary binding 
for limited use in REST-based applications; the main binding 
being a transport protocol (TCP or other) binding.
 Then we would have to create the WebP (Web Protocol == REST over
SOAP in XML over TCP/other), make browsers use it and web servers 
support it, and the world would be a better place. 8-)

                   Jacek Kopecky

                   Senior Architect, Systinet Corporation
                   http://www.systinet.com/



On Fri, 14 Jun 2002, Paul Prescod wrote:

 > 
 > Thank you for your attention to web-friendly SOAP.
 > 
 > I feel that the SOAP specifications should call particular attention to
 > an aspect of Web Architecture which is commonly misunderstood by web
 > services creators. This is especially true for the Primer which will
 > give programmers a flavour of SOAP usage. I propose:
 > 
 > "One of the principles of Web Architecture is that all important
 > resources should be identified by URIs. This implies that most SOAP
 > services will have many endpoints and that SOAP services that create and
 > destroy resources (e.g. purchase orders, calendars) will also create and
 > destroy endpoints."
 > 
 > It is my personal sense that giving URIs to resources is not a large
 > burden and will greatly improve the interoperability of web services.
 > Unfortunately this is quite difficult with today's SOAP toolkits. This
 > is understandable because the original "SOAP style" was not based upon
 > web architecture principles. Now that we are trying to move SOAP into
 > accordance with web architecture I think we need to point out areas
 > where the installed toolkit base is out of sync.
 > 
 > I would like to see future SOAP toolkits have first-class support for
 > mapping logical objects to URIs as HTTP toolkits do.
 > 
 >  Paul Prescod
 >

Received on Sunday, 16 June 2002 07:00:56 UTC