Operation names in WSDL: choices, choices, choices

The WSDL WG is currently working on the description of bindings for Web services. We've started working on some interesting issues and potential solutions around the relationship between application operations in either a generic or specific method interface, and the underlying protocol. I'm going to expand on the solution space I first proposed in http://lists.w3.org/Archives/Public/www-ws-desc/2004Apr/0004.html.

Let's take it for now that there is market pressure to fully utlize HTTP as a transfer protocol in Web services. That's an important debate (!) but I only want to look at the solution space in this entry. What I mean by a transfer protocol is, well, what HTTP means. It's the protocol used to transfer application state between nodes. So to fully utilize HTTP as a transfer protocol means to fully utilize the features of HTTP, specifically the various methods it has.

Contrast this with the predominant state of Web services, where most services send SOAP messages through the HTTP POST method, with the operation name encoded in a variety of places in the message. It's another interesting yet tangental debate about whether POST is used primarily for the "feature" of firewall tunnelling, or some other reason.

These two uses of HTTP will be the end points of our spectrum of solutions for web services and HTTP. On one side is "strict" HTTP. There are NO application methods allowed, just HTTP. There is no "binding" per se, because the application operations ARE HTTP. On the other side is the "HTTP as transport". The application methods are all custom and when bound to HTTP, use HTTP POST.

Many people believe that these are the only 2 positions. It turns out there are a few other important combinations of application operations and protocol operations. We can see the combinations by examing the 2 different axes that can be mixed. The first axis is the style of application operations, and the second is the usage of the underlying protocol operations. There are 2 styles of application operations: generic or custom. By generic, we mean that they are constrained to a small set of operations, typically the CRUD methods (Create/Read/Update/Delete). The Web has been built upon an architecture style with generic operations, as well as other constraints. This style is called REST - Representational State Transfer. The converse then is custom operations, where the application can create arbitrary operation names.

It should be noted that the use of generic versus custom operations is not mutually exclusive. One could easily see a scenario where an application wanted a variety of "GET" methods, but also needs to indicate that they are all follow the "GET" semantics of REST. One could argue that the "binding" should take care of this, but having the 2 operation names on a given operation means that they can be re-used for either multiple bindings to a given protocol or for use with protocols that do not have generic interfaces.

The usage of the underlying protocol is straightforward. The WSDL 1.1 SOAP HTTP binding only uses the POST method. It is obvious that an application may want to use other HTTP methods than POST.

Given these 2 axes, the solution space is roughly:

1. App protocol (custom) + HTTP as Transport.
The current WSDL 1.1 SOAP HTTP binding, and uses HTTP POST. The operation name is encoded either in the message content (RPC), an HTTP header (soap:action) or a SOAP header (WSA:Action).

2. App protocol (custom) + HTTP as Transfer
This allows the specification of an HTTP method for each application operation. This is in the editor's draft of the WSDL 2.0 Part 3: bindings document.

There may be some additional trickiness in encoding the operation name in the request. The client will probably have to follow an algorithm for ensuring that the request is self-describing, that is it contains the custom operation name. It may very well be that the URI used by HTTP will contain the operation name. For example,

<interface>
<operation name="getFoo"/>

may only be allowed on URIs that are of the form
http://foo.org/Foo
and thus the "type" of the operation is actually embedded in the identifier for the resource. I proposed one algorithm for this in my proposal on SOAP HTTP GET binding a few years ago.

3. App protocol (generic) + HTTP as Transfer.
ATOM uses this style as it's basis. IF WSDL provided a definition of the the generic operations for applications, then WSDL could also probably a direct mapping to HTTP for the generic operations. One solution is a "REST" interface with the GET/PUT/DELETE/POST operations.

4. App protocol (generic) + HTTP as Transport.
On the face of it, this seems like a strange scenario. This uses HTTP POST to contain HTTP methods. However, the ATOM specification has to do exactly this because sometimes DELETE and PUT cannot go through HTTP firewalls. Further, HTTP does not have a "GET" operation that can contain a body, such as an XML Query. Therefore the XQuery must be encoded in an HTTP POST request somehow, perhaps with a special soap header as I suggested in XQuery:Meet the Web

5. App protocol (generic + custom) + HTTP as Transfer.
This would probably a direct mapping to HTTP for the generic operations. The same issues raised earlier about encoding operation name(s) in the request apply.

6. App protocol (generic + custom) + HTTP as Transport.
This is a combination of scenarios 4 and 5, with the additional complexity of determining how the HTTP POST request should contain the operation name(s).

We see that there are 6 different possibilities for describing an applicaiton operation name(s) and binding to HTTP. I believe all 6 are useful, but methinks that the last 2 ( or 3 or 4) will take some time and a separate blog entry or 2 more fully describe.