Re: message exchange patterns and # of parties

Amy,

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.
>
>Amy!
>--
>Amelia A. Lewis
>Architect, TIBCO/Extensibility, Inc.
>alewis@tibco.com

-- 
David Booth
W3C Fellow / Hewlett-Packard
Telephone: +1.617.253.1273

Received on Friday, 12 September 2003 16:25:04 UTC