Relationship cardinalities (was ... RE: Requirements: Decision Po ints Requirement Proposals

JJ said ...

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

Here's *my* take on the cardinality of some of the relationships associated
with choreographies. The list comes first then it's repeated with
explanations ...

1. A role may take part in one or more choreographies
2. A message is sent from one role to one other role
3. A choreography involves two or more roles
4. A choreography specifies the sequence, conditions and dependencies of
sending one or more messages
5. A choreography must send each message at least once.
6. A message may be used by one or more choreography definitions.
7. A role's state is changed by sending, receiving or processing a message.
8. The sending of the same message may result in different changes of state
9. A change in a role's state may cause a role to send one or more messages
10. A change in a roles state may cause a role to execute a process
11. A process is executed by a single role
12. A role may execute multiple processes.
13. A choreography definition may be dependent on the execution of another
choreography definition
14. A choreography definition may be composed from other choreography
definitions.

There are also some relationships associated with the binding of a
choreography to a (web service), for example
1. An operation can accept or generate zero or more messages
2. A message may have one or more physical representations
3. A web service can support zero or more choreographies (or parts of
choreographies)
4. A choreography is supported by one or more web services
5. A process may be implemented by one or more (web) services
6. A web service may implement zero or more processes

... and here's the list with explanations ....

CHOREOGRAPHY RELATED
1. A role may take part in one or more choreographies
For example a buyer there are several different ways of placing orders that
involve different sequences of messages. However the basic role stays the
same.

2. A message is sent from one role to one other role
A message is always sent from one role, e.g. a buyer, to another, e.g. a
seller. I can't think of a use case where it makes sense to have the same
role as sender and receiver of a message.

3. A choreography involves two or more roles
As choreographies involve sending messages and each message involves two
roles this must be true.

4. A choreography specifies the sequence, conditions and dependencies of
sending one or more messages
This is really the core of what choreographies are all about. The only
question I would have is whether this is compatible with the ideas of
pi-calculus, and if it isn't does it matter?

5. A choreography must send each message at least once.
This is because you don't really want to litter choreography definitions
will definitions of messages that are not used.

6. A message may be used by one or more choreography definitions.
For example, there are many different ways you can place an order. However
the semantics and content of the order document can be the same. This
probably means that any choreography definition we come up with needs to
include the idea of importing or including message definitions.

7. A role's state is changed by sending, receiving or processing a message.
If we want to follow a "state machine" approach, then the sending, receiving
or processing of a message should result in some state change. However, the
states that are included in the choreography definition should only be the
ones that affect the choreography flow. The others are private "decision
points".

8. The sending of the same message may result in different changes of state
Sometimes the same message can have different meanings. For example, an
"order response" message sent by a supplier to a buyer could mean:
- the order's OK,
- the order's partially OK, but I can't satisfy all of it, or
- the order's rejected, for some reason.
These have a material effect on the choreography, however the message
definition is actually the same. Now you could argue that there should be
different messages for each reason, but often real existing messages aren't
like that and one document and therefore one message is used for multiple
purposes. This means that you need some way of specifying the material
differences where needed.

9. A change in a role's state may cause a role to send one or more messages
The simple use case is where you receive a message and it is processed which
results inh a change of state. However the result of the process is an error
state which means that an error message MUST be returned according to the
rules of the choreography. 

10. A change in a roles state may cause a role to execute a process.
For example if a message arrives, which results in a state change, then the
message should be processed.

11. A process in a choreography is executed by a single role
If a process is split over multiple roles, then you need a choreography to
define the interactions which defeats the purpose of specifying the roles.

12. A role may execute multiple processes.
This is a corollary of a role being able to accept multiple messages. Each
message will need to be examined by a process.

13. A choreography definition may be dependent on the execution of another
choreography definition
For example, you can only do a choreography to do a query on the status of
processing of an earlier choreography if there is an earlier choreography
that can be referenced.

14. A choreography definition may be composed from other choreography
definitions.
For example you might want to compose an order+invoice choreography from an
existing order choreography and an existing invoice choreography.

CHOREOGRAPHY BINDING RELATED
1. An operation can accept or generate zero or more messages
This is the key implementation binding since (abstract) messages in
choreographies need to bound to particular input/output messages in service
implementations.

2. A message may have one or more physical representations
This is the idea of reusability. You don't want to have to create a new
definition of a sequence of exhanging messages if all that has changed is
the detail of the format as it would lead to an explosion of choreography
definitions. The logical consequence of this might be that a single service
operation can accept multiple different messages, although ideally they
should be in the same message family.

3. A web service can support zero or more choreographies (or parts of
choreographies)
This is the consequence of an operation supporting multiple messages as the
same operation could support the same message in multiple choreographies.
You can imagine a use case where there are say four different choreographies
for placing an order but the actual order is always sent to the same
service.

4. A choreography is supported by one or more web services
This comes about because different implementations may chose different
services to support a choreography.

5. A process may be implemented by one or more (web) services
A process is operated by a role and is implemented by services. These can be
web services, for example an SalesOrderManagement service. Note that the
mapping of services to processes can vary by implementation. A process can
also tie into a BPEL process definition.

6. A web service may implement zero or more processes
For example you could have a product price check query that is a
choreography that is a stand-alone query for checking prices. You could also
have the same exchange of messages in a choreography acts as a price quote.

Thoughts .......

David

-----Original Message-----
From: Jean-Jacques Dubray [mailto:jjd@eigner.com]
Sent: Thursday, June 05, 2003 2:36 AM
To: 'Yaron Y. Goland'; 'WS Chor Public'
Subject: RE: Requirements: Decision Points Requirement Proposals



>>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 Monday, 9 June 2003 14:34:32 UTC