Novelli 12/27/2005: Resolution for Recursion and Optionality -Feedback Requested

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

Cristiano,
We discussed this verbiage below in this last week's call 12/20/2005. 
We'll make some minor updates to effectively communicate that what is 
expressed with these condition expressions are the shareable information 
relevant to both parties.  I'll send out an update today and ask that 
you review it to see what you think and provide any comments.

In addition, we'd like to receive any update on your progress and 
findings since our last discussion. We hope to close out this phase of 
the specification in short order in January 2006, so your timely 
feedback would be greatly appreciated. Thank you. We look forward to 
hearing back from you.

Best regards and Happy New Year 2006.

> mm1 12/19/2005: I've received feedback from John that no additional 
> flag is needed unless, at some time in the near future, we have a 
> better idea of the requirements surrounding its usage for optionality. 
> Therefore, in reviewing the discussion and suggestions thus far, a 
> short appendices may be helpful. This is the option we chose when we 
> addressed manual or implicit activities.
>
> Therefore I'd suggest a short Appendix D (that moves our glossary to 
> Appendix E) related to Recursive or Optional Activities. It will be 
> short and to the point, recognizing the investment and ideas thus far.
>
> Change from:
> Add Appendix D: Handling Recursive or Optional Activities
> Change Appendix D (existing) to Appendix E: ebBP Glossary
>
> Change to:
> Appendix D: Handling Recursive or Optional Activities.
>
> In eBusiness, a business partner or collaborating party may need to 
> plan for potential activities - those that may occur more than once or 
> more, or not at all (i.e. they are optional).  Several mechanisms can 
> assist in realizing these needs including semantic variables, 
> condition expressions and guards on transitions.  In the technical 
> specification, we describe these capabilities in detail.
>
> However, understanding their usage in user communities to solve 
> complex eBusiness needs is important.  For example, the textile 
> industry in Italy often engage in activities which may or may not 
> occur, and, others that may occur more than once. Different order 
> statuses or types of business messages with business documents may 
> occur.  The process designer may utilize the ebBP capabilities for 
> these purposes, including:
>
>   1. Condition expressions using BeginsWhen, EndsWhen, PreCondition,
>      and PostCondition: When these expressions are enabled in a
>      computable way, they could be used as gating mechanisms to be
>      available to enter or enter, or be available to exit or exit
>      activities.  In this manner, the activities flow using Fork and
>      Join to drive the correct Business Transactions.
>          * Explicit recursions: Any Business Transaction may be part of
>            a recursive loop that continues until explicitly terminated.
>            The EndsWhen could be used in this case.
>          * Explicit optionality: Any Business Transaction can be
>            fronted by a Decision that explicitly excludes execution of
>            the Business Transaction. For example, Partner A decides to
>            send a business document today only as a discount offer.
>            Partner A may handle that through parallel execution paths
>            and BeginsWhen.
>          * Other examples:
>                o Under certain conditions, it is unknown if more Order
>                  Status Update will occur. At some point, a Delivery
>                  Confirmation will be received with a different
>                  business document.  A Join may relate to this - when
>                  the Delivery Confirmation is received, always move on.
>                  If this is not the case and explicit closure is more
>                  difficult, a Fork may be used where parallel
>                  processing occurs.
>                o Both a Delivery Advice and a Freight Status Advise
>                  could be occurring.  A PreCondition could be used to
>                  see if a Delivery Advice is received; if a Freight
>                  Status Advice is instead, the Business Collaboration
>                  is done and an error occurs.
>   2. Condition expressions on gateways for Fork, Join and Decision:
>      Using condition expressions on ToLink and FromLink: Condition
>      expressions can be associated with the ToLink and FromLink
>      element. The conditionGuard attribute of the FromLink element can
>      contain status values obtained from the state pointed to by the
>      FromLink; matching the value governs whether a transition is made
>      at run time. For the ToLink completion states can have condition
>      expressions that are checked at runtime to determine whether the
>      transition to a state is actually made.
>          * For example for recursion: For re-entering a transaction, a
>            Fork could send the process back into the same Business
>            Transaction. Conditions could be used on the Fork that
>            preclude re-entry. For example, a Freight Status Advice has
>            several possible values - one that reoccurs many times with
>            a condition on the Fork after the advice that says that if
>            this status is 'delivered', then re-entry may not occur.
>            Otherwise, recycle and look for another one.
>
> In the future, an optional declaration on a Business Transaction may 
> be considered to support certain types of status messages. In this 
> case, assuming the explicit modeling of execution paths, any 
> declaration would be considered documentation.
>
> See the technical specification associated with this appendix for more 
> details on condition expressions, condition guards, business states 
> and their characteristics.
>
> Change to: Appendix D (current) becomes Appendix E: ebBP Glossary.