I've come to a conclusion that the Web services community needs a simpler and yet more powerful way of describing bindings and message exchanges patterns. I've been working for a while now on asynchronous Web services, and it turns out to be quite difficult to describe What's Going On.
As part of the Async Task force at W3C, I've written an async scenarios document [1] and 2 meps and bindings using the binding framework [2], [3]. The current SOAP 1.2 Convention for describing Features and Bindings [4] does not seem to add significant value, rather it makes the process significantly more difficult.
My call is for a simplified binding and mep conventions and a new MEP and binding [5]. This could be standalone or could be an errata to SOAP 1.2. I think it could be SOAP 1.2 errata because it doesn't change any of the bytes on the wire and I don't think that are any bindings that would be broken by changing the conventions.
For context, the binding framework was created by the SOAP 1.2 working group to describe protocol aspects of SOAP, particularly a clear description of the on-the-wire expectations for binding to protocols like HTTP. The Message Exchange Patterns introduced are request-response and soap-response, and then these are specified for HTTP GET and HTTP POST. The MEPs contain a state machine for senders and receivers as well as specific properties (like request message, response message, status). The state machine and properties are used and augmented by the binding to fully specify the behaviour for a given protocol, such as HTTP.
It is roughly a goal that there will be "fewer" bindings rather than more, that is there won't be a large number of bindings for HTTP.
Two points of note: 1) with all irony, SOAP is about single one-way messages but it doesn't provide a binding for one-way messaging over HTTP. 2) There is partial support for HTTP, which is accomplished by the "soap-response" MEP and use of HTTP GET.
Some of the advantages that the binding framework ought to offer, but don't:
1. Re-use of the MEP state machines
The state machines defined in the MEP ought to be re-usable in different bindings. However, the reality is that there have been very few bindings formally written, and I have not seen one that actually re-uses the state machine. Further, the state machines as designed were not re-usable. To describe HTTP GET requests returning a SOAP body, the soap-response MEP was created. SOAP had a request-response MEP and HTTP POST described, but the solution for HTTP GET didn't re-use the request-response MEP. This obviously affected the binding. This soap-response MEP has not been re-used ever as far as I know, and introduced further complexity into the SOAP HTTP Binding because it requires that the HTTP binding deal with 2 different MEPs.
2. Re-use of bindings
Adding a one-way MEP without changing the HTTP Binding is not possible, in a strict interpretation of the wording of the binding. Therefore the SOAP HTTP Binding re-use was never achieved.
3. Re-use and extensibility of threading model
The state machines are roughly written as a single threaded process. From the receiver perspective, there are roughly 2 separate threads that are important: receiving the request and sending the response. The MEP design combines these states into states for each combination, ie receiving or sending/receiving. Then the binding has to combine these states together. There is no benefit to separating then combining these states together.
The matter is further complicated when WS-Addressing ReplyTo or FaultTo are introduced. It may be very well possible for a receiver to have a new thread, which is the sending to the ReplyTo or FaultTo address, even while it is still in the receiving or sending/receiving state with the initial sender. Using a SOAP request-response MEP over 2 HTTP connections actually may involve 3 separate "threads". This is even more difficult to describe in the MEP given the parallel nature of the threads. For example, at what point in the receiving state machine is the receiver allowed to open a new connection are start sending a message? In reality, it could happen during the receiving, the sending/receiving, or after the terminate state.
Attempting to describe such an asynchronous callback is thus quite difficult in the binding framework. We have agreement on how the messages appear on the wire and how they are described in WSDL, so it is the binding framework that "gets in the way".
4. Implementation Reality
I believe the reality of implementations have implemented a request-optional-response MEP. There is no proof that any software will actually fault if a response is not received. The tightly specified nature of the request-response MEP has not been implemented or proven useful.
5. Web architecture
The soap binding conventions made it difficult to add support for HTTP GET. This solution of the SOAP-response MEP solution has not been adopted to any serious degree. Further, adding support for other HTTP methods, like HTTP PUT, is not possible using the current MEP and binding. A solution that does not constrain the MEP to exactly which message directions are required and which are SOAP messages is more extensible.
WS-Addressing ReplyTo
WS-Addressing ReplyTo provides an illustration of the problem. We know what the WSDL is and what the HTTP messages look like. Does a WSDL request-response which has a ReplyTo value (and so uses 2 HTTP connections) map to: a) one SOAP request-response MEP and then a new binding that supports 2 HTTP connections OR b) two SOAP one-way MEPs and 2 instance of a new one-way HTTP Binding for each connection? To a certain extent, is the "soap" mep layer closer to the WSDL( 1 SOAP request-response) or closer to the protocol ( 2 soap meps for 2 protocol connections). There are pros and cons to both approaches, but remember: we know what the WSDL and the HTTP messages look like so we're just shuffling bits in the abstract specifications.
This dissertation then begs the question: what is useful in a binding framework?
Properties
The properties that contain the request, response, status code, and availability of response are useful for bindings to use. Otherwise, each binding would have it's own property for these. When the WSDL request-response is mapped to "something", it shouldn't map to a specific protocol, like "HTTP request" and "HTTP Response". Defining and re-using these properties is a useful layer between WSDL and the protocol. Describing these properties without coupling them to SOAP also makes it possible to mix SOAP messages with protocol messages, such as HTTP GET, in a simple manner.
Simple state machine
A simple state machine that says that a request is followed by a response, with an indication of when the response is available for processing by the sender or receiver provides sufficient utility to create bindings. This would have enabled a "request-response" MEP to be bound to HTTP GET as well.
This simplified approach to describing bindings as well as a simpler MEP and Binding is described in the Simplified MEP and Binding proposal [5]
[1] http://www.pacificspirit.com/Authoring/async/async-scenarios.html
Comments (1)
I do agree with the need for a simpler way. Do you think the WS-ADDRESSING spec will address the maintenance of the multiple reply-to endpoints in a multi-hop MEP? Would this data be stored in the WS-ADDRESSING payload or in a state machine. Specifically, I'm talking about MQSeries request messages passing through WBIMB hub to a service responder. Where is the orginal requestor's data stored, once the hub sends the request on to the intended responder?
Posted by Bob VanOrsdale | December 15, 2005 9:36 AM
Posted on December 15, 2005 09:36