| Newsgroups |
gmane.text.xml.distributed |
| Message-ID |
<[email protected]> |
Forwarding...
-------------------------
Comments inline
> -----Original Message-----
> From: [email protected] [mailto:w3c-xml-protocol-wg-
> [email protected]] On Behalf Of [email protected]
> Sent: Tuesday, November 29, 2005 1:38 PM
> To: David Orchard
> Cc: [email protected]
> 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