Re: MEP text

David Booth wrote on 07/02/2003 04:19:32 PM:

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

I'm a little uncomfortable with the phrase "which describes a single use 
of a service".
Could we simply omit this and leave it as:

        A message exchange pattern is a template for the exchange of 
messages 
        between nodes.

rationale: I am not clear at all on what a single "use of a service" 
means.

Further, we could actually change the word "nodes" to "agents" since this 
is
the term used below.

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

As would I for my own 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.

IMO, this is NOT part of the MEP but a description of a choreography! It 
does not
belong in this section at all.

> >
> >(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
> 
Cheers,

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

Received on Thursday, 3 July 2003 16:57:02 UTC