FW: Re: Comments on uber-MEP

Forwarding thread to public list... 

>-----Original Message-----
>From: w3c-xml-protocol-wg-request@w3.org 
>[mailto:w3c-xml-protocol-wg-request@w3.org] On Behalf Of ext 
>w3c-xml-protocol-wg-request@listhub.w3.org
>Sent: Tuesday, November 29, 2005 1:38 PM
>To: David Orchard
>Cc: w3c-xml-protocol-wg@w3.org
>Subject: Re: Comments on uber-MEP
>
>
>I took an action last week to further explain my concerns 
>about MEPs. Dave has quoted from the minutes:
>
><Yves> noah: not really happy with the no-MEP option. the way 
>a binding know how to send a message is a normative thing in 
>the spec. Saying it's in the rec but we won't use it would be 
>an issue <Yves> noah: there may be more protocols than HTTP 
>that supports natively request/response <Yves> and the soap 
>level MEP allow to abstract that <Yves> concern witht he 
>uber-MEP is that Request-reponse MEP is already there, adding 
>another MEP might introduce an incompatibility <Yves> also 
>adding too much possibilities may undermine its usefulness 
><Yves> for example if a request -response is expected and no 
>response comes, would that trigger a binding level fault? 
><scribe> ACTION: Noah to send email describing position on 
>uber MEP/no MEP/new MEP due 30 Nov [recorded in
>http://www.w3.org/2005/11/16-xmlprotocol-minutes.html#action02
>
>
>Perhaps the easiest way to do this is to respond to the 
>specifics of what Dave wrote in the attached note:
>
>> The uber-MEP is a protocol level MEP (and abstract from any 
>particular 
>> protocol)
>
>I think we should work with the terminology in the published 
>recommendations.  The definition of a "Message Exchance 
>Pattern" is at [1].  It says:
>
>3.2 SOAP Message Exchange Patterns (MEPs) A Message Exchange 
>Pattern (MEP) is a template that establishes a pattern for the 
>exchange of messages between SOAP nodes. MEPs are a type of 
>feature, and unless otherwise stated, references in this 
>specification to the term "feature" apply also to MEPs. The 
>request-response MEP specified in SOAP 1.2 Part 2 [SOAP Part 
>2] illustrates the specification of a MEP feature.
>The specification of a message exchange pattern MUST:
>As mandated by 3.1.1 Requirements on Features, provide a URI 
>to name the MEP.
>Describe the life cycle of a message exchange conforming to 
>the pattern.
>Describe the temporal/causal relationships, if any, of 
>multiple messages exchanged in conformance with the pattern 
>(e.g. responses follow requests and are sent to the originator 
>of the request.) Describe the normal and abnormal termination 
>of a message exchange conforming to the pattern.
>Underlying protocol binding specifications can declare their 
>support for one or more named MEPs.
>MEPs are SOAP features, so an MEP specification MUST conform 
>to the requirements for SOAP feature specifications (see 3.1.1 
>Requirements on Features). An MEP specification MUST also include:
>1.      Any requirements to generate additional messages (such as 
>responses to requests in a request/response MEP).
>2.      Rules for the delivery or other disposition of SOAP faults 
>generated during the operation of the MEP.
>
>
>I'm a little confused about your suggestion that the über MEP 
>is "protocol level".  My assumption is that the SOAP Rec says 
>what an MEP is, and we're trying to decide in this case how 
>many of them to have, with what semantics, and with what 
>relationship to the MEP's already included in the SOAP Recommendation.
>
>> and thus any protocol that supports request-response is handled. 
>
>Yes, but the concern is not whether protocols can be made to 
>work.  We can write a binding to a protocol and claim it 
>supports no MEPs and the protocol will work.  What will be 
>lost is the ability to say that two or more protocols provide 
>the same abstraction.  MEP's were invented, IMO, to insulate 
>applications from protocol details.  If you know that the 
>binding supports the existing Request/Response MEP, then you 
>very often can write your appliation without further detailed 
>knowledge of HTTP or another protocol.  You know to address a 
>request and wait for a response (which may be a fault). 
>
>While the über MEP is a contract of sorts, it is so loose as 
>to not be particularly helpful to an application.  Your 
>binding says "I support the über MEP". Good.  Do I send a 
>request?  Maybe.  Should I wait for a response?  Maybe.  Well, 
>I knew that without the MEP.
>
>Furthermore, the existing request/response MEP is  a normative 
>part of the recommendation, and I think it's appropriate that 
>we state clearly the relationship between the über MEP (if we 
>have it) and the existing MEP. 
>What does it mean for a binding to support both?  The original 
>MEP is more restrictive, so presumably such a binding requires 
>a request and a response anyway.
>
>> There will be another MEP anyways, so it's whether to have a 
>SOAP only
>MEP or have a more general MEP as the one new MEP. 
>
>There will?  As I understand the SOAP Extensibility Model the 
>intention is 
>that for any given interaction the sender and receiver should 
>agree on the 
>MEP.  Specfically, the original sender will use some local API 
>to tell the 
>binding something like "Send this as the request of a 
>request/response". 
>The binding implementation will do whatever is appropriate on 
>the wire to 
>make that happen.  The receiver will understand from the 
>message which MEP 
>is in use.
>
>Yes, it is possible in principle to talk about MEP's at lots 
>of levels, 
>such a in WSDL, but in this case we are talking exactly at the 
>level of 
>what the SOAP Rec. defines as an MEP, I think.
>
>> The issue about request-response dealing with no response is 
>already a 
>problem, because right now you can use WS-A with req-response 
>but put a 
>non-anon value in replyTo.  This doesn't cause a binding fault 
>currently 
>because WS-A overrides this constraint.
>
>OK.  I only partly understand this, but it sounds about right.
>
>Getting back to my original action.  My priorities are roughly:
>
>* The MEP's we should be defining and using are at the level 
>of what the 
>SOAP Rec calls an MEP.  They should work well with patterns 
>established in 
>other contexts, such as WSDL, but we are not trying to introduce a new 
>level of MEP in SOAP.
>
>* We should have some MEP(s) to cover the WSA cases.  I don't 
>like the no 
>MEP option because it fails to leverage the useful mechanisms 
>already in 
>the Recommendation.
>
>* The existing MEPs such as Request/Response and Response-only 
>are already 
>normative in the Rec and are supported by the HTTP binding.  
>We should use 
>them where they apply.
>
>* I tentatively conclude that any patterns not covered by 
>those should be 
>new MEPs to be supported by enhanced versions of the HTTP 
>binding.  As is 
>already the case, it should be possible to tell from the initial 
>interaction which of the MEPs is in use.  Most likely the best 
>way to do 
>this is to intruduce a new "Request-with-Optional-Response" 
>MEP.  I will 
>admit that I'm less clear on how carefully I'd want to signal 
>the choice 
>of MEP in the HTTP message.   In principle, I'd prefer that 
>one be able to 
>tell from inspecting the message whether the old or the new 
>MEP is in use. 
> In practice, I could probably live with saying that new 
>versions of the 
>HTTP binding support just "Response only" and a new "Request 
>with optional 
>Response", which would be designed to be interoperable with the old 
>Request/Response in the specific case where a response was indeed sent.
>
>I'm not sure I'll make the call tomorrow.  Hope this helps.
>
>Noah
>
>
>[1] http://www.w3.org/TR/soap12-part1/#soapmep
>--------------------------------------
>Noah Mendelsohn 
>IBM Corporation
>One Rogers Street
>Cambridge, MA 02142
>1-617-693-4036
>--------------------------------------
>
>
>
>
>
>
>
>
>"David Orchard" <dorchard@bea.com>
>Sent by: w3c-xml-protocol-wg-request@w3.org
>11/28/2005 04:57 PM
> 
>        To:     <w3c-xml-protocol-wg@w3.org>
>        cc:     (bcc: Noah Mendelsohn/Cambridge/IBM)
>        Subject:        Comments on uber-MEP
>
>
>I see from the minutes, 
><Yves> noah: not really happy with the no-MEP option. the way 
>a binding 
>know how to send a message is a normative thing in the spec. 
>Saying it's 
>in the rec but we won't use it would be an issue 
><Yves> noah: there may be more protocols than HTTP that 
>supports natively 
>request/response 
><Yves> and the soap level MEP allow to abstract that 
><Yves> concern witht he uber-MEP is that Request-reponse MEP 
>is already 
>there, adding another MEP might introduce an incompatibility 
><Yves> also adding too much possibilities may undermine its usefulness 
><Yves> for example if a request -response is expected and no response 
>comes, would that trigger a binding level fault? 
><scribe> ACTION: Noah to send email describing position on uber MEP/no 
>MEP/new MEP due 30 Nov [recorded in 
>http://www.w3.org/2005/11/16-xmlprotocol-minutes.html#action02] 
> 
> 
>The uber-MEP is a protocol level MEP (and abstract from any particular 
>protocol) and thus any protocol that supports request-response 
>is handled. 
> There will be another MEP anyways, so it's whether to have a 
>SOAP only 
>MEP or have a more general MEP as the one new MEP.  The issue about 
>request-response dealing with no response is already a 
>problem, because 
>right now you can use WS-A with req-response but put a 
>non-anon value in 
>replyTo.  This doesn't cause a binding fault currently because WS-A 
>overrides this constraint.
> 
>Dave
> 
>
>
>

Received on Wednesday, 30 November 2005 01:02:18 UTC