- From: Jean-Jacques Dubray <jjd@eigner.com>
- Date: Thu, 5 Jun 2003 05:35:59 -0400
- To: "'Yaron Y. Goland'" <ygoland@bea.com>, "'WS Chor Public'" <public-ws-chor@w3.org>
>>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. [JJ] Does this requirement imply that a role can only be bound to one web service or several web services. IMHO, we need to support multiple web service binding to one role. >> >>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.] [JJ] Maybe we could say that a role MAY be implemented by more than one participant in a web service choreography instance. It sounds like an interesting proposal, but I would like to be convinced that any use case that require this cannot be implemented by a series of "simple" choreography that only involve a one-to-one relationship between role and participants. The "multiple participant scenario" would require that the initiator of the choreography is able to broadcast a message to a role, then the run time has to keep track of the individual conversations with the participants of the same role. Sounds like a proposition difficult to implement. >> >>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. [JJ] Furthermore, if a web service choreography definition is exposing some logic as part of a decision point, this logic MUST apply to the content of messages exchanged during the choreography instance prior to the decision point. The decision point expression language MUST be compatible with XML. >> >>The WS-Chor choreography description format MUST enable the annotation of >>all actions with human readable descriptions. [JJ] It would be best if these annotations can be XML fragments rather than text only. It would enable people to add "Commitment Oriented" semantics (See Bob Haugen's COOL presentation). >> >>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. [JJ] I predict that as soon as we will open choreography to "internal" logic, either it will be identical to the logic on the messages exchanged during the choreography exchange or it will open a whole set of issue related to "objects" represented by the messages being exchanged and their respective state. In other words, a message typically carries representation of business objects in a given state. The fundamental question is do we want to expose this to the choreography definition language (via decision point expression), or is it enough to express the decision point on the content of the messages. Orchestration languages need by definition to understand the objects and their state, however, it is not always clear in current BPM "standards". JJ-
Received on Thursday, 5 June 2003 05:36:58 UTC