Re: message exchange patterns and # of parties

On Thu, 11 Sep 2003 23:38:24 +0600
Sanjiva Weerawarana <sanjiva@watson.ibm.com> wrote:
> I also dislike "client" .. and we need to define somewhere that the 
> pattern MUST have as a participant someone which plays the role of
> the service. Clearly every pattern must have AT LEAST one more 
> participant ..

Hmm, yes.

> 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.

Sorry.  This was a contentious issue throughout the life of the task
force on patterns.  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.

This is a good rule of thumb, and I think it was approved as such at the
face-to-face in Raleigh.  However, it's only a rule of thumb, and it
isn't completely clear which side of the rule multicast falls on.

*If* we argue that [exchange particpants not acting in the role of the
service described] do not care whether other [such participants] may
also receive the same messages that they receive, then multicast is only
of interest to the service.  *If* [such participants] can be expected to
care (to change behavior based on whether they receive a whisper or a
shout), then multicast is of interest to both participants.

How the issue gets resolved depends, in part, on how the specification
is phrased.  If the language is such that a single message can only,
conceptually, ever be delivered to a single recipient, then we would be
mandating unicast semantics.  If it is made clear, for instance, that a
single service (publisher) may send a single message (output-only,
notification) but that this may be received by zero or more recipients
(subscribers), then we have no need to specify different patterns for
"multicast output-only" versus "unicast output-only".  In the patterns
TF, we came to the conclusion that, for each individual [non-service
participant], precisely the same behavior was defined whether the medium
was unicast or multicast, so that it didn't matter, and one output-only
pattern could be used for both.

Sorry, I may have been muddying the waters.  The distinction between
multicast and unicast, though, seems to live right on the border of
recognition, when discussing what needs inclusion in exchange patterns.

Amy!
> 
> Sanjiva.
> 
> ----- Original Message ----- 
> From: "Amelia A. Lewis" <alewis@tibco.com>
> To: "David Booth" <dbooth@w3.org>
> Cc: <sanjiva@watson.ibm.com>; <www-ws-desc@w3.org>
> Sent: Thursday, September 11, 2003 9:37 PM
> Subject: Re: message exchange patterns and # of parties
> 
> 
> > 
> > That's what I thought, and that's how I answered, I believe.
> > 
> > Except that I dislike the term "client" in this context.
> > 
> > Amy!
> > On Thu, 11 Sep 2003 11:17:31 -0400
> > David Booth <dbooth@w3.org> wrote:
> > 
> > > Amy,
> > > 
> > > I think Sanjiva was counting both the client and the service when
> > > he said "two parties".
> > > 
> > > At 01:08 PM 9/10/2003 -0400, Amelia A. Lewis wrote:
> > > 
> > > >On Wed, 10 Sep 2003 22:55:36 +0600
> > > >Sanjiva Weerawarana <sanjiva@watson.ibm.com> wrote:
> > > > > I remember some discussion during the last F2F about the
> > > > > number of parties that may be involved with a single message
> > > > > exchange pattern. I think I was arguing against having more
> > > > > than two parties as that's getting more into choreography
> > > > > space.
> > > >
> > > >Err, umm.  No, in my opinion, any more than a description of more
> > > >than one party's participation is choreography.
> > > >
> > > > > What did we decide? Are patterns allowed to have more than 2
> > > > > parties participating in a single pattern?
> > > >
> > > >So far as I can recall, this was not one of the things ruled out.
> > > >
> > > >Each pattern description must now contain identifications of
> > > >participating nodes, but there is no ruling out of something such
> > > >as the "third-party request/response" (A -> Service -> C).
> > > >
> > > >Multicast is apparently now to be handled by ignoring it, on the
> > > >basis that the fact of multicast is not important to *both*
> > > >parties. So an output-only MEP may actually be delivered to
> > > >multiple recipients; the MEP is in this case construed to model
> > > >the interaction between the service and *each* receiving node
> > > >(the service may send a single message, and multiple recipients
> > > >may receive it, but this information is considered to be not
> > > >visible in the description of the exchange pattern).
> > > >
> > > >Amy!
> > > >--
> > > >Amelia A. Lewis
> > > >Architect, TIBCO/Extensibility, Inc.
> > > >alewis@tibco.com
> > > 
> > > -- 
> > > David Booth
> > > W3C Fellow / Hewlett-Packard
> > > Telephone: +1.617.253.1273
> > > 
> > > 
> > 
> > 
> > -- 
> > Amelia A. Lewis
> > Architect, TIBCO/Extensibility, Inc.
> > alewis@tibco.com
> 
> 


-- 
Amelia A. Lewis
Architect, TIBCO/Extensibility, Inc.
alewis@tibco.com

Received on Thursday, 11 September 2003 15:36:28 UTC