Re: What it means to "get rid of MEPs"

Thanks, Noah.  That clarifies quite a bit (and it was right there in the
SOAP specs :-).

I think the main impetus behind wanting to "get rid of MEPs" is a desire
to avoid redundancy between the WSDL notion of MEP and the SOAP notion.

At one extreme, WSDL MEPs could basically delegate everything to SOAP
MEPs (e.g., in-out means SOAP request-response). This would be bad for
any number of reasons.

At the other (another?) extreme, WSDL could define most of the semantics
(in-out means this lifecycle, these causal relationships, these
termination conditions) and say something like "WSDL in-out over SOAP
means the in-out MEP with both messages realized as SOAP envelopes."

In practice, there appears to be some duplication.  E.g., WSDL's fault
rules (fault replaces message, etc.) may overlap or interact with SOAP's
notion of generating faults.  It also seems worthy of consideration to
define the lifecycle and causal relationships once and for all at the
WSDL level, orthogonally to whether the messages in question are SOAP
envelopes or something else.

However, SOAP is not just SOAP envelopes.  It has a processing model,
including forwarding by intermediaries, and its own notion of MEPs. 
Reconciling the two notions of MEPs requires one of:

    * Getting rid of WSDL MEPs, which seems unlikely in the extreme
    * Getting rid of SOAP MEPs
    * Keeping both, but clarifying the relationship between the two and
      demonstrating that they are compatible.

FWIW, the proposal I recently sent out takes the third approach, but
does so by constructing a framework in between the two, in such a way
that the framework could conceivably stand on its own and the current
SOAP MEPs be quietly removed out from under it (and kept publicly
available for the next 10-20 years for the benefit of those wise enough
to let sleeping dogs lie).



noah_mendelsohn@us.ibm.com wrote:

>
> At the end of today's call we had an interesting discussion about what
> MEPs are, to what degree state machines are part of them, etc.  SOAP
> 1.2 is very clear on what MEP's are [1]:
>
> *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]_
> <http://www.w3.org/TR/soap12-part1/#SOAP-PART2> illustrates the
> specification of a MEP feature.
>
> The specification of a message exchange pattern MUST:
>
>     * As mandated by *_3.1.1 Requirements on Features_*
>       <http://www.w3.org/TR/soap12-part1/#featurereq>, 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_* <http://www.w3.org/TR/soap12-part1/#featurereq>). 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.
>
> If we get "rid" of MEPs as a concept, then we delete this text from
> SOAP part 1.  I'm currently against doing that, but that's what it
> would require.
>
> There are obviously concerns about state machines etc.  It should be
> clear from the above that the particular style of state machines in
> part 2 are not fundamental to being an MEP;  they are an editorial
> device that was adopted set down in detail the particular MEPs
> provided.  Maybe or maybe not we should either change them or
> re-express them in simpler form, but doing so is not IMO best
> described as getting rid of MEPs.
>
> Noah
>
> [1] http://www.w3.org/TR/soap12-part1/#soapmep
>
> --------------------------------------
> Noah Mendelsohn
> IBM Corporation
> One Rogers Street
> Cambridge, MA 02142
> 1-617-693-4036
> --------------------------------------
>
>
>