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

Re: MEP text

From: <jones@research.att.com>
Date: Mon, 7 Jul 2003 13:41:25 -0400 (EDT)
Message-Id: <200307071741.h67HfPp09408@bual.research.att.com>
To: chrisfer@us.ibm.com, www-ws-arch@w3.org

Hi Chris,

Replies embedded below...

	To: www-ws-arch@w3.org
	From: Christopher B Ferris <chrisfer@us.ibm.com>
	Date: Thu, 3 Jul 2003 16:56:52 -0400
	Subject: 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.

<mark>
Both of these suggestions are fine with me.
</mark>

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

<mark>
The editors are free to move the material.  I included it here
precisely to sharpen the distinction between MEPs and choreographic
patterns.  It is a minimal example that REQUIRES a choreography and is
not amenable as a complex MEP in the SOAP/WSDL formulation.

So we're in violent agreement on its being a choreography.  The
question is pedagogy and placement.  The editors can decide.
</mark>

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


Mark Jones
AT&T
Received on Monday, 7 July 2003 13:41:18 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:21 GMT