ebBP 5/23/2004: WI-21 Definition and Use of beginsWhen, endsWhen,Pre-Post Conditions [RSD]

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

OASIS.ebBP.WI-21-Pre- and post-conditions;
Topic|;
Point|Use of Current Attributes to Guide Business Processes;
Attachment|http://www.oasis-open.org/archives/ebxml-bp/200405/msg00100.html;

mm1@
Let me say there has been a heated debate raging with some implementers 
this last week about beginsWhen, endsWhen, and pre- and post conditions.
We touched on these attributes in the February 2004 F2F and recognized 
we should discuss them for v2.0 and make substantive changes in v3.0.  
Well, for best laid plans....

First let's set a baseline on goals on these functions:

    * Alleviate confusion and be as explicit as practical in the schema
      and/or specification.
    * Allow flexibility while definitive guidance on what elements or
      attributes are, and how they are used.
    * Enable future v3.0 functionality.

OK, down to substance. Now, let's talk about what these elements 
currently are and how they relate to or could be used with other 
existing ebBP functionality. They exists on the BTA, CA and BC (through 
the BusinessActivity). They are xsd:string and currently are not 
included in the BSI (due to documentation nature and the use of string).

    * beginsWhen:  A description of an event external to the
      collaboration that <<<normally causes this collaboration to commence>>
    * endsWhen: A description of an event external to this collaboration
      that <<<normally causes this collaboration to conclude>>>
    * Pre-condition: A description of a state external to this
      collaboration that is <<<required before this collaboration can
      commence>>> [1]
    * Post-condition: A description of a state external to this
      collaboration that is <<<required before this collaboration can
      conclude>>>

In February we discussed that, pre- and post-conditions are rules around 
events that provide allow for encapsulation of specific process 
activities.  John Yunker had indicated at that time that we could 
consider adding a conditionExpression on the pre-condition. 

Now, fast forward to the discussion that has occurred (sorry, sometimes 
implementers go on tangents before they go public):

    * What was their original intent and their projected use?
    * How does this relate to our condition expressions, transitions and
      pseudo states? Are these string attributes redundant?
    * Can they be used together? [2]

I believe we need to separate these functions and concerns clearly. 
There is a distinct difference on use of a conditionExpression on 
business document content that supports a guard condition on state 
transitions and an external event that may create the capability to 
initiate/conclude or trigger an activity.  I realize that a protocol 
failure could be a considered an external event - save that for later.

The key to this discussion is an external event, not one associated with 
the included activities. That is a clear differentiator to me (if to 
no-one else). It also is possible  an external event may drive a 
transition and condition to be possible or not (hence it could affect a 
success or failure). For example, you may have an invoice generated 
during a business process. However, you may not be able to generate the 
invoice until a product is delivered. Therefore, that condition exists. 
In specific environments, the business rules may dictate that the 
product delivery triggers the invoice generation, or in others, that the 
product delivery allows an invoice to be aggregated (for example, one 
invoice may include many product deliveries and orders for that matter) 
and later generated. Those are separate conditions and rules. We have 
seen, in disucssions with high-technology and online retail players, 
that these business rules are important. Those triggers (for beginsWhen, 
endsWhen) may not be business messages, but events generated from an 
outside ERP system that are relevant to us.

OK, where do we go from here and how these four attributes can be 
effectively used. For v2.0: The collaboration and external conditions 
are important. Currently, they are not all computable. Currently, they 
may be misconstrued by developers. They can work together but they are 
not the same.

Suggest we clarify they are external events not those visible in the 
process. I understand now, after reviewing the issue more fully, that if 
we move these attributes away from the activities into documentation, we 
may further confuse the developer. And if we wish to effectively use 
them in the future, more changes will be required to move these 
attributes back to the activities (again). Therefore, I propose we leave 
them on the activities as defined. However, I agree we have to put 
mechanisms in place to ensure they are effectively used (if so) until we 
can place more functionality and computability into them. I would not be 
adverse to placing a condition expression on these attributes. I would 
further say, we need to consider making them an element to allow for 
futher specification (supported by below).

    * pre-condition + other variables = beginsWhen [3]
    * post-condition + other variables = endsWhen [3]

Since those external events can occur anytime during the process, I am 
not suggesting we delete either unless we have more reason to do so.

Therefore, in summary for v2.0, I would propose:

    * We retain these capabilities and consider combining them.
    * We make them elements so we can apply more characteristics which
      will allow them to be used with effects, variables, etc. in the
      future.
    * We make clear these are external events and put some user hints to
      encourage their appropriate use.
    * We get more use cases from David Webber, John Yunker and others.
      HINT-HINT!!!

[1] This is not to be confused with production rules for UML=>XML 
transformation and the fact we are looking to develop well-formedness rules.
[2] David Webber has used beginsWhen and endsWhen as a complement to the 
guards.
[3] Remember that pre-condition only enables a condition, the beginsWhen 
allows the triggered event to occur.  Anders Tell has suggested that 
specific effects (and other variables) could be used here as well. So, I 
think we are of like minds.

Dale is traveling so he asked if fast-forward this discussion and bring 
it to Monday's meeting.  Well, start shooting arrows so we can set a 
direction. Thanks.

@mm1