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, 10 June 2003 11:47:01 UTC