Re: Partial executability/ determinism of a Chor description language

I think the absolute requirement is that you are able to specify who 
decides what. Forget about the how for a second.

When A and B interact with each other and reach a fork in the road, from 
which they can go one of several paths, the question now becomes who 
makes the decision. If it's the first participant to decide we get into 
interesting race conditions. We may have wonderful technologies to deal 
with race condition, but the reality is that businesses try to avoid 
these problems by trying to work out their issues up front. You work out 
these issues by agreeing who decides at what point.

If you look at the order accepted/rejected case we are so fond of 
discussing, then the buyer and seller agreeed up front that the seller 
would make a decision at this particular point. They have not agreed 
what decision will be made in each and every case, though they both hope 
it would end up being more acceptance then rejection. And they may not 
agree how the decision is made.

The ability to model "the decision I make" vs "the decision I abide to" 
is an important part of the choreography definition.


As for how the decision is made, we have three options:

1. Absolutely no detail whatsoever.

2. All the information in each and every case.

3. No information unless when otherwise specified.

The way I look at it, option #3 is like having an online service with 
documentation to go along with it. Option #2 is like having an online 
service with no documentation. In either case you have the exact same 
online service, which is what the group focuses about. The fact that in 
some cases some vendors would also like to include additional 
documentation should supported, if it can be done without 
breaking/complicating/obfuscating the online service. Can it be done?


My suggestion is have the following minimal capability in the 
choreography language:

- Use QNames to name decisions

Any implementation of the specification would have at the minimum to 
meet the following requirements:

- Do nothing about it.

For me this appears like a good solution. Those who have absolutely no 
interest in ever defining, parsing, contemplating or alphabetizing 
decisions that are part of the choreography definition have to do 
nothing to fully conform with the spec (see requirement above). Those 
who have an interest in augmenting the choreography definition with 
additional definitions have a mechanism to do so, and can easily figure 
out a solution to allow such information to be shared/used.

Can this be considered a compromise that is acceptable to everyone?

arkin


Ricky Ho wrote:

> I think there are 2 kinds of decision logic ...
>
> 1) Private decision that I want to keep secret
> E.g. If you send me a PO, I will either accept it or reject it.  But I 
> don't want to share with you how I decide.
>
> 2) Public decision that I want my partners to know about
> E.g. If you send me a PO, I want to tell you that I will reject your 
> PO message if you don't have a valid signature.
>
> I think WS-Chor should cover the later but not the former.  But I 
> don't think expressing an XPATH necessary mean exposing private 
> decision.  You may intentionally want to expose your decision criteria 
> to your partners so they don't waste time to prepare something invalid.
>
> Best regards,
> Ricky
>
> At 09:11 PM 5/27/2003 -0400, Yaron Y. Goland wrote:
>
>> My personal preference is that nothing be said in the cDl about how 
>> the message is to be processed. E.g. nothing is ever said about the 
>> contents of the message and decisions made on those contents. This is 
>> exactly what BPEL in general and BPEL abstract processes in 
>> particular are intended for. They provide direct insight into how a 
>> participant makes a decision at whatever level of detail one cares to 
>> share.
>>  
>> The cDl on the other hand describes just the global behavior without 
>> insight into a particular process. That is its key distinction with 
>> regards to BPEL. If this group chooses to go down the path of 
>> providing the type of message based execution decision described 
>> below inside of the cDl then the working group will be taking a 
>> position that puts it into direct competition with BPEL.
>>  
>> There is nothing in the group's charter that says 'thou shalt avoid 
>> competing with BPEL' and perhaps our best technical needs will be met 
>> by such a competition. I personally do not believe so and have 
>> explained my reasoning in my use case/requirements document. But if 
>> we do decide to provide insight into the internals of a process's 
>> execution we should do so with a clear understanding that we are 
>> talking a position in direct competition with BPEL.
>>  
>>     Thanks,
>>  
>>         Yaron
>>
>>     -----Original Message----- 
>>     From: public-ws-chor-request@w3.org
>>     [mailto:public-ws-chor-request@w3.org]
>>     <mailto:public-ws-chor-request@w3.org%5DOn>On
>>     <mailto:public-ws-chor-request@w3.org%5DOn> Behalf Of Fletcher, Tony 
>>     Sent: Thursday, May 22, 2003 2:41 AM 
>>     To: public-ws-chor@w3.org 
>>     Subject: Partial executability/ determinism of a Chor description
>>     language
>>
>>     Dear Colleagues,
>>       
>>     I would like to clarify in my own mind and continue a discussion
>>     o the degree to which a Choreography description language (CDL)
>>     is deterministic or 'executable'.  I think this issue links to
>>     previous threads on the use of information from messages, or not. 
>>       
>>     I think we all agree that a CDL will only give a very partial
>>     description of the behaviour of any 'entity' playing a particular
>>     role (and that you do need a full programming language such as
>>     Java or C#  for any sort of 'complete' description. 
>>       
>>     However, consider the following: 
>>       
>>     Role A sends message 1 to role B 
>>       
>>     Role B replies with message 2 to role A 
>>       
>>     At this point there may now be say three different messages that
>>     A could next send to B according to the CDL instance and given no
>>     other information. 
>>       
>>     Now suppose that message 1 was an order message and message 2 an
>>     order response with a critical information field that says
>>     'accept' or 'reject'. 
>>       
>>     The CDL could now say that role A can examine the incoming
>>     message 2 extract the semantic accept or reject and if reject
>>     then send message 3 else send message 4 or message 5 (means of
>>     determining which is not shown in this CDL instance, but would be
>>     in the CPL for that role). 
>>       
>>     Without being dependent on the precise syntax of messages, only
>>     some of the semantic elements, I think that some people in this
>>     group would like the above behaviour to be supported by the
>>     WS-Chor language and thus support for this behaviour to be a
>>     requirement. 
>>       
>>     Others seem to be arguing for no dependence on message content at
>>     all - perhaps just the name of the message received(?).  Can we
>>     reach an amicable consensus? 
>>       
>>     Best Regards     Tony 
>>     A M Fletcher 
>>       
>>     Cohesions 1.0 (TM) 
>>       
>>     Business transaction management software for application
>>     coordination 
>>       
>>     Choreology Ltd., 13 Austin Friars, London EC2N 2JX     UK 
>>     Tel: +44 (0) 20 76701787   Fax: +44 (0) 20 7670 1785  Mobile: +44
>>     (0) 7801 948219 
>>     tony.fletcher@choreology.com
>>     <mailto:tony.fletcher@choreology.com>     (Home: amfletcher@iee.org) 
>>       
>>

Received on Friday, 30 May 2003 02:43:20 UTC