Re: Approaches to SOAP MEPs and WSD/WSA requirements

On Tue, 25 Oct 2005, Anish Karmarkar wrote:

> 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
Yes, but at least you _can_ link a HTTP request/reply to a SOAP 
request/reply "natively". If you remove the notion of SOAP level MEP, then 
you pretty much end in tunneling

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

Well, no. If WS-Addressing is in use, then the description should indicate 
that multiple SOAP level MEP might be used.

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

I don't see the point of using wsa in that case.

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

In that cas you are defining an exchange involving 2 MEPs between 3 SOAP 
nodes, even if you are able to model this as a request/response in WSDL. 
Those are at different level and should not be mixed. Also having the 
message in an HTTP response or in a HTTP request has not the same 
semantic. If you say that they are equivalent because you just want to 
send the message, you are doing tunneling.

-- 
Yves Lafon - W3C
"Baroula que barouleras, au tiéu toujou t'entourneras."