Cómo navegar por el SitioCómo usar el GlosarioCómo usar las Preguntas-FrecuentesCómo buscar en el SitioAcerca del SitioDeclaración acerca del contenido del Sitio
Figure 9.18 depicts 13 distinct Conversations between collaborating
Participants in a logistics domain. As examples, Retailer and Supplier are
involved in a Delivery Negotiations Conversation, and Consignee converses
with Retailer and Supplier through Delivery/Dispatch Plan and Shipment
Schedule Conversations respectively. More than two participants MAY be
involved in a Conversation, e.g., Consignee, Consolidator and Shipper in
Detailed Shipment Schedule. The association of Participants to a
Conversation are constrained to indicate whether one or many of Participants
are involved. For example, one instance of Retailer converses with one
instance of Supplier for Deliver Negotiations. However, one instance of
Shipper converses with multiple instances of Carrier (indicated by the
multiinstance symbol of the Pool for Carrier) for Carrier Planning. Note,
multiplicity in constraints of Conversation diagrams means one or more (not
zero or more).
The behavior of different Conversations is modeled through separate
Choreographies, detailing the Message exchange sequences. In practice,
Conversations which are closely related could be combined in the same
Choreography models. For example, a Message exchange in the Delivery
Negotiation leads to Shipment Schedule, Delivery Planning, and
Delivery/Dispatch Conversations and these could be combined together in the
same Choreography. Alternatively, they could be separated in different
models.
Figure 9.19 shows a subset of the larger Conversation diagram of Figure
9.18, above. Figure 9.20 and Figure 9.21 show the drill down into the
“Delivery Negotiations” Sub-Conversation. This expands the Conversation with
the Message Flows, providing a structural view of a Conversation without the
“clutter” of sequencing details in the same diagram. Figure 9.19 also
indicates the CorrelationKey involved in the Message Flows of the
Conversation. For example, Order Id is necessary for in all Messages of
Message Flows in Delivery Negotiation. In addition, someMessage Flows also
require Variation Id (for dealing with shipment variations on a per line
item basis).
Figure 9.20 shows how the Sub-Conversation of Figure 9.19, above, is
expanded into a set of Message Flows and a lower-level Conversation.
Figure 9.21 shows how the Conversation of Figure 9.20 is also expanded into
a set of Message Flows, combined with the previous Message Flows. Note that
the newly exposed Message Flows of the lower-level Conversation will be
correlated by the CorrelationKey of both the lower-level Conversation
(Variation Id) and the higher-level SubConversations (Order Id).
In Figure 9.19 a hierarchical structure of Conversations can be seen with
one set of Message Flows occurring within another in a parent-child
relationship. In particular, after Planned Order Variations (keyed on Order
Id) at the parent, a number of Message Flows of the child follow till
Retailer Order and Delivery Variations Ack (keyed on Variation Id and Order
Id). The remaining Message Flows (keyed on Order Id) are at the parent
level. The child Conversation, as such, is part of the parent Conversation.
Nesting is indicated graphically on a Conversation symbol (by a “+”),
indicating a Sub-Conversation or a Call Conversation calling a
Collaboration. Nesting can go to an arbitrary number of levels.
A common dependency between Conversations is overlap. Overlap occurs when
two or more conversations have some Message exchanges in common but not
others. As an example in Figure 9.18, a Message is sent as part of Detailed
Shipment Schedule (keyed on Carrier Schedule Id) to trigger Delivery
Monitoring (keyed on Shipment Id). During Delivery Monitoring, Message could
be sent to Detailed Shipment Schedule (to request codifications when
transportation exceptions occur).
Splits and joins are special types of overlap scenarios. A Conversation
split arises when, as part of a Conversation, a message is exchanged between
two or more Participants that at the same time spawns a new, distinct
Conversation (either between the same set of Participants or another set).
Additionally, no further Message exchanges are shared by the split
Conversations as well as no subsequent merges of them occur. An example is
Delivery Planning which leads to Carrier Planning and Special Cover. A
Conversation join occurs when several Conversations are merged into one
Conversation and no further Message exchanges occur in the original
Conversations, i.e., these Conversations are finalized. The generalization
of a split and join is a Conversation refactor where Conversations are split
into parallel Conversations and then are merged at a later point in time.
