Re: [xml-dev] The association of SOA with SOAP, and to the inevitable en

["Fraser Goffin" <goffinf@googlemail.com>]

Noah,

 

thanks for the links to the W3C Workshop on Web of Services for Enterprise Computing, I hadn't seen this stuff before, most interesting.

 

As far as heat-to-light, I agree, it was causing 'heat' by provocative statements that I was arguing to stop (but I don't think in this case it was Bryan's intention - so maybe I'm getting too sensitive). I think the follow-up emails had much less of this though even if they perhaps in parts contain mis-informed commentary.  As far as 'light' is concerned, well ... we're not all experts and open debates which reveal that and allow others to help correct mis-understanding are useful to me at least, and I expect to others.

Whilst I work predominantly in the enterprise space and in communities where SOAP/WS* are, for good or bad, the accepted approach, when I read about REST I sometimes feel that these use cases are ignored. There are lots of reasons why solutions end up the way they do, often as an accident of history. But when things work (adequately) there is no practical money for rip and replace. We all still use COBOL right ? I'm with Len on this question, but I fully accept different communities have different concerns and pressurs, and ultimately may have the wear-with-all to make different technology choices. Whilst I appreciate that most people on this list tend towards technical pro's/cons', who's paying the bill is often much more pertinent. No-one is giving me a blank check and IT typically can't fund itself.

 

I too think REST has a bunch of things going for it, but at the same time, its no more a silver bullet than people once thought SOAP/WS*/SOA was/is.

 

Fraser.

 

On 05/12/2007, noah_mendelsohn@us.ibm.com <noah_mendelsohn@us.ibm.com > wrote:

Bryan Rasmussen writes:

> That SOAP did not identify bindings for GET was I think its downfall
> (sorry, I believe in the war metaphor).

Oh, come on.  The tone of this discussion is pretty disappointing for a variety of reasons, but if you make a statement like this please at least read the pertinent specifications.  Quoting what is probably the most relevant part of the SOAP 1.2 Recommendation [1]:

--------

4.1.2 Distinguishing Resource Retrievals from other RPCs

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:

• The conventions described in 4.1.1 Identification of RPC Resources 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 6.4 SOAP Web Method Feature and the 6.3 SOAP Response Message Exchange Pattern 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 4.2.2 RPC Response
• 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 6.4 SOAP Web Method Feature and the 6.2 SOAP Request-Response Message Exchange Pattern are used. The request envelope is encoded as described in 4.2.1 RPC Invocation, and the results are as described in 4.2.2 RPC Response. The http://www.w3.org/2003/05/soap/features/web-method/Method property is set to "POST".

The SOAP RPC Representation does not define any other value for the http://www.w3.org/2003/05/soap/features/web-method/Method .

--------

Also [2]:

7.1.3 Interoperability with non-SOAP HTTP Implementations

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
--------------------------------------