[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

Re: The association of SOA with SOAP, and to the inevitable en

• From: noah_mendelsohn@u...
• To: "bryan rasmussen" <rasmussen.bryan@g...>
• Date: Wed, 5 Dec 2007 09:54:03 -0500

The World Wide Web depends on mechanisms that optimize commonly performed information retrieval tasks. Specifically, protocols such as HTTP http://www.w3.org/TR/soap12-part2/#RFC2616 provide a GET method which is used to perform safe retrievals, i.e., to perform retrievals that are idempotent, free of side effects, and for which security considerations do not preclude the use of cached results or URI-based resource identification.

Certain procedure or method calls represent requests for information retrieval. For example, the call:

getQuantityInStock(PartNumber="123")

might be used to retrieve the quantity established in the example above.

The following conventions can be employed to implement SOAP retrievals and other RPCs on the Web:

• The conventions described in http://www.w3.org/TR/soap12-part2/#RPCWebArguments are used to identify the resource with a URI.
• In cases where all the arguments have been represented in the URI, no SOAP header blocks are to be transmitted and the operation is a safe retrieval, the http://www.w3.org/TR/soap12-part2/#WebMethodFeature and the http://www.w3.org/TR/soap12-part2/#soapresmep are used. Accordingly, no SOAP envelope is transmitted for the request, and the http://www.w3.org/2003/05/soap/features/web-method/Method property is set to "GET". The results of the retrieval are a SOAP RPC response as described in http://www.w3.org/TR/soap12-part2/#rpcresponse
• In cases where the operation to be performed is not a retrieval, when SOAP header blocks are to be transmitted (a digital signature, for example), or when a retrieval is not safe, the http://www.w3.org/TR/soap12-part2/#WebMethodFeature and the http://www.w3.org/TR/soap12-part2/#singlereqrespmep are used. The request envelope is encoded as described in http://www.w3.org/TR/soap12-part2/#rpcinvocation, and the results are as described in http://www.w3.org/TR/soap12-part2/#rpcresponse. The http://www.w3.org/2003/05/soap/features/web-method/Method property is set to "POST".

Particularly when used with the http://www.w3.org/TR/soap12-part2/#soapresmep, the HTTP messages produced by this binding are likely to be indistinguishable from those produced by non-SOAP implementations performing similar operations. Accordingly, some degree of interoperation can be made possible between SOAP nodes and other HTTP implementations when using this binding. For example, a conventional Web server (i.e., one not written specifically to conform to this specification) might be used to respond to SOAP-initiated HTTP GET's with representations of Content-Type "application/soap+xml". Such interoperation is not a normative feature of this specification.

Even though HTTP often is used on the well-known TCP port 80, the use of HTTP is not limited to that port. As a result, it is possible to have a dedicated HTTP server for handling SOAP processing on a distinct TCP port. Alternatively, it is possible to use a separate virtual host for dealing with SOAP processing. Such configuration, however, is a matter of convenience and is not a requirement of this specification (see SOAP 1.2 Part 1 http://www.w3.org/TR/soap12-part2/#SOAP-PART1 http://www.w3.org/TR/2007/REC-soap12-part1-20070427/#secbindappspecprot).

--------

We worked very hard to add this support.   In case the above isn't quite clear, let me summarize the essence:  A SOAP envelope has a media type (application/soap+xml).   You can and should use it just as you would another media type.  For example, if you want to return a stock quote, but want to put in a SOAP header that indicates with a digital signature "this quote is sourced by XYZ Investments Corp. and this digital signature prevents XYZ Corp from repudiating it"), all you have to do is make up the appropriate SOAP envelope with the quote in the body and the signature in a standard SOAP header, mint a URI for the stock quote resource, and return then envelope using HTTP GET when asked.

It is true, and very much a shame IMO, that many of the commercial implementations fail to support this GET pattern, and/or that much of the tooling around SOAP doesn't exploit it.  Supporting GET is the easy part;  the hard part is building tooling that uses URIs in the right way so that each stock quote gets its own, as opposed to just having one "QuotesRUS" URI that serves lots of quotes.

So, there are serious issues about how the SOAP implementation community has failed to provide the RESTful features of the SOAP Recommendation, but to say that "SOAP did not identify bindings for GET" demonstrates lack of knowledge of the pertinent specifications.  The specifications are there.  If users of WS* want this, they should scream at their vendors to implement it.  By the way, that non-repudiated stock quote is an example of something that HTTPS, the usual security answer from the REST community, doesn't even try to provide.

Just to be clear:  I'm a big fan of REST for what it does well.  I spend a lot of my time on the TAG defending it and/or clarifying it, and I was among those who worked very hard before the SOAP Recommendation was published to put in those REST features.  I also think there are many things SOAP does for which REST does not at this point provide interoperable standards (specifically, a header model with distributed extensibility, I.e. one that lets you invent your own URI-qualified headers, and with a rigorous set of processing rules for them. and also support for transports like reliable queuing systems such as JMS, WebSphere MQ, etc.)  REST is also at the moment a stretch for transactions that take 5 days to complete, etc. (please order these items and respond when they ship).  I have many problems with how the upper level parts of the WS* stack were built, and some problems with SOAP itself, but I think there are important use cases that the current REST embodiments don't even try to address.

By the way, a lot of this was discussed quite rationally and in some depth at the W3C Workshop on Web of Services for Enterprise Computing held last year.  Many REST and WS* experts/advocates participated, including some such as Mark Baker who have been mentioned in this thread.  Minutes are at [3] and a final report at [4].  I think it might be worthwhile, before this debate goes too much further here, for those involved to review what was covered there.  I think the light/heat ratio might improve a bit.

Noah

[1] http://www.w3.org/TR/soap12-part2/#RPCResourceRetrieval
[2] http://www.w3.org/TR/soap12-part2/#httpinterop
[3] http://www.w3.org/2007/02/wsec-minutes.html
[4] http://www.w3.org/2007/04/wsec_report.html


--------------------------------------
Noah Mendelsohn
IBM Corporation
One Rogers Street
Cambridge, MA 02142
1-617-693-4036
--------------------------------------

• Follow-Ups:
  • Re: The association of SOA with SOAP, and to the inevitable ends of religious wars
    • From: "Fraser Goffin" <goffinf@g...>
  • Re: The association of SOA with SOAP, and to the inevitable ends of religious wars
    • From: "bryan rasmussen" <rasmussen.bryan@g...>

• References:
  • Re: The association of SOA with SOAP, and to the inevitable ends of religious wars
    • From: "bryan rasmussen" <rasmussen.bryan@g...>