Re: Partial executability/ determinism of a Chor description language

I think Assaf is NOT talking about guarantee acceptance at all, NOR about 
disclosing all decision criteria.  For performance optimization or other 
reason, do we need a provide a way where "some" decision criteria can be 
exposed ?

Rgds, Ricky

At 12:30 PM 5/30/2003 -0700, Jon Dart wrote:

>I suppose in this case you could (given the choreography definition, which 
>may contain XPath) simulate the effect of submitting an order, without 
>submitting it, and determine that it wouldn't be accepted. But you 
>couldn't really obtain assurance of acceptance, because there's no 
>guarantee all relevant processing criteria are visible to you (e.g. the 
>seller may reject your order because you have bad credit. You don't know 
>this until the seller does a credit query).
>
>--Jon
>
>Assaf Arkin wrote:
>>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
>>
>>
>
>
>

Received on Friday, 30 May 2003 15:36:57 UTC