Re: Comments on uber-MEP

My über-concern with the über-MEP is that it is out of sync with the
actual capabilities of transports.  It is the sort of abstraction that
seems likely to leak.

On the one hand, a transport like HTTP is inherently request-response. 
Saying that it supports the über-MEP, or any form of request with
optional response distorts this.  However, we can probably get away with
this by defining a standard non-response (i.e., empty 202).  We'll most
likely end up doing the same thing when we talk about one-way messaging
over HTTP (we don't have to, but that's a separate proposal [1]).  Given
that we do, this is sort of a wash; there's probably not that much
difference between saying "HTTP supports one-way and request-response"
and "HTTP supports in-optional-out".

On the other hand, though, a one-way transport like the "mythical
one-way" inherently /only/ supports one-way.  Defining only the one-way
SOAP MEP for it reflects this and explicitly leaves correlation to other
levels.  Saying that it supports in-optional-out means either defining a
standard correlation mechanism at the protocol level and then defining
how or whether that relates to WSA MAPs, or saying something like "this
transport supports in-optional-out, but without the optional out".  Sort
of like describing a slice of bread as an open-face cheese sandwich
without the cheese.

On the balance, I would prefer describing MEPs (i.e. features)
corresponding directly to the capabilities of the transport.  For
one-way transports, this means binding the one-way MEP only.  Are there
any request-response bindings for one-way transports at the moment? 
Email is an interesting case.  It's inherently one-way, but has standard
correlation features already built in.

For HTTP et. al. this means either defining /only/ request-response and
handling non-response at a higher level ([2]), or defining both
request-response and one-way.  Though I've advocated the first approach,
and still think it has merit, at this point defining both
request-response and one-way seems like the most direct way forward. 
SOAP is (as I understand it) inherently hop-by-hop, so it would seem odd
not to define one-way everywhere (but on the other hand, we've gotten
along how long without it?).

As to the ability to determine the MEP from examining the inbound
message alone, I don't think that's compatible with asynchrony as we
understand it.  The standard use case I mentioned shows that, in
general, it's not possible to know whether an application-level response
(i.e., the out message of a /WSDL/ in-out) is coming back as a
transport-level response until the receiver has processed that inbound
message and performed arbitrary application-level computation.

Given that, it seems reasonable to say that how (say) a WSDL in-out is
realized as SOAP MEPs is in general determined dynamically.  In the
special case (extremely important but still a special case from the
technical point of view) of synchronous request-response of HTTP, we
/can/ tell in advance, but if we want to handle the fully general case,
we have to drop the assumption that a given WSDL MEP always corresponds
to a given SOAP MEP.  If we do, we're left with what I believe is a
short, coherent and tractable set of rules ([3]) for determining what to
do, at least in the context of SOAP 1.2.

[1]
http://lists.w3.org/Archives/Public/public-ws-addressing/2005Sep/0045.html
(don't be put off by the use of "refactored" -- one of the major results
is that the existing request-response and response only MEPs work
completely unchanged)
[2] http://lists.w3.org/Archives/Public/public-ws-async-tf/2005Jun/0031.html
[3]
http://lists.w3.org/Archives/Public/public-ws-addressing/2005Nov/0093.html

michael.mahan@nokia.com wrote:

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