RE: Partial executability/ determinism of a Chor description language

Assaf

See comments in line.

David

-----Original Message-----
From: Assaf Arkin [mailto:arkin@intalio.com]
Sent: Friday, May 30, 2003 2:05 PM
To: Burdett, David
Cc: Ricky Ho; Yaron Y. Goland; public-ws-chor@w3.org
Subject: Re: Partial executability/ determinism of a Chor description
language


Burdett, David wrote:

>Assaf
>
>The fact that a supplier rejects international orders can be thought of in
>two ways:
>1. As a policy - i.e. the supplier has a policy of rejecting international
>order
>2. As a decision - made by the supplier software at run time.
>
>You can also think that the decision in the suppliers software is actually
>nothing more than an implementation of the supplier policy.
>  
>
Let's call it a policy then. I really don't care what the supplier 
software does at run-time or how it evaluates the policy. The actual 
ruleset will account for more details and would probably contain the 
policy but include additional rules. Not interesting to me.

But the policy is. So if I can agree on the policy, can I at least 
determine where the policy takes effect? Obviously just knowing the 
policy is not very interesting, afterall the policy does not apply to 
invoicing or account withdrawals. It applies to a specific set of 
choreographies and even there in specific places.

<DB>I think it more likely that the policies will most often apply to
services rather than choreographies. For example the "no international
orders" policy could apply to *all* orders. The actual choreography used to
place the order is irrelevant.</DB>

>There is also a requirement for the buyer to discover the fact that
>international orders are rejected. There are two main ways of doing this:
>1. Examine the policy information in a registry or directory somewhere - if
>it exists,
>2. Send an order to find out if it will be rejected (not a good idea
really)
>
>Either way works and actually the choice is really an implementation
>decision.
>
>So instead of saying "there is some benefit to knowing which decision is
>being made", I would say that all you need to be ablt to do is know what
the
>possible outcomes of sending a message can be.
>
If I know what the possible outcome is, which I should know in any case, 
then I'm down to option #2 - send an order and discover what happens, 
which you say is not a good idea. If I know the policy that applies then 
I can determine that one outcome is eventual before sending the message. 
So is there a benefit to knowing the policy or not?
<DB>Yes there is. But it is only really relevant to your internal business
process (or orchestration) rather than to the choreography because
ultimately only the sender of the order and nobody but the sender of the
order can decide whether or not to send the order - it's a private
process.</DB>

arkin


>
>David
>
>
>
>-----Original Message-----
>From: Assaf Arkin [mailto:arkin@intalio.com]
>Sent: Friday, May 30, 2003 12:04 PM
>To: Burdett, David
>Cc: Ricky Ho; Yaron Y. Goland; public-ws-chor@w3.org
>Subject: Re: Partial executability/ determinism of a Chor description
>language
>
>
>Let's assume this refinement of the use case given by Ricky.
>
>The buyer sends quote requests to three different suppliers, obtains the 
>results, and decides which one supplier to obtain the product from. The 
>decision criteria is called decision X. The buyer has absolutely no 
>intention whatsoever to disclosed decision X to the world. The buyer is 
>perfecly fine saying 'my decision X', but not providing any more 
>meaningful information.
>
>The supplier decides whether or not to accept the order. That decision 
>is called decision Y. Let's assume a more trivial example whereby some 
>suppliers do not support international orders for whatever reason.
>
>The buyer goes into the process of identifying a buyer, the cheapest one 
>of the bunch for that particular product, constructing a PO and sending 
>it to the buyer. Due to technical issues the response comes back 4 hours 
>later. The response says "RTFM - international orders not supported 
>here". The buyer understands why the order was rejected (a common error 
>code), but has just wasted 4 hours waiting for that response. Had the 
>buyer read the FM upfront the buyer would not even have selected that 
>particular supplier. The buyer then goes to the second supplier, 
>unfortunately with the same effect (it seems that all good deals are not 
>available internationally).
>
>Now let's change it slightly. Let's assume that the supplier can, along 
>with all other information indicating it's willingness to participate in 
>the choreography, indicate that one of the rules for decision Y is that 
>'no international orders are accepted'. Let's say there's a common way 
>to express it, which may or may not be an XPath expression, and a place 
>to say it. Now the buyer has the option to actually RTFM by not 
>selecting that supplier up front. So instead the buyer only selects the 
>suppliers that can actually fulfill the purchase order, selects the best 
>one, and starts talking to that supplier directly.
>
>So there is some benefit to knowing which decision is being made, so 
>that in some cases - in this scenario Y but not X, for some suppliers 
>but not all, for some buyers but not all - it is possible to determine 
>the outcome before sending the message saving money by not starting any 
>transaction that is doomed to fail. Is there a benefit in that capability?
>
>arkin
>
>
>Burdett, David wrote:
>
>  
>
>>Following on from this, in practice you would need to have error codes 
>>in the return message that included one for "badlist" country. To 
>>realize interoperability, the error codes that could be present in the 
>>message data should be published in advance. In this case the sender 
>>should already know that orders from a badlist country would not be 
>>accepted.
>> 
>>I don't see what this has to do with choreography ... or am I missing 
>>something.
>> 
>>David
>>    
>>
>
>  
>