Re: message exchange patterns and # of parties

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

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.

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

Received on Thursday, 11 September 2003 13:39:02 UTC