RE: Comments on uber-MEP

Forwarding...

-------------------------

Comments inline

> -----Original Message-----
> From: w3c-xml-protocol-wg-request@w3.org [mailto:w3c-xml-protocol-wg- 
> request@w3.org] On Behalf Of noah_mendelsohn@us.ibm.com
> 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.

It is fact that the SOAP rec says what a SOAP MEP is.  It is a fact that there are MEPs above and beyond SOAP, ie WSDL MEPs.   It is a fact that every protocol exchanges messages, and will thus have some kind of pattern of message exchange.

It is my belief that specification of a SOAP MEP as defined in the SOAP specification is overly prescriptive.  My messages shows a simpler subset of the specification of a SOAP MEP - basically just the "input" and "output" properties, not the state transition diagrams - and also relaxes the constraint of SOAP messages.

The uber MEP is a protocol level MEP because it is SOAP independent and only reflects the inputs and outputs of a protocol level exchange of messages.

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

I 100% agree that having the ability to say that two protocols support the same MEP, ie request-response, and thus insulate the application from the particular protocol is important.  That's why I have argued so strongly against ChrisF's suggestion to remove MEPs completely.  


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

I show in the WS-A proposal how the uber mep is useful.  It gives the properties for use in accessing requests, responses and results.  There has been a lot of debate as to whether the mep should also have the mandatory/optional/disallowed response "flag".  

I use the term "strongly-typed" to describe the SOAP req-resp MEP because it says that a response is required.  The problem with a strongly typed MEP is that the actual MEP will be determined by the contents of a message, say anon vs non-anon ReplyTo value.  Given that, how is specifying an req-resp MEP at all useful to a WS-A WSDL processor?  It won't know the MEP until it gets a message.  Hence the uber-mep leaves these things unspecified which more clearly models the fact that WS-A processors are mucking around with the message exchange.

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

The uber MEP can replace the request-response MEP in the SOAP spec, and not a single implementation would break.  The MEP framework goes to great lengths to constrain how a binding is written, not the bindings themselves.  Except that IMHO the constraints on bindings have been so onerous that almost no bindings have been written.

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

There will have to be another MEP to deal with one-way.  So we can either specify a SOAP one-way MEP or do the uber/protocol MEP.

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

I understand.  I just don't think that the full fidelity of the SOAP rec.'s definition of an MEP is useful, and may be actively harmful to propagation of SOAP 1.2 and related bindings.

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

I don't know what you mean by "level".  If you mean independent of a protocol, I agree.  If you mean to the complete extent as defined by the SOAP rec, I disagree strongly.

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

I agree.  I believe there is utility in having some abstraction between WSDL and the underlying protocols.

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

Disagree, for reasons above.

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

You make an assumption that the messages should be self-describing from an MEP perspective, which I do not believe is true.  

You might want to talk to Paco because he's been advocating on WS-A for quite some time that even the presence of a ReplyTo does not mean that request-response is in effect, nor does absence of ReplyTo indicate that one-way is in effect.  There may be application semantics or higher level MEPs - such as WS-Eventing or WS-Notification - that constrain the MEP.

Also, I'll point out that on the OASIS WS-RX committee, BEA has asked that the WS-RX:AcksTo cannot be anonymous when the ReplyTo is not-anonymous.  The problem is that the WS-rx software, and anybody else that defines a *To value, will have be in the loop to see if there needs to be an HTTP response value.  In this case, the SOAP MEP might be "one-way" because the ReplyTo is not-anonymous, but then maybe the SOAP MEP should be "request-response" because rx layer has to stuff an SOAP ack response in.  I'm sure ChrisF can and will comment on this.

Cheers,
Dave

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