MEP text from break-out session

(sorry I'm having to use my freemail account due to
firewall issues)

This is some prose that I wrote up to summarize some
owrk done in a break out session at the face-to-face
yesterday on MEPs, web services stack layering, etc.

Mark Jones
AT&T
jones@research.att.com
___________________________________

Distributed applications in a Web services
architecture communicate
via message exchanges.  These message exchanges are
logically factored
into patterns that compose at different levels.  These
patterns can be
descibed 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, the message exchange
pattern (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 associate instance of MEPs with
particular operations
from the perspective of a particular service node.

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 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.
Conceptually, the choreographic level can enforce
constraints on
message order, maintain state consistency, communicate
choreographic
faults to the application, etc.


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com

Received on Thursday, 23 January 2003 13:13:02 UTC