All,

The editors (Chris, Dave and I) have had a few concalls to discuss how to satisfy WSD/WSA requirements wrt one-way/SOAP-request SOAP-MEP, as requested by the WG. The discussion revolved around how to satisfy the WSD/WSA requirements, how to make things easy to describe in WSDL, how to enable WS-Addressing to do various interesting things and the question of transport-level MEPs/SOAP-level MEPs/WSDL-level MEPS/Application-level MEPs and how all of this ties in together.

Two approaches have emerged from the discussions. The editors have not come to a consensus on a particular approach/recommendation and have decided that the best way forward would be to bring the two approaches to the WG's attention and have a discussion about these approaches in the WG. Below is a very brief summary of the two approaches. The summary does not cover all the details and may have missed key points (Chris/Dave, pl. do send corrections).

1) Über-MEP: Define an MEP that allows multiple optional input messages and multiple optional output message. Define a framework consisting of properties that allows one to constraint the number/optionality of input/output messages. By using these properties one can define in-out, in-only, out-only etc exchanges. These properties can be used to define transport bindings (including HTTP-binding). The properties can also be used by a WSDL document in its binding section, in conjunction with the über-MEP, to describe a specific MEP "instance" or interaction.

[Dave will be sending a separate email on this approach with more details (and perhaps corrections to my summary)]


2) No-MEP: Don't define an abstract SOAP MEP(s) which can be bound to various transports. Abstract SOAP MEPs are not useful because:

1. One still has to define how that SOAP MEP is used with a particular transport and
2. WS-Addressing provides a way to specify whether SOAP messages are sent on the transport-level back-channel or not, potentially modifying the abstract SOAP MEP.
   

Instead, we specify how SOAP messages are carried by specific transport-level messages. In the case of HTTP, we specify :
1) how HTTP requests can be sent with a SOAP env in its entity body, HTTP-methods allowed/required/disallowed, and constraints on HTTP header/values, if any.
2) how HTTP requests can be sent without a SOAP env in its entity body, HTTP-methods allowed/required/disallowed and constraints on HTTP header/values, if any.
3) how HTTP response can be sent with a SOAP env in its entity body and constraints on HTTP header/values, if any.
4) how HTTP response can be sent without a SOAP env in its entity body and constraints on HTTP header/values, if any.

The user of the HTTP transport binding decides which method to use, whether to have the SOAP env in the entity body or not. To that end, the WSDL description and/or WS-A headers may help constraint the HTTP-method, whether there is a SOAP env in the response etc. If needed, we may choose to define HTTP specific properties that can be used by WSDL descriptions to specify constraints such as: entity body of a HTTP response must/must not be empty.

Example 1:
A WSDL processor processes a WSDL containing a req-res WSDL MEP along with a SOAP/HTTP binding and decides to send a SOAP request over HTTP request, it includes the wsa:ReplyTo with a value of "anonymous". The service then responds with a HTTP response containing the SOAP response.

Example 2:
A WSDL processor processes a WSDL containing a req-res WSDL MEP along with a SOAP/HTTP binding and decides to send a SOAP request over HTTP request, it includes the wsa:ReplyTo with a value of non-"anonymous"-soap-http endpoint. The service then responds with a HTTP response containing an empty entity-body. The service also sends a HTTP request containing a SOAP response to the endpoint pointed to by wsa:ReplyTo. The endpoint pointed to by wsa:ReplyTo responds with a HTTP response containing an empty entity body.

Thanks.

-Anish
--