W3C home > Mailing lists > Public > www-ws-arch@w3.org > July 2003

Re: section 2.2.22 Message Exchange Pattern (MEP)

From: Christopher B Ferris <chrisfer@us.ibm.com>
Date: Mon, 7 Jul 2003 16:36:25 -0400
To: www-ws-arch@w3.org
Message-ID: <OFA05B9634.3D306E98-ON85256D5C.006FFEC8-85256D5C.00713238@us.ibm.com>


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 
require more than one of the operations to be invoked by the client. Given 
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 
exchange of messages, one is a pattern (the P in MEP) and the other is 

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


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)
> Summary
> A message exchange pattern is a template for the exchange of messages
> between agents that describes a single use of a service.
> 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.
> 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 
>     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 
> 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 
> 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

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:41:08 UTC