Re: [Fwd: Toward more fully-formed options]

I would like to put forward a fifth option that was outlined in [1] -- 
the No-MEP option.

After having conversations with Chris (who has been championing this 
option) and thinking about it more, it seems to me that SOAP MEPs hinder 
more than help when you put WSDL MEPs, WS-Addressing, Application-level 
MEPs in the mix (too many turtles all the way down [2] ;-) ).

SOAP MEPs are abstract transport-independent templates that establish a 
pattern for the exchange of messages between SOAP Nodes. But SOAP MEPs 
that we have created (Req-Res and SOAP-Res) are geared toward transports 
which are inherently req-res (HTTP). As such the applicability of these 
SOAP MEPs is limited to certain kinds of transports and not all 
transports. That is itself is not a bad thing. But even when a SOAP MEPs 
exists, one still has to specify how the SOAP MEP is bound to a specific 
transport in the transport binding spec. The existence of MEPs does not 
in any way simplify the binding specification, in fact makes it a little 
complicated.

What do such abstract SOAP MEPs add? We already have WSDL MEPs which are 
indeed a different beast than SOAP MEPs, and there also exists 
application level MEPs which may be different than a WSDL MEP (for 
example, an application MEP may correlate a 2 WSDL one-way MEPs into a 
req-res application-level MEP). Abstract SOAP MEPs were meant to allow 
one to figure out the message exchange without having to know the 
underlying transport. But in practice that is not how most 
implementations work. The SOAP sender/receiver have to agree/know on 
what the message exchange is going to look like along with how the SOAP 
messages would be sent on the selected transport. For that either there 
is an out-of-band agreement (policy/metadata/whatever) or a WSDL (or 
some other description) available. It is such WSDL descriptions (include 
WSDL MEPs, bindings etc) that provide the information such as whether a 
response is expected/required. The transport binding along with run-time 
WS-Addressing related constructs such as EPRs (ReplyTo, FaultTo, AcksTo) 
provide the information about how the message(s) are transfered from one 
end to another (and back).

This, I think (but not sure), is similar to DH2 proposal at [3], but 
goes further and eliminates SOAP MEPs.

-Anish
--

[1] 
http://lists.w3.org/Archives/Public/xml-dist-app/2005Oct/att-0011/00-part
[2] http://en.wikipedia.org/wiki/Turtles_all_the_way_down
[3] 
http://lists.w3.org/Archives/Public/public-ws-addressing/2005Sep/0045.html

David Hull wrote:
> 
> ------------------------------------------------------------------------
> 
> Subject:
> Toward more fully-formed options
> From:
> David Hull <dmh@tibco.com>
> Date:
> Wed, 14 Dec 2005 00:28:35 -0500
> To:
> w3c-xml-protocol-wg@w3.org
> 
> To:
> w3c-xml-protocol-wg@w3.org
> 
> 
> First, here are some basic facts I believe we are trying to account for:
> 
>    1. An HTTP interaction always consists of a request message and a
>       response message, though neither need contain a SOAP envelope. 
>       There may be other transports (actual or anticipated) with the
>       same behavior.
>    2. There are transports (actual or anticipated) which are inherently
>       fire-and-forget.  In such a case, a request-response MEP must be
>       built from one-way messages (using, say, WSA).
>    3. Depending on the WSDL MEP and response endpoints in the inbound
>       message any of the following may hold
>          1. The sender of the inbound message will know that it will
>             receive no SOAP response message over the connection used to
>             send the inbound message (this is always the case over a
>             fire-and-forget transport).
>          2. The sender of the inbound message will expect a SOAP
>             response message over the same connection.
>          3. The sender of the inbound message may or may not receive a
>             SOAP response over the same connection, depending on the
>             application logic of the receiver.
>    4. In case 3.3, some sort of acknowledgment is needed if no SOAP
>       response occurs, for example, an empty 2xx response in HTTP.
>    5. Transport failures may occur anywhere, including an in-only MEP
>       over a fire-and-forget transport.  If this is to be considered as
>       a SOAP message, each subitem of 3 will need to be amended in a
>       tedious but straightforward way.
> 
> The following table attempts to summarize how the various proposals 
> address these facts.  I believe the handling (5) is orthogonal to 
> everything else, so I've omitted it.  Please read "HTTP" as "HTTP or 
> similar request-response transport. Please take this as a sketch and 
> feel free to correct any errors or inadvertent misrepresentations.  In 
> particular, I don't feel qualified to speak for the "über-MEP" proposal, 
> though I've taken my best guess:
> 
> *Proposal*
> 	*1 (HTTP req-rep)*
> 	*2 (Fire and Forget)*
> 	*3 (dynamically variable number of SOAP messages)*
> 	*4 (ack needed)*
> Define request-response /or/ one-way, per transport ("DH1")
> 	HTTP  interaction  is  /always/ SOAP request-response MEP 	Always 
> one-way SOAP MEP
> 	One SOAP MEP per transport-level exchange
> 	Ack is a special SOAP message
> One-way everywhere, request-response where supported. ("DH2")
> 	HTTP interaction is SOAP request-response MEP if response message 
> contains SOAP, one-way otherwise
> 	Always one-way SOAP MEP
> 	One one-way MEP per WSDL message, unless transport is request-response 
> and SOAP response was sent.
> 	Ack is transport-level, presence indicates one-way MEP
> SOAP-level in-optional-out
> 	HTTP interaction is always in-optional-out, with "out" occurring if 
> SOAP response is sent.
> 	Always in-optional-out SOAP MEP without "out"
> 	One MEP per WSDL MEP, "out" present if transport is request-response 
> and a SOAP response was sent
> 	Ack is transport-level, presence indicates no "out"
> Transport-level in-optional-out ("über-MEP")
> 	(?) HTTP interaction  is in-optional-out with "out" always present.  
> "out" may or may not be SOAP.
> 	Always in-optional-out without "out"
> 	(?) "out" message may be absent or may not be SOAP
> 	(?) Ack is a distinguished "out" message.
> 
>

Received on Wednesday, 21 December 2005 07:13:11 UTC