W3C home > Mailing lists > Public > public-ws-chor@w3.org > May 2003

RE: Partial executability/ determinism of a Chor description language

From: Yaron Y. Goland <ygoland@bea.com>
Date: Wed, 28 May 2003 09:53:15 -0400
To: "Ricky Ho" <riho@cisco.com>, <public-ws-chor@w3.org>
Isn't the decision to require the use of a signature a configuration
decision and therefore should be covered with a configuration mechanism and
not in the high level workflow logic?
  -----Original Message-----
  From: public-ws-chor-request@w3.org
[mailto:public-ws-chor-request@w3.org]On Behalf Of Ricky Ho
  Sent: Wednesday, May 28, 2003 3:18 AM
  To: Yaron Y. Goland; public-ws-chor@w3.org
  Subject: RE: Partial executability/ determinism of a Chor description

  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,

  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.


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

      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

      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     (Home: amfletcher@iee.org)
Received on Wednesday, 28 May 2003 12:42:45 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 19:30:05 UTC