Re: Partial executability/ determinism of a Chor description language

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:30:27 UTC