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