Re: section 2.2.22 Message Exchange Pattern (MEP)

Mark,

I am still uncertain as to what "a single use of the service" means in 
this, or any
context. A service may have many operations, and fulfilment of the service 
may
require more than one of the operations to be invoked by the client. Given 
this,
where does the SOAP Req/Resp MEP come into play?

I believe that WSD WG is mapping MEP at the operation level and hence
at the very least, we should be aligning our definition with that notion.

I agree that it is important to distinguish between an MEP and a 
choreographed
exchange of messages, one is a pattern (the P in MEP) and the other is 
not.

SOAP1.2[1] defines an MEP as:

        A Message Exchange Pattern (MEP) is a template that establishes a 
pattern for the exchange of messages between SOAP nodes. 

Why isn't that definition good enough for us?

[1] http://www.w3.org/TR/soap12-part1/#soapmep

Cheers,

Christopher Ferris
STSM, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
phone: +1 508 234 3624

Mark Jones wrote on 07/07/2003 02:17:29 PM:

> 
> Editors,
> 
> Here is revised material for section 2.2.22, Message Exchange Pattern
> (MEP).  I have two caveats.
> 
> 1. Chris Ferris suggests eliminating the phrase "that describes a
> single use of a service", which has been in the text to date and was
> also in David Booth's proposed revision which I incorporated.
> Personally, I think the definition needs some qualifier such as this
> in order to differentiate it MEPs from arbitrary or even
> choreographically-related collections of messages that happen to be
> exchanged between agents.  Chris's proposal to drop the phrase would
> create an overly broad scope for the term MEP.
> 
> 2. I have retained the layering discussion and example which
> illustrates the clarifies the MEP/choreography distinction.  This
> material could be moved elsewhere for purposes of overall exposition,
> but IMO it should be retained somewhere.
> 
> Mark Jones
> AT&T
> 
> ================================================================
> 
> 2.2.22 Message Exchange Pattern (MEP)
> 2.2.22.1 Summary
> A message exchange pattern is a template for the exchange of messages
> between agents that describes a single use of a service.
> 
> 2.2.22.2 Relationships to other elements
> a message exchange pattern is
> a template for the exchange of messages between agents
> that describes a single use of a service
> 
> a message exchange pattern is
> a feature of the architecture
> 
> a message exchange pattern has
> a unique identifier
> 
> a message exchange pattern describes
> the temporal and causal relationships, if any, of multiple
> messages exchanged in conformance with the pattern.
> 
> a message exchange pattern describes
> the normal and abnormal termination of any message exchange conforming
> to the pattern.
> 
> a message exchange pattern may be expressed
> in a choreography description language.
> 
> a message exchange pattern may realize
> message correlation
> 
> a message exchange pattern may describe
> a service invocation.
> 
> 2.2.22.3 Description
> 
> Distributed applications in a Web services architecture communicate
> via message exchanges.  A Message Exchange Pattern (MEP) is a template
> that establishes a pattern for the exchange of (one-way) messages
> between agents.  These message exchanges are logically factored into
> patterns that may compose at different levels.  These patterns can be
> described by state machines that indicate the flow of the message, the
> handling of faults that may arise, and the correlation of messsages.
> 
> At the SOAP messaging level, an MEP refers to an exchange of messages
> in various invoking-response patterns.  Each message at this level may
> travel across multiple transports en route to its destination.  A
> message and its response(s) are correlated, either implicitly in the
> underlying protocol (e.g., request-response in HTTP) or by other
> correlation techniques implemented at the binding level.  The
> exchanges may be synchronous or asynchronous.  An asynchronous
> exchange involves some form of rendezvous to associate the message and
> its responses, typically due to separate invocations of the underlying
> transport or to long response time intervals.
> 
> Web service description languages at the level of WSDL view MEPs from
> the perspective of a particular service actor.  A simple
> request-reponse MEP, for example, appears as an incoming message which
> invokes an operation and an associated outgoing message with a reply.
> Extremely simple applications based on single message exchanges may be
> adequately characterized at the operation level.  More complex
> applications require multiple, related message exchanges; choreography
> describes patterns where the units of communication are themselves
> instances of MEPs.  Especially at this higher level of abstraction,
> the communicating actors are seen as peers which play various roles in
> more complex applications.  These choreographic patterns form the
> communication structure of the application.
> 
> Consider the following simple structure:
> 
>           (1)
>     A------------>B
>      \            |
>       \ (3)       | (2)
>        \          V
>         --------->C
> 
> In this pattern:
> 
> (1) actor A uses an instance of an MEP (possibly request-response) to 
communicate
>     initially with B.
> 
> (2) B then uses a separate, but related instance of an MEP to 
communicate with C.
> 
> (3) Actor A uses another instance of an MEP to communicate with C but 
gets a reply
>     only after C has processed (2).
> 
> The example makes it clear that the overall pattern cannot be described
> in terms of the inputs and outputs of any single actor.  The pattern 
involves
> constraints and relationships among the messages in the various MEP 
instances.  It also
> illuminates the fact that exchange (1) is in in-out MEP from the
> perspective of actor B, and mirrored by an out-in MEP from the
> perspective of actor A.  Finally, an actual application instantiates
> this communication pattern and completes the picture by adding
> computation at A, B and C to carry out application-specific
> operations.
> 
> The following stack roughly captures the typical layering described
> above:
> 
>      application
>         |
>         | (application instantiates some choreographic structure
>         |  and provides message content)
>         V
>      choreography
>         |
>         | (application + choreography yields an XML Infoset,
>         |   attachments, and messaging features including the
>         |   MEP)
>         V
>      message transport binding
>         |
>         | (the binding produces a serialization, implements
>         |   required features, manages MEP-level coordination
>         |   for associating request/responses, etc.)
>         V
>      transfer/transport protocol
> 
> It is instructive to consider to consider the kinds of fault reporting
> that occur in such a layering.  Consider a fault at the transport
> protocol level.  This transport level may itself be able to manage
> certain faults (e.g., re-tries), but it may also simply report the
> fault to the binding level.  Similarly the binding level may manage
> the fault (e.g., by re-initiating the underlying protocol) or may
> report a SOAP fault.  The choreography and application layers may be
> intertwined or separated depending on how they are architected.
> There is also no rigid distinction between the choreography and
> binding layers; binding-level MEPs are essentially simple 
choreographies.
> Conceptually, the choreographic level can enforce constraints on
> message order, maintain state consistency, communicate choreographic
> faults to the application, etc. in ways that transcend particular
> bindings and transports.
> 

Received on Monday, 7 July 2003 16:36:39 UTC