RE: Partial executability/ determinism of a Chor description lan guage

Jon

To answer your questiuon, here's my $0.02c on what I think our objectives
should be:
1. Choreographies are NOT directly executable - you can't load a
choreography into some software and run it
2. Choreographies CAN be used to automatically validate that a process is
following a choreography.
3. Choreographies are NOT bound to any specific data or message content
4. An executlable process definition can be created from a choreography by:
  a) Extracting from a choreography definition, the interactions, states,
etc, associated with SINGLE role, then 
  b) Expanding that data into an executablke process by including the
"private" processing and decision logic required.

David

-----Original Message-----
From: Jon Dart [mailto:jdart@tibco.com]
Sent: Friday, May 30, 2003 2:19 PM
To: public-ws-chor@w3.org
Cc: public-ws-chor@w3.org
Subject: Re: Partial executability/ determinism of a Chor description
language



I agree Assaf's use case doesn't really lead to a *requirement* that 
(some) decision points be expressed via executable expressions.

The question may come down to, is this facility the preferred way to 
solve a certain class of problems?

Some of the past arguments against executability include:

1. It makes the public side of the choroegraphy more complex to parse 
and understand.

2. (Related to 1). It makes automated tools that run against the public 
choroegraphy more difficult (impossible?) to implement.

3. It doesn't provide a good separation between interface and 
implementation. (But maybe this is good, if you think the separation is 
arbitrary anyway).

N.b. I'm not actually putting forward these objections .. I'm just 
re-stating them.

One of the problems I'm having evaluating the various proposals for 
solving this problem is that relatively few people are actually doing 
this kind of automated interaction at present. It is easy to find use 
cases that involve complex interaction of business partners. It is a 
little harder IMO to turn those into plausible scenarios involving 
automation of the interaction.

--Jon

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.
> 
> 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.
> 
> 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
> 
> 
> 
> 
>