RE: MEP text

Sounds like most people are in agreement then.  Shouldn't be too hard for
some uml diagram updates and text to go into our docs :-)

Cheers,
Dave

> -----Original Message-----
> From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On
> Behalf Of Francis McCabe
> Sent: Friday, June 27, 2003 1:58 PM
> To: jones@research.att.com
> Cc: dmh@contivo.com; www-ws-arch@w3.org
> Subject: Re: MEP text
>
>
>
> I think it is worth pointing out that WS-CHOR has consistently agreed
> that any choreography language *should* be able to describe MEPs as a
> kind of limit case; but that teh choreography *should* also
> be able to
> use MEPs as atomic steps.
>
> Frank
>
> On Friday, June 27, 2003, at 11:46  AM, jones@research.att.com wrote:
>
> >
> > 	From: Dave Hollander <dmh@contivo.com>
> > 	To: www-ws-arch@w3.org
> > 	Date: Fri, 27 Jun 2003 10:38:52 -0700
> > 	Subject: RE: MEP text
> >
> > 	I think we agree on:
> >
> > 		* lose "lifecycle" statement.
> > 		* use MEP in the description of the pattern example
> >
> > 	Still to be discussed:
> > 		* If a MEP does not have an identifier, is it
> still a mep?
> > 			I think so and therefor suggest "may
> have" instead of "has"
> >
> > I'd be happier with "should" if we are going to weaken it.
> Having an
> > identifier (URI) allows the world to talk about it -- and there is
> > plenty that one needs to say about MEPs.
> >
> > 		* I also think the definition may be circular
> if choreorgraphy
> > 			language can use any mep to change
> state. That is to say
> > 			that the signal to change state in a
> choreography language
> > 			should be a MEP (not a message). If
> that is true, then
> > 			the MEP used must not rely upon a
> choreography in its
> > 			definition (I think).
> >
> > I don't think that this statement is definitional.  It is
> descriptive
> > and doesn't contradict anything else that I can see:
> >
> > 		> a message exchange pattern may be expressed
> > 		> in a choreography description language.
> >
> > We could move it to a choreography section instead and restate it
> > as a property of a choreography language, but I'm not sure
> that helps.
> >
> > Mark
> >
> > 	Dave
> >
> >
> > 	-----Original Message-----
> > 	From: jones@research.att.com [mailto:jones@research.att.com]
> > 	Sent: Friday, June 27, 2003 10:47 AM
> > 	To: dmh@contivo.com; www-ws-arch@w3.org
> > 	Subject: RE: MEP text
> >
> >
> > 		From: Dave Hollander <dmh@contivo.com>
> > 		To: www-ws-arch@w3.org
> > 		Date: Fri, 27 Jun 2003 09:04:47 -0700
> > 		Subject: RE: MEP text
> >
> > 		Thanks Mark.
> >
> > 		I have one big concern.
> >
> > 		> a message exchange pattern may be expressed
> > 		> in a choreography description language.
> >
> > 		I fear that this may end up in circular difinition.
> > 		I expect that Choreography will need to ground
> upon the definition
> > 		MEP's.
> >
> > 	It would only be circular if we said that choreography
> was subsumed by
> > 	MEPs, which it is not.  The way I see it, MEPs talk in
> terms of the
> > 	messages exchanged at a a rather atomic binding/operation level.
> > 	Choreography builds on the foundation that the MEPs
> provide.  Since
> > 	one-way messages can also be simple MEPs in their own
> right, you can
> > 	potentially express MEPs such as request-response in a
> choreography
> > 	language.  You would not typically want to do so for
> things like the
> > 	SOAP HTTP request-response binding, but you might use
> choreography to
> > 	describe an asynchronous request-response rendezvous
> that uses a SOAP
> > 	module for callbacks.
> >
> > 		I am assuming that MEPs describe the arrows in
> the diagram, not
> > 		the entire diagram. If not, wouldn't it be
> clearer to use the word
> > 		MEP in (2) and (3)? eg: B then uses an MEP to
> send a separate ...
> >
> > 	Yeah, since an MEP is a message and its response(s), I was using
> > 	message and MEP rather interchangeable in (2) and (3).
> That could
> > 	be tightened up.
> >
> > 		------------------------------
> > 		    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).
> >
> > 		-----------------------------------------------------
> >
> >
> >
> >
> > 		I also have a few minor concerns:
> >
> > 	I inherited both of the following clauses from the original text
> > 	and left them in.
> >
> > 		> a message exchange pattern has
> > 		> a unique identifier
> >
> > 	There may some merit in keeping this, particularly if the WSDL
> > 	group uniquely identifies its various patterns.
> >
> > 		Shouldn't that be "may have"?
> >
> > 		> a message exchange pattern is
> > 		> the life cycle of a message exchange
> >
> > 	I would just as soon lose this one altogether.
> >
> > 		Is "life cycle" defined somewhere? I doubt
> there is any widespread
> > 		understanding of a precise difinition for life cycle.
> >
> > 		I know I would have difficulty defining when
> the life cycle ends
> > 		for a "message exchange". In one sense, the
> message exchange
> > 		within this wg will span the entire existance of the WG.
> > 		I would make the same assumption in thinking
> about two agents
> > 		and their message exchanges.
> >
> >
> > 		daveh
> >
> > 	Mark Jones
> > 	AT&T
> >
> >
> > 		-----Original Message-----
> > 		From: Mark Jones [mailto:jones@research.att.com]
> > 		Sent: Friday, June 27, 2003 8:49 AM
> > 		To: www-ws-arch@w3.org
> > 		Subject: MEP text
> >
> >
> >
> > 		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 17:12:23 UTC