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

a good start at a meta model i think.
Some comments:

> 1. A role may take part in one or more choreographies

see my email about roles and parties

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

The choreography doesn't send anything! Its the participants that do!

> 6. A message may be used by one or more choreography definitions.

I think you mean message defintion/type here - an actual message can only be
part of one choreography

> 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

but the choreography should define the possible states and state
transitions?

> 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

So either this is declared and becomes part of a composition relationship
(14) or this point is mute (i.e.
its not relevent to the chorei language)


> 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

should be the same as wsdl (just in case it isnt!)
> 2. A message may have one or more physical representations

as per wsdl
> 3. A web service can support zero or more choreographies (or parts of
> choreographies)

im not sure this needs to be said or makes sense. Do you mean instance of a
web service, or type ????

> 4. A choreography is supported by one or more web services

what does is supported mean?
<mc end>

> 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 17:40:08 UTC