[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: ebBP 4/5/2005: Comment re:waitForAll on OR-fork-join semantics(wd/10-schema 2/22)
I have a more detailed question about the OR-fork-join semantics prompted by this comment received from Yano Keisuke: Comment: line 1504: In the table, the comment of OR-Fork and waitForAll="false" Join says "The duration of the fork TimeToPerform SHALL NOT be null." This restriction should be relaxed. (Please consider the case that one path in a Fork-Join block is a normal sequence and another path is optional. In this case, we don't need TimeToPerform timeout to reach the Join.) Note in wd10: Section 4.6.8.1 A fork has a TimeToPerform element, where the duration may be specified. At the end of this time interval, the state of the Binary (Business) Collaboration will automatically be moved to its corresponding join. This feature MAY be used in cases where the business activities are optional. For instance a Cancel Purchase Order and Change Purchase Order business transaction activity could be defined as part of a Fork/Join control block. However, most often none of these activity would happen. If any given Business Transaction Activity within the Fork/Join pair has not reached its completion state, the BSI will generate a corresponding timeout exception. The TimeToPerform duration of a fork cannot be less that any TimeToPerform duration of its business activities. The waitForAll attribute of the join SHALL indicate that all transitions coming into the join SHALL be executed for the collaboration to reach the join state that reflects the state movement (via the AND-join), by default, the join is an AND-join. When this parameter is set to false, it is an OR-join. <<The BSI will generate a timeout exception if an OR-join is reached while a Business Activity has not reached its completion state.>> The semantics of fork and join are such that for instance a fork MAY be defined without a corresponding join. In this case, the TimeToPerform element SHALL NOT be used. It MUST only be used in the case where all outgoing transitions from the fork have incoming transitions to the join. Text seems consistent and fairly well understandable, except for one point which I will articulate below. Let's now look at the table (see attached). I think that the verbiage may need updating for OR-Join where waitForAll='false' in the table and may need clarification in the text above (see <<....>>). There may be semantics or historical precedence of which I am unaware. I don't see we need a schema change at this time, regardless of what is decided herein. If waitForAll='false' on OR-join (not XOR), it seems to reason: * All activities may occur (Text even says that not all forks have incoming transitions to the join, a fork may not have a corresponding join, etc). * There is no requirement to wait for all (i.e. the default is 'true' but a party may set a value of 'false' because the attribute value is not fixed. In addition, it is not required use (i.e. the attribute may not be used at all). My questions: * Shouldn't this be that at least one activity completes (although more than one can be expected and activated) or a timeout occurs (whereby the BSI kicks in)? Note: John Yunker has indicated this is correct. Yes, an OR join does not mean the paths are exclusive, only that the wait is not dependent on all of them completing. Martin: Text should be clarified then. * If a timeout occurs and one activity has completed, does the BSI still raise an exception? Logically to me this should be NO (My assumption is that if a timeout occurs and no activity has completed, the BSI does raise an exception). Note: John Yunker indicated: If it is an OR join, and one activity has completed, then there cannot be a timeout, since the join completed when the activity completed. On this text (as highlighted by <<...>> above) in Section 4.6.8.1: When this parameter is set to false, it is an OR-join. The BSI will generate a timeout exception if an OR-join is reached while a Business Activity has not reached its completion state. The semantics of fork and join are such that for instance a fork MAY be defined without a corresponding join. Shouldn't this be? When this parameter is set to false, it is an OR-join. The BSI will generate a timeout exception if an OR-join [time to perform] is reached while [all preceding] Business Activity has not reached their completion state (i.e. at least one Business Activity has not completed as there is no requirement they all complete). The semantics of fork and join are such that for instance a fork MAY be defined without a corresponding join.
open-fork-join-semantics-mm1-040105.doc
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]