W3C home > Mailing lists > Public > public-ws-chor@w3.org > June 2003

RE: Requirements: Decision Points Requirement Proposals

From: Yaron Y. Goland <ygoland@bea.com>
Date: Tue, 24 Jun 2003 13:01:55 -0700
To: "Martin Chapman" <martin.chapman@oracle.com>, "Jean-Jacques Dubray" <jjd@eigner.com>, "Assaf Arkin" <arkin@intalio.com>, "Burdett, David" <david.burdett@commerceone.com>
Cc: "'WS Chor Public'" <public-ws-chor@w3.org>
Message-ID: <GMEOJGJFKALPDCNPFMDOAEGDDEAA.ygoland@bea.com>

Should we move the e-mail thread to the bug or keep it on the mailing list?
I must admit I'm not clear how exactly how the bug mechanism is to work with
the mailing list.
	Thanks,
		Yaron

> -----Original Message-----
> From: Martin Chapman [mailto:martin.chapman@oracle.com]
> Sent: Tuesday, June 10, 2003 8:46 AM
> To: Jean-Jacques Dubray; Assaf Arkin; Burdett, David
> Cc: 'Yaron Y. Goland'; 'WS Chor Public'
> Subject: RE: Requirements: Decision Points Requirement Proposals
>
>
> I have logged this as an issue in Bugzilla, for which I urge you
> all to have
> a play with.
>
> http://www.w3.org/Bugs/Public/show_bug.cgi?id=220
>
> Martin.
>
> > -----Original Message-----
> > From: public-ws-chor-request@w3.org
> > [mailto:public-ws-chor-request@w3.org]On Behalf Of Jean-Jacques Dubray
> > Sent: Tuesday, June 10, 2003 5:48 PM
> > To: Assaf Arkin; Burdett, David
> > Cc: 'Yaron Y. Goland'; 'WS Chor Public'
> > Subject: Re: Requirements: Decision Points Requirement Proposals
> >
> >
> >
> > Assaf:
> >
> > > The question is, can we assume we're always going to use a
> standardized
> > > mechanism, and can we agree on which mechanism it is?*
> >
> > This question realy relates to do we assume that web services that
> > participate in a web service choreography require a specific
> > software layer.
> > If yes, then it probably would not be too hard to deal with
> correlation at
> > the protocol level. On the contrary, if we assume that any
> services could
> > participate in a choreography, we would then need ad hoc correlation
> > mechanisms.
> >
> > I guess we should have a requirement around that topic as well.
> >
> > JJ-
> >
> > >
> > > arkin
> > >
> > >
> > > Burdett, David wrote:
> > >
> > > > JJ
> > > > I agree with you that correlation is not a topic we have
> discussed. I,
> > > > like you prefer a choreography instance id as it simplifies the
> > > > choreography definition and is indpendent of the detail of
> the message
> > > > content. However it does mean that there can then be inconsistencies
> > > > between the choreography instance id and some id inside the message
> > > > content e.g. an order no.
> > > > David
> > > >
> > > >     -----Original Message-----
> > > >     *From:* Jean-Jacques Dubray [mailto:jjd@eigner.com]
> > > >     *Sent:* Monday, June 09, 2003 2:22 AM
> > > >     *To:* 'Burdett, David'; 'Yaron Y. Goland'; 'WS Chor Public'
> > > >     *Subject:* RE: Requirements: Decision Points
> Requirement Proposals
> > > >
> > > >     "The WS-Chor choreography definition MUST provide mechanisms by
> > > >     which the execution of one choreography definition is
> dependent on
> > > >     the execution of the instance of some other choreography
> > > >     definition". The use case for this is where you want to
> execute a
> > > >     choreography that determines the current state of processing of
> > > >     some earlier choreography. The "query" choreography can only
> > > >     validly be executed if there is some earlier instance of the a
> > > >     choreography that can be referenced.
> > > >
> > > >     */[JJ] I would treat the “query/admin” problem as an independent
> > > >     problem like you seem to suggest in the following
> points. However,
> > > >     I can see the advantages of your proposal above in
> > > >     Multi-party-collaborations. This will save us from complex
> > > >     correlation schemes./*
> > > >
> > > >     */This is another area of requirements that I think we did not
> > > >     touch: correlation. There are two possible approaches:
> an explicit
> > > >     correlation mechanism based on the document contents, and a
> > > >     choreography protocol which envelope contains a choreography
> > > >     instance ID. I personally favor the choreography protocol as it
> > > >     works in all cases and simplifies the choreography
> definition. /*
> > > >
> > > >     The following couple of requirements are ones that have been
> > > >     discussed much earlier on the list however I am not sure that we
> > > >     really want to do them, at least not initially, but I do think
> > > >     they are worth discussing ...
> > > >
> > > >     "The WS Choreography specification MUST provide standardized,
> > > >     reusable choreography definitions that allow one role
> to determine
> > > >     another roles state of processing of a choreography instance, no
> > > >     matter what choreography definition was being followed."
> > > >
> > > >     "The WS Choreography specification MUST provide standardized,
> > > >     reusable choreography definitions that allow one role to request
> > > >     another role to restart the processing of a "stalled"
> choreography
> > > >     instance, no matter what choreography definition was being
> > > >     followed." This could simply be a request to resend some earlier
> > > >     message that got lost.
> > > >
> > > >     The rationale for both of these is that querying the status of a
> > > >     choreography and re-starting a choreography will be common
> > > >     requirements for many (but not all) choreographies and therefore
> > > >     having a standard way of doing these functions will make
> > > >     choreographies easier to design and develop.
> > > >
> > > >     As stated earlier, more comments inline below.
> > > >
> > > >     David
> > > >
> > > >     -----Original Message-----
> > > >     From: Yaron Y. Goland [mailto:ygoland@bea.com]
> > > >     Sent: Wednesday, June 04, 2003 4:28 PM
> > > >     To: WS Chor Public
> > > >     Subject: Requirements: Decision Points Requirement Proposals
> > > >
> > > >     I propose the following requirements be added to the
> requirements
> > > >     document:
> > > >
> > > >     The WS-Chor choreography description format MUST provide
> > > >     mechanisms to
> > > >     enable a choreography to specify that a process in a particular
> > > >     role MUST
> > > >     send zero, one or more messages from a statically defined set of
> > > >     messages in
> > > >     parallel, serial or any combination of the two.
> > > >     <DB> A couple of comments:
> > > >     1. I think a role that MUST send zero messages doesn't
> work as if
> > > >     the role MUST send zero messages, then why is it in the
> > choreography.
> > > >
> > > >     2. Why do you use the term "description format" instead of the
> > > >     simpler "definition' because, aren't the properties you seek a
> > > >     characteristic of the definition rather than the format of the
> > > >     definition.
> > > >
> > > >     3. The first sentence is circular as it says ... "The WS-Chor
> > > >     choreography description format MUST enable a choreography ..."
> > > >     without specifying what a choreography is.
> > > >
> > > >     4. I think you mean when you say a "statically defined set of
> > > >     messages" that the actual messages definitions that can be sent
> > > >     are finite in number and from a proscribed list. There
> has been a
> > > >     lot of discussion on the idea of variability in the detailed
> > > >     message content which means that limiting a choreography to
> > > >     specific message formats will inhibit choreography
> reuse. Instead
> > > >     I thinkt that we should refer to "Message Types" or "Message
> > > >     Families" rather than "messages".
> > > >
> > > >     5. This requirement is also very similar to the next so my
> > > >     alternative is described below
> > > >     </DB>
> > > >
> > > >     The WS-Chor choreography description format MUST be able
> > to describe
> > > >     decision points where a process in a particular role MAY send
> > > >     zero, one or
> > > >     more messages from a statically defined set of messages in
> > > >     parallel, serial
> > > >     or any combination of the two.
> > > >     <DB>So how about the following requirement that combines the
> > > >     previous two and takes into account the comments I made ...
> > > >
> > > >     "The WS-Chor choreography definition MUST provide
> mechanisms that
> > > >     define the sequence in which one or more messages types are
> > > >     exchanged between two or more roles either in parallel, serially
> > > >     or any combination of the two, together with the conditions that
> > > >     cause those messages to be sent."</DB>
> > > >
> > > >     The WS-Chor choreography description format MUST be able to
> > > >     describe who is
> > > >     to receive a message by referencing their role.
> > > >     <DB>I would add the sender to this definition to give
> ... "The WS
> > > >     Choreography definition MUST be able to describe who
> the sender of
> > > >     a message is and who the receiver should be by referencing their
> > > >     role." The rationale for this is that what you do with a message
> > > >     may well depend on the role of the sender ... assuming that the
> > > >     same message can be sent by different roles.</DB>
> > > >
> > > >     The WS-Chor choreography description format MUST make
> it possible
> > > >     to specify
> > > >     a role's binding to an actual web service instance either
> > > >     statically, when a
> > > >     web service using that choreography is deployed, or
> dynamically at
> > > >     run time.
> > > >
> > > >     The WS-Chor choreography description format MUST provide
> > > >     mechanisms to allow
> > > >     messages to be sent to a particular member of a set of web
> > > >     services in the
> > > >     same role.
> > > >     [Ed Note: What I'm very inelegantly trying to capture
> is the idea
> > > >     that if
> > > >     you are running an auction service and you just found
> out that one
> > > >     of the
> > > >     bidders isn't qualified to bid you need a way to say things like
> > > >     "I'm now
> > > >     going to send out an unsolicited 'get lost you dead
> beat' message
> > > >     to one web
> > > >     service that is in the role of bidder." This could then
> trigger a
> > > >     whole set
> > > >     of messages back and forth between the auction service and the
> > > >     dead beat
> > > >     bidder, the choreography needs some way to capture the fact that
> > > >     you are
> > > >     still talking to the same member of the role group.]
> > > >     <DB>This example introduces the idea of a role group, which I
> > > >     don't *think* we need. If we take this use case, then you can
> > > >     actually consider it as an internal "business process" problem,
> > > >     for example:
> > > >
> > > >     The auctioneer has a business process that consists of a set of
> > > >     separate individual identical choreographies between the
> > > >     auctioneer and the bidder where each choreography instance would
> > > >     take the following form ...
> > > >
> > > >     AUCTIONEER BIDDER
> > > >     Bid Invite ------->
> > > >     Either ...
> > > >     Get Lost --------->
> > > >     ... or ...
> > > >     <--------------- Bid
> > > >     ... etc ...
> > > >     The fact that there are several bidders involved is
> something that
> > > >     only the auctioneer needs to be concerned of.
> > > >
> > > >     This means that this is really a business process (e.g. BPEL )
> > > >     problem rather than a choreography problem especially as the
> > > >     auctioneer is in complete control of what goes on. For example,
> > > >     the auctioneer could treat all the interactions as being part of
> > > >     one choreography by using the same identifier for the
> correlation
> > > >     of all the messages irrespective of the bidder.
> > > >
> > > >     Now there may be a use case where you really do the need the
> > > >     variability, but I can't think of one. On the other hand, if we
> > > >     can avoid this variability, then it will simplify the
> > > >     specification we need to write significantly.
> > > >
> > > >     </DB>
> > > >
> > > >     The WS-Chor choreography description format MUST NOT
> require that
> > > >     the logic
> > > >     used by a sender in a decision point to decide how to act be
> > > >     exposed in the
> > > >     choreography.
> > > >     <DB>There's a corollary, I think, that says something like ...
> > > >     "The WS-Chor choreography definition MUST enable the results of
> > > >     decisions made by one role that affect the behavior of another
> > > >     role to be communicated to the other role." This is really about
> > > >     the transmission of relevant state information between
> roles.</DB>
> > > >
> > > >     The WS-Chor choreography description format MUST enable the
> > > >     annotation of
> > > >     all actions with human readable descriptions.
> > > >     <DB>I agree but would go further and replace the last
> phrase with
> > > >     "... with clear semantic definitions." Something might be human
> > > >     readable but that does not mean it explains the purpose
> well.</DB>
> > > >
> > > >     The WS-Chor choreography description format MUST provide
> > an abstract
> > > >     mechanism where by the logic used to make a decision at
> a decision
> > > >     point can
> > > >     be expressed through reference to a WSBPEL abstract or
> executable
> > > >     process or
> > > >     similar machine readable logic.
> > > >     <DB>I don't have an alternative definition, but this
> pre-supposes
> > > >     a binding to WSBPEL that we might (or might not) want to make
> > > >     unless and until we collectively (i.e. WSBPEL and
> WSCHOR) work out
> > > >     what the goals and relationships of each activity will be.</DB>
> > > >
> > > >     The WS-Chor choreography description format base specification
> > > >     MUST NOT
> > > >     specify bindings for the abstract mechanism used to reference
> > machine
> > > >     readable logic, rather extension specifications on top
> of the base
> > > >     specification MUST be used.
> > > >     <DB>As a general comment, we could do with developing
> definitions
> > > >     of various terms, e.g. "decision point", "base specification"
> > > >     which although quite intuitive, could be open to
> > > >     miss-interpretation.</DB>
> > > >
> > > >     I would appreciate it if objections to these requirements were
> > > >     stated in the
> > > >     form of alternate proposals. It's easy to say why something is
> > > >     wrong, it's a
> > > >     lot harder to spend the time to specify what is right.
> > > >
> > > >     Yaron
> > > >
> > >
> > >
> >
> >
>
>
Received on Tuesday, 24 June 2003 16:02:02 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 01:00:21 GMT