Issue 9121: BPMN comment (bpmn-ftf) Source: (, ) Nature: Uncategorized Issue Severity: Summary: BPMNOne point that need more precision in the BPMN specification is Inclusive Gateways behavior. The rule "When the Inclusive Gateway is used as a Merge, it will wait for (synchronize) all Tokens that have been produced upstream" is not clear at all. It can be applied in very simple situations (when a token is divided in several tokens when going out of an Inclusive Gateway, and merge at another Inclusive Gateway for example), but as no sense in more complex cases. As BPMN is very flexible and allows modeling of business processes that are not "block-structured" as opposed to BPEL, a more precise rule is needed for Inclusive Gateways. A discussion was opened by Petko Chobantonov on BPMN forum about this problem. He proposed another rule to clarify the Inclusive Gateway behavior but that led to nothing. Here is another comment: In the last version of the BPMN specification (Version 1.1 - July 31, 2005), a new rule was added on gateways (p 88): "If two or more Signals (Tokens) arrive to their respective Gates at the exact same time, then the Signal..." "exact same time" does not mean anything, and a rule like this has nothing to do in a "Notation" specification. Resolution: Revised Text: Section 9.5.2, page 71, section title: remove " (XOR)" from section title. Section 9.5.3, page 78, section title: remove " (OR)" from section title. Section 9.5.5, page 85, section title: remove " (AND)" from section title. Section 9.5.3, page 80, paragraph 2: replace the first sentence with "When the Inclusive Gateway is used as a Merge, it will synchronize all Tokens that exist upstream, but at most one for each incoming Sequence Flow (refer to the section entitled “XXXX” for a definition of Token flow semantics). Note: Tokens with a loop are upstream of every node in the loop." Section 9.5.3, page 80, paragraph 2: remove the second sentence. Actions taken: October 26, 2005: received comment July 26, 2006: moved to bpmn-ftf April 19, 2007: closed issue Discussion: Resolution: We will enhance the definition of the merging behavior of the Inclusive Gateway to include the definition as stated in the revised text section below. The second part of the Issue is considered out of scope of the FTF since it refers to a version (draft V1.1 by BPMI) of the specification that is not under consideration of the FTF and never will be under consideration of an OMG Task Force. The use of formal terms such as XOR, OR, and AND was considered as potentially confusing when the description of Gateway behavior is considered. The names of the Gateways was considered a better (but not perfect) indicator of the behavior. Thus, we decided to remove parenthetical additions of the formal terms, especially in the section titles. End of Annotations:===== m: webmaster@omg.org Date: 26 Oct 2005 09:38:07 -0400 To: Subject: RFC Comments -------------------------------------------------------------------------------- Comments: BPMNOne point that need more precision in the BPMN specification is Inclusive Gateways behavior. The rule "When the Inclusive Gateway is used as a Merge, it will wait for (synchronize) all Tokens that have been produced upstream" is not clear at all. It can be applied in very simple situations (when a token is divided in several tokens when going out of an Inclusive Gateway, and merge at another Inclusive Gateway for example), but as no sense in more complex cases. As BPMN is very flexible and allows modeling of business processes that are not "block-structured" as opposed to BPEL, a more precise rule is needed for Inclusive Gateways. A discussion was opened by Petko Chobantonov on BPMN forum about this problem. He proposed another rule to clarify the Inclusive Gateway behavior but that led to nothing. Here is another comment: In the last version of the BPMN specification (Version 1.1 - July 31, 2005), a new rule was added on gateways (p 88): "If two or more Signals (Tokens) arrive to their respective Gates at the exact same time, then the Signal..." "exact same time" does not mean anything, and a rule like this has nothing to do in a "Notation" specification. Name: Casenove Cédric Email: ccasenove@axway.com Company: Axway Software B1: Submit To: bpmn-ftf@omg.org Subject: Proposed Resolution for Issue 9121 X-Mailer: Lotus Notes Release 7.0 HF85 November 04, 2005 From: Stephen A White Date: Mon, 20 Feb 2006 16:23:35 -0800 X-MIMETrack: Serialize by Router on D03NM690/03/M/IBM(Release 6.53HF743 | November 3, 2005) at 02/20/2006 17:23:36, Serialize complete at 02/20/2006 17:23:36 The resolution and related information about the Issue can be found here: http://www.bpmn.org/FTF/Issues/Issue%209121.htm If you have any comments, questions, suggested revisions to the current resolution, or an alternative resolution, then reply to this message or speak up at a group meeting. Thanks. -Steve Subject: A comment on Issue 9121 - Definition of Inclusive OR Merging Date: Tue, 21 Feb 2006 13:55:35 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: A comment on Issue 9121 - Definition of Inclusive OR Merging Thread-Index: AcY3GGXAk6m1g4cmQaqNTEVM/4Fllg== From: "Rob Bartel" To: Unfortunately, I was unable to attend the FTF meeting and listen to the discussion about this issue, but I am unclear why the first diagram in the issue description at http://www.bpmn.org/FTF/Issues/Issue%209121.htm presents a problem or ambiguity. The simulation tool that I work on has had the inclusive-or feature in it for many years, and I am unaware of any problem created by this configuration. I completely support clarifying the description of the behavior of the inclusive-or join using the language in Wil van der Aalst's YAWL paper, but I do not believe the second part of the proposal, to include a paragraph discouraging its use except in the case shown in the second diagram, is warranted. It is not uncommon to have a process with multiple and optional parallel paths, some of which need to synchronize or merge before all do. Rob To: bpmn-ftf@omg.org Subject: Re: A comment on Issue 9121 - Definition of Inclusive OR Merging X-Mailer: Lotus Notes Release 7.0 HF85 November 04, 2005 From: Stephen A White Date: Tue, 21 Feb 2006 19:33:14 -0800 X-MIMETrack: Serialize by Router on D03NM690/03/M/IBM(Release 6.53HF743 | November 3, 2005) at 02/21/2006 20:33:17, Serialize complete at 02/21/2006 20:33:17 I've replaced the figure for the Issue (http://www.bpmn.org/FTF/Issues/Issue%209121.htm) with a clearer one. The general idea of the old description was that the identification of the Token would be sufficient to work the Inclusive OR merging (so that the Gateway wouldn't have to know the layout of the diagram, which could be very complex). But in the figure, if an upstream Inclusive OR split doesn't send all of its potential Tokens to the downstream Inclusive OR merge, then the ID of the Tokens would confuse the merge. That is, Token "A: 1 of 2" Arrives, implying that a Token "A: 2 of 2" should arrive later. If the model isn't set up that way, then problems could occur. The new definition is suppose to alleviate the problem. Certainly the FTF should review the definition to see if that is in fact the case. Also, more comments should be addressed to the warning comment in the proposal. -Steve "Rob Bartel" 02/21/2006 10:55 AM To cc Subject A comment on Issue 9121 - Definition of Inclusive OR Merging Unfortunately, I was unable to attend the FTF meeting and listen to the discussion about this issue, but I am unclear why the first diagram in the issue description at http://www.bpmn.org/FTF/Issues/Issue%209121.htm presents a problem or ambiguity. The simulation tool that I work on has had the inclusive-or feature in it for many years, and I am unaware of any problem created by this configuration. I completely support clarifying the description of the behavior of the inclusive-or join using the language in Wil van der Aalst's YAWL paper, but I do not believe the second part of the proposal, to include a paragraph discouraging its use except in the case shown in the second diagram, is warranted. It is not uncommon to have a process with multiple and optional parallel paths, some of which need to synchronize or merge before all do. Rob Subject: OR-Join Definition Date: Fri, 17 Feb 2006 14:06:53 -0600 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: OR-Join Definition Thread-Index: AcYz/bIsvntb0nNOSvSkR1lH+ZkM/A== From: "Petko Chobantonov" To: I'm sending the document that I have posted to the BPMN group. The new definition clarifies the current definition and provides a strong execution semantics. It also contains several examples. I'm attaching the PDF document mentioned in the proposal. This document describes the formal approach to the definition. Petko ORJoinDefinition.doc yawlqut2003.pdf Reply-To: From: "Conrad Bock" To: "'Petko Chobantonov'" , Subject: RE: OR-Join Definition Date: Fri, 17 Feb 2006 15:25:21 -0500 X-Mailer: Microsoft Office Outlook 11 thread-index: AcYz/bIsvntb0nNOSvSkR1lH+ZkM/AAAcrmQ Hi Petko, > The new definition clarifies the current definition > and provides a strong execution semantics. How does the execution engine tell if there are more tokens coming to the OR join? If there are any steps/nodes in the graph that receive events from the outside, it's impossible to tell. Even if there are no external events, the detection is very nonlocal, so the execution depends on a central overall execution. > I'm attaching the PDF document mentioned in the proposal. > This document describes the formal approach to the definition. Formality is great, but it can hide trouble. Conrad Subject: RE: OR-Join Definition Date: Fri, 17 Feb 2006 15:29:39 -0600 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OR-Join Definition Thread-Index: AcYz/bIsvntb0nNOSvSkR1lH+ZkM/AAAcrmQAAHAIeA= From: "Petko Chobantonov" To: , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id k1HLM7eD019864 Hi Conrad, >> How does the execution engine tell if there are more tokens coming to the OR join? If there are any steps/nodes in >> the graph that receive events from the outside, it's impossible to tell. Even if there are no external events, the >> detection is very nonlocal, so the execution depends on a central overall execution. This is an implementation concern. The current problem is that the execution semantics is not well defined. The proposed solution fixes this problem. About the implementation: The execution engine needs to know only about tokens that are on the current diagram. The fact that business process could span multiple process definitions and that multiple execution engines could be involved during the execution of a diagram is not a problem. For example: A business process could be described using multiple diagrams A, B, C. Each of those diagrams could be executed in multiple execution engines. Also the fact that an engine has to know about the tokens on a diagram is not a problem specific to OR-Joins. The same is true when you want to cancel all created human tasks (e.g. to withdraw them) for a particular sub-process if something goes wrong. For example: an author decides to cancel all created user tasks because they are no longer relevant. In this case the engine has to know cancel all active actions e.g. it had to know the location of the tokens. Petko -----Original Message----- From: Conrad Bock [mailto:conrad.bock@nist.gov] Sent: Friday, February 17, 2006 2:25 PM To: Petko Chobantonov; bpmn-ftf@omg.org Subject: RE: OR-Join Definition Hi Petko, > The new definition clarifies the current definition > and provides a strong execution semantics. How does the execution engine tell if there are more tokens coming to the OR join? If there are any steps/nodes in the graph that receive events from the outside, it's impossible to tell. Even if there are no external events, the detection is very nonlocal, so the execution depends on a central overall execution. > I'm attaching the PDF document mentioned in the proposal. > This document describes the formal approach to the definition. Formality is great, but it can hide trouble. Conrad Reply-To: From: "Conrad Bock" To: "'Petko Chobantonov'" , Subject: RE: OR-Join Definition Date: Fri, 17 Feb 2006 17:14:06 -0500 X-Mailer: Microsoft Office Outlook 11 thread-index: AcYz/bIsvntb0nNOSvSkR1lH+ZkM/AAAcrmQAAHAIeAAAgA2wA== > > How does the execution engine tell if there are more tokens coming > > to the OR join? If there are any steps/nodes in the graph that > > receive events from the outside, it's impossible to tell. Even if > > there are no external events, the detection is very nonlocal, so > > the execution depends on a central overall execution. > > This is an implementation concern. The current problem is > that the execution semantics is not well defined. The > proposed solution fixes this problem. Sure, but a semantics that asks a question ("are there any more tokens coming?") that can't be answered isn't a good semantics. > About the implementation: > The execution engine needs to know only about tokens that > are on the current diagram. Tokens can come into a diagram from external sources that are not under the control of the diagram. It is impossible to know if there are no more coming. A semantics that ignores this won't handle processes involved in a choreography. > The fact that business process could span multiple process > definitions and that multiple execution engines could be involved > during the execution of a diagram is not a problem. For example: A > business process could be described using multiple diagrams A, B, > C. Each of those diagrams could be executed in multiple execution > engines. The above doesn't explain why it is not a problem. It isn't guaranteed that the execution engines have access to each other, so any semantics requiring that is not possible to implement. > Also the fact that an engine has to know about the tokens on a > diagram is not a problem specific to OR-Joins. The same is true when > you want to cancel all created human tasks (e.g. to withdraw them) > for a particular sub-process if something goes wrong. For example: > an author decides to cancel all created user tasks because they are > no longer relevant. In this case the engine has to know cancel all > active actions e.g. it had to know the location of the tokens. Yes, it would be a problem there, too. The fact that the problem appears in more than one place doesn't make it less of a problem. Conrad Subject: RE: OR-Join Definition Date: Fri, 17 Feb 2006 18:16:27 -0600 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OR-Join Definition Thread-Index: AcYz/bIsvntb0nNOSvSkR1lH+ZkM/AAAcrmQAAHAIeAAAgA2wAAATm1g From: "Petko Chobantonov" To: , >Sure, but a semantics that asks a question ("are there any more tokens >coming?") that can't be answered isn't a good semantics. Actually the PDF document that I sent answers this question and proves that it is possible to build an execution engine that handles the proposed semantics. There is an implementation that uses this semantics in the implementation of YAWL (Yet Another Workflow Language). > Tokens can come into a diagram from external sources that are not under > the control of the diagram. It is impossible to know if there are no > more coming. A semantics that ignores this won't handle processes > involved in a choreography. The definition is based on the current set of tokens. (This was implied, but you are right that it should be made explicit). The PDF document defines the meaning of current token set. When an event is sent, it will be correlated to a Process Instance (it could be correlated to multiple instances too). At that point a token will appear on the actual event. >> Also the fact that an engine has to know about the tokens on a >> diagram is not a problem specific to OR-Joins. The same is true when >> you want to cancel all created human tasks (e.g. to withdraw them) >> for a particular sub-process if something goes wrong. For example: >> an author decides to cancel all created user tasks because they are >> no longer relevant. In this case the engine has to know cancel all >> active actions e.g. it had to know the location of the tokens. >Yes, it would be a problem there, too. The fact that the problem >appears in more than one place doesn't make it less of a problem. Again this is an implementation concern. Maybe someone will come up with a common way of solving the problem. Petko -----Original Message----- From: Conrad Bock [mailto:conrad.bock@nist.gov] Sent: Friday, February 17, 2006 4:14 PM To: Petko Chobantonov; bpmn-ftf@omg.org Subject: RE: OR-Join Definition > > How does the execution engine tell if there are more tokens coming > > to the OR join? If there are any steps/nodes in the graph that > > receive events from the outside, it's impossible to tell. Even if > > there are no external events, the detection is very nonlocal, so > > the execution depends on a central overall execution. > > This is an implementation concern. The current problem is > that the execution semantics is not well defined. The > proposed solution fixes this problem. Sure, but a semantics that asks a question ("are there any more tokens coming?") that can't be answered isn't a good semantics. > About the implementation: > The execution engine needs to know only about tokens that > are on the current diagram. Tokens can come into a diagram from external sources that are not under the control of the diagram. It is impossible to know if there are no more coming. A semantics that ignores this won't handle processes involved in a choreography. > The fact that business process could span multiple process > definitions and that multiple execution engines could be involved > during the execution of a diagram is not a problem. For example: A > business process could be described using multiple diagrams A, B, > C. Each of those diagrams could be executed in multiple execution > engines. The above doesn't explain why it is not a problem. It isn't guaranteed that the execution engines have access to each other, so any semantics requiring that is not possible to implement. > Also the fact that an engine has to know about the tokens on a > diagram is not a problem specific to OR-Joins. The same is true when > you want to cancel all created human tasks (e.g. to withdraw them) > for a particular sub-process if something goes wrong. For example: > an author decides to cancel all created user tasks because they are > no longer relevant. In this case the engine has to know cancel all > active actions e.g. it had to know the location of the tokens. Yes, it would be a problem there, too. The fact that the problem appears in more than one place doesn't make it less of a problem. Conrad Subject: Re: OR-Join Definition Date: Sat, 18 Feb 2006 01:50:25 +0100 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OR-Join Definition Thread-Index: AcYz/bIsvntb0nNOSvSkR1lH+ZkM/AAAcrmQAAHAIeAAAgA2wAAFs/6V From: "LONJON Antoine" To: , , The activity flow allows for multiple unstructured parallel threads. An OR-join means that one of the thread will arbitrarely pass through, thé others will be cancelled I tend to think this is bad practice but it is thé nature of unstructiured parallel threads -----Original Message----- From: Conrad Bock To: 'Petko Chobantonov'; bpmn-ftf@omg.org Sent: Fri Feb 17 23:14:06 2006 Subject: RE: OR-Join Definition > > How does the execution engine tell if there are more tokens coming > > to the OR join? If there are any steps/nodes in the graph that > > receive events from the outside, it's impossible to tell. Even if > > there are no external events, the detection is very nonlocal, so > > the execution depends on a central overall execution. > > This is an implementation concern. The current problem is > that the execution semantics is not well defined. The > proposed solution fixes this problem. Sure, but a semantics that asks a question ("are there any more tokens coming?") that can't be answered isn't a good semantics. > About the implementation: > The execution engine needs to know only about tokens that > are on the current diagram. Tokens can come into a diagram from external sources that are not under the control of the diagram. It is impossible to know if there are no more coming. A semantics that ignores this won't handle processes involved in a choreography. > The fact that business process could span multiple process > definitions and that multiple execution engines could be involved > during the execution of a diagram is not a problem. For example: A > business process could be described using multiple diagrams A, B, > C. Each of those diagrams could be executed in multiple execution > engines. The above doesn't explain why it is not a problem. It isn't guaranteed that the execution engines have access to each other, so any semantics requiring that is not possible to implement. > Also the fact that an engine has to know about the tokens on a > diagram is not a problem specific to OR-Joins. The same is true when > you want to cancel all created human tasks (e.g. to withdraw them) > for a particular sub-process if something goes wrong. For example: > an author decides to cancel all created user tasks because they are > no longer relevant. In this case the engine has to know cancel all > active actions e.g. it had to know the location of the tokens. Yes, it would be a problem there, too. The fact that the problem appears in more than one place doesn't make it less of a problem. Conrad **********************************IMPORTANT*********************************** The content of this email and any attachments are confidential and intended for the named recipient(s) only. If you have received this email in error please return it to our postmaster immediately and delete it from your system. WARNING: Although MEGA has taken reasonable precautions to ensure no viruses are present in this email, MEGA cannot accept responsibility for any loss or damage arising from the use of this email or attachments. ****************************************************************************** Reply-To: From: "Conrad Bock" To: "'Petko Chobantonov'" , Subject: RE: OR-Join Definition Date: Thu, 23 Feb 2006 10:48:47 -0500 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcYz/bIsvntb0nNOSvSkR1lH+ZkM/AAAcrmQAAHAIeAAAgA2wAAATm1gAR9Fr7A= X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id k1NFerPd021547 Petko, > Actually the PDF document that I sent answers this question > and proves that it is possible to build an execution engine > that handles the proposed semantics. Perhaps, but you can't include the PDF in the spec. The statement of the semantics short enough to fit into the spec, where "semantics" means something more explanatory than the one-liner in ryou document. A good place to start on that is to give this in an email. After thinking more on this, there are couple things that should be included for clarification (if this is the intention): - Activities (UML actions) that wait for incoming events are considered to have tokens in them. This means an or-join downstream of this activity can't be enabled if the activity is still waiting for events. This is true even if no events ever come. - Decision points upstream from the or-join may decide never to send tokens along the path to the or-join. Since it is difficult to analyze if this is the case, presumably the semantics will assume that it might send token to or-join. So if tokens are upstream of the decision point, the or-join cannot be enabled, even if the decision point never sends tokens to the or-join. > When an event is sent, it will be correlated to a Process Instance > (it could be correlated to multiple instances too). At that point a > token will appear on the actual event. I don't think the semantics of the diagram waiting for the event should not depend on figuring out if other agents are sending events. > [Antoine] The activity flow allows for multiple unstructured > parallel threads. An OR-join means that one of the thread will > arbitrarely pass through, thé others will be cancelled I tend to > think this is bad practice but it is thé nature of unstructiured > parallel threads My understanding of the proposal is that there are no cancelled threads. One can't get through until all the others that can "possibly" arrive actually do. It's the "possibly" part that is poorly specified, and not even necessarily desirable. Is there any input from business users on whether it is the execution they would expect? Conrad Subject: RE: OR-Join Definition Date: Thu, 23 Feb 2006 11:10:14 -0500 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OR-Join Definition Thread-Index: AcYz/bIsvntb0nNOSvSkR1lH+ZkM/AAAcrmQAAHAIeAAAgA2wAAATm1gAR9Fr7AAAR6O8A== From: "Rob Bartel" To: , "Petko Chobantonov" , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id k1NG2NxA021968 - Decision points upstream from the or-join may decide never to send tokens along the path to the or-join. Since it is difficult to analyze if this is the case, presumably the semantics will assume that it might send token to or-join. So if tokens are upstream of the decision point, the or-join cannot be enabled, even if the decision point never sends tokens to the or-join. I would agree with this, and believe it is conventional behavior of execution systems and simulators that support or-join, assuming that your intent with this last sentence is: "So if tokens are upstream of the decision point, the or-join cannot be enabled *until the decision is made*, even if the decision point never sends tokens to the or-join" > [Antoine] The activity flow allows for multiple unstructured > parallel threads. An OR-join means that one of the thread will > arbitrarely pass through, thé others will be cancelled I tend to > think this is bad practice but it is thé nature of unstructiured > parallel threads My understanding of the proposal is that there are no cancelled threads. One can't get through until all the others that can "possibly" arrive actually do. It's the "possibly" part that is poorly specified, and not even necessarily desirable. Is there any input from business users on whether it is the execution they would expect? I would agree with Conrad's understanding. I understand the type of join that Antoine describes (first one wins) to be the behavior of an exclusive-or gateway (see p.119-120 of the OMG BPMN spec). I don't know if I can be considered a "business user", in that what I do is work on a business process simulation tool that supports both or-join and multiple unstructured threads, but we have had a considerable amount of pushback from our simulation users in trying to discourage use of "multiple unstructured threads". Admittedly, these users are doing process modeling and simulation rather than execution. In an actual execution system I have to agree with Antoine about the unadvisability of using them. Subject: RE: OR-Join Definition Date: Thu, 23 Feb 2006 10:34:30 -0600 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OR-Join Definition Thread-Index: AcYz/bIsvntb0nNOSvSkR1lH+ZkM/AAAcrmQAAHAIeAAAgA2wAAATm1gAR9Fr7AAAR6O8AABMgLQ From: "Cummins, Fred A" To: "Rob Bartel" , , "Petko Chobantonov" , X-OriginalArrivalTime: 23 Feb 2006 16:34:37.0484 (UTC) FILETIME=[095B66C0:01C63897] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id k1NGRNkR022540 I believe the "normal" expectation of an or-join would be that the subsequent activity would proceed if and when one of the inputs is received. In other words the subsequent activity is enabled by one of the inputs. I do not believe most would expect the activity to proceed for each input received. Thus subsequent inputs (tokens if you like) would be cancelled. If the or-join does not function in that way, then there is a need for a one-only-or-join to provide the more straight-forward result. I do not see that as equivalent to an exclusive or. Fred >-----Original Message----- >From: Rob Bartel [mailto:Rob.Bartel@igrafx.com] >Sent: Thursday, February 23, 2006 11:10 AM >To: conrad.bock@nist.gov; Petko Chobantonov; bpmn-ftf@omg.org >Subject: RE: OR-Join Definition > > > - Decision points upstream from the or-join may decide never to send > tokens along the path to the or-join. Since it is difficult to > analyze if this is the case, presumably the semantics will assume > that it might send token to or-join. So if tokens are upstream of > the decision point, the or-join cannot be enabled, even if the > decision point never sends tokens to the or-join. > > >I would agree with this, and believe it is conventional >behavior of execution systems and simulators that support >or-join, assuming that your intent with this last sentence is: >"So if tokens are upstream of the decision point, the or-join >cannot be enabled *until the decision is made*, even if the >decision point never sends tokens to the or-join" > > > > [Antoine] The activity flow allows for multiple >unstructured > parallel threads. An OR-join means that one >of the thread will > arbitrarely pass through, thé others >will be cancelled I tend to > think this is bad practice but >it is thé nature of unstructiured > parallel threads > >My understanding of the proposal is that there are no >cancelled threads. >One can't get through until all the others that can "possibly" >arrive actually do. It's the "possibly" part that is poorly >specified, and not even necessarily desirable. Is there any >input from business users on whether it is the execution they >would expect? > > >I would agree with Conrad's understanding. I understand the >type of join that Antoine describes (first one wins) to be the >behavior of an exclusive-or gateway (see p.119-120 of the OMG >BPMN spec). I don't know if I can be considered a "business >user", in that what I do is work on a business process >simulation tool that supports both or-join and multiple >unstructured threads, but we have had a considerable amount of >pushback from our simulation users in trying to discourage use >of "multiple unstructured threads". Admittedly, these users >are doing process modeling and simulation rather than >execution. In an actual execution system I have to agree with >Antoine about the unadvisability of using them. > Reply-To: From: "Conrad Bock" To: "'Rob Bartel'" , "'Petko Chobantonov'" , Subject: RE: OR-Join Definition Date: Thu, 23 Feb 2006 11:39:07 -0500 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcYz/bIsvntb0nNOSvSkR1lH+ZkM/AAAcrmQAAHAIeAAAgA2wAAATm1gAR9Fr7AAAR6O8AABj9jw Rob, > > - Decision points upstream from the or-join may decide never to send > tokens along the path to the or-join. Since it is difficult to > analyze if this is the case, presumably the semantics will assume > that it might send token to or-join. So if tokens are upstream of > the decision point, the or-join cannot be enabled, even if the > decision point never sends tokens to the or-join. > > > I would agree with this, and believe it is conventional > behavior of execution systems and simulators that support > or-join, assuming that your intent with this last sentence > is: "So if tokens are upstream of the decision point, the > or-join cannot be enabled *until the decision is made*, > even if the decision point never sends tokens to the or-join" There still may be other tokens upstream of the decision node, even if it happens to make a decision on a particular one. > we have had a considerable amount of pushback from our simulation > users in trying to discourage use of "multiple unstructured > threads". Admittedly, these users are doing process modeling and > simulation rather than execution. In an actual execution system I > have to agree with Antoine about the unadvisability of using them. This was the input to UML 2 Activities also. It's not directly related to inclusive OR however. Conrad Reply-To: From: "Conrad Bock" To: "'Cummins, Fred A'" , "'Rob Bartel'" , "'Petko Chobantonov'" , Subject: RE: OR-Join Definition Date: Thu, 23 Feb 2006 11:44:28 -0500 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcYz/bIsvntb0nNOSvSkR1lH+ZkM/AAAcrmQAAHAIeAAAgA2wAAATm1gAR9Fr7AAAR6O8AABMgLQAACVANA= Fred, > I believe the "normal" expectation of an or-join would be > that the subsequent activity would proceed if and when one > of the inputs is received. In other words the subsequent > activity is enabled by one of the inputs. I do not believe > most would expect the activity to proceed for each input received. > Thus subsequent inputs (tokens if you like) would be cancelled. Yet another interpretation! The cancellation effect isn't so well captured by the term "inclusive or", but that's just naming. Conrad Subject: RE: OR-Join Definition Date: Thu, 23 Feb 2006 10:50:22 -0600 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OR-Join Definition Thread-Index: AcYz/bIsvntb0nNOSvSkR1lH+ZkM/AAAcrmQAAHAIeAAAgA2wAAATm1gAR9Fr7AAAR6O8AABMgLQAACVANAAACmaAA== From: "Cummins, Fred A" To: , "Rob Bartel" , "Petko Chobantonov" , X-OriginalArrivalTime: 23 Feb 2006 16:50:29.0674 (UTC) FILETIME=[40E810A0:01C63899] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id k1NGhMFx022859 I suggest that this interpretation is also easier to implement and need not give rise to unpredictable results as described by Ed on the phone where we may not know how many tokens are generated or where they may come from. Fred >-----Original Message----- >From: Conrad Bock [mailto:conrad.bock@nist.gov] >Sent: Thursday, February 23, 2006 11:44 AM >To: Cummins, Fred A; 'Rob Bartel'; 'Petko Chobantonov'; >bpmn-ftf@omg.org >Subject: RE: OR-Join Definition > > >Fred, > > > I believe the "normal" expectation of an or-join would be >> that the subsequent activity would proceed if and when one >> of the inputs is received. In other words the subsequent >> activity is enabled by one of the inputs. I do not believe >> most would expect the activity to proceed for each input received. > > Thus subsequent inputs (tokens if you like) would be cancelled. > >Yet another interpretation! The cancellation effect isn't so >well captured by the term "inclusive or", but that's just naming. > >Conrad > > Subject: RE: OR-Join Definition Date: Thu, 23 Feb 2006 10:12:20 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OR-Join Definition Thread-Index: AcYz/bIsvntb0nNOSvSkR1lH+ZkM/AAAcrmQAAHAIeAAAgA2wAAATm1gAR9Fr7AAAR6O8AABC0+w From: "Dale Moberg" To: "Rob Bartel" , , "Petko Chobantonov" , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id k1NH4TTY023204 It's the "possibly" part that is poorly specified, and not even necessarily desirable. Is there any input from business users on whether it is the execution they would expect? BPSS choreography has two constructs for handling concurrency and synchronization in flows, fork and join. These have been introduced to capture use cases from end users. A fork has one "incoming" link (called a "FromLink") and 2 or more outgoing links ("ToLinks") (Nodes (states) are what the links are to or from.) The fork construct has a type attribute documented as Defines the type of Fork. OR: An OR value will mean that any business activity pointed to by a transition coming from the fork might be initiated. All activities may run in parallel. XOR: Only one of the possible activities will run. [In Petri tokenese, I think this would be OR means every path gets a token and XOR means exactly one gets a token...] The join construct has 2 or more incoming links and one outgoing link. The join construct has a boolean attribute "waitForAll" documented by "Indicates that all transitions coming into the Join are executed in order for the Business Collaboration to reach the Join state (AND-join). By default, the Join is an AND-join." At present, we mainly have use cases where one fork "goes with" one join, though this constraint is not strictly required. (Some use cases appear to need a many forks to many joins pattern, but detailed specifications on these complex cases are deferred for the next version as we get more input.) So the simple patterns of fork and join involve 1. OR and waitForAll=true (Conjunction really) 2. XOR and waitForAll=false (XOR) 3. OR and waitForAll=false (Inclusive ?) Case 1 captures concurrency with synchronization, case 2 captures a switch/case like control, and case 3 is an OR without synchronization and represents an inclusive OR. As I understand it, it would be an error for a case 2 process to have two incoming forks active and have multiple "true" (Links can have Boolean conditions on them to evaluate. When absent, the links act as if there is a condition that evaluated to true.) No explicit Petri-like flow is defined for graph traversal and clocking. Rather, message events and state status values provide the main control information. But if tokens were added to carry the message and status information, I would think that that case 3 means that all the forked paths are "active," and would have to be regarded as having tokens on them. Nevertheless, in case 3, the next state becomes active after at least one link becomes true. Since the waitForAll flag is false, and the paths would have tokens on them, I am not certain how to relate this BPSS construct to the proposed Petko et al. semantics. The semantics for 3 might be for a RequestForBid business process, where the request is sent to multiple venders and the process continues when the first quote arrives ("early bird gets the worm"). [Incidentally, the join ToLink can have a condition on it that would cause an implicit wait until an acceptable bid arrived.] The difficulty then is that a transition can occur even when other paths are active, a _static_ graph analysis shows that other paths are active (are "tokened"), and an ignore after at least one semantics is operative. Subject: [BPMN]: OR-Join Definition Date: Thu, 23 Feb 2006 10:01:02 -0800 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: [BPMN]: OR-Join Definition Thread-Index: AcYz/bIsvntb0nNOSvSkR1lH+ZkM/AAAcrmQAAHAIeAAAgA2wAAATm1gAR9Fr7AAAR6O8AABMgLQAAF1sfAAAaPWkA== Priority: Non-Urgent From: "Vincent, Paul D" To: , X-OriginalArrivalTime: 23 Feb 2006 18:01:09.0707 (UTC) FILETIME=[2029C1B0:01C638A3] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id k1NHrfoC024155 Just an off-topic observation [from a rules perspective]: - this sort of highly complex semantic is getting close to removing the advantage of the visual notation of process flow; - considering expressing the OR-Join in a declarative (rule?) language may be beneficial: e.g. I found Dale's description the most useful Paul Vincent Fair Isaac Blaze Advisor --- Business Rule Management OMG Standards for Business Rules, PRR & BPMI mobile: +44 (0)781 493 7229 ... office: +44 (0)20 7871 7229 -----Original Message----- From: Conrad Bock [mailto:conrad.bock@nist.gov] Sent: Thursday, February 23, 2006 5:35 PM To: 'Cummins, Fred A'; 'Rob Bartel'; 'Petko Chobantonov'; bpmn-ftf@omg.org Subject: RE: OR-Join Definition A summary of the things I think are needed to resolve the inclusive OR issue (probably to any of the semantic issues): 1. Concise specification covering the various cases (even if the semantics in some of cases is undefined). 2. Validate requirements (check against business user needs). 3. Validate name (name should imply the semantics as much as possible). 4. Calculatable semantics (avoid halting problem, etc). Conrad To: "Vincent, Paul D" Cc: bpmn-ftf@omg.org, conrad.bock@nist.gov Subject: Re: [BPMN]: OR-Join Definition X-Mailer: Lotus Notes Release 7.0 HF85 November 04, 2005 From: Stephen A White Date: Thu, 23 Feb 2006 10:53:14 -0800 X-MIMETrack: Serialize by Router on D03NM690/03/M/IBM(Release 6.53HF743 | November 3, 2005) at 02/23/2006 11:53:15, Serialize complete at 02/23/2006 11:53:15 Paul, In that case, using a Complex Gateway for merging is probably closer to being a rule or at least tied to one. Using a Complex Gateway maybe a way out of some of the Inclusive OR merging problems anyway. But that is more of a best practice and doesn't mean we should nail down the OR semantics. -Steve "Vincent, Paul D" 02/23/2006 10:01 AM To , cc Subject [BPMN]: OR-Join Definition Just an off-topic observation [from a rules perspective]: - this sort of highly complex semantic is getting close to removing the advantage of the visual notation of process flow; - considering expressing the OR-Join in a declarative (rule?) language may be beneficial: e.g. I found Dale's description the most useful Paul Vincent Fair Isaac Blaze Advisor --- Business Rule Management OMG Standards for Business Rules, PRR & BPMI mobile: +44 (0)781 493 7229 ... office: +44 (0)20 7871 7229 -----Original Message----- From: Conrad Bock [mailto:conrad.bock@nist.gov] Sent: Thursday, February 23, 2006 5:35 PM To: 'Cummins, Fred A'; 'Rob Bartel'; 'Petko Chobantonov'; bpmn-ftf@omg.org Subject: RE: OR-Join Definition A summary of the things I think are needed to resolve the inclusive OR issue (probably to any of the semantic issues): 1. Concise specification covering the various cases (even if the semantics in some of cases is undefined). 2. Validate requirements (check against business user needs). 3. Validate name (name should imply the semantics as much as possible). 4. Calculatable semantics (avoid halting problem, etc). Conrad Subject: RE: OR-Join Definition Date: Thu, 23 Feb 2006 13:00:53 -0600 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OR-Join Definition Thread-Index: AcYz/bIsvntb0nNOSvSkR1lH+ZkM/AAAcrmQAAHAIeAAAgA2wAAATm1gAR9Fr7AAAR6O8AABMgLQAACVANAAACmaAAAEP4fwAABLROA= From: "Cummins, Fred A" To: , "Rob Bartel" , "Petko Chobantonov" , X-OriginalArrivalTime: 23 Feb 2006 19:01:06.0512 (UTC) FILETIME=[8006A500:01C638AB] X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id k1NIsMdv025267 It seems to me that if every token reaching an or-join is going to be forwarded, there is no need for a join at all--there is no dependency between the tokens. I think we need to outline all of the variants and decide which should be supported and with what graphic(s). Fred >-----Original Message----- >From: Conrad Bock [mailto:conrad.bock@nist.gov] >Sent: Thursday, February 23, 2006 1:54 PM >To: Cummins, Fred A; 'Rob Bartel'; 'Petko Chobantonov'; >bpmn-ftf@omg.org >Subject: RE: OR-Join Definition > > >Fred, > > > I suggest that this interpretation is also easier to > >implement and need not give rise to unpredictable results > >as described by Ed on the phone where we may not know how > >many tokens are generated or where they may come from. > >Yes, it has a local semantics. It might not do what you want >in the presence of loops, eg, in Petko's thrid example, the >second cycle would never get past the join, unless there's >some way to "reset" the join. > >In any case, I think it's a different construct than issue >9113 is addressed. You should file one asking for this kind >join functionality. > >Conrad > > > >Fred, > > > > > > > I believe the "normal" expectation of an or-join >would be > >> that the subsequent activity would proceed if >and when > one of the > >> inputs is received. In other >words the subsequent activity is > >> enabled by one of the >inputs. I do not believe most > would expect the > >> >activity to proceed for each input received. > > > > Thus subsequent inputs (tokens if you like) would be >> cancelled. > > > > > >Yet another interpretation! The cancellation effect >isn't so well > >captured by the term "inclusive or", but >that's just naming. > > > > > >Conrad > > > > > > > > > > > > > Reply-To: From: "Conrad Bock" To: "'Cummins, Fred A'" , "'Rob Bartel'" , "'Petko Chobantonov'" , Subject: RE: OR-Join Definition Date: Thu, 23 Feb 2006 12:34:44 -0500 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcYz/bIsvntb0nNOSvSkR1lH+ZkM/AAAcrmQAAHAIeAAAgA2wAAATm1gAR9Fr7AAAR6O8AABMgLQAAF1sfA= A summary of the things I think are needed to resolve the inclusive OR issue (probably to any of the semantic issues): 1. Concise specification covering the various cases (even if the semantics in some of cases is undefined). 2. Validate requirements (check against business user needs). 3. Validate name (name should imply the semantics as much as possible). 4. Calculatable semantics (avoid halting problem, etc). Reply-To: From: "Conrad Bock" To: "'Cummins, Fred A'" , "'Rob Bartel'" , "'Petko Chobantonov'" , Subject: RE: OR-Join Definition Date: Thu, 23 Feb 2006 13:54:17 -0500 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcYz/bIsvntb0nNOSvSkR1lH+ZkM/AAAcrmQAAHAIeAAAgA2wAAATm1gAR9Fr7AAAR6O8AABMgLQAACVANAAACmaAAAEP4fw Fred, > I suggest that this interpretation is also easier to > implement and need not give rise to unpredictable results > as described by Ed on the phone where we may not know how > many tokens are generated or where they may come from. Yes, it has a local semantics. It might not do what you want in the presence of loops, eg, in Petko's thrid example, the second cycle would never get past the join, unless there's some way to "reset" the join. In any case, I think it's a different construct than issue 9113 is addressed. You should file one asking for this kind join functionality. Conrad > >Fred, > > > > > I believe the "normal" expectation of an or-join would be > >> that the subsequent activity would proceed if and when > one of the > >> inputs is received. In other words the subsequent activity is > >> enabled by one of the inputs. I do not believe most > would expect the > >> activity to proceed for each input received. > > > Thus subsequent inputs (tokens if you like) would be > cancelled. > > > >Yet another interpretation! The cancellation effect isn't so well > >captured by the term "inclusive or", but that's just naming. > > > >Conrad > > > > > > > Date: Thu, 23 Feb 2006 14:25:22 -0500 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en, fr, de, pdf, it, nl, sv, es, ru To: "Cummins, Fred A" , bpmn-ftf@omg.org Subject: Re: OR-Join Definition Cummins, Fred A wrote: I believe the "normal" expectation of an or-join would be that the subsequent activity would proceed if and when one of the inputs is received. In other words the subsequent activity is enabled by one of the inputs. I do not believe most would expect the activity to proceed for each input received. Thus subsequent inputs (tokens if you like) would be cancelled. I understand this to be the "wait for first" semantics, and not the "wait for all available" semantics. They (should) both have the semantics that subsequent tokens in the same (sub-)family that arrive at the gate terminate there. But "wait for first" causes the process to proceed *even though other family members are still ongoing*, while "wait for all available" causes the process to proceed *only after all* family members have arrived or terminated otherwise. And with respect to synchronizing operations, that is NOT a trivial distinction. Note: It is presumably not the intent that the IOR node proceeds when ALL of the children of the "parent split" die, although the text might lead one to believe that. If the business process actually intends that, the split node should include an unconditional branch that goes directly to the IOR gate with no intervening activity. The interpretation is: Conditionally do these things, and when they are done (or skipped), go on. There is a further nuance that may not be significant in BPMN: The interpretation of "wait for first" is that the first arriving token is emitted by the gate (and any others terminate without children). The interpretation of "wait for all available" is that a *new* token is emitted when all eligible tokens have arrived, and it is a child of *all* the arriving tokens. This is important if a subsequent activity interrogates the upstream history of its token/thread. The IOR token inherits all of the history; the "first" token only carries its own. (This is better carried in annotations to the resources, but it is not an uncommon practice to rely on the workflow engine to carry that information.) If the or-join does not function in that way, then there is a need for a one-only-or-join to provide the more straight-forward result. I do not see that as equivalent to an exclusive or. I agree that there is a need for "wait for first", which is, or at least might be, what the XOR gate does. The current spec is confused on this point. (Whether there *is* more than one child is a "split" concern, not a "join" concern.) Note also that, given the "wait for all available" definition of IOR, the only use of "wait for all" (AND gate) is to join threads from "different" families, which probably means synchronizing internal actions and external events. BTW, Petko's active graph analysis stuff is a nice theoretical model, but in practice, an engine can implement IOR-join with "publish" markups on the threads and "subscribe" arrangements for the IOR-gate, as long as there is a reference "parent" split node associated with the IOR. At the split node, you mark the children with the publication requirement: tell X when you split (and mark your children), and tell X when you die. The parent sends the list of its children to X and when the IOR gate is activated by the first arriving token, it watches X and continues to watch X until it is satisfied. But this all depends on the concept of a parent split-node who can make the relevant first-generation list, not just a remote ancestor who may have lots of irrelevant grandchildren. -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 FAX: +1 301-975-4482 "The opinions expressed above do not reflect consensus of NIST, Subject: RE: OR-Join Definition Date: Thu, 23 Feb 2006 19:32:26 -0600 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: OR-Join Definition Thread-Index: AcYz/bIsvntb0nNOSvSkR1lH+ZkM/AAAcrmQAAHAIeAAAgA2wAAATm1gAR9Fr7AAAR6O8AABMgLQAAF1sfAAENZy4A== From: "Petko Chobantonov" To: , "Cummins, Fred A" , "Rob Bartel" , I'm sending an updated version of the document about the OR-Join Semantics. It clarifies issues that were raised. >> 1. Concise specification covering the various cases (even if the >> semantics in some of cases is undefined). I think that I addressed this in the new version of the document. If you consider that more clarifications are needed, let me know. >> 2. Validate requirements (check against business user needs). Those requirements are validated using the standard workflow patterns. This is the pattern that the OR-Join solve http://is.tm.tue.nl/research/patterns/synchronizing_merge.htm Have a look at the flash demo. >> 3. Validate name (name should imply the semantics as much as possible). OR-Join is the standard name for this kind of behavior >> 4. Calculatable semantics (avoid halting problem, etc). It is possible to build an execution engine that follows this semantic. YAWL proves this. Further the semantics is formal. Having said that it is possible someone to create invalid diagrams - but the same is true for using an AND-Join. It is possible to create a diagram that could result in a deadlock using an AND-Join (one of the examples in the document shows this). A good modeling environment will provide diagram analysis features and will point to a potential problems. I would like to ask everyone - if you consider that something is not very clear for a particular use case, then create an example and send it to bpmn-ftf@omg.org. This is important in order everyone to be on the same page and to make sure that we are communicating issues correctly. Thanks, Petko -----Original Message----- From: Conrad Bock [mailto:conrad.bock@nist.gov] Sent: Thursday, February 23, 2006 11:35 AM To: 'Cummins, Fred A'; 'Rob Bartel'; Petko Chobantonov; bpmn-ftf@omg.org Subject: RE: OR-Join Definition A summary of the things I think are needed to resolve the inclusive OR issue (probably to any of the semantic issues): 1. Concise specification covering the various cases (even if the semantics in some of cases is undefined). 2. Validate requirements (check against business user needs). 3. Validate name (name should imply the semantics as much as possible). 4. Calculatable semantics (avoid halting problem, etc). Conrad ORJoinSemantics.doc Subject: RE: OR-Join Definition Date: Fri, 24 Feb 2006 09:00:52 +0100 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: OR-Join Definition Thread-Index: AcYz/bIsvntb0nNOSvSkR1lH+ZkM/AAAcrmQAAHAIeAAAgA2wAAATm1gAR9Fr7AAA1+IQA== From: "Giraud Jean-Luc" To: "Rob Bartel" Cc: X-OriginalArrivalTime: 24 Feb 2006 08:00:52.0495 (UTC) FILETIME=[6EA519F0:01C63918] X-Scanned-By: MIMEDefang 2.38 Rob, > My understanding of the proposal is that there are no cancelled threads. > One can't get through until all the others that can "possibly" arrive > actually do. It's the "possibly" part that is poorly specified, and not > even necessarily desirable. Is there any input from business users on > whether it is the execution they would expect? Here is an example how business users may use an Inclusive OR Join with an "external" path. Jean-Luc -----Message d'origine----- De : Conrad Bock [mailto:conrad.bock@nist.gov] Envoyé : jeudi 23 février 2006 16:49 À : 'Petko Chobantonov'; bpmn-ftf@omg.org Objet : RE: OR-Join Definition Petko, > Actually the PDF document that I sent answers this question > and proves that it is possible to build an execution engine > that handles the proposed semantics. Perhaps, but you can't include the PDF in the spec. The statement of the semantics short enough to fit into the spec, where "semantics" means something more explanatory than the one-liner in ryou document. A good place to start on that is to give this in an email. After thinking more on this, there are couple things that should be included for clarification (if this is the intention): - Activities (UML actions) that wait for incoming events are considered to have tokens in them. This means an or-join downstream of this activity can't be enabled if the activity is still waiting for events. This is true even if no events ever come. - Decision points upstream from the or-join may decide never to send tokens along the path to the or-join. Since it is difficult to analyze if this is the case, presumably the semantics will assume that it might send token to or-join. So if tokens are upstream of the decision point, the or-join cannot be enabled, even if the decision point never sends tokens to the or-join. > When an event is sent, it will be correlated to a Process Instance > (it could be correlated to multiple instances too). At that point a > token will appear on the actual event. I don't think the semantics of the diagram waiting for the event should not depend on figuring out if other agents are sending events. > [Antoine] The activity flow allows for multiple unstructured > parallel threads. An OR-join means that one of the thread will > arbitrarely pass through, thé others will be cancelled I tend to > think this is bad practice but it is thé nature of unstructiured > parallel threads My understanding of the proposal is that there are no cancelled threads. One can't get through until all the others that can "possibly" arrive actually do. It's the "possibly" part that is poorly specified, and not even necessarily desirable. Is there any input from business users on whether it is the execution they would expect? Conrad Issue 9121 - Inclusive Or Join - Semantics Sample.ppt.pdf Subject: RE: OR-Join Definition Date: Fri, 24 Feb 2006 10:33:06 -0600 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OR-Join Definition Thread-Index: AcYz/bIsvntb0nNOSvSkR1lH+ZkM/AAAcrmQAAHAIeAAAgA2wAAATm1gAR9Fr7AAA1+IQAAxXRow From: "Petko Chobantonov" To: "Giraud Jean-Luc" , "Rob Bartel" Cc: X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id k1OGPTvk004377 This is an excellent use case. The current proposal solves this use case too. Petko -----Original Message----- From: Giraud Jean-Luc [mailto:jlgiraud@axway.com] Sent: Friday, February 24, 2006 2:01 AM To: Rob Bartel Cc: bpmn-ftf@omg.org Subject: RE: OR-Join Definition Rob, > My understanding of the proposal is that there are no cancelled threads. > One can't get through until all the others that can "possibly" arrive > actually do. It's the "possibly" part that is poorly specified, and not > even necessarily desirable. Is there any input from business users on > whether it is the execution they would expect? Here is an example how business users may use an Inclusive OR Join with an "external" path. Jean-Luc -----Message d'origine----- De : Conrad Bock [mailto:conrad.bock@nist.gov] Envoyé : jeudi 23 février 2006 16:49 À : 'Petko Chobantonov'; bpmn-ftf@omg.org Objet : RE: OR-Join Definition Petko, > Actually the PDF document that I sent answers this question > and proves that it is possible to build an execution engine > that handles the proposed semantics. Perhaps, but you can't include the PDF in the spec. The statement of the semantics short enough to fit into the spec, where "semantics" means something more explanatory than the one-liner in ryou document. A good place to start on that is to give this in an email. After thinking more on this, there are couple things that should be included for clarification (if this is the intention): - Activities (UML actions) that wait for incoming events are considered to have tokens in them. This means an or-join downstream of this activity can't be enabled if the activity is still waiting for events. This is true even if no events ever come. - Decision points upstream from the or-join may decide never to send tokens along the path to the or-join. Since it is difficult to analyze if this is the case, presumably the semantics will assume that it might send token to or-join. So if tokens are upstream of the decision point, the or-join cannot be enabled, even if the decision point never sends tokens to the or-join. > When an event is sent, it will be correlated to a Process Instance > (it could be correlated to multiple instances too). At that point a > token will appear on the actual event. I don't think the semantics of the diagram waiting for the event should not depend on figuring out if other agents are sending events. > [Antoine] The activity flow allows for multiple unstructured > parallel threads. An OR-join means that one of the thread will > arbitrarely pass through, thé others will be cancelled I tend to > think this is bad practice but it is thé nature of unstructiured > parallel threads My understanding of the proposal is that there are no cancelled threads. One can't get through until all the others that can "possibly" arrive actually do. It's the "possibly" part that is poorly specified, and not even necessarily desirable. Is there any input from business users on whether it is the execution they would expect? Conrad Subject: RE: OR-Join Definition Date: Fri, 24 Feb 2006 10:23:53 -0700 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OR-Join Definition Thread-Index: AcYz/bIsvntb0nNOSvSkR1lH+ZkM/AAAcrmQAAHAIeAAAgA2wAAATm1gAR9Fr7AAA1+IQAAxXRowAADS8oA= From: "Dale Moberg" To: "Petko Chobantonov" , "Giraud Jean-Luc" , "Rob Bartel" Cc: >>It's the "possibly" part that is poorly specified, and not > even necessarily desirable. Is there any input from business users on > whether it is the execution they would expect? Let me expand on the request for bid use case, and forget about all the other BPPS stuff. I will provide a more complete business level description of the process. Whether it fits in with Petko's proposed criterion for "delay" depends on how the Petri net tokens in the system are flowing, at least in part. The following example seems to me to make trouble for the technical solution being advanced, but perhaps it is an edge case for inclusive or semantics that is to be provided. [From an engineering point of view the example resembles standard disjunction, with lazy evaluation.] A manufacturer has 3 suppliers for parts for a finished product it assembles. All sub manufacturers have fixed price agreements for parts of certain types, and they compete by agreeing to supply quantities of a part by a certain deadline. In this situation, the requests for bids solicit a commitment to deliver a requested quantity of a part by a deadline. Whoever first commits gets the business for that request. Message level analysis of this use case: The manufacturer sends three request messages to 3 sub-manufacturers, and 3 responses are expected (where the responses can be bid acceptance or no bid.) Petri net token view: 3 tokens are active in the network. [All questions of the "clocking" of the simulation are here ignored. These would be needed to handle iteration, resets from asynchronous interrupts, interrupts of interrupts, etc., etc.] Application of the "not possible to effect the outcome by delay": there are still, formally speaking, tokens which can complete flows through private processes on two subs "sides" when the winning (first) bid arrives as a message response to the manufacturer. So the definition would seem to imply that delay is needed, because live tokens are still trickling through the network. However, the business semantics of the contractual agreement says that no delay is required by the manufacturer. [At most technical cleanup (reception of late responses and archiving when received) would be needed, and might not even be modeled.] So the criterion for tacit synchronization for simulating the Or-Join appears to be at odds with the intended semantics of the business case. The business user wants the process to move on (perhaps proceeding to commit to delivery of final assemblies, e.g., once one supplier has agreed to the parts delivery. The business user does not wish to delay to process what the other responses are, whether they are bids or no-bids. Date: Fri, 24 Feb 2006 10:22:40 -0800 From: Monica J Martin Subject: Re: OR-Join Definition To: Dale Moberg Cc: Petko Chobantonov , Giraud Jean-Luc , Rob Bartel , bpmn-ftf@omg.org X-Accept-Language: en-us, en User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.4) Gecko/20030624 .....moberg: Application of the "not possible to effect the outcome by delay": there are still, formally speaking, tokens which can complete flows through private processes on two subs "sides" when the winning (first) bid arrives as a message response to the manufacturer. So the definition would seem to imply that delay is needed, because live tokens are still trickling through the network. However, the business semantics of the contractual agreement says that no delay is required by the manufacturer. [At most technical cleanup (reception of late responses and archiving when received) would be needed, and might not even be modeled.] So the criterion for tacit synchronization for simulating the Or-Join appears to be at odds with the intended semantics of the business case. The business user wants the process to move on (perhaps proceeding to commit to delivery of final assemblies, e.g., once one supplier has agreed to the parts delivery. The business user does not wish to delay to process what the other responses are, whether they are bids or no-bids. mm1: Dale is correct. Correspondingly if we also introduce a time limit, the join may occur irrespective of some suppliers haven't responded to a quote too. For a Request for Quote, a condition may exist where if one response is received and meets the business criteria, the others could also go to a different join. [1] The conditions also account for where activites are optional. For example, in retail or manufacturing/production cases, order status may or may not occur. However, when it does occur, the order response and status are important to the involved parties. In another case between a Producer and a subcontractor, the order status, a disposition change and response, and other integration changes may or may not occur. In both cases, these optional business transactions may be modeled as forks between the related business transactions. We have some key use cases from knit production in Europe for this detail. Thanks. [1] This discusssion arose in ebBP from specific user community feedback in Asia Pacific, I believe. From the specification, "This allows a split in processing between a group all of which must be done and one where at least one (or more) is sufficient for the transition. As bounded by Fork semantics, multiple joins may be allowed for a fork (multiple dependencies exist). The behavior of Forks over Joins may be handled by monitoring capabilities (for example, detection via static analysis)." Date: Fri, 24 Feb 2006 15:23:43 -0500 From: Ed Barkmeyer Reply-To: edbark@nist.gov Organization: NIST User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en, fr, de, pdf, it, nl, sv, es, ru To: Dale Moberg CC: bpmn-ftf@omg.org Subject: Re: OR-Join Definition Dale Moberg wrote: BPSS choreography has two constructs for handling concurrency and synchronization in flows, fork and join. These have been introduced to capture use cases from end users. A fork has one "incoming" link (called a "FromLink") and 2 or more outgoing links ("ToLinks") (Nodes (states) are what the links are to or from.) The fork construct has a type attribute documented as Defines the type of Fork. OR: An OR value will mean that any business activity pointed to by a transition coming from the fork might be initiated. All activities may run in parallel. XOR: Only one of the possible activities will run. [In Petri tokenese, I think this would be OR means every path gets a token and XOR means exactly one gets a token...] Not quite. Because the definition says any "from" transition "might be initiated", OR means that zero or more paths may get a token. There is clearly an unspecified intent that at least 1 will get a token. (For certain kinds of Petri-net tests and simulations, it suffices to place a token on every such path, so long as no two of those paths interact before the join, because that in effect tests all possible situations. But if two such paths interact, the situations in which only one of them is activated are importantly different.) If the intent is that every "from" path will have a token, the definition should say that every "from" transition *will* be initiated. And this difference is important to the definition of the join. The join construct has 2 or more incoming links and one outgoing link. The join construct has a boolean attribute "waitForAll" documented by "Indicates that all transitions coming into the Join are executed in order for the Business Collaboration to reach the Join state (AND-join). By default, the Join is an AND-join." This "waitForAll" definition seems to be oblivious to the fact that *not every* "from" transition out of the OR-split is required to receive a token. And therefore, not every transition coming into the Join will (ever) be executed! For the "waitForAll" to work when some "from" transition out of the OR-split *only might* receive a token, the Join has to have the BPMN OR-join semantics: "waitForAll" *tokenized* paths, i.e all the "from" paths that were actually activated. Further, the model has to require that none of those "from" transitions can ever conditionally lead to a Terminus, instead of the "waitForAll" join. (Other well-formedness rules might make that an invalid graph.) At present, we mainly have use cases where one fork "goes with" one join, though this constraint is not strictly required. If you don't require the pairing, the semantics of "waitForAll" (AND-join) has to be defined as you do -- all incoming transitions must be taken -- and then the possibility that some "from" transition out of the OR-split is not taken is fatal to the process. Put another way, there are two choices: - the OR-split has to tokenize *all* outbound paths, or - the waitForAll-join has to characterize "all" by reference to the OR-split that generates the set of tokens it will actually wait for. So the simple patterns of fork and join involve 1. OR and waitForAll=true (Conjunction really) 2. XOR and waitForAll=false (XOR) 3. OR and waitForAll=false (Inclusive ?) BPMN defines: - AND-split to generate tokens on all outbound paths, - OR-split to generate tokens on one or more outbound paths, and - XOR-split to generate a token on exactly one outbound path. And it defines: - AND-join to wait for a token on every inbound path, - XOR-join to wait for a token on exactly one inbound path, And it is proposed to define - OR-join to wait for a token on all "active" inbound paths So AND-split/AND-join matches the BPSS-viable instances of use case 1. OR-split/proposed-OR-join matches the instances of use case 1 that BPSS can't do as currently defined. XOR-split/XOR-join matches the instances of use case 2. Nothing as currently defined matches use case 3. If we redefine OR-join to activate its outbound transition on the first incoming token and terminate any later incoming tokens, then XOR-join is useless, XOR-split/OR-join will work for use case 2 and OR-split/OR-join will support use case 3. But in that case, BPMN also won't be able to support the instances of use case 1 that BPSS can't do as currently defined. I don't care what the name is (others may), but we all need - a "waitForFirst and suppress later arrivals" join to do use case 3, - a "waitForAll activated" join to do use case 1 properly, and - a "waitForAll" join to do the no-split "external synchronization" use case correctly (wait for the navigation instructions AND the green light). And I don't see that we need any others. But in the Final Adopted Specification we have only the last, which is the AND-join. We have two useless definitions of OR-join and XOR-join, which are neither of the others above. We don't need to debate whether OR-join should be the first or the second, because whichever one it is, we *also* need the other! I would prefer to give waitForFirst semantics to the XOR, because that will work correctly for all the existing XOR diagrams (in which only one token will arrive). But if everyone wants to give "WaitForFirst" semantics to the OR-join, that's fine; it just makes the XOR-join vestigial. What is important is that we cover use case 1 completely, and that means that *some* XYZ-join has to support the "wait for all activated" case, and we still need to agree on how that case should be defined so that everyone can make it work. Case 1 captures concurrency with synchronization, case 2 captures a switch/case like control, and case 3 is an OR without synchronization and represents an inclusive OR. As I understand it, it would be an error for a case 2 process to have two incoming forks active and have multiple "true" With the current definition of XOR-join, this is correct. (And in my view, it has no value. The choices are: only one incoming path is active or the process is invalid, so it is a purely syntactic join that has no useful semantics. You can wire one branch of the XOR to the off-switch, so that it stops the process. ) (Links can have Boolean conditions on them to evaluate. When absent, the links act as if there is a condition that evaluated to true.) I don't follow this. Are you suggesting that a tokenized path holds the link to FALSE until the token arrives at the join, while a path with no token immediately raises the link to TRUE? Or did you mean "when present" rather than "when absent"? No explicit Petri-like flow is defined for graph traversal and clocking. Rather, message events and state status values provide the main control information. But if tokens were added to carry the message and status information, I would think that that case 3 means that all the forked paths are "active," and would have to be regarded as having tokens on them. Nevertheless, in case 3, the next state becomes active after at least one link becomes true. Since the waitForAll flag is false, and the paths would have tokens on them, I am not certain how to relate this BPSS construct to the proposed Petko et al. semantics. I agree. That is, use case 3 requires the waitForFirst semantics. That is *not* what Petko is proposing, and BPMN currently doesn't provide any join with that semantics. And, yes, it should. The semantics for 3 might be for a RequestForBid business process, where the request is sent to multiple venders and the process continues when the first quote arrives ("early bird gets the worm"). [Incidentally, the join ToLink can have a condition on it that would cause an implicit wait until an acceptable bid arrived.] The difficulty then is that a transition can occur even when other paths are active, a _static_ graph analysis shows that other paths are active (are "tokened"), and an ignore after at least one semantics is operative. This is a good example of Use Case 3, even if others will quibble with it. The police (or taxi) dispatch example is the common one. There is a "forcing event" that requires the system to take *some* responsive action quickly -- the 911 call comes in to the dispatcher. She broadcasts the need for action to a collection of subordinates -- the active patrol cars -- and assigns the call to the first car that responds. If subsequent responses come from other cars, she tells them to "stand down" -- don't go. The real problem with the "waitForFirst" join is fitting it into an arbitrary process graph that may have loops or timer synchronizations that confuse the concepts "first" and "others". The scope of a "waitForFirst" has to be defined by an acyclic subprocess or (dare I say it) "group". (It is seductive to think of joins as paired with specific splits with only linear flows on each connecting path. BPMN deliberately didn't make rules that require the situation to be that simple, even though "most" business uses may be.) -Ed -- Edward J. Barkmeyer Email: edbark@nist.gov National Institute of Standards & Technology Manufacturing Systems Integration Division 100 Bureau Drive, Stop 8263 Tel: +1 301-975-3528 Gaithersburg, MD 20899-8263 FAX: +1 301-975-4482 "The opinions expressed above do not reflect consensus of NIST, and have not been reviewed by any Government authority." Cc: "Petko Chobantonov" , "Giraud Jean-Luc" , "Rob Bartel" , From: Francis McCabe Subject: Re: OR-Join Definition Date: Fri, 24 Feb 2006 13:21:21 -0800 To: Dale Moberg X-Mailer: Apple Mail (2.746.2) This sounds a little like an auction. The auction does not, should not, use the inclusive OR gate -- as written, it should use a 'first- OR' gateway, with late tokens being dropped. However, if you rewrite it slightly, where the cheapest bid is accepted, but not all parties are required to make a bid, then you get into more interesting territory. Incidentally, there is a famous protocol - the contract net protocol - that has echoes of the same issues. There the waiting-until problem is resolved normally by having a time-out: all tokens that arrive after a certain time are dropped. Frank On Feb 24, 2006, at 9:23 AM, Dale Moberg wrote: >>It's the "possibly" part that is poorly specified, and not > even necessarily desirable. Is there any input from business users on > whether it is the execution they would expect? Let me expand on the request for bid use case, and forget about all the other BPPS stuff. I will provide a more complete business level description of the process. Whether it fits in with Petko's proposed criterion for "delay" depends on how the Petri net tokens in the system are flowing, at least in part. The following example seems to me to make trouble for the technical solution being advanced, but perhaps it is an edge case for inclusive or semantics that is to be provided. [From an engineering point of view the example resembles standard disjunction, with lazy evaluation.] A manufacturer has 3 suppliers for parts for a finished product it assembles. All sub manufacturers have fixed price agreements for parts of certain types, and they compete by agreeing to supply quantities of a part by a certain deadline. In this situation, the requests for bids solicit a commitment to deliver a requested quantity of a part by a deadline. Whoever first commits gets the business for that request. Message level analysis of this use case: The manufacturer sends three request messages to 3 sub-manufacturers, and 3 responses are expected (where the responses can be bid acceptance or no bid.) Petri net token view: 3 tokens are active in the network. [All questions of the "clocking" of the simulation are here ignored. These would be needed to handle iteration, resets from asynchronous interrupts, interrupts of interrupts, etc., etc.] Application of the "not possible to effect the outcome by delay": there are still, formally speaking, tokens which can complete flows through private processes on two subs "sides" when the winning (first) bid arrives as a message response to the manufacturer. So the definition would seem to imply that delay is needed, because live tokens are still trickling through the network. However, the business semantics of the contractual agreement says that no delay is required by the manufacturer. [At most technical cleanup (reception of late responses and archiving when received) would be needed, and might not even be modeled.] So the criterion for tacit synchronization for simulating the Or-Join appears to be at odds with the intended semantics of the business case. The business user wants the process to move on (perhaps proceeding to commit to delivery of final assemblies, e.g., once one supplier has agreed to the parts delivery. The business user does not wish to delay to process what the other responses are, whether they are bids or no- bids. Subject: RE: OR-Join Definition Date: Fri, 24 Feb 2006 15:41:15 -0600 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: OR-Join Definition Thread-Index: AcYz/bIsvntb0nNOSvSkR1lH+ZkM/AAAcrmQAAHAIeAAAgA2wAAATm1gAR9Fr7AAA1+IQAAxXRowAADS8oAACSZhsA== From: "Petko Chobantonov" To: "Dale Moberg" , "Giraud Jean-Luc" , "Rob Bartel" , Dale, The use case that you specify is not directly related to OR-Joins. In BPMN your use case could be modeled using the following process. The following properties are specified: "Send Request To N Suppliers" (page 273 of BPMN Specification, Table B.11) Multi-Instance Activity MI_Ordering = Parallel MI_FlowCondition = Complex ComplexMI_FlowCondition = expression that evaluates to true only for the first activity instance that completes. For example "completedCounter == 1". A timer is attached and if no one responds within the timeframe then "No One Responded" will have to determine what to do in this case So we have specified the following: N number of activity instances will be created during the runtime. All will execute in parallel The first activity instance that completes will produce token on the sequence flow to "Process First Supplier". The reason for this is MI_FlowCondition = Complex -> meaning a decision will be made is a token should be produced based on the expression per each activity instance completion ComplexMI_FlowCondition will evaluate to true only for the first activity e.g. when the second activity completes it will not produce a token on the sequence flow to "Process First Supplier" All N responses are expected to complete, but we will continue the execution when someone responds. Petko -------------------------------------------------------------------------------- From: Dale Moberg [mailto:dmoberg@cyclonecommerce.com] Sent: Friday, February 24, 2006 11:24 AM To: Petko Chobantonov; Giraud Jean-Luc; Rob Bartel Cc: bpmn-ftf@omg.org Subject: RE: OR-Join Definition >>It's the "possibly" part that is poorly specified, and not > even necessarily desirable. Is there any input from business users on > whether it is the execution they would expect? Let me expand on the request for bid use case, and forget about all the other BPPS stuff. I will provide a more complete business level description of the process. Whether it fits in with Petko's proposed criterion for "delay" depends on how the Petri net tokens in the system are flowing, at least in part. The following example seems to me to make trouble for the technical solution being advanced, but perhaps it is an edge case for inclusive or semantics that is to be provided. [From an engineering point of view the example resembles standard disjunction, with lazy evaluation.] A manufacturer has 3 suppliers for parts for a finished product it assembles. All sub manufacturers have fixed price agreements for parts of certain types, and they compete by agreeing to supply quantities of a part by a certain deadline. In this situation, the requests for bids solicit a commitment to deliver a requested quantity of a part by a deadline. Whoever first commits gets the business for that request. Message level analysis of this use case: The manufacturer sends three request messages to 3 sub-manufacturers, and 3 responses are expected (where the responses can be bid acceptance or no bid.) Petri net token view: 3 tokens are active in the network. [All questions of the "clocking" of the simulation are here ignored. These would be needed to handle iteration, resets from asynchronous interrupts, interrupts of interrupts, etc., etc.] Application of the "not possible to effect the outcome by delay": there are still, formally speaking, tokens which can complete flows through private processes on two subs "sides" when the winning (first) bid arrives as a message response to the manufacturer. So the definition would seem to imply that delay is needed, because live tokens are still trickling through the network. However, the business semantics of the contractual agreement says that no delay is required by the manufacturer. [At most technical cleanup (reception of late responses and archiving when received) would be needed, and might not even be modeled.] So the criterion for tacit synchronization for simulating the Or-Join appears to be at odds with the intended semantics of the business case. The business user wants the process to move on (perhaps proceeding to commit to delivery of final assemblies, e.g., once one supplier has agreed to the parts delivery. The business user does not wish to delay to process what the other responses are, whether they are bids or no-bids. Reply-To: From: "Conrad Bock" To: "BPMNFTF" Subject: RE: OR-Join Definition, clarifications Date: Thu, 9 Mar 2006 11:53:19 -0500 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcYz/bIsvntb0nNOSvSkR1lH+ZkM/AAAcrmQAAHAIeAAAgA2wAAATm1gAR9Fr7ACwx/oYA== X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id k29GioPP016403 Hi Petko, Just a reminder about these clarifications (added one more): - Activities (UML actions) that wait for incoming events are considered to have tokens in them. This means an or-join downstream of this activity can't be enabled if the activity is still waiting for events. This is true even if no events ever come. - Decision points upstream from the or-join may decide never to send tokens along the path to the or-join. Since it is difficult to analyze if this is the case, presumably the semantics will assume that it might send token to or-join. So if tokens are upstream of the decision point, the or-join cannot be enabled, even if the decision point never sends tokens to the or-join. - Activities that break down into further subactivities upstream from the or-join are considered active as long as their subactivities are executing (assuming BPMN doesn't support asychronous invocation). Of course you might clarify these cases differently, the above are just my suggestions. Original email below. Conrad -----Original Message----- From: Conrad Bock [mailto:conrad.bock@nist.gov] Sent: Thursday, February 23, 2006 10:49 AM To: 'Petko Chobantonov'; 'bpmn-ftf@omg.org' Subject: RE: OR-Join Definition Petko, > Actually the PDF document that I sent answers this question > and proves that it is possible to build an execution engine > that handles the proposed semantics. Perhaps, but you can't include the PDF in the spec. The statement of the semantics short enough to fit into the spec, where "semantics" means something more explanatory than the one-liner in ryou document. A good place to start on that is to give this in an email. After thinking more on this, there are couple things that should be included for clarification (if this is the intention): - Activities (UML actions) that wait for incoming events are considered to have tokens in them. This means an or-join downstream of this activity can't be enabled if the activity is still waiting for events. This is true even if no events ever come. - Decision points upstream from the or-join may decide never to send tokens along the path to the or-join. Since it is difficult to analyze if this is the case, presumably the semantics will assume that it might send token to or-join. So if tokens are upstream of the decision point, the or-join cannot be enabled, even if the decision point never sends tokens to the or-join. > When an event is sent, it will be correlated to a Process Instance > (it could be correlated to multiple instances too). At that point a > token will appear on the actual event. I don't think the semantics of the diagram waiting for the event should not depend on figuring out if other agents are sending events. > [Antoine] The activity flow allows for multiple unstructured > parallel threads. An OR-join means that one of the thread will > arbitrarely pass through, thé others will be cancelled I tend to > think this is bad practice but it is thé nature of unstructiured > parallel threads My understanding of the proposal is that there are no cancelled threads. One can't get through until all the others that can "possibly" arrive actually do. It's the "possibly" part that is poorly specified, and not even necessarily desirable. Is there any input from business users on whether it is the execution they would expect? Conrad X-VirusChecked: Checked X-Env-Sender: Petko.Chobantonov@lombardisoftware.com X-Msg-Ref: server-14.tower-86.messagelabs.com!1141948874!24555055!1 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [64.3.1.136] Subject: RE: OR-Join Definition (some delayed responses to the thread) Date: Thu, 9 Mar 2006 18:01:13 -0600 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: OR-Join Definition (some delayed responses to the thread) Thread-Index: AcYz/bIsvntb0nNOSvSkR1lH+ZkM/AAAcrmQAAHAIeAAAgA2wAAATm1gAR9Fr7AAA1+IQAAxXRowAADS8oAACSZhsAEjPQZAAW2fQCA= From: "Petko Chobantonov" To: "Dale Moberg" , "Giraud Jean-Luc" , "Rob Bartel" , >> But suppose the example were varied to illustrate a .greedy. approach to job scheduling, where distinct manufacturing setups depended on supplier availability, and so concurrently we sent out quite different parts orders to several suppliers, and then wanted to ignore >> outstanding responses in order to commit the manufacturing floor to a configuration for the first responder. Are you still recommending this approach even when different requests are sent? Yes. However you will have to cancel all outstanding requests before processing to "Process First Supplier". In this case the execution engine that you use must have the capability to withdraw tokens from the diagram e.g. to cancel an existing activities. Petko -------------------------------------------------------------------------------- From: Dale Moberg [mailto:dmoberg@cyclonecommerce.com] Sent: Thursday, March 02, 2006 10:30 AM To: Petko Chobantonov; Giraud Jean-Luc; Rob Bartel; bpmn-ftf@omg.org Subject: RE: OR-Join Definition (some delayed responses to the thread) Thanks for the reference to the table B. I had seen the example in Figure 10.14 which used a loop and that modeling that had not had the needed concurrency. I did not look far enough apparently. It does seem that the multi-instance activity might be OK especially if the actions taken for each supplier are .sufficiently similar.. But suppose the example were varied to illustrate a .greedy. approach to job scheduling, where distinct manufacturing setups depended on supplier availability, and so concurrently we sent out quite different parts orders to several suppliers, and then wanted to ignore outstanding responses in order to commit the manufacturing floor to a configuration for the first responder. Are you still recommending this approach even when different requests are sent? In other words, it seems to me that this modeling (which I do find to be useful btw) is still evasive of the core problem of needing to ignore control tokens still floating around. At any rate, if your semantics is accepted, I think we will have to inform the modeler/analyst that the OR-Join, despite its catchy name, is not applicable to certain disjunctive merges in which a need to ignore control tokens is needed. Maybe it is an edge situation, but I am interested in the correct way to model it so that appropriate BPMN diagrams can be produced for these known BPSS use cases (provided by .real. business analysts, not me!) Dale Moberg PS: I am running behind in responding this week to all the messages. I did want to comment both on Frank.s desire to have the Petri token underpinnings sharpened up for the reader and the idea of a declarative .waitFor X. semantics for other quantities than .all. -------------------------------------------------------------------------------- From: Petko Chobantonov [mailto:Petko.Chobantonov@lombardisoftware.com] Sent: Friday, February 24, 2006 2:41 PM To: Dale Moberg; Giraud Jean-Luc; Rob Bartel; bpmn-ftf@omg.org Subject: RE: OR-Join Definition Dale, The use case that you specify is not directly related to OR-Joins. In BPMN your use case could be modeled using the following process. The following properties are specified: "Send Request To N Suppliers" (page 273 of BPMN Specification, Table B.11) Multi-Instance Activity MI_Ordering = Parallel MI_FlowCondition = Complex ComplexMI_FlowCondition = expression that evaluates to true only for the first activity instance that completes. For example "completedCounter == 1". A timer is attached and if no one responds within the timeframe then "No One Responded" will have to determine what to do in this case So we have specified the following: N number of activity instances will be created during the runtime. All will execute in parallel The first activity instance that completes will produce token on the sequence flow to "Process First Supplier". The reason for this is MI_FlowCondition = Complex -> meaning a decision will be made is a token should be produced based on the expression per each activity instance completion ComplexMI_FlowCondition will evaluate to true only for the first activity e.g. when the second activity completes it will not produce a token on the sequence flow to "Process First Supplier" All N responses are expected to complete, but we will continue the execution when someone responds. Petko -------------------------------------------------------------------------------- From: Dale Moberg [mailto:dmoberg@cyclonecommerce.com] Sent: Friday, February 24, 2006 11:24 AM To: Petko Chobantonov; Giraud Jean-Luc; Rob Bartel Cc: bpmn-ftf@omg.org Subject: RE: OR-Join Definition >>It's the "possibly" part that is poorly specified, and not > even necessarily desirable. Is there any input from business users on > whether it is the execution they would expect? Let me expand on the request for bid use case, and forget about all the other BPPS stuff. I will provide a more complete business level description of the process. Whether it fits in with Petko's proposed criterion for "delay" depends on how the Petri net tokens in the system are flowing, at least in part. The following example seems to me to make trouble for the technical solution being advanced, but perhaps it is an edge case for inclusive or semantics that is to be provided. [From an engineering point of view the example resembles standard disjunction, with lazy evaluation.] A manufacturer has 3 suppliers for parts for a finished product it assembles. All sub manufacturers have fixed price agreements for parts of certain types, and they compete by agreeing to supply quantities of a part by a certain deadline. In this situation, the requests for bids solicit a commitment to deliver a requested quantity of a part by a deadline. Whoever first commits gets the business for that request. Message level analysis of this use case: The manufacturer sends three request messages to 3 sub-manufacturers, and 3 responses are expected (where the responses can be bid acceptance or no bid.) Petri net token view: 3 tokens are active in the network. [All questions of the "clocking" of the simulation are here ignored. These would be needed to handle iteration, resets from asynchronous interrupts, interrupts of interrupts, etc., etc.] Application of the "not possible to effect the outcome by delay": there are still, formally speaking, tokens which can complete flows through private processes on two subs "sides" when the winning (first) bid arrives as a message response to the manufacturer. So the definition would seem to imply that delay is needed, because live tokens are still trickling through the network. However, the business semantics of the contractual agreement says that no delay is required by the manufacturer. [At most technical cleanup (reception of late responses and archiving when received) would be needed, and might not even be modeled.] So the criterion for tacit synchronization for simulating the Or-Join appears to be at odds with the intended semantics of the business case. The business user wants the process to move on (perhaps proceeding to commit to delivery of final assemblies, e.g., once one supplier has agreed to the parts delivery. The business user does not wish to delay to process what the other responses are, whether they are bids or no-bids. X-VirusChecked: Checked X-Env-Sender: Petko.Chobantonov@lombardisoftware.com X-Msg-Ref: server-10.tower-86.messagelabs.com!1141951062!8560273!1 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [64.3.1.136] Subject: RE: OR-Join Definition Date: Thu, 9 Mar 2006 18:37:42 -0600 X-MS-Has-Attach: X-MS-TNEF-Correlator: Thread-Topic: OR-Join Definition Thread-Index: AcYz/bIsvntb0nNOSvSkR1lH+ZkM/AAAcrmQAAHAIeAAAgA2wAAATm1gAR9Fr7AAA1+IQAAxXRowAADS8oAACSZhsAEi07WgAADbdfUBcPSQ8A== From: "Petko Chobantonov" To: "Rob Bartel" , , "Dale Moberg" , "Giraud Jean-Luc" , X-MIME-Autoconverted: from quoted-printable to 8bit by amethyst.omg.org id k2A0TCWm022013 I agree with this. Especially when you have more then 2 lines coming from the split or if you have more then 1 split. The diagram will become very messy even with 2 splits and more then 2 outgoing lines. Petko -----Original Message----- From: Rob Bartel [mailto:Rob.Bartel@igrafx.com] Sent: Thursday, March 02, 2006 10:29 AM To: conrad.bock@nist.gov; Petko Chobantonov; Dale Moberg; Giraud Jean-Luc; bpmn-ftf@omg.org Subject: RE: OR-Join Definition Though I'm sure it's going to sound that way, I really don't mean this as "snippy". I think this is an excellent example of one of the reasons why the "business users" don't want to use UML and are looking for something like BPMN. To their mind, I think, the "extra" line on the diagram is clutter - "any reasonable human viewer" of the diagram will understand what it means without the circle. -----Original Message----- From: Conrad Bock [mailto:conrad.bock@nist.gov] Sent: Thu 3/2/2006 8:11 AM To: 'Petko Chobantonov'; 'Dale Moberg'; 'Giraud Jean-Luc'; Rob Bartel; bpmn-ftf@omg.org Subject: RE: OR-Join Definition Or-joiners, Attached is a figure showing how UML addresses the "OR join". It requires the user to be explicit about what is required for the join, but gives a notation that makes it easier (the circle shapes are notation for a single flow line, see Figure 12.43 of doc.omg.org/ptc/06-02-01). I think this is clearer and reduces the possibility of misunderstandings. Conrad -- This message has been scanned for viruses and dangerous content, and is believed to be clean. X-VirusChecked: Checked X-Env-Sender: Petko.Chobantonov@lombardisoftware.com X-Msg-Ref: server-2.tower-86.messagelabs.com!1142011620!23951616!1 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [64.3.1.136] Subject: RE: OR-Join Definition Date: Fri, 10 Mar 2006 11:26:59 -0600 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: OR-Join Definition Thread-Index: AcYz/bIsvntb0nNOSvSkR1lH+ZkM/AAAcrmQAAHAIeAAAgA2wAAATm1gAR9Fr7AAAR6O8AABMgLQAAF1sfAAENZy4AFMLGEwAXK80UA= From: "Petko Chobantonov" To: , Hi Conrad, >> The document still refers off to another that cannot be included in the >> specification and can't be understood by most OMG spec readers. The document refers to this additional document in the abstract where I'm describing the problem at this point of time and I'm pointing out existing work in this area. The section discusses the reason why we wanted to change it e.g. what are the problems. I don't see this section to become part of the specification, but it is part of the document describing the clarification e.g. why we want to do this. To make it even clearer I renamed the section and explicitly specified that it will not be part of the specification. Having said that, we have to give credit to Wil van der Aalst. In could be in the form of references at the end of the document in a similar way that we can say - we had looked at BPEL (Section 3). It is up to the group to decide if this should be included. > The definition given is still too high level. It requires a complex > deduction that isn't clarified (is the join reachable by the tokens on > the graph). For example, how will can the implementer automate the > deduction in the loop example? There are token upstream of the join if > the implementer just traces the flows backwards. The definition is not on too high level. I think the BPMN Specification should define just the semantics and not what algorithm an implementer should use to detect this. I guess your question is how such execution engine could be built e.g. is it possible? If someone is interested how this could be done, here is the sourceforge project that implements this semantics http://sourceforge.net/projects/yawl/ You can have a look at the source code of one possible implementation of the OR-Join algorithm that complies with the proposed semantics. I don't want to discuss the algorithm, because it is one possible implementation of the proposed semantics. The value of this algorithm is that it proves that it is possible such execution engine to be built. > Validation means to check that the proposed semantics is what users > want. The above like doesn't address that. It does address user requirements. They have not defined this pattern just to have 1 pattern more. > the implementations do not handle loops. Here is the paragraph from the web page The two workflow engines known to the authors that provide a straightforward construct for the realization of this pattern are MQSeries/Workflow and InConcert. As noted earlier, if a synchronizing merge follows an OR-split and more than one outgoing transition of that OR-split can be triggered, it is not until runtime that we can tell whether or not synchronization should take place. MQSeries/Workflow works around that problem by passing a False token for each transition that evaluates to False and a True token for each transition that evaluates to True. The merge will wait until it receives tokens from each incoming transition. InConcert does not use a False token concept. Instead it passes a token through every transition in a graph. This token may or may not enable the execution of an activity depending on the entry condition. This way every activity having more than one incoming transition can expect that it will receive a token from each one of them, thus deadlock cannot occur. The careful reader may note that these evaluation strategies require that the workflow process does not contain cycles. He is saying that the only engines implementing this feature (this was done several years ago) are MQSeries and InConcert. The algorithms of those engines do not handle loops. This is different then stating that the proposed definition does not handle loops. I does handle loops. I've added another section in the document 4.5 where a possible deadlock is described. To some extent it is related to loops e.g. you can achieve the same scenario using more then 2 OR-Joins in a specific order participating in the same loop. An in this case the behavior is specified: "It will result in a deadlock". To me this is very similar to how a simple AND-Join could result in a deadlock on a specific diagram. An static analysis engine could detect a number of such cases (obviously not all) and to help a process author designing sound processes. >> OR-Join is the standard name for this kind of behavior > It can't be completely standard, because the link above calls it a > "syncrhronized merge". In addition, the term "OR" usually does not > imply synchronization. "Synchronized merge" is the name of the pattern, not the name of the actual type of join. At least I have not seen other name for this type of join. Having in mind that BPMN is using this term it means that it is a standard term. If you feel that you don't like the term, then you can raise another issue. I'm also sending an updated version of the document. Petko -----Original Message----- From: Conrad Bock [mailto:conrad.bock@nist.gov] Sent: Thursday, March 02, 2006 9:55 AM To: Petko Chobantonov; 'Cummins, Fred A'; 'Rob Bartel'; bpmn-ftf@omg.org Subject: RE: OR-Join Definition Hi Petko, Thanks for the update. Unfortunately it is not much better than the first in the respects we discussed last time: 1. Concise specification covering the various cases (even if the semantics in some of cases is undefined). > I think that I addressed this in the new version of the > document. If you consider that more clarifications are > needed, let me know. The document still refers off to another that cannot be included in the specification and can't be understood by most OMG spec readers. The definition given is still too high level. It requires a complex deduction that isn't clarified (is the join reachable by the tokens on tha graph). For example, how will can the implementer automate the deduction in the lopp example? There are token upstream of the join if the implementer just traces the flows backwards. > >> 2. Validate requirements (check against business user needs). > Those requirements are validated using the standard > workflow patterns. > This is the pattern that the OR-Join solve > http://is.tm.tue.nl/research/patterns/synchronizing_merge.htm > Have a look at the flash demo. Validation means to check that the proposed semantics is what users want. The above like doesn't address that. The link above is actually more of what is needed in the BPMN specification, but notice it says: - the implementations do not handle loops. - the implementation is typically is "not straightforward". "The only solution is to avoid the explicit use of the OR-split that may trigger more than one outgoing transition and implement it as a combination of AND-splits and XOR-splits (see Pattern 6 (Multi-choice))." These argue against the including the proposed semantics. > >> 3. Validate name (name should imply the semantics as much as > possible). > OR-Join is the standard name for this kind of behavior It can't be completely standard, because the link above calls it a "syncrhronized merge". In addition, the term "OR" usually does not imply synchronization. > >> 4. Calculatable semantics (avoid halting problem, etc). > It is possible to build an execution engine that follows > this semantic. See above problems. > YAWL proves this. Further the semantics is formal. It is not sufficient to point off to complicated papers. It needs to be explained in a way that an average spec reader can follow. > I would like to ask everyone - if you consider that > something is not very clear for a particular use case, then > create an example and send it to bpmn-ftf@omg.org. This is > important in order everyone to be on the same page and to > make sure that we are communicating issues correctly. See above. You've provide plenty of example.s Conrad ORJoinSemantics1.doc X-VirusChecked: Checked X-Env-Sender: Petko.Chobantonov@lombardisoftware.com X-Msg-Ref: server-10.tower-85.messagelabs.com!1142016873!14067153!1 X-StarScan-Version: 5.5.9.1; banners=-,-,- X-Originating-IP: [64.3.1.136] Subject: RE: OR-Join Definition, clarifications Date: Fri, 10 Mar 2006 12:54:33 -0600 X-MS-Has-Attach: yes X-MS-TNEF-Correlator: Thread-Topic: OR-Join Definition, clarifications Thread-Index: AcYz/bIsvntb0nNOSvSkR1lH+ZkM/AAAcrmQAAHAIeAAAgA2wAAATm1gAR9Fr7ACwx/oYAAzqG0g From: "Petko Chobantonov" To: , "BPMNFTF" Conrad, > Activities (UML actions) that wait for incoming events are > considered to have tokens in them. This means an or-join downstream > of this activity can't be enabled if the activity is still waiting > for events. This is true even if no events ever come. Agree. But I don't see what the problem is? If they expect an event then the OR-Join should not be enabled before the event to arrive. I'm not very sure if you are talking about the following case: The message event is attached to the pool. In this case until the message is received there is no token on the message event e.g. the message event listens for an event and is activated only when the message event is received. Thus if the there is a token on the line "Task 1" to "J1" and there is no message received then J1 will be activated. If what they want to achieve is to wait for this message event then authors should use AND-Join. > Decision points upstream from the or-join may decide never to send > tokens along the path to the or-join. Since it is difficult to > analyze if this is the case, presumably the semantics will assume > that it might send token to or-join. So if tokens are upstream of > the decision point, the or-join cannot be enabled, even if the > decision point never sends tokens to the or-join. This is correct. And before executing this decision point the OR-Join will not be enabled. But after executing the decision gateway and deciding which paths should be taken then at that time the OR-Join will be enabled. > Activities that break down into further subactivities upstream > from the or-join are considered active as long as their > subactivities are executing (assuming BPMN doesn't support > asychronous invocation). Correct. And in this case any OR-Joins afterwards will not be enabled similar to how AND-Joins will not be enabled. In a virtual engine the analysis if an OR-Join is enabled should be performed every time an Flow Object is completed. This does not mean that an execution engine should try to check it every time e.g. the engine could be smarter to know if something was changed that could have invalidated previous analysis. Thus if something changes upstream the OR-Join will be checked again if it could be enabled. This does not mean that an OR-Join will be executed twice. An engine could check if a Flow Object is enabled multiple times, but it should execute it only once (assuming that an author did not specified otherwise) Petko -----Original Message----- From: Conrad Bock [mailto:conrad.bock@nist.gov] Sent: Thursday, March 09, 2006 10:53 AM To: BPMNFTF Subject: RE: OR-Join Definition, clarifications Hi Petko, Just a reminder about these clarifications (added one more): - Activities (UML actions) that wait for incoming events are considered to have tokens in them. This means an or-join downstream of this activity can't be enabled if the activity is still waiting for events. This is true even if no events ever come. - Decision points upstream from the or-join may decide never to send tokens along the path to the or-join. Since it is difficult to analyze if this is the case, presumably the semantics will assume that it might send token to or-join. So if tokens are upstream of the decision point, the or-join cannot be enabled, even if the decision point never sends tokens to the or-join. - Activities that break down into further subactivities upstream from the or-join are considered active as long as their subactivities are executing (assuming BPMN doesn't support asychronous invocation). Of course you might clarify these cases differently, the above are just my suggestions. Original email below. Conrad -----Original Message----- From: Conrad Bock [mailto:conrad.bock@nist.gov] Sent: Thursday, February 23, 2006 10:49 AM To: 'Petko Chobantonov'; 'bpmn-ftf@omg.org' Subject: RE: OR-Join Definition Petko, > Actually the PDF document that I sent answers this question > and proves that it is possible to build an execution engine > that handles the proposed semantics. Perhaps, but you can't include the PDF in the spec. The statement of the semantics short enough to fit into the spec, where "semantics" means something more explanatory than the one-liner in ryou document. A good place to start on that is to give this in an email. After thinking more on this, there are couple things that should be included for clarification (if this is the intention): - Activities (UML actions) that wait for incoming events are considered to have tokens in them. This means an or-join downstream of this activity can't be enabled if the activity is still waiting for events. This is true even if no events ever come. - Decision points upstream from the or-join may decide never to send tokens along the path to the or-join. Since it is difficult to analyze if this is the case, presumably the semantics will assume that it might send token to or-join. So if tokens are upstream of the decision point, the or-join cannot be enabled, even if the decision point never sends tokens to the or-join. > When an event is sent, it will be correlated to a Process Instance > (it could be correlated to multiple instances too). At that point a > token will appear on the actual event. I don't think the semantics of the diagram waiting for the event should not depend on figuring out if other agents are sending events. > [Antoine] The activity flow allows for multiple unstructured > parallel threads. An OR-join means that one of the thread will > arbitrarely pass through, thé others will be cancelled I tend to > think this is bad practice but it is thé nature of unstructiured > parallel threads My understanding of the proposal is that there are no cancelled threads. One can't get through until all the others that can "possibly" arrive actually do. It's the "possibly" part that is poorly specified, and not even necessarily desirable. Is there any input from business users on whether it is the execution they would expect? Conrad Reply-To: From: "Conrad Bock" To: "'Petko Chobantonov'" , "'Rob Bartel'" , "'Dale Moberg'" , "'Giraud Jean-Luc'" , Subject: RE: OR-Join Definition Date: Tue, 14 Mar 2006 21:40:39 -0500 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcYz/bIsvntb0nNOSvSkR1lH+ZkM/AAAcrmQAAHAIeAAAgA2wAAATm1gAR9Fr7AAA1+IQAAxXRowAADS8oAACSZhsAEi07WgAADbdfUBcPSQ8AD2IXRg Petko, > I agree with this. Especially when you have more then 2 > lines coming from the split or if you have more then 1 > split. The diagram will become very messy even with 2 > splits and more then 2 outgoing lines. Me too, but if the alternative is confusion about the semantics, it's worth the clutter. For example, Martin Fowler suggests using more notation when it is necessary for clarity. Also see followon message on the new proposal. Conrad Reply-To: From: "Conrad Bock" To: "'Petko Chobantonov'" , Subject: RE: OR-Join Definition Date: Tue, 14 Mar 2006 21:41:19 -0500 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcYz/bIsvntb0nNOSvSkR1lH+ZkM/AAAcrmQAAHAIeAAAgA2wAAATm1gAR9Fr7AAAR6O8AABMgLQAAF1sfAAENZy4AFMLGEwAXK80UAA9F3fsA== Petko, > > > The document still refers off to another that cannot be included > > > in the specification and can't be understood by most OMG spec > > > readers. > The document refers to this additional document in the > abstract where I'm describing the problem at this point of > time and I'm pointing out existing work in this area. Sure, but pointing off to complicated articles doesn't give the group anything it can reasonably evaluate. We get either two (now four) sentences or a long paper for the semantic definition. How about something in between? > > The definition given is still too high level. It requires a > > complex deduction that isn't clarified (is the join reachable by > > the tokens on the graph). For example, how will can the > > implementer automate the deduction in the loop example? There are > > token upstream of the join if the implementer just traces the > > flows backwards. > The definition is not on too high level. I think the BPMN > Specification should define just the semantics and not what > algorithm an implementer should use to detect this. Agreed, but it might help you work out the semantics better without pointing to papers. The semantics so far is defined in too demanding a way for vendors (the "halting problem" as Frank calls it), and I don't think it even reflects your intent. To illustrate, let's look at the most recent semantics (just the first two for now): 1. There is at least 1 token on an incoming sequence flow 2. The number of consumed tokens cannot be increased by postponing the occurrence of the OR-Join considering the current Token Set. The first is an example of an undemanding semantics, which is a good thing. Any vendor can see what the execution should be. The second requires a very complicated deduction, that I think you don't even actually mean. For example, suppose: - An or-join has a token along one incoming flow line. - Upstream from the or-join along another flow line is an activity that receives events from somewhere external to the process. - The external environment will not generate any more events. Does the above satisfy the second bullet? Just reading the second semantic rule, the answer is yes. Waiting will not produce any more tokens at the join. Are you expecting vendors to automate the deduction that no more external events will arrive? Please correct me, but I'm figuring not. You probably want to assume that external events *might* come in, so the or-join should wait. If they happen to not come in, then the or-join should wait forever. Here's the third part of the semantics, added in the last revision: 3. During analysis if a specific OR-Join should be enabled, all other OR-Joins are treated as XOR-Gateways. This is an "Optimistic" Approach e.g. we are assuming that any OR-Join (different then the one we analyze) could be enabled as long as 1 token could arrive. This means the actual execution could violate the second rule above, because waiting could give more tokens to the "assumed XORs". Does anyone in the group see business users thinking this way? If not, maybe we should have semantic options for pessimism, moderate optimism (has more than half the tokens), and other variations. :) Conrad Reply-To: From: "Conrad Bock" To: "'Petko Chobantonov'" , "'BPMNFTF'" Subject: RE: OR-Join Definition, clarifications Date: Tue, 14 Mar 2006 21:41:39 -0500 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcYz/bIsvntb0nNOSvSkR1lH+ZkM/AAAcrmQAAHAIeAAAgA2wAAATm1gAR9Fr7ACwx/oYAAzqG0gANL+X1A= Petko, > > Activities (UML actions) that wait for incoming events are > > considered to have tokens in them. This means an or-join > > downstream of this activity can't be enabled if the activity is > > still waiting for events. This is true even if no events ever > > come. > > Agree. But I don't see what the problem is? If they expect > an event then the OR-Join should not be enabled before the > event to arrive. When should the event be expected and when not? What if there's no way to determine if events are coming or not? > I'm not very sure if you are talking about the following case: Yes, it is, thanks for drawing it up. > The message event is attached to the pool. In this case > until the message is received there is no token on the > message event e.g. the message event listens for an event > and is activated only when the message event is received. > Thus if the there is a token on the line "Task 1" to "J1" > and there is no message received then J1 will be activated. This violates the second rule of the proposed semantics, because the or-join could wait and might receive more events. > > Decision points upstream from the or-join may decide never to send > > tokens along the path to the or-join. Since it is difficult to > > analyze if this is the case, presumably the semantics will assume > > that it might send token to or-join. So if tokens are upstream of > > the decision point, the or-join cannot be enabled, even if the > > decision point never sends tokens to the or-join. > > This is correct. And before executing this decision point > the OR-Join will not be enabled. But after executing the > decision gateway and deciding which paths should be taken > then at that time the OR-Join will be enabled. OK, let's suppose that for some reason the decision branch going to the or-join will never succeed, due to some peculiarity in the guard condition and the entities it refers to. The text of the second semantic rule ("The number of consumed tokens cannot be increased ...") implies the execution engine should be able to figure this out and not wait for more tokens at the or-join. > > Activities that break down into further subactivities upstream > > from the or-join are considered active as long as their > > subactivities are executing (assuming BPMN doesn't support > > asychronous invocation). > > Correct. And in this case any OR-Joins afterwards will not > be enabled similar to how AND-Joins will not be enabled. OK, once again let's suppose for some reason the subactivity goes into an infinite loop. The downstream or-join will never receive a token. The text of the second semantic rule implies the execution engine should be able to figure this out and not wait for more token at the or-join. This is the halting problem Frank was referring to, which isn't possible to solve in general. To summarize the comments of this message and the last, the semantics should be much more specific about where the tokens must be in the graph for the or-join to succeed, rather than the overly general second item text. I hope the event and decision point examples show this clearly enough. Conrad Reply-To: From: "Conrad Bock" To: "'Petko Chobantonov'" , "'BPMNFTF'" Subject: RE: OR-Join Definition, clarifications Date: Wed, 15 Mar 2006 12:26:14 -0500 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcYz/bIsvntb0nNOSvSkR1lH+ZkM/AAAcrmQAAHAIeAAAgA2wAAATm1gAR9Fr7ACwx/oYAAzqG0gAPYsAbA= P.S., > The message event is attached to the pool. In this case > until the message is received there is no token on the > message event e.g. the message event listens for an event > and is activated only when the message event is received. > Thus if the there is a token on the line "Task 1" to "J1" > and there is no message received then J1 will be activated. Another issue shows up in your example of March 10 if there is a subactivity just before the end node. While that subactivity is executing, a message may come in and start Task 2, and after that the order or-join will succeed, according to the rules in your proposal. Not sure if this the intention of the example, but in Jean-Luc's of Feb 24, a Special_Notice message may arrive during the while the Invoice subactivity is executing, causing the or join to succeed, which I gather is undesirable. As a separate question, does BPMN have a way to control when "wait for event" nodes actually wait? In UML these are kinds of actions (AcceptForEvent), and can have control flow inputs to determine when they start waiting. This is probably how Jean-Luc's example should be modeled. Conrad Reply-To: From: "Conrad Bock" To: "'Petko Chobantonov'" , "'BPMNFTF'" Subject: RE: OR-Join Definition, clarifications Date: Wed, 15 Mar 2006 15:27:28 -0500 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcYz/bIsvntb0nNOSvSkR1lH+ZkM/AAAcrmQAAHAIeAAAgA2wAAATm1gAR9Fr7ACwx/oYAAzqG0gAQGu7uA= P.P.S., > The message event is attached to the pool. In this case > until the message is received there is no token on the > message event e.g. the message event listens for an event > and is activated only when the message event is received. > Thus if the there is a token on the line "Task 1" to "J1" > and there is no message received then J1 will be activated. Rob Bartel sent a message separately saying the clarifications below were how his simulator interprets the OR-join, which is different from the above. (took the liberty of including his clarifications) Rob, have you looked at Petko's example (see attached)? Conrad - Activities (UML actions) that wait for incoming events are considered to have tokens in them. This means an or-join downstream of this activity can't be enabled if the activity is still waiting for events. This is true even if no events ever come. - Decision points upstream from the or-join may decide never to send tokens along the path to the or-join. Since it is difficult to analyze if this is the case, presumably the semantics will assume that it might send token to or-join. So if tokens are upstream of the decision point, the or-join cannot be enabled, even if the decision point never sends tokens to the or-join. Rob: So if tokens are upstream of the decision point, the or-join cannot be enabled, even if the decision point never sends tokens to the or-join. So if tokens are upstream of the decision point, the or-join cannot be