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

["David RR Webber" <david@drrw.info>]

Monica,

The new mechanism described by John on todays' call moves this whole
forward.

Essentially you can declare variables in a BPSS header - that then act
as switches to some condition that needs to be tested.

So - isTestedOnAnimals = "false" could be a reason to accept a
product in a beginsWhen - and then you would specify the
XPath expression to actually determine if this variable is true or
false.  In the ebContext approach - this variable name is then
used to reference that instance of the XPath expression - John
described other details on this for within the BPSS too.

At this point we're waiting on John and Dale to complete changes
to the Schema so we then work on examples to show how
this really works in practice.

Conceptually however - based on John's description on the call -
it would appear that we have resolution forthcoming on this
coupling that Serm is wanting to understand.

Thanks, DW.

----- Original Message ----- 
From: "Monica J. Martin" <Monica.Martin@Sun.COM>
To: "ebXML BP" <ebxml-bp@lists.oasis-open.org>; "Yunker, John"
<yunker@amazon.com>
Sent: Monday, July 12, 2004 7:58 PM
Subject: [Fwd: Re: [ebxml-bp] [ebBP] 6/28/2004: Work Item 21 - Summary for
Conditional Constraints-beginsWhen, endsWhen!!]


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!).
>>