RE: Web-friendly SOAP

If I understand this correctly, you are proposing a kind of dual approach,
for example including the method name in the HTTP binding and also within
the message itself?

My big concern with the move toward HTTP specific binding for SOAP is losing
the ability to easily map to JMS, MQ Series, CORBA, J2EE, etc.  I know Mark
Baker says we can do it anyway, and perhaps we can, but to me one of the big
questions is whether or not we are thinking about just sending the entire
message over the transport, and letting the "endpoints" decide what to do
with it, and how to interpret it.

So you are suggesting including the header information in both the HTTP part
of the message and also in the SOAP part of the message?

Eric

-----Original Message-----
From: xml-dist-app-request@w3.org [mailto:xml-dist-app-request@w3.org]On
Behalf Of Jacek Kopecky
Sent: Sunday, June 16, 2002 7:06 AM
To: Paul Prescod
Cc: Mark Baker; xml-dist-app@w3.org
Subject: Re: Web-friendly SOAP



 Oh, I forgot to mention that we'd have better underlying
transport independence if the high goal is achieved because then
SOAP could be bound to various messaging protocols like JMS or
MQSeries, to various transport protocols like TCP etc.

                   Jacek Kopecky

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



On Sun, 16 Jun 2002, Jacek Kopecky wrote:

 >  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 12:10:56 UTC