RE: Partial executability/ determinism of a Chor description lang uage

Yaron
 
You said ...
 
>>>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. <<<
 
Yes, but, you have to include in the CDl the fact that the message IS
processed even though you don't say HOW. You also need to specify WHAT the
outcomes of that process are, e.g. the Order is either Accepted or Rejected,
but you don't say HOW that information is represented.
 
If you identify that: a) a process exists, and b) define the outcome of the
process, you can then a) map the process in the CDl to an actual process
perhaps, but not necessarily, defined using BPEL, and b) map the outcomes of
the process in the cDL to messages or data produced by the actual process,
for example using XPath.
 
So now we have:
1. A CDL defines the "what", and
2. A "Binding" that maps the "what" to the "how".
 
The question is where does the binding go. Options are:
1. An extension to the CDL
2. As a separate document
 
I *strongly* prefer the latter as it will make reuse easier as well as allow
alternative bindings to be developed. However, what I think we MUST do is
define how to do a binding of a CDL to WSDL.
 
David

-----Original Message-----
From: Yaron Y. Goland [mailto:ygoland@bea.com]
Sent: Tuesday, May 27, 2003 6:12 PM
To: Fletcher, Tony; public-ws-chor@w3.org
Subject: RE: Partial executability/ determinism of a Chor description
language


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]On
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)