ebBP 10/31/2005: Update on Recursion and Optionality

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

Everyone, in looking at Cristiano forwarded to us - the flow diagrams and the different BTA, I do see there are potentially 
condition expressions that could be used to gate whether these BTA are used (optional or not) and reused (recursion).

See the attached .doc. In each you see conditions either through the expectations of the parties, from previous business documents
or as a periodic notification. It would stand to reason these conditions could be used accommodate Cristiano. I encourage
your comments after looking at the document as well as the URL below (that shows the flow diagram). Thanks.


--------
excerpt: 
http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/email/archives/200510/msg00032.html

Earlier this month, we received a comment from Cristiano Novelli 
regarding recursion and optionality [1] [2]. Here is a brief summary, 
some conclusions and questions for us to consider in next week's call, 
and are a result of comments from John Yunker, Dale Moberg and myself. 

    * Need/requirement statement: (See [2])
         1. Italian textiles have several business messages in their
            processes, that may be executed in any order, may or may not
            be used (BT) and may be executed recursively.
         2. They also have requirements to describe two consecutive
            gateways, whereby there is a transition between a gateway
            and a fork, or from a join to a gateway.
    * Possible solutions:
          o Handle via nested collaborations. [3] Dale Moberg suggested
            that BTAs be bundled in a BC and then a
            CollaborationActivity could reference them.
                + Note: It appears that John Yunker's suggestions may be
                  more succinct and may simplify the process definition.
                  See Considerations.
          o Use conditional expressions to handle optionality and
            recursion. See Considerations.
          o Consider optional attributes on BTA. See Considerations.
    * Considerations:
          o Need to explicitly model the activities expected. [Yunker]
               1. Any BT can be fronted by a decision that explicitly
                  excludes execution of the BT (explicit optionality).
                      + Partner A decides to send a document today only
                        as a discount offer. He handles that through
                        parallel execution paths and beginsWhen.
               2. Any BT can be part of a recursive loop that continues
                  until explicitly terminated (explicit recursions). Use
                  endsWhen for example.
               3. Note: Cristiano, it doesn't appear you have made use
                  of beginsWhen and endsWhen as
                  ConditionExpressionTypes. These conditions could be
                  rendered as computable at runtime which is when you
                  were interested in implementing the flexibility of
                  what your domain requires. They can exist at
                  collaboration or BTA level. They are described in the
                  specification in Section 3.4.10.1.
          o Fully utilize existing constructs. Choose the compilation
            constructs that optimally meet the requirements stated.

WP102-012-MM-KnitWearProduction-BTflow.doc