Re: [ebxml-bp] ebBP 4/5/2005: Comment re:waitForAll onOR-fork-join semantics (wd/10-schema 2/22)

[YANO Keisuke (矢野啓介 ) <yano@jp.fujitsu.com>]

Monica,

Thank you for considering my comments.

I feel that I should explain more details on my comment on question.

The original text you quoted in the attached Word file reads:

   The duration of the fork TimeToPerform SHALL NOT be null. The Join
   state is reached when at least one activity has been performed or
   when the timeout occurs, whichever comes first.

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.


Regards,

Yano K.

P.S. Monica, could you please record my name as Yano rather than
Keisuke in meeting minutes because my family name is Yano. Sorry
for my poor explanation.  FYI, the web page "Japanese names"
<http://www.japan-guide.com/e/e2271.html> would be a helpful resource
to call and write Japanese names.


From: "Monica J. Martin" <Monica.Martin@Sun.COM>
Subject: [ebxml-bp] ebBP 4/5/2005: Comment re:waitForAll on OR-fork-join semantics (wd/10-schema 2/22)
Date: Tue, 05 Apr 2005 08:04:49 -0700

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