Evaluating SOAP 1.2 and Web Services (long)

All.

I'm going to take a stab at evaluating SOAP 1.2, and Web services common
practice, from the point of view of Roy's "requirements" (my word) that
he discusses here.

On Fri, Apr 26, 2002 at 05:25:11PM -0700, Roy T. Fielding wrote:
> If "Web Services" truly used URI to identify services, as in allowing
> no other identifier for the service to exist within the envelope
> outside of the target URI, and it properly reflected the semantics
> of responses to that service within whatever application-layer protocol
> it uses as its delivery binding, then it wouldn't be a danger to the
> other systems that already use those application protocols correctly.
> That doesn't mean it would be great, but then at least it wouldn't
> actively cause harm.

The SOAP 1.2 specification currently says very little about this, and
I believe does nothing to prevent developers from using it this way.

Common practice though, demonstrates that URI abuse is rampant.  Some
random examples yanked from Xmethods.com;

http://betty.userland.com/rpc2
http://api.google.com/search/beta2
http://www.marotz.se/scripts/SearchPerson.exe/soap/ISearchSwedishPerson
http://xml.redcoal.net/smssoap/xmlserver.ASP
http://www.danmarinescu.com/WebServices/ChessCGIServer.exe/soap/IBorlandChess

> This bears repeating: The difference between an application-level
> protocol and a transport-level protocol is that an application-level
> includes application semantics, by standard agreement, within
> the messages that the protocol transfers.  That is why HTTP is called
> a Transfer protocol.  It is impossible to conform to an
> application-level protocol without also conforming faithfully to
> its message semantics.

SOAP 1.2 permits POST to be used to mean POST.  But once again, it is up
to the developer to use it this way.

Common practice with SOAP is not to do this.  It is to use POST to
carry a new method name.  For example, see any WSDL at XMethods.com;

http://api.google.com/GoogleSearch.wsdl
http://www.marotz.se/scripts/searchperson.exe/wsdl/ISearchSwedishPerson
etc..

> This DOES NOT mean that I expect SOAP to use GET when accessing services.
> I have never once said that this was a requirement for the HTTP binding.
> POST is every bit as much a part of HTTP (and REST) as GET.  It is
> necessary for a resource to be able to respond to GET appropriately
> in order for it to take advantage of the interconnectivity inherent
> in the Web, but it is not necessary for all such services to be
> interconnected with the rest of the Web.  It would be nice and beneficial
> for such services to be so, but it isn't necessary for the health of
> the rest of the Web.

The examples above demonstrate, I believe, that SOAP and URIs are not
commonly used in this way by Web services developers.

> Furthermore, it is necessary that the
> messages be stateless (carry all of the semantics for each request
> within the request message)

SOAP 1.2 does not include any feature that prevents the message from
being stateless.

> and that when a failure or redirection
> occurs, the appropriate HTTP response code be given in the HTTP
> envelope,

Much discussion happened early on regarding this issue.  In the end, the
group decided that the HTTP binding would reuse the appropriate HTTP
response code.

http://www.w3.org/2000/xp/Group/xmlp-issues#x12

Then came a related issue, which was how SOAP faults should be
recognized.  The resolution isn't as strong as I'd like, but it
represents concensus;

http://www.w3.org/2000/xp/Group/xmlp-issues#x192

> and also the appropriate cache-control mechanisms be
> included -- not at random, or by fiat of some clueless gateway
> interface, but by actually inspecting the SOAP response for the
> corresponding semantics and mapping those back out to the HTTP binding.

The HTTP binding includes no cache-control directives at all.  Since it
is a POST binding, I believe this to be correct.

> As a *separate* issue, Web Services cannot be considered an equal
> part of the Web until they allow their own resources to become
> interconnected with the rest of the Web.  That means using URI to
> identify all important resources, even if those URI are only used
> via non-SOAP mechanisms (such as a parallel HTTP GET interface) after
> the SOAPified processing is complete.  The reason to do so is solely
> for the benefit of those Web Services; so that they can participate
> in the unforeseen ways in which the Web allows resources to be shared.
> That is the principle of the Web architecture that I absolutely refuse
> to water-down for the sake of any technology.

As I also participate in the Web Services Architecture WG, I can state
that from what I've heard there, there is a very real chance that we
will produce something that is incompatible with this view, unless
something is done to educate the group about Web architecture.  I have
expressed my concerns about this to the chair, Chris Ferris.

> However, it is also a
> principle that SOAP, just like HTTP, can only encourage -- it is a
> byproduct of good information design, rather than a mandate of the
> protocol.  Mind you, it does require SOAP to be able to do things
> like allow the SOAP sender tell the SOAP receiver about the URI.

I'm unclear what you mean by that last sentence.

MB
-- 
Mark Baker, Chief Science Officer, Planetfred, Inc.
Ottawa, Ontario, CANADA.      mbaker@planetfred.com
http://www.markbaker.ca   http://www.planetfred.com

Received on Saturday, 27 April 2002 22:39:04 UTC