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

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

Dale Moberg wrote:

>Hi Monica,
>
>Your discussion seems to get most of the relevant issues gathered
>together.
>
>An additional question about the information to be placed in the 4
>attributes is
>whether it is information pertaining to the "public" process or to the
>"private" process?
>  
>
mm1: Agreed. 

>Also, is the information something that every participant "needs to
>know" in order to arrive at "state alignment"?
>
mm1: Agreed, visibility will be determined by the answer to your first 
question.

>Finally, is the information to be used in deciding how states
>transition? (where states are the high level BTA,
>CA, or perhaps OA components)?
>  
>
mm1: We can discuss if this information is available (probably v2.0) and 
then whether it is computable and potentially used for state alignment 
(I would vote for v3.0 but will go with the team's decision).

>Sorry to miss this debagte because it is important to decide what the
>2.0 scope on this will be.
>  
>
mm1: These questions are great and I can add them to today's discussion.

>Thanks
>Dale Moberg
>-----Original Message-----
>From: Monica J. Martin [mailto:Monica.Martin@Sun.COM] 
>Sent: Sunday, May 23, 2004 1:52 PM
>To: ebXML BP
>Subject: [ebxml-bp] ebBP 5/23/2004: WI-21 Definition and Use of
>beginsWhen, endsWhen, Pre-Post Conditions [RSD]
>
>
>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.h
>Attachment|tml;
>
>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
>
>  
>