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

Re: section 2.2.22 Message Exchange Pattern (MEP)

From: <jones@research.att.com>
Date: Fri, 11 Jul 2003 10:41:01 -0400 (EDT)
Message-Id: <200307111441.h6BEf1K09657@bual.research.att.com>
To: chrisfer@us.ibm.com, dbooth@w3.org, jones@research.att.com
Cc: www-ws-arch@w3.org


Well, I guess I see this as a terminological issue.  I certainly agree
that there will be more complex "messaging patterns" than (SOAP) MEPs,
but for me the SOAP notion of an "exchange" has always had in view the
set of communicating participants involved in a message and its
responses.  For example, a messaging pattern that involved A and B
exchanging messages, followed by A and C exchanging messages (as
dictated by some application logic) is certainly a messaging pattern.
I just wouldn't call it a message *exchange* pattern in the SOAP/WSDL

Note that there are some pretty complex MEPs admitted by the phrase "a
message and its responses".  It isn't really a simple/complex
distinction being made here.  For example, you can have asynchronous
responses, a succession of response messages that incrementally build
up a result, a multicast message with a cumulative result, etc.

At the very least, if we widen the MEP term to include arbitrary
messaging patterns (MPs), it would still be good to have a term that
corresponds to the earlier notion of an MEP that involves "a message
and its responses".  This will be the natural unit upon which
higher-level messaging patterns are constructed.  I can't tell whether
you think that unit is or should be co-extant with "SOAP MEP", "WSDL
MEP", or some other term.  We could coin another term -- Message
Response Pattern (MRP)?? -- but it seems a shame since we had one.

Mark Jones

	Date: Thu, 10 Jul 2003 18:14:21 -0400
	To: jones@research.att.com, Christopher B Ferris <chrisfer@us.ibm.com>
	From: David Booth <dbooth@w3.org>
	Subject: Re: section 2.2.22 Message Exchange Pattern (MEP)
	Cc: www-ws-arch@w3.org

	At 10:49 AM 7/10/2003 -0400, jones@research.att.com wrote:
	> Summary
	>  A message exchange pattern is a template for the exchange of messages
	>  between agents that arise from a message and its responses, if any.

	I don't think the definition of MEP should be restricted this way.   The 
	addition of the phrase "that arise from a message and its responses, if 
	any" makes this definition unnecessarily restrictive.  In fact, this 
	defintion is not even consistent with either WSDL 1.2 or SOAP 1.2 today!

	For example, in WSDL 1.2, the "Multicast Solicit Response"[1] pattern may 
	involve a sequence of THREE messages: (1) the initial "solicit" message; 
	(2) the normal response message; and (3) a fault message that is returned 
	as a result of the response message.

	And in SOAP 1.2, the SOAP 1.2 definition of MEP does not restrict the 
	concept of MEPs to only those patterns that "arise from a message and its 
	responses".  In fact, the SOAP 1.2 definition of MEP does not restrict 
	either the number of messages or the number of nodes involved.

	I think it makes more sense for our WS Architecture to define MEP more 
	broadly, and recognize that MEPs may range from simple to complex.  Some 
	languages, such as WSDL, may only deal with simple MEPs involving only 
	sequences of one, two or a few messages or nodes (such as request or 
	response).  Others, such as choreography, may permit very complex MEPs to 
	be described (presumably out of simpler building blocks).  Both WSDL and 
	SOAP define certain, specific MEPs, (and clearly the relationship between 
	them should be clear), but these are only a few of the possible universe of 
	all "Message Exchange Patterns".

	I propose simplifying our definition of "Message Exchange Pattern" to:

	" Summary
	  A message exchange pattern is a template for the exchange of messages
	  between agents."

	2. http://www.w3.org/TR/2003/PR-soap12-part1-20030507/#soapmep

	David Booth
	W3C Fellow / Hewlett-Packard
	Telephone: +1.617.253.1273
Received on Friday, 11 July 2003 10:40:53 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:41:08 UTC