RE: Partial executability/ determinism of a Chor description language

David, my comment embedded ....

><DB>Sadly there is difference between the real decision criteria and the
>actual ones. Suppose you have a simple response which results in rejecting
>an order if the goods ordered are "out-of-stock". Sounds OK yes? However the
>seller may have a policy of always saying "out of stock" when stock levels
>are less than 10 so that they can always meet the demands of an important
>customer. The buyer should never know that the seller is making this type of
>decision. Again separate the decision criteria from the results of the
>decision and how it communicated.</DB>

<RH>
Nowhere have I said that the seller MUST expose his "PRIVATE DECISION" to 
the buyer.  If this is a "PRIVATE DECISION", then it is up to the seller to 
decide how much of his decision criteria he want to share for the benefit 
of the buyer, purely from the performance optimization perspective.
In another scenario, the decision criteria may be a "CONTRACT" between the 
buyer and seller.  In this case, one party can sue the other one if the 
contract is breach.
Now whether this contract should be in a separate document is a different 
question.  I don't see why this contract cannot be also specified in the 
choreography definition itself.  As Assaf point out, this contract only 
applies at this particular step in this choreography.
</RH>

><DB>Decisions can only be machine enforceable if there is one "authority"
>that has the power to enforce. As soon as you have two (or more) independent
>businesses, running separate systems, the power to enforce is removed. So
>basically when more than one role is involved, decisions are
>unenforceable.</DB>

<RH>
I disagree.  If the decision is a contract, then either party can verify 
whether the other party has breach it (ie: it is "enforceable").  Whether 
it is "human enforceable" or "machine enforceable" depends on how the 
decision criteria is specified.  If it is XPATH, then it is 
machine-enforceable.  Otherwise, it is human-enforceable by having a person 
read through the message log.
</RH>


>On the other hand, do we have other situations that no single party owns
>the decision.  Lets say I withdraw money from my bank account.  Then there
>should be a common decision criteria (if I have sufficient fund in my
>account, then the withdrawal must be successful).
><DB>Maybe, but suppose you are behind on your mortgage payments, the bank
>(in its fine print) may have legal right to freeze your funds.</DB>

<RH>
In this case, then an additional decision criteria "MUST have good credit 
history" should also be added.  The bank can keep adding more criteria but 
it must be exposed to me. (as long as this decision criteria is a "contract")
</RH>


>In other words, the
>decision criteria is part of the contract between me and my bank in our
>choreography.  It is certainly not a private or "one-party" decision.
><DB>I disagree the bank has complete control. Ultimately you cannot force
>the bank to make a payment to you unless you take them to court to enforce
>the agreement. Also, this would only work if you working within the terms of
>the agreement.</DB>

<RH>
What do I show to the court unless the contract is well-specified ?  Why 
can't the choreography definition itself be the contract ?  Why a separate 
document is needed ?
</RH>


>In both cases, decision QName can be completely opaque and Yaron's
>suggestion of using a text description of the decision completely fufill
>the bare minimum requirement; "do-nothing" because nothing can be
>done.  But if we allow the decision QName be "optionally" has an associated
>XPATH expression (which can be at another message binding level as David
>suggest), then more automated checking can be done.  In other words, I
>suggest XPATH should be "optional", not required but also not excluded.
><DB>I also think that you need a Qname, but I think it should be the Qname
>of the state which is the result of making the decision rather than the
>QName that identifies *how* a decision is made.</DB>

<RH>
You don't need the QName to communicate the decision outcome.  The outcome 
will be communicated from subsequent messages being exchanged.

Let me give an example:

if (qname:hasEnoughFund)
         then
                 send fund-transfer-command
         else
                 send reject message

After the QName is defined, there are three options .....

Option 1 -- Nothing is binded to the QName.
=================================
Do nothing because nothing can be done.  Still meeting the "minimum 
requirement" as Assaf suggested.

Option 2 -- A 30 page legal text document is binded to the QName
=================================================
hasEnoughFund = "www.bank.com/legalAgreement.pdf"
In this case, the contract is "human enforceable".  I can trace through the 
message log to discover whether the bank has breach the contract.  If so, I 
can printout the PDF file and bring that to the court.

Option 3 -- An XPATH is binded to the QName
==================================
hasEnoughFund = "/Request/@fundAmount < $BankAccount/@totalBalance"
In this case, the contract is "machine enforceble".  I can have an 
automated software that correlate the withdrawal rejection to the decision 
conditions and detect whether the bank has breach the contract.  If so, I 
can printout my choreography (which also has the XPATH) and my message log 
to the court.

</RH>


Best regards,
Ricky

Received on Saturday, 31 May 2003 01:52:37 UTC