ebBP 12/27/2005: Updated Appendix D for Recursion/Optionality(Feedback needed!)

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

Cristiano and John,
By the request of the TC I've provided some updated text for Appendix D 
subsequent to our meeting 20 December 2005.  Here is the update where we 
require TC and your feedback. Let me know prior to next week's call what 
changes, if any, are required or provide questions. Thanks.

Updated Appendix D (as of 27 December 2005)
===============
Change from:
(1) Add Appendix D: Handling Recursive or Optional Activities
(2) Change Appendix D (existing) to Appendix E: ebBP Glossary

Change to:
(1) 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.

In this capabilities area, the ebBP primarily concentrates on the actual 
business collaborations defined by the business partners or 
collaborating parties involved
in order to achieve optimal if not maximum interoperability. A continuum 
is supported from simple business transactions and collaborations (that 
are modular in design but capable of being packaged for optimal use by 
interested user communities) to complex collaborations (that recognize 
the intricacy of partner expectations).  What is developed and the 
complexity of the collaborations depends on the community and the 
partners involved. 

When complex collaborations are developed, it is anticipated that the 
conditions surrounding them will also become more intricate, such as 
those discussed in 1. below.  It is a delicate balance to provide 
flexibility in the collaboration definition while also recognizing what 
user communities can enable and adopt.

For ebBP, conditions expressions are shareable and relevant to the 
parties involved. In some cases, these expressions may be similar to 
business rules relevant to a partner only, but may impose constraints on 
other business partners. There may be situations where they use these 
functions to elicit more control, such as in a hub.

It is important that user communities understand the potential and 
intricacy of such expressions when solving their complex eBusiness needs 
where appropriate. For example, the textile industry in Italy or UK 
local government may engage in activities which may or may not occur,  
and, others that may occur more than once. For the Italian case, 
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. BeginsWhen, EndsWhen, PreCondition, and PostCondition condition
      expressions: 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 (additional attribute, for 
example) 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. 
However, additional changes will be focused on balancing the 
capabilities provided against the user communities served and their 
capability to adopt such functions.

See the technical specification associated with this appendix for more 
details on condition expressions, condition guards, business states and 
their characteristics.

(2) Change to: Appendix D (current) becomes Appendix E: ebBP Glossary.