[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-bp] ebBP 5/23/2004: WI-21 Definition and Use of beginsWhen, endsWhen, Pre-Post Conditions [RSD]
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? Also, is the information something that every participant "needs to know" in order to arrive at "state alignment"? Finally, is the information to be used in deciding how states transition? (where states are the high level BTA, CA, or perhaps OA components)? Sorry to miss this debagte because it is important to decide what the 2.0 scope on this will be. 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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]