RE: MEP text

	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 14:45:58 UTC