Re: Partial executability/ determinism of a Chor description language

Assaf, very good points that you've brought.

If there is a clear picture about who (a particular role) is deciding at 
each decision point, then it is up to that decision maker to determine if 
he wants to share his decision criteria to other partners.  It is also up 
to other partners how to make use of that information, in a minimum, do 
nothing as you said.  In other words, the decision doesn't need to be 
machine-enforcable.

On the other hand, do we have other situations that no single party owns 
the decision.  Lets say I withdraw money from my bank account.  Then there 
should be a common decision criteria (if I have sufficient fund in my 
account, then the withdrawal must be successful).  In other words, the 
decision criteria is part of the contract between me and my bank in our 
choreography.  It is certainly not a private or "one-party" decision.

In both cases, decision QName can be completely opaque and Yaron's 
suggestion of using a text description of the decision completely fufill 
the bare minimum requirement; "do-nothing" because nothing can be 
done.  But if we allow the decision QName be "optionally" has an associated 
XPATH expression (which can be at another message binding level as David 
suggest), then more automated checking can be done.  In other words, I 
suggest XPATH should be "optional", not required but also not excluded.

Best regards,
Ricky

At 11:31 AM 5/29/2003 -0700, Assaf Arkin wrote:
>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 12:28:46 UTC