Re: message exchange patterns and # of parties

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

Received on Thursday, 11 September 2003 17:41:56 UTC