[Fwd: MEP text]

This sounds relevant to the current MEP/pattern discussion. Also, we 
want to indicate if this fits with our vision.

Jean-Jacques.

-------- Original Message --------
Subject: MEP text
Resent-Date: Fri, 27 Jun 2003 10:48:49 -0400 (EDT)
Resent-From: www-ws-arch@w3.org
Date: Fri, 27 Jun 2003 10:48:49 -0400 (EDT)
From: Mark Jones <jones@research.att.com>
Reply-To: jones@research.att.com
To: www-ws-arch@w3.org


Per my action item to flesh out section 2.2.22 on MEPs, here is a new
synthesis of my January f2f MEP text with the current doc structure.
It includes a discussion of MEPs at both the binding/operation level
and the choreography level.  It also includes both the SOAP and WSDL
perspectives on MEPs.  Finally, there is an example to motivate the
choreography issues and a stab at a layering discussion.  Some of the
material can be moved elsewhere for editorial purposes.

Mark Jones
AT&T

================================================================

2.2.22 Message Exchange Pattern (MEP)
2.2.22.1 Summary
A message exchange pattern is a minimal set of messages, together with
their sender and receivers, that constitutes a single use of a
service.

2.2.22.2 Relationships to other elements
a message exchange pattern is set of messages between agents that
corresponds to a single instantiation 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 is
the life cycle of a message exchange

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 node.  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 nodes 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) node A uses an MEP (possibly request-response) to communicate
     initially with B.

(2) B then sends a separate, but related message to C.

(3) Node A sends another message to C but gets a reply only after C
     has processed (2).

The example makes it clear that the overall pattern can't be described
from the perspective of any single node.  The pattern involves
constraints and relationships among the various messages.  It also
illuminates the fact that exchange (1) is in in-out MEP from the
perspective of node B, and mirrored by an out-in MEP from the
perspective of node 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 Friday, 27 June 2003 11:39:40 UTC