Re: MEP text

Mark,

Nice work.  I have a few suggestions that are orthogonal to those that 
others have made already.  I think they are mostly just wordsmithing 
comments, but I never know when someone else will see a different wording 
as being very significant, :) so I'm posting my comments here.

At 10:48 AM 6/27/2003 -0400, Mark Jones wrote:
>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.

I suggest rewording the summary as:

         2.2.22.1 Summary
         A message exchange pattern is a template for the exchange of
         messages between nodes, which describes a single use
         of a service.

Rationale: The summary omits the word "template", which I think is 
important to avoid confusing an *actual* sequence of messages from the 
*template* for a sequence of messages.  (Kind of a class versus instance 
distinction.)  Also, the word "set" does not imply ordering, though the 
ordering of messages is usually very important.  Also, I don't think it is 
necessary to say "together with their sender and receivers".

FYI, this wording was adapted from the working definition used in the MEP 
Task Force of the WS Description WG 
(http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/meps-vs-iops/meps-vs-iops_clean.htm#modeling_objective).

That, in turn, was derived from the SOAP MEP definition 
(http://dev.w3.org/cvsweb/~checkout~/2002/ws/arch/glossary/wsa-glossary.html#soapmep).



>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

This text is pretty similar to the summary, so I would make the same 
suggestions.

>. . .
>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.

I think this last sentence confuses the perspective with the meaning of the 
pattern.  The *perspective* from which a pattern is described affects the 
way (i.e., *how*) the pattern is written.  But that is independent of the 
*meaning* of the pattern, i.e., *what* that pattern describes.  I suggest 
instead wording this as:

         The example makes it clear that the overall pattern cannot be 
described
         in terms of inputs and outputs 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.

-- 
David Booth
W3C Fellow / Hewlett-Packard
Telephone: +1.617.253.1273

Received on Wednesday, 2 July 2003 16:19:37 UTC