- From: David Hull <dmh@tibco.com>
- Date: Wed, 21 Dec 2005 11:24:35 -0500
- To: noah_mendelsohn@us.ibm.com
- Cc: Anish Karmarkar <Anish.Karmarkar@oracle.com>, xml-dist-app@w3.org
- Message-id: <43A981C3.6010507@tibco.com>
The idea behind DH2 was to leave the existing SOAP MEPs and binding
(bindings?) in place exactly as-is, but to define a more flexible
framework in which the existing MEPs and bindings fall out as special
cases. The extended framework allows for one-way messaging, tunneling
(with PAOS-like behavior also falling out as a special case) mixing SOAP
and non-SOAP (e.g., SOAP request and binary reply) and quite a bit more.
You /could/ just go with this framework and deprecate the existing SOAP
MEPs, but there is no need to since you provably get the same semantics
either way. Put another way, the existing SOAP MEPs still exist, but
they're no longer primitive. I've likened it to moving from Newtonian
mechanics to relativity, albeit on a much less grand stage.
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. 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.
>
>--------------------------------------
>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:25:08 UTC