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

noah_mendelsohn@us.ibm.com wrote:
>>I would like to put forward a fifth option that was outlined in [1] -- 
> 
> the No-MEP option.
> 
> Whatever the other merits of this proposal, I think it is way beyond an 
> erratum, as the existing HTTP binding clearly implements MEPs. 
> Accordingly, I think going this route would take us back through a full 
> CR/PR cycle, and should IMO result in a change of name to SOAP 1.3 or 
> maybe somethink like SOAP 1.2b or SOAP 1.2.1 if W3C naming conventions 
> allow.  

I did not intend to mean that this is errata work.
My understanding was that the 4 options were for the new work in our 
recharter. I was addition a 5th option for the new work.

> So, I think the need to do all that is a drawback of this 
> approach.   The question is:  is this the right way, and by a sufficient 
> degree to merit that work?  I'm not personally convinced at the moment, 
> but I'm certainly open to convincing.  Or maybe I'm wrong and it is an 
> erratum, but right now it doesn't look like one to me.  BTW:  is the 
> proposal to rewrite SOAP to not have MEPs at all, or to have them but not 
> use them in our one normative binding?  I think it's an important 
> distinction.
> 

The proposal was to not use SOAP MEPs in our new binding work that we 
have undertaken without rewriting SOAP.

> --------------------------------------
> Noah Mendelsohn 
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
> 
> 
> 
> 
> 
> 
> 
> 
> Anish Karmarkar <Anish.Karmarkar@oracle.com>
> Sent by: xml-dist-app-request@w3.org
> 12/21/05 02:12 AM
>  
>         To:     David Hull <dmh@tibco.com>
>         cc:     xml-dist-app@w3.org
>         Subject:        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 16:43:19 UTC