ebBP 4/5/2005: Comment re:waitForAll on OR-fork-join semantics(wd/10-schema 2/22)

["Monica J. Martin" <Monica.Martin@Sun.COM>]

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