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

Martin

See comments in line.

David

-----Original Message-----
From: Martin Chapman [mailto:martin.chapman@oracle.com]
Sent: Monday, June 09, 2003 2:40 PM
To: Burdett, David; 'Jean-Jacques Dubray'; 'Yaron Y. Goland'; 'WS Chor
Public'
Subject: 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
<DB>See my reply</DB>

> 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!
<DB>I totally agree. The above is really an abbreviated way of saying "Each
message definition specfified in a Choreography Defintion MUST identify, by
reference, the sending of each message at least once.</DB>

> 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
<DB>Absolutely, for brevity, I was using the term message colloqually. I
actually think that it should be a Message family as there can be three
levels of messages:
1. A Message Family which identifies a set of messages that serve the same
purpose, for example a RosettaNet Order, a UBL Order, an EDI Order, etc
would all be part of the same "Order" message family
2. A Message Type, which identifies the structure of a particular message,
for example the structure of a RosettaNet Order OR the structure of a UBL
order.
3. A Message Instance (or just Message) which is an instance of a Message
Type that is transported over the wire between parties taking roles.
</DB>

> 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?
<DB>Agreed.</DB>

> 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)
<DB>Not sure it is mute, as you could have one choreography that can validy
exist on its own. For example the good 'ol order placement choreography. You
could then separately have an "Order Status Inquiry" choreography that can
only be executed if the it references the Order Placement choreography.</DB>

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