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

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

In Tuesday's call we discussed in more detail Mr. Yano's question prior 
to another posting he made 6 April 2005. Here is a revised proposal 
based on our discussion and decision, and hopefully addressing his 
second inquiry.  His secondary question is a slightly different 
interpretation/use case to consider so any feedback would be 
appreciated. I've tried to capture the essence of his request, after 
speaking about this with John Yunker. This is more a best practice (and 
some sense thrown in). Comments welcome.

===========================================================================================================
References:
Mr. Yano: 
http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/email/archives/200504/msg00017.html
Martin: 
http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/email/archives/200504/msg00012.html

Original comment:

       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.)

Second comment: My thought is that the first sentence above is written 
based on the assumption that any path in a Fork/Join block usually 
doesn't reach Join (such like an example shown in line 1491-1493) and 
therefore TimeToPerform timeout is needed to reach Join. However, in my 
thought, the combination of OR-fork and OR-join (waitForAll="false") can 
be used also in a case that a path in a Fork/Join block always reach 
Join (and another path is optional). In such case, a business process 
designer doesn't need (and probably, should not) specify TimeToPerform 
parameter to Fork element. Therefore, my suggestion is to change the 
first sentence quoted above to a sentence such like:

    The duration of the fork TimeToPerform SHALL NOT be null if any path
    in a Fork/Join block does not reach Join.

My understanding can be wrong. Anyway, my point is that a business 
process designer should not be forced to specify unnecessary 
TimeToPerform attribute.

===========================================================================================================
Section 4.6.8.1  Key Semantics of Choreography

    Change from:
    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.

    Change to:
    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.

    Via the AND-join (by default, the join is an AND-join), the
    waitForAll attribute (waitForAll='true') 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. When the waitForAll parameter is set to false, it is an
    OR-join. If one or more Business Activities complete, the OR-join
    (waitForAll='false') completes. For an OR-join (where
    waitForAll='false'), 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. 

In the matrix that follows in this section, for the OR-fork, 
waitForAll='false':

    Change from:
    The duration of the fork TimeToPerform SHALL NOT be null. The Join
    state is reached when all activities have been performed or when the
    timeout occurs, whichever comes first

    Change to:
    The Join state is reached when the activity has been performed or
    when the timeout occurs, whichever comes first. TimeToPerform on a
    fork is typically used when a join is expected to be taken (i.e. the
    join takes place even if the activities do not). 

Schema: no changes.
===========================================================================================================