W3C home > Mailing lists > Public > www-ws-desc@w3.org > September 2003

Re: message exchange patterns and # of parties

From: David Booth <dbooth@w3.org>
Date: Fri, 12 Sep 2003 16:25:02 -0400
Message-Id: <>
To: "Amelia A. Lewis" <alewis@tibco.com>
Cc: sanjiva@watson.ibm.com, www-ws-desc@w3.org


Bear in mind that I was quoting from our TF recommendations -- not from the 
current patterns draft[1].  If the ambiguity that you mention is only in 
the wording of the TF recommendations, then I don't think we need to worry 
so much about it.

The patterns document[1] currently says:
Like interfaces and operations, WSDL message patterns do not exhaustively 
describe the set of messages exchanged between a service and other nodes; 
by some prior agreement, another node and/or the service may send other 
messages (to each other or to other nodes) that are not described by the 
pattern. For instance, even though a pattern may define a single message 
sent from a service to one other node, the Web Service may broadcast that 
message to other nodes.

That verbiage seems clear enough to me (i.e., it permits the case you 
describe), but maybe that's just because I already know what I think it 
should be saying.  Do you think we need to add more clarification to 
it?  If so, what would you propose?

1. http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/wsdl12-patterns.html

At 04:50 PM 9/11/2003 -0400, Amelia A. Lewis wrote:
>Yes, but ...
>On Thu, 11 Sep 2003 16:32:16 -0400
>David Booth <dbooth@w3.org> wrote:
> > See comment below.
> >
> > At 02:25 PM 9/11/2003 -0400, Amelia A. Lewis wrote:
> > >On Thu, 11 Sep 2003 23:38:24 +0600
> > >Sanjiva Weerawarana <sanjiva@watson.ibm.com> wrote:
> > >. . .
> > > > Amy, I'm confused about your comment ref multicast- are you
> > > > suggesting that the pattern framework is deficient in some form
> > > > w.r.t. being able to capture multicast patterns? If so please
> > > > suggest what needs to be changed; IMO our objective is and should
> > > > be to define a framework rich enough to capture patterns including
> > > > multicast ones.
> > >
> > >. . .  Our final resolution proposed that unless the
> > >information was important to both sides of a message being exchanged,
> > >then it wasn't to be represented in the pattern.
> >
> > Yes, the other reason the Patterns TF thought that the current
> > patterns are adequate for use also in multicast situations is that the
> > client and service are not limited to all and only those messages that
> > are indicated in the pattern.  One of the Pattern Task Force
> > recommendations explains this:
> >
> > 
> http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/meps-vs-iops/recommendations_clean.htm
> > [[
> > Recommendation: Patterns Specify *Minimal* Behavior
> >
> > Each pattern represents a contract that specifies *minimal* behavior
> > that is expected between the parties. . . .
> >
> > The clients and services may have additional behaviors that are not
> > specified by the pattern. Specifically, a client or service may send
> > other messages (to each other or other parties) that are not described
> > by the pattern. However, in such case, the parties must use other
> > means to agree on the handling of the additional messages. For
> > example, a message specified in a pattern as being from service S to
> > client A might actually be broadcast to other clients in addition to
> > being sent to client A. However, the pattern only governs the
> > agreement to send the message to client A.
> > ]]
>This is, potentially, interpretable as precluding multicast.  *sigh*  I
>realize you're gonna hate me again, David, but the phraseology leaves
>multicast on the edges.
>So.  Say we have a description of output-only, it says that a message is
>sent to from service S to receiving node A.
>Service S, in fact, sends one message to a TCP multicast address.  The
>service is quite well aware that it is doing so, and that potentially
>*more than one* receiving node A may receive it.  In fact, it sends its
>messages to the *set* of receiving nodes designated A (and that set may
>be empty, too).
>The receiving nodes are also aware that multicast is in use (presumably,
>unless the application architecture is extremely strongly layered).
>They joined the multicast network, after all.
>The point is that the "also broadcast to other clients" is potentially
>misleading: if the message is simply multicast to the set of receiving
>nodes A, then each receiving node adopts the identity A specified in the
>pattern.  It is possible to construe the language above as saying that
>the exchange involves the service, one receiving node designated A, and
>other receiving nodes that are not participating in a pattern with the
>service; in fact, all that is meant to be said is that the interaction
>between the service and any other nodes that receive the message is not
>defined, but *may* be exactly this exchange, with the other nodes
>adopting the role of A.
>Which is so complex and obfuscated an explanation that one begins to
>despair.  It is easy enough to describe a message exchange pattern as
>being between a service and a set of nodes, or between a service and a
>node; it is difficult to achieve language that lets the participants be
>either a set of identically-acting nodes or a single node.
>Amelia A. Lewis
>Architect, TIBCO/Extensibility, Inc.

David Booth
W3C Fellow / Hewlett-Packard
Telephone: +1.617.253.1273
Received on Friday, 12 September 2003 16:25:04 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:06:33 UTC