| Newsgroups |
gmane.text.xml.distributed |
| Message-ID |
<[email protected]> |
Forwarding thread to public list...
>-----Original Message-----
>From: [email protected]
>[mailto:[email protected]] On Behalf Of ext
>[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.
>
>> 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" <[email protected]>
>Sent by: [email protected]
>11/28/2005 04:57 PM
>
> To: <[email protected]>
> 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
>
>
>
>