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

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

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.

I'd encourage your comments on Tuesday or this week so we can resolve 
what changes if any need to be made. This example could also be useful 
as another industry example of ebBP. Thanks, Cristiano. Comments 
encouraged everyone. Thanks.

[1] Reference Novelli comment: 
http://lists.oasis-open.org/archives/ebxml-bp-comment/200510/msg00001.html
[2] Attachments show KnitWear process, picture of issue, and .xml draft.
[3] Working draft pseudo from Novelli:

    BusinessCollaboration (Main)
       firstBTA
       myCA
       finalBTA

       Decision1 (no condition)
           from firstBTA to myCA
           from firstBTA to finalBTA
       End Decision1 (no condition)
       Decision2 (no condition)
           from myCA to myCA
           from myCA to finalBTA
       End Decision2 (no condition)
    End  BusinessCollaboration (Main)

    BusinessCollaboration (myCA)
       StateStart
       BTA1
       BTA2
       BTA3
       StateEnd

       Fork OR (no condition)
           from StartState to BTA1
           from StartState to BTA2
           from StartState to BTA3
       End Fork

       Join waitforall=false
           from BTA1 to StateEnd
           from BTA2 to StateEnd
           from BTA3 to StateEnd
       End
    End BusinessCollaboration (myCA)

knitwear-ebbp-instance-novelli-102105.zip