Re: Partial executability/ determinism of a Chor description language

David,

You are citing a lot of good cases for when saying anything about the 
decision is useless. Factoring that capability into the language for 
these usescases is, to put it mildy, pointless.

But what about other use cases?

In the case which I cited you can tell up front that the message is 
rejected. I do not care if my message is sent, is accepted and an order 
delivered internationally even though the supplier said it would not do 
so. But I expect that in most cases if the supplier said it would be 
rejected it would, and being able to avoid such suppliers up-front seems 
beneficial.

I definitely cannot force my bank to do anything, but my bank advertises 
a lot of its rules up-front. When I open an account or sign for a 
service I get a booklet explaining a lot of rules. You can't withdraw 
unless withdrawAmount<=balance is one of them. You will be charged $X 
for returned check another one. Are we saying that the choreography 
language should not in anyway reference such rules, even though they are 
known and well defined?

arkin

Burdett, David wrote:

>Ricky
>
>See comments in line below.
>
>David
>
>-----Original Message-----
>From: Ricky Ho [mailto:riho@cisco.com]
>Sent: Friday, May 30, 2003 9:28 AM
>To: Assaf Arkin
>Cc: public-ws-chor@w3.org
>Subject: Re: Partial executability/ determinism of a Chor description
>language
>
>
>
>Assaf, very good points that you've brought.
>
>If there is a clear picture about who (a particular role) is deciding at 
>each decision point, then it is up to that decision maker to determine if 
>he wants to share his decision criteria to other partners.  
><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>
>
>It is also up to other partners how to make use of that information, in a
>minimum, do nothing as you said.  In other words, the decision doesn't need
>to be machine-enforcable.
><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>
>
>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>
>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>
>
>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>
>
>Best regards,
>Ricky
>
>At 11:31 AM 5/29/2003 -0700, Assaf Arkin wrote:
>  
>
>>I think the absolute requirement is that you are able to specify who 
>>decides what. Forget about the how for a second.
>>
>>When A and B interact with each other and reach a fork in the road, from 
>>which they can go one of several paths, the question now becomes who makes 
>>the decision. If it's the first participant to decide we get into 
>>interesting race conditions. We may have wonderful technologies to deal 
>>with race condition, but the reality is that businesses try to avoid these 
>>problems by trying to work out their issues up front. You work out these 
>>issues by agreeing who decides at what point.
>>
>>If you look at the order accepted/rejected case we are so fond of 
>>discussing, then the buyer and seller agreeed up front that the seller 
>>would make a decision at this particular point. They have not agreed what 
>>decision will be made in each and every case, though they both hope it 
>>would end up being more acceptance then rejection. And they may not agree 
>>how the decision is made.
>>
>>The ability to model "the decision I make" vs "the decision I abide to" is 
>>an important part of the choreography definition.
>>
>>
>>As for how the decision is made, we have three options:
>>
>>1. Absolutely no detail whatsoever.
>>
>>2. All the information in each and every case.
>>
>>3. No information unless when otherwise specified.
>>
>>The way I look at it, option #3 is like having an online service with 
>>documentation to go along with it. Option #2 is like having an online 
>>service with no documentation. In either case you have the exact same 
>>online service, which is what the group focuses about. The fact that in 
>>some cases some vendors would also like to include additional 
>>documentation should supported, if it can be done without 
>>breaking/complicating/obfuscating the online service. Can it be done?
>>
>>
>>My suggestion is have the following minimal capability in the choreography 
>>language:
>>
>>- Use QNames to name decisions
>>
>>Any implementation of the specification would have at the minimum to meet 
>>the following requirements:
>>
>>- Do nothing about it.
>>
>>For me this appears like a good solution. Those who have absolutely no 
>>interest in ever defining, parsing, contemplating or alphabetizing 
>>decisions that are part of the choreography definition have to do nothing 
>>to fully conform with the spec (see requirement above). Those who have an 
>>interest in augmenting the choreography definition with additional 
>>definitions have a mechanism to do so, and can easily figure out a 
>>solution to allow such information to be shared/used.
>>
>>Can this be considered a compromise that is acceptable to everyone?
>>
>>arkin
>>
>>
>>Ricky Ho wrote:
>>
>>    
>>
>>>I think there are 2 kinds of decision logic ...
>>>
>>>1) Private decision that I want to keep secret
>>>E.g. If you send me a PO, I will either accept it or reject it.  But I 
>>>don't want to share with you how I decide.
>>>
>>>2) Public decision that I want my partners to know about
>>>E.g. If you send me a PO, I want to tell you that I will reject your PO 
>>>message if you don't have a valid signature.
>>>
>>>I think WS-Chor should cover the later but not the former.  But I don't 
>>>think expressing an XPATH necessary mean exposing private decision.  You 
>>>may intentionally want to expose your decision criteria to your partners 
>>>so they don't waste time to prepare something invalid.
>>>
>>>Best regards,
>>>Ricky
>>>
>>>At 09:11 PM 5/27/2003 -0400, Yaron Y. Goland wrote:
>>>
>>>      
>>>
>>>>My personal preference is that nothing be said in the cDl about how the 
>>>>message is to be processed. E.g. nothing is ever said about the contents 
>>>>of the message and decisions made on those contents. This is exactly 
>>>>what BPEL in general and BPEL abstract processes in particular are 
>>>>intended for. They provide direct insight into how a participant makes a 
>>>>decision at whatever level of detail one cares to share.
>>>>
>>>>The cDl on the other hand describes just the global behavior without 
>>>>insight into a particular process. That is its key distinction with 
>>>>regards to BPEL. If this group chooses to go down the path of providing 
>>>>the type of message based execution decision described below inside of 
>>>>the cDl then the working group will be taking a position that puts it 
>>>>into direct competition with BPEL.
>>>>
>>>>There is nothing in the group's charter that says 'thou shalt avoid 
>>>>competing with BPEL' and perhaps our best technical needs will be met by 
>>>>such a competition. I personally do not believe so and have explained my 
>>>>reasoning in my use case/requirements document. But if we do decide to 
>>>>provide insight into the internals of a process's execution we should do 
>>>>so with a clear understanding that we are talking a position in direct 
>>>>competition with BPEL.
>>>>
>>>>    Thanks,
>>>>
>>>>        Yaron
>>>>
>>>>    -----Original Message-----     From: public-ws-chor-request@w3.org
>>>>    [mailto:public-ws-chor-request@w3.org]
>>>>    <mailto:public-ws-chor-request@w3.org%5DOn>On
>>>>    <mailto:public-ws-chor-request@w3.org%5DOn> Behalf Of Fletcher, 
>>>>Tony     Sent: Thursday, May 22, 2003 2:41 AM     To: 
>>>>public-ws-chor@w3.org     Subject: Partial executability/ determinism 
>>>>of a Chor description
>>>>    language
>>>>
>>>>    Dear Colleagues,
>>>>
>>>>    I would like to clarify in my own mind and continue a discussion
>>>>    o the degree to which a Choreography description language (CDL)
>>>>    is deterministic or 'executable'.  I think this issue links to
>>>>    previous threads on the use of information from messages, or 
>>>>not.
>>>>    I think we all agree that a CDL will only give a very partial
>>>>    description of the behaviour of any 'entity' playing a particular
>>>>    role (and that you do need a full programming language such as
>>>>    Java or C#  for any sort of 'complete' description.
>>>>    However, consider the following:
>>>>    Role A sends message 1 to role B
>>>>    Role B replies with message 2 to role A
>>>>    At this point there may now be say three different messages that
>>>>    A could next send to B according to the CDL instance and given no
>>>>    other information.
>>>>    Now suppose that message 1 was an order message and message 2 an
>>>>    order response with a critical information field that says
>>>>    'accept' or 'reject'.
>>>>    The CDL could now say that role A can examine the incoming
>>>>    message 2 extract the semantic accept or reject and if reject
>>>>    then send message 3 else send message 4 or message 5 (means of
>>>>    determining which is not shown in this CDL instance, but would be
>>>>    in the CPL for that role).
>>>>    Without being dependent on the precise syntax of messages, only
>>>>    some of the semantic elements, I think that some people in this
>>>>    group would like the above behaviour to be supported by the
>>>>    WS-Chor language and thus support for this behaviour to be a
>>>>    requirement.
>>>>    Others seem to be arguing for no dependence on message content at
>>>>    all - perhaps just the name of the message received(?).  Can we
>>>>    reach an amicable consensus?
>>>>    Best Regards     Tony     A M Fletcher
>>>>    Cohesions 1.0 (TM)
>>>>    Business transaction management software for application
>>>>    coordination
>>>>    Choreology Ltd., 13 Austin Friars, London EC2N 2JX     UK     Tel: 
>>>>+44 (0) 20 76701787   Fax: +44 (0) 20 7670 1785  Mobile: +44
>>>>    (0) 7801 948219     tony.fletcher@choreology.com
>>>>    <mailto:tony.fletcher@choreology.com>     (Home: 
>>>>amfletcher@iee.org)
>>>>        
>>>>
>>
>>    
>>

Received on Friday, 30 May 2003 17:01:16 UTC