ebBP 12/19/2005: Resolution for Recursion and Optionality - SuggestedAppendix

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

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.