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 16:58:29 UTC