Figure 158: Collaboration for creating an advertisement
Chapter 5 described how collaborations are modeled using message flows between processes. In chapter 6, catching message events and event-based gateways were introduced. With these elements, it is possible to specify that a process is waiting for a message, or that a certain path is selected based on a received message.
In many cases it is required to define the co-operation of different partners. This applies e.g. for business-to-business integration. Several partners connect their information systems in such a way that placing and fulfilling orders, as well as other business transactions, can be completely automated. In such a case, every company is responsible for its own process. It is necessary, however, that all involved partners agree on the messages to be exchanged.
In order to support this, black box pools can be used, i.e. pools without their processes displayed. Figure 158 shows the collaboration for creating an advertisement. In this diagram, the message flow between customer, advertising agency, and several designers can be seen.
The approximate temporal order can be deduced from the sequence of message flows from left to right. Nevertheless, this can be ambiguous because no sequence flow is shown, and possible conditions and repetitions are not visible. In the example, an inquiry will usually be followed by an order, but not every case will involve change requests. If changes are requested, on the other hand, it is also possible to send more than one change request.
Figure 158: Collaboration for creating an advertisement
Presumably, only one of the two messages “Order” and “Rejection” will be sent within one process instance. Availability requests will probably be sent to several designers, but an assignment should obviously be sent to only one of these designers.
All these dependencies are not visible in the black box representation of the collaboration. One possibility for modeling the described logic is to include one or more public processes. In the example it is advantageous to model the public process of the advertising agency since all messages of the other two partners are exchanged with the advertising agency (figure 159). If there were also a direct interaction between customer and designer, at least one additional process would be necessary.
From figure 159 the exact sequence of message exchanges can be deduced. It can be seen, for example, that it is possible to send several change requests, each of which is answered by the advertising agency with a new offer. It is also visible that several availability requests are sent to designers, but only one assignment. The model does not clearly show that the assignment is sent to one selected designer (and not perhaps one single assignment to all designers). For this, it would be necessary either to model an additional pool for the selected designer or to display the designer’s process, which could specify that all designers wait for the assignment for a certain time span. Only the designer who has received the assignment will send graphics. The others finish their processes.
In the presented process, many possibilities are not covered, e.g. it is assumed that the customer always reacts to an offer. Likewise, it is expected that a designer always sends graphics after having received an assignment. The case that one partner does not react within a certain period could be modeled with event-based gateways and timer events.
Choreography diagrams provide another possibility for modeling the temporal and logical sequence of message flows in the scenario described above. In these diagrams, the focus is on the message exchanges themselves. They are modeled as choreography activities.
Figure 160 contains the choreography for the example of creating an advertisement which has already been shown as a collaboration. A choreography activity represents the exchange of one or more messages between two or more partners. In the simplest case, it comprises sending only one message from one partner to another. An example is the choreography activity “Send Inquiry”, in which a customer sends the message “Inquiry” to an advertising agency. A choreography activity can also represent several message flows. Within “Get Approval”, first a message with an advertisement is sent from the advertising agency to the customer, and then the customer sends back a message with the approval.
The presented choreography is easy to understand. First, an inquiry is sent (from the customer to the advertising agency), followed by an offer (from the advertising agency to the customer). Then there are three possibilities: Firstly, it is possible to send a change request. In this case, the choreography activity “Send Offer” will be repeated.
Figure 160: Choreography for creating an advertisement
Secondly, a rejection can be sent, and the choreography is finished. In the third case, an order is placed, followed by finding an appropriate designer. The activity “Find Designer” is carried out several times. Besides the advertising agency, each time one member of the group of designers is involved. Finally, the message exchanges “Handle Graphics Production” and “Get Approval” follow.
Each choreography activity is initiated from one of the partners by sending the first message. This initiating partner is shown in a white band at the upper or lower edge of the choreography activity symbol. The name of the other participant is placed in a shaded field at the other edge. The modeler can freely decide which partner is placed at the top and which at the bottom. If there are several choreography activities involving the same partners, the placement will usually be the same in all choreography activities. If an additional collaboration is modeled for the same scenario, it is adviceable to reflect the collaboration’s arrangement of pools. Accordingly, the choreography activities in figure 160 have the customer at the top and the advertising agency at the bottom, respectively the advertising agency at the top and the designers at the bottom.
The choreography activity “Find Designer” contains a multiple marker, i.e. it is carried out several times. Since the involved partner also has a multiple marker, the message exchange involves one single designer in each repetition. Here, the number of repetitions is known in advance. If this is not the case, the choreography activity receives the loop marker, which is already known from normal activities (figure 161).
In this example, there are only two partners involved in each choreography activity. For more partners, additional participant bands can be placed at the edges. Thereby always only one field is colored white because only one of the partners initiates the message exchange by a first message. An example can be found in figure 165.
In a choreography diagram, a sequence flow is defined for the choreography activities. It is basically modeled like the sequence flow in normal processes.
However, some process modeling elements are not meaningful in choreography diagrams. Therefore, they are not allowed here. For example, there are no message events within normal sequence flow, because message exchanges are contained in the choreography activities by definition. Likewise, the event-based gateway in figure 160 is not followed by events, but by choreography activities. This means that the path is selected by the choreography activity which is first started by its initiating message.
Figure 161: A looping choreography activity
Figure 162: Choreography activities with message icons
If one wants to know which messages are exchanged in each choreography activity, small envelope symbols can be added and connected with the respective partner’s band (figure 162). The envelopes have the same colors as their partner bands. A white envelope signifies a message that initiates a choreography activity. The envelope symbols of the other messages are shaded.
Figure 163: Choreography within collaboration (fragment)
The choreography is closely related to the respective collaboration. If this relation should be shown, a choreography can be included in a collaboration diagram. Figure 163 shows a part of the advertisement process in which the choreography has been inserted into the collaboration diagram from figure 159.
Since choreographies display the sequence of message exchanges, the choreography activities are placed between the pools. The related message flows run from pool to pool, as in normal collaboration diagrams. Here they run through the respective choreography activities. Thus, choreographies and collaborations are connected via the message flows.
The related partners, therefore, can be identified by the sources and the targets of the message flows, so the names of the partners need not to be shown in the choreography activities. They still contain the participants’ bands in order to remain clearly identifiable as choreography activities and to be distinguished from normal activities. Again, the initiating messages are blank; the others are shaded (figure 164).
It can be helpful to include a choreography into a collaboration to validate that the logic of the message exchange within the own process is in accordance with the choreography.
Like normal activities, choreography activities can be organized hierarchically. Besides choreography tasks which cannot be decomposed further, there are choreography subprocesses which comprise more detailed choreographies. They are marked with a small ‘+’. In figure 165, the above choreography has been re-arranged into two sub-processes. They are shown in the collapsed state, i.e. the internal details of the sub-processes are not visible.
Figure 165: Choreography with collapsed sub-processes
“Process Order” is an example that illustrates how to draw a choreography activity with more than two participants. There is always only one white participant’s band, because only one participant initiates the choreography activity. Multiple participants’ bands are distributed in such a way that the difference of the numbers of bands at the top and of those at the bottom is not more than one. An initiating participant, with a white band, can also be placed together with one or more other participants with shaded bands, at the same edge.
For each sub-process, there is a detailed choreography which can either be modeled in a separate choreography diagram, or inserted into the expanded sub-process symbol, as in figure 166. In order to make the different results of the first sub-process (“Order placed” or “Rejection sent”) visible on the upper level, an exclusive gateway is used. It selects the sequence flow according to the sub-process’s result.
Like normal sub-processes, choreography sub-processes can also be aborted by catching intermediate events which are attached to their boundaries (cf. chapter 8.1). It is also possible to model event sub-processes in choreographies (cf. chapter 8.5).
Besides the event-based exclusive gateway, it is also possible to use the normal, databased gateways in a choreography. In figure 165, an exclusive gateway has been used. Inclusive, parallel, and complex gateways can also occur in a choreography.
The conditions at a gateway can only refer to contents of messages that have been exchanged earlier in the process. It is not possible to include other data for the decision. After all, a choreography only reflects the logic of the involved partners’ processes. Actually, the decisions are taken in these partners’ processes. Based on the result of a decision, different messages are sent. In the example, the decision is indeed only based on the exchanged messages. “Order placed” will be true if a message with an order has been exchanged. The condition “Rejection sent” will be fulfilled if a message with a rejection has been sent instead.
The data required for a decision must also be known to those partners who initiate the choreography activities directly after the gateway. Otherwise, they would not know whether they have to send a message.
As in normal processes, a default exit of an inclusive or an exclusive gateway can be defined by marking the outgoing sequence flow with a diagonal slash. For a choreography activity, it is also possible to have outgoing conditional sequence flows.
In principle, it is possible to use not only untyped start and end events in choreographies, but also events with specific types of triggers, and intermediate events.
Triggers for start events can be signals, timer and multiple. Multiple start events are only allowed to combine signals and timers. Each participant can receive a broadcasted signal, and each can determine when a timer event occurs. Thus, all participants know about the occurrence of such an event, so that they can commence their common activities. Conditional events are also permitted, but only in event sub-processes. Signals, timer events, and multiple events may also be used for triggering an event subprocess.
There are only two possible end event types: The untyped event and the terminate event. When using a terminate event, it is important that all participants are informed of the termination during the preceding choreography-activity. Otherwise, the participants in parallel paths would not know about the termination and that they must not continue.
Normal sequence flows in choreographies can contain intermediate events of the following types: None, timer, conditional, link, signal, and multiple. When using a conditional intermediate event, it must be ensured that each participant has all information which is necessary to determine whether this event has occurred. Message events are not allowed since message flows are already covered by choreography activities.
In order to abort a choreography activity, a catching intermediate event can be attached to its boundary. For this purpose, timer and conditional events, as well as signals and multiple events can be used. Thereby it must be ensured that all concerned participants learn about the occurrence of the respective event. It is also possible to attach message, cancel, or compensation events; however they must be attached to the band of that participant that receives the event. For an attached message intermediate event, the message must be sent by another participant who is also involved in the same choreography activity.
In chapter 7.5 the concept of the call activity was explained, which can be used for calling a global task or a process defined elsewhere.
Figure 167: Calls of global choreography tasks (left) and of choreographies – collapsed (center) and expanded (right)
The same concept is also available for choreographies. The border of a choreography activity which is used for a call is drawn with a thick line (figure 167). It can either call a global choreography task (left) or another choreography. A global choreography task is defined once and can be re-used in several choreographies. The call of another, independent choreography can either be shown in a collapsed (center) or expanded call activity (right).
As explained at the beginning of the chapter, the contents of a choreography can also be expressed by a collaboration. However, there are some reasons for using choreographies:
Especially for complex business-to-business scenarios, choreography diagrams can be interesting, e.g. in the context of electronic marketplaces or for developing industry standards and guidelines for handling certain business transactions between partners.
However, if a company develops its internal processes and wants to show the message exchange with partners, usually a collaboration diagram will be the first choice.
