The World Wide Web depends on mechanisms that optimize commonly performed information retrieval tasks. Specifically, protocols such as HTTP [RFC 2616] 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:
Particularly when used with the 6.3 SOAP Response Message Exchange Pattern, 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 [SOAP
Part 1] Binding
to Application-Specific Protocols).
--------
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
--------------------------------------