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

RE: Requirements: Decision Points Requirement Proposals

From: Jean-Jacques Dubray <jjd@eigner.com>
Date: Thu, 5 Jun 2003 05:35:59 -0400
To: "'Yaron Y. Goland'" <ygoland@bea.com>, "'WS Chor Public'" <public-ws-chor@w3.org>
Message-ID: <000001c32b45$f5052a00$1a6e100a@JJD>

>>The WS-Chor choreography description format MUST make it possible to
>>specify
>>a role's binding to an actual web service instance either statically,
when
>>a
>>web service using that choreography is deployed, or dynamically at run
>>time.
[JJ] Does this requirement imply that a role can only be bound to one
web service or several web services. IMHO, we need to support multiple
web service binding to one role.

>>
>>The WS-Chor choreography description format MUST provide mechanisms to
>>allow
>>messages to be sent to a particular member of a set of web services in
the
>>same role.
>>[Ed Note: What I'm very inelegantly trying to capture is the idea that
if
>>you are running an auction service and you just found out that one of
the
>>bidders isn't qualified to bid you need a way to say things like "I'm
now
>>going to send out an unsolicited 'get lost you dead beat' message to
one
>>web
>>service that is in the role of bidder." This could then trigger a
whole
>>set
>>of messages back and forth between the auction service and the dead
beat
>>bidder, the choreography needs some way to capture the fact that you
are
>>still talking to the same member of the role group.]
[JJ] Maybe we could say that a role MAY be implemented by more than one
participant in a web service choreography instance. It sounds like an
interesting proposal, but I would like to be convinced that any use case
that require this cannot be implemented by a series of "simple"
choreography that only involve a one-to-one relationship between role
and participants. The "multiple participant scenario" would require that
the initiator of the choreography is able to broadcast a message to a
role, then the run time has to keep track of the individual
conversations with the participants of the same role. Sounds like a
proposition difficult to implement.



>>
>>The WS-Chor choreography description format MUST NOT require that the
>>logic
>>used by a sender in a decision point to decide how to act be exposed
in
>>the
>>choreography.
[JJ] Furthermore, if a web service choreography definition is exposing
some logic as part of a decision point, this logic MUST apply to the
content of messages exchanged during the choreography instance prior to
the decision point.

The decision point expression language MUST be compatible with XML.

>>
>>The WS-Chor choreography description format MUST enable the annotation
of
>>all actions with human readable descriptions.
[JJ] It would be best if these annotations can be XML fragments rather
than text only. It would enable people to add "Commitment Oriented"
semantics (See Bob Haugen's COOL presentation).

>>
>>The WS-Chor choreography description format MUST provide an abstract
>>mechanism where by the logic used to make a decision at a decision
point
>>can
>>be expressed through reference to a WSBPEL abstract or executable
process
>>or
>>similar machine readable logic.
[JJ] I predict that as soon as we will open choreography to "internal"
logic, either it will be identical to the logic on the messages
exchanged during the choreography exchange or it will open a whole set
of issue related to "objects" represented by the messages being
exchanged and their respective state. In other words, a message
typically carries representation of business objects in a given state.
The fundamental question is do we want to expose this to the
choreography definition language (via decision point expression), or is
it enough to express the decision point on the content of the messages.
Orchestration languages need by definition to understand the objects and
their state, however, it is not always clear in current BPM "standards".

JJ-
Received on Thursday, 5 June 2003 05:36:58 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 18 December 2010 01:00:21 GMT