[Fwd: Re: [ebxml-bp] [ebBP] 6/28/2004: Work Item 21 - Summary forConditional Constraints-beginsWhen, endsWhen!!]

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

John,
Perhaps you and the rest of the team can add to my comments to Serm 
regarding begins- and endsWhen, particularly:

Serm: For example, an agent monitoring a states of a system spawns a new process if a condition met. Following the example above, if an account monitoring agent found that the balance of checking accout < payment balance, it
triggers a process to transfer $$ from saving to the checking. But I think this does not fit the BPSS scope.
2) All of the example described above seems to be conditions internal to business systems that are not necessarily be disclosed to the outside. I am also thinking about another aspect of pre-conditions at the business process level as business requirements to do business. For example, one may want to specify that the partner must be ISO-9000 certified or the product sold must not be tested on animal. These could be just for documentation as well. Not sure if this makes sense and in the scope of BPSS.

Thanks.

>Kulvatunyou: Monica, please post to the list as you see appropriate.
>
>I guess I sort of understand your June 18 quote, and I still think that that
>situation is internal to the business system which need not be exposed in
>BPSS.
>
>I can't understand the quote from June 25 on the first part of "legal ..."
>and I think I read the whole minute. I understand John Yunker example about
>the retry a little bit as it is similar to my example, and again I think it
>is internal to the system.
>- serm
>
>----- Original Message ----- 
>From: "Monica J. Martin" <Monica.Martin@Sun.COM>
>To: "Boonserm (Serm) Kulvatunyou" <serm@nist.gov>
>Sent: Monday, July 12, 2004 6:50 PM
>Subject: Re: [ebxml-bp] [ebBP] 6/28/2004: Work Item 21 - Summary for
>Conditional Constraints-beginsWhen, endsWhen!!
>
>>>Serm: Monica,
>>>Could you see if these comments are valid and make sense to post of ebBP, if so please do it on behalf of me. I'm so behind that I'm afraid that what I have described below may be duplicate of the guard conditions (but I
>>>remember that guard conditions only deal with transaction success/fail).
>>>
>>>Thanks and regard,
>>>Serm
>>>____________________________________________________________________
>>>
>>>May I add a few thoughts. Those questions toward the end of your note are worthy to think about.
>>>
>>>I think depending on the interpretation beginsWhen and endsWhen could be equivalent to the pre and post condition, because events trigger new states.
>>>      
>>>
>>mm1: Serm we have some other use cases evolving for these conditional constraints. We see they may be different - remember beginsWhen and endsWhen are the case that trigger. The pre- and post-condition only allow the enablement to transition (conditions are true).
>>
>>>Serm: Here is one way I had in my mind to look at these attribute. Back when I had a computer control class, pre- and post- conditions are used for ensuring that the action/transaction can be safely executed (pre-con) and that the transaction has been completed appropriately (safely). For example, before a robot 'move' a part, a [pre-con = no-obstruction] triggers an action to check that no obstruction in the trajectory path. After the robot 'put' a part into the maching station, a [post-con = part presents] trigger an action to double check that the part is still there. In these two examples, 'move' and 'put' are two actions. The pre- and post- conditions are very important but are not necessary (if one think that the whole system is so reliable and synchronized).
>>>
>>mm1: This is in line with our discussions last week and with the use cases we've found thus far and my premise above. See notes for reference from last week's call at:
>>http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/documents.php (under Documents in Meeting Notes section). I've also attached excerpts of the meeting minutes from 18 and 25 July 2004 special sessions [1].
>>
>>>Serm: They are important because a robot collision and the machine tool could machine the expensive fixture instead of the part. The unmet pre-con could produces a 'wait', e.g., wait until the trajectory path is clear or other robot out of its way. The unmet post-con could produces a pause and a warning light going off; consequently, an operator pick up a fallen part into the fixture. Then the process could resume. The pre- anc post- conditions could imply a lot of actions depending how sophisticated a system is designed. Now in these scenarios the 'endsWhen' could come into play. A system architect or production engineer may want the system to idle too long or want to prevent a system from getting into an infinite wait. So he/she can specify that if the robot has been waiting for 5 mins, it should abandon the action and ends the process (e.g., put part into a bin and resume production of another part). The fallen part case, one may or may not want to do similar thing depending on the technology. If one can ensure that the fallen part will not inflict the machine machanics, then a production can resume. 
>>>
>>mm1: This shows that the endsWhen triggers an event; the pre- or post-condition only guards (makes the condition conducive to proceed). 
>>
>>>Serm: Now for an analogy to business arena. A pre-con may be, for example, check that the money is sufficiently in the bank before making payment (balance = payment). A post-con may be to double-check that balance is equal to deposit + previous balace (to ensure that check is clear). Both of them could result in a 'wait' and other subsequent side-effect actions to resolve the system to meet the specified conditions (possibly by human). One may also want to specify and 'endsWhen' condition that trigger a notification to the human to may trigger other channels of the payment.
>>>
>>>Having said all of these, 1) I haven't see a use case for the 'beginsWhen'. Neither I see one in the minute below. I think it may be used at the process leve rather than at the transaction level, for example to spawn a new process if conditions match.
>>>      
>>>
>>mm1: See [1] below for inputs from 18 and 25 June 2004. We are seeing it at both levels. Please also look at the editors' F2F notes: http://www.oasis-open.org/archives/ebxml-bp/200407/msg00035.html.
>>
>>I'll have more information to distribute on the semantic element ('variable') this week. Thanks and we do appreciate your questions and input. I'd like to post this to the list if you agree. 
>>
>>>Serm: For example, an agent monitoring a states of a system spawns a new process if a condition met. Following the example above, if an account monitoring agent found that the balance of checking accout < payment balance, it
>>>triggers a process to transfer $$ from saving to the checking. But I think this does not fit the BPSS scope.
>>>2) All of the example described above seems to be conditions internal to business systems that are not necessarily be disclosed to the outside. I am also thinking about another aspect of pre-conditions at the business process level as business requirements to do business. For example, one may want to specify that the partner must be ISO-9000 certified or the product sold must not be tested on animal. These could be just for documentation as well. Not sure if this makes sense and in the scope of BPSS.
>>>
>>>I also have a question to whether there are good definitions for what are 'internal/external to the collaboration'? I think it is quite difficult to determine.
>>>- serm
>>>
>>mm1: [1] See special session minutes. Here is a specific excerpt relevant to your message herein:
>>
>>18 June 2004
>>Possible case for endsWhen:
>>[We were discussing the benefit of Acc Ack and its legal and business meanings.]
>>If there is no Acc Ack and I am rejected in 30 seconds when I conduct business with a party, I am in a compromising situation. I could have acted sooner.
>>Messaging layer has acknowledgements with legal meaning as well. Need to qualify statement. What is tested in most cases: receivable and storable for future reference. In this case, we have three options:
>>a. Acceptance signal
>>b. Limit time to reject
>>c. Cause acceptance for long-running responses, require a formal business messages. It may be multiple transactions.
>>In the latter two cases, we may be able to use the endsWhen to apply conditional constraints.
>>
>>Reference: (for full text and context) http://www.oasis-open.org/apps/org/workgroup/ebxml-bp/event.php?event_id=5473&; (under Calendar event for second special session held 25 June 2004).
>>
>>25 June 2004
>>
>>    * ........Take this case, you could place the order regardless (if
>>      inventory available). If a check succeeds, and there is no
>>      inventory, that doesn't mean that inventory doesn't exist. If it
>>      is a premier vendor and I have time constraints, I may place the
>>      order anyway.
>>    * Could translate XPath into a success if a value is greater than
>>      needed value.
>>    * We want to use BPSS to describe the business constraints that a
>>      business person could understand and use a way to have those
>>      constraints evaluated against implementation. The key XPath action
>>      is to determine if you take the transition and if you have
>>      business success and failure.
>>    * It is a core philosophical requirement to succeed.  Legal to
>>      declare a constraint on an action that maps onto information that
>>      is produced on that action. Use beginsWhen and base on content of
>>      the business message that is delivered on that action.
>>    * Constraints on business agreement has to be visible to both
>>      parties and is self-documentating.
>>    * If we put these constraints on beginswhen, it doesn't place undue
>>      burden for monitoring and verification. It only places
>>      choreography constraints.
>>    * Same concepts apply for use with web services. Eventually we
>>      should use the semantic label and have implementers implement a
>>      mapping from semantic tag to the implementation. We could add a
>>      section to map names to implementations that are context aware.
>>      For example, Semantic: Non-zero, third-tier inventory. In the
>>      CPPA, relate that semantic tag to the actual implementation
>>      scheme...........
>>
>>    * ........Case for endsWhen: retryCount and retry: The only reason
>>      is to use if the action repeated in the case of a failure.
>>      endsWhen true and try to retry, you should not retry. For example,
>>      if you have 3 tries to get right; otherwise you fail. In an
>>      academic setting, you try certification three times as a health
>>      care provider. Submit a certification request. Do a registration
>>      step. Submit certification. It is returned and I fail. I then
>>      check my error messages and increase insurance. I get more staff
>>      and I retry. I fail again. I do another action and fail. I then
>>      re-registrer and have to start over again. This is actually a use
>>      case. Look at Amazon self-service registration.
>>    * These attributes are used, when you receive the document, you do
>>      additional checks. It is QoS and evaluate business transaction
>>      status. Status is computed after you receive the document. See how
>>      to compute status values to these conditions......
>>
>>Reference: (for full text and context)
>>http://www.oasis-open.org/archives/ebxml-bp/200406/msg00171.html (It
>>does give a use case for endsWhen too!).
>>