Issue 14686: Exclusive gateway Choreography rules too restrictive, only sender needed (bpmn2-rtf) Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov) Nature: Revision Severity: Significant Summary: Decisions are prevented from being used Choreographies if not all participants have access to the information on which the decision is made. But if the activities following the gateway are all sent by the same participant, only that participant needs to know how the decision is made. Using an event-based gateway in this case is confusing, since there is no waiting for events to proceed to the activities following it. Some sided email below about this. Steve, > The Gateway would most likely be Event based. The Buyer is > probably not going to be aware of the data that would be > used to make the decision, particularly a change order. > Thus, the Buyer is just going to be waiting for one of the > three responses. Makes sense for the buyer, but this isn't a model of the buyer (and the Seller is making a regular decision, why isn't that shown?). It's also odd to see an event-based gateway in a choreography since choreography can't don't wait for events, the participants do. The figure looks right according to the spec, but I think the spec is too restrictive on regular decisions in choreogrpahies. Conrad Steve, > The Seller is making a regular decision internally, but the > rationale (i.e., data) used to make the decision is private > for the Seller. A Choreography can only use Exclusive > Gateways if the data used for them is public. I understand that's the rule, but I'm not sure it make sense. In this case, the activities following the gateway are all initiated by the Seller. The rule should be that the seller has access to the decision data. > The Buyer does not know ahead of time, what the > results of the decision will be since the Buyer has not seen the > Seller's internal data. And that's fine, because it isn't the Buyer who initiates any of the activities after the gateway. > All private Exclusive Gateways show up as Event Gateways in a > Choreography. This is too hard to explain, for example, who receives the event? The choreography itself can't received an event, and there's no indication that it's the Buyer (other than they Buyer is receiving in the activities after the gateway). For FTF discussion. :) Conrad Resolution: Revised Text: Actions taken: November 19, 2009: received issue Discussion: This requires decisions with no conditions in a choreography, which means the conditions are known privately to the sender of the activities after the exclusive gateway, but not modeled in the "public" choreography. This avoids event-based gateways in choreographies, which cannot respond to events. These "abstract" choreographies are possible, but requires more discussion in RTF in conjunction with 14663 [OMG 14663]. Disposition: Deferred End of Annotations:===== s is issue # 14686 [OMG 14686] Exclusive gateway Choreography rules too restrictive, only sender needed ##Source: NIST (Conrad Bock, conrad.bock@nist.gov) ##Original Issue: http://www.osoa.org/jira/browse/BPMN-546 ##Original Info: (Severity: Significant - Nature: Revision) Decisions are prevented from being used Choreographies if not all participants have access to the information on which the decision is made. But if the activities following the gateway are all sent by the same participant, only that participant needs to know how the decision is made. Using an event-based gateway in this case is confusing, since there is no waiting for events to proceed to the activities following it. Some sided email below about this. Steve, > The Gateway would most likely be Event based. The Buyer is > probably not going to be aware of the data that would be > used to make the decision, particularly a change order. > Thus, the Buyer is just going to be waiting for one of the > three responses. Makes sense for the buyer, but this isn't a model of the buyer (and the Seller is making a regular decision, why isn't that shown?). It's also odd to see an event-based gateway in a choreography since choreography can't don't wait for events, the participants do. The figure looks right according to the spec, but I think the spec is too restrictive on regular decisions in choreogrpahies. Conrad Steve, > The Seller is making a regular decision internally, but the > rationale (i.e., data) used to make the decision is private > for the Seller. A Choreography can only use Exclusive > Gateways if the data used for them is public. I understand that's the rule, but I'm not sure it make sense. In this case, the activities following the gateway are all initiated by the Seller. The rule should be that the seller has access to the decision data. > The Buyer does not know ahead of time, what the > results of the decision will be since the Buyer has not seen the > Seller's internal data. And that's fine, because it isn't the Buyer who initiates any of the activities after the gateway. > All private Exclusive Gateways show up as Event Gateways in a > Choreography. This is too hard to explain, for example, who receives the event? The choreography itself can't received an event, and there's no indication that it's the Buyer (other than they Buyer is receiving in the activities after the gateway). For FTF discussion. :)