Issue 14737: Exclusive Gateway Choreography Rule too Restrictive, starting new process (bpmn2-rtf)
Source: NIST (Dr. Conrad Bock, conrad.bock(at)nist.gov)
Nature: Revision
Severity: Significant
Summary: Filed for Dale Moberg.  The rule illustrated by Figure 12-36  is that the
choreography activities after an exclusive gateway must have the same
receivers if the initiators are different.  However, the receivers can
be different if the activity starts a new process in the receiving
participant, or if the receiving participant has access to the data in
the decision from earlier in the flow.  Steve says the discussions so
far did not account for activites that start processes in the
participants.

Resolution: The beta specification does not seem to have the restriction for
exclusive gateways cited in the issue, but the filer is correct that the
choreography enforcability rules do not account for the possibility of
starting new processes in receivers. The issue is deferred for more
discussion in RTF.
Disposition: Deferred
Revised Text: 
Actions taken:
November 20, 2009: received issue
Discussion: 
Comments:
From: conrad.bock created: Wed, 25 Feb 2009 10:17:41 -0600 (CST)
From Steve's minutes:

Dale also brought up a problem with the rule defined in the Text
Annotation in Figure 11-36. The rule is too restrictive. We need to
clarify. The rule applies for some cases, but not others. If all the
Ptps have seen a message with the appropriate data, then the rule could
be relaxed. Basically all internal processes would be using data
Decisions. Also, we didn't consider that a message could be the start of
an internal Process for one of the Participants? However, if the
receivers of the message (after the decision) didn't have access to the
data, but had been previous part of the process, then there would be a
problem. The internal process of those participants would be using an
Event Gateway, but the Choreography Process would not contain the time
out information for the internal process (so that it would not get
stuck).  Basically, we need to review the examples update how the rules
are specified.

From: conrad.bock created: Thu, 23 Jul 2009 08:45:57 -0500 (CDT)
Presumably this issue applies to inclusive gateways, because a similar
decision is made about which paths to split/merge.

End of Annotations:=====
usive Gateway Choreography Rule too Restrictive, starting new process

##Source: NIST (Conrad Bock, conrad.bock@nist.gov)
##Original Issue: http://www.osoa.org/jira/browse/BPMN-437
##Original Info: (Severity: Significant - Nature: Revision)

Filed for Dale Moberg.  The rule illustrated by Figure 12-36  is that the
choreography activities after an exclusive gateway must have the same
receivers if the initiators are different.  However, the receivers can
be different if the activity starts a new process in the receiving
participant, or if the receiving participant has access to the data in
the decision from earlier in the flow.  Steve says the discussions so
far did not account for activites that start processes in the
participants.

Comments:
From: conrad.bock created: Wed, 25 Feb 2009 10:17:41 -0600 (CST)
From Steve's minutes:

Dale also brought up a problem with the rule defined in the Text
Annotation in Figure 11-36. The rule is too restrictive. We need to
clarify. The rule applies for some cases, but not others. If all the
Ptps have seen a message with the appropriate data, then the rule could
be relaxed. Basically all internal processes would be using data
Decisions. Also, we didn't consider that a message could be the start of
an internal Process for one of the Participants? However, if the
receivers of the message (after the decision) didn't have access to the
data, but had been previous part of the process, then there would be a
problem. The internal process of those participants would be using an
Event Gateway, but the Choreography Process would not contain the time
out information for the internal process (so that it would not get
stuck).  Basically, we need to review the examples update how the rules
are specified.

From: conrad.bock created: Thu, 23 Jul 2009 08:45:57 -0500 (CDT)
Presumably this issue applies to inclusive gateways, because a similar
decision is made about which paths to split/merge.