WebServices dot org

Message Exchange Patterns and Flavours of "One-Way" Messaging

We've had WSDL one-way messages, but then we fall off the map when it comes to SOAP because we don't actually have a fully standardized SOAP one-way binding. Interestingly, lots of people use the WS-I Basic Profile which allows an empty HTTP Response, but let's talk in the context of W3C and WS-Addressing, SOAP, WSDL stds specs..

To do one-way, we need both SOAP 1.1 and SOAP 1.2. SOAP 1.1 should be fairly straightforward - allow a 202 with an empty http response body. I've written up such a beast that is straight up one-way and a more popular variant that allows for a response .

SOAP 1.2 is a much more complex case because SOAP 1.2 introduced the notion of SOAP message exchange patterns. Now ironically and frustratingly, the "one-way" SOAP 1.2 never defined a one-way MEP. We are now *finally* doing that work in XMLP and WS-A, mostly because a number of us got really agitated on WS-Addressing land and said "one-way" is in scope for WS-A, so do it somewhere. The SOAP 1.2 MEP notation style specifies a detailed state machine for each MEP, particulary the request-response.

This has led us into some interesting issues: What are the various flavours of One-way particularly Fire and Forget, and how many MEPs do we need? In fact, what does F-A-F really mean? Does F-A-F mean that the sender can close the connection as soon as it has placed the message on the connection? Does it mean that the receiver can close the connection as soon as it has received the message? That is, who's "forget" is it? And how does this all relate to HTTP? How does all this get described in WSDL?

There seem to be two camps emerging, what I call the "strongly-typed" mep and the "weakly-typed" mep. The strongly typed camp says that each mep ideally has no optionality. Roughly, for each combination of messages introduce a new MEP. In addition to the request-response MEP, introduce a F-A-F MEP, introduce a request-optional-protocol response mep, etc. Then each binding is constrained by what it can do. I wrote up a one-way MEP with a binding in December 2004

One thing pops out of this analysis, is that an HTTP binding cannot implement a true client F-A-F. HTTP is a request-response protocol as the client MUST wait for a response. Therefore a F-A-F MEP couldn't be implemented using HTTP. HTTP could implement any kind of MEP that allowed required a protocol response, such as a request-response, request-optional-soap-response, or request-nosoap-response-but-protocol-response.... From the binding perspective, it's easy to write bindings for the MEPs because there is no variability in the aspects of the message cardinality.

This gets to the core of my disagreement with the "strongly-typed" meps. I proposed what I call a protocol mep , aka weakly typed mep, which is basically coming up with a single mep that covers all variants. Incidentally, I propose removing all the state machine gorp from the mep. The problem that I see is that I think looking from the application down is very important. When a WSDL author decides they want a "one-way" message, I don't think they want to have to look to each binding to see which flavour of MEP it supports. If I define a one-way message, why do I want to peek into each binding to see which MEPs it supports? If I offer my one-way message over UDP and over HTTP, why do I want 1 version that is f-a-f, and another that is request-optional-protocol response?

WSDL has cleanly separated the "abstract" operation out from the binding. There is a "SOAP binding" section in both wsdl 1.1 and wsdl 2.0. WSDL 2.0 allows me the choice of which MEP is associated with an operation. With strongly typed MEPs, I have to do multiple SOAP bindings per different MEP.

The core of this problem is that SOAP meps tried to abstract things from underlying protocols - that's a big reason why SOAP is a protocol and not a format BTW, the addition of the MEPs is a key part of this. My opinion is that this abstraction hasn't provided any utility. Using the previous example, we have a SOAP binding that is supposed to be protocol independent, but now I'd need a SOAP binding for each type of underlying protocol. Yuck!

Effectively, I think that we should get rid of the SOAP MEPs and the way to do that is to come up with one MEP that provides an abstraction of all underlying protocols for giving us properties for the request, response, results, destination, etc. I still think some kind of abstraction is necessary to insulate the WSDL from the particular binding. With a layer of abstraction, you can write a binding (like my sample SOAP 1.1 HTTP binding using protocol MEP ) independent of WSDL, you can write WSDL and extensions independent of any particular binding (like my proposal for WS-Addressing usingAddressing extension and WSDL 2.0's binding WSDL 2.0 MEPs to SOAP 1.2 MEPs

So I like having some kind of abstraction above the protocol, which is why I favour some kind of MEP abstraction. The key question is, given a "weakly typed" mep, how does a sender and a receiver know when they can close the connection? In the strongly typed mep, it is specified in the MEP. In the weakly typed mep, I believe that this is controlled by a combination of the application and the binding. Imagine that a receiver is using HTTP, SOAP and WS-Addressing. The receiver is going to have to look at the message to see what all the *To properties are. If there's a ReplyTo and FaultTo that is non-anonymous, the receiver will know that it can close the connection before the application creates a response.

This is the crux of my issue with the question about receivers "knowing", is that it asks the question the wrong way around. The data needed for a receiver to "know" can be in the message. Therefore trying to say the receiver will "know" ahead of time based upon the MEP is just plain wrong. It leads down bizarre paths like "If the ReplyTo is anonymous then the soap mep is request response else if the replyTo is non-anonymous then the soap mep is f-a-f if the protocol is not http else the mep is request-optional-response if the protocol is http. If the mep is f-a-f then close the connection, etc. ". The whole point of doing things "strongly" or "statically" is that there's something known up front, but with data driven protocol interactions supported by WS-A et al, this is just plain broken. Instead of the previous, I propose "The mep is request-optional-response. If protocol is HTTP and replyTo is anonymous, wait for response from application. Else don't wait.".

This makes the WSDL authors life easier, and it correctly places the burden on the receiver to look at the message for how to know when to close the connection, without some arbitrary and complex strongly typed mep in the middle.