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

I agree with all of these.  But I don't see why allowing a "public decision 
criteria" specified at the choreography violate any of these.

Rgds, Ricky

At 02:44 PM 5/30/2003 -0700, Burdett, David wrote:

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