Re: [ebxml-bp] ebBP 10/25/2005: Update on Recursion and Optionality

["David Webber \(XML\)" <david@drrw.info>]

Monica,

I think in the limited case recursion works - and as John noted - the
beginWhen / endsWhen provides local control neatly between partners, and
within steps.

Then you need state management across the whole collaboration - say in a
marketplace - so that an endsWhen can be globally shared between
colloborators - or Exception implemented - such as when a bid condition
terminates further bids in an auction.   The signal mechanism can certainly
help publish that of course - as one option here - to collectively end
recursive threads.

So today I believe we can build recursive processes where each step is
discrete and has single entry and exit points (very Prolog-esque execution
model) - and continuing that analogue - by using fact assertion to shared
information spaces (via signals) that can be acted on by recursive tasks.

Beyond that then we get into what BCM calls "Linking and Switching" and the
provision of a global state management agent service as a more comprehensive
solution set, and that is not supported yet - and we know is a probably V3.0
feature.

DW



----- Original Message ----- 
From: "Monica J Martin" <Monica.Martin@Sun.COM>
To: "ebXML BP" <ebxml-bp@lists.oasis-open.org>
Cc: "Cristiano Novelli" <cristiano.novelli@bologna.enea.it>
Sent: Tuesday, October 25, 2005 4:20 PM
Subject: [ebxml-bp] ebBP 10/25/2005: Update on Recursion and Optionality


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


----------------------------------------------------------------------------
----