Hammer and Champy’s definition of a business process [10] targets at (re-)structur-ing the business processes from a s(re-)structur-ingle company’s perspective optimiz(re-)structur-ing its out-come. Over the last few years supply chain management involving multiple parties became more and more popular, leading to an inter-organizational focus of business process management. In this context the above given definition of a business pro-cess of Hammer and Champy toward creating customer value does not fit anymore, because a supply chain includes many seller—customer relationships. An inter-organizational business process is an organized group of related activities carried out by multiple organizations to accomplish a common business goal. An inter-organizational business process does not focus on the internal tasks of an individual organization, it rather focuses on the tasks carried out between the actors in the network of organizations.
A service oriented architecture and its realization by web services, may be used to describe and implement the workflow of both kinds of business processes de-scribed above. In the area of web services two terms have emerged to distinguish the two kinds of business processes: orchestration and choreography. These terms describe closely related, but well distinguished concepts [28]. Orchestration deals
with the sequence and conditions in which one business process calls its components to realize a business goal. Choreography describes business processes in a peer-to-peer collaboration. It describes the flow of interactions between the participating business partners that interlink their individual processes. We distinguish local and global choreographies. A local choreography describes the flow from a participating partner’s point of view. It makes the public parts of its local process visible to oth-ers. A global choreography defines the inter-organizational process from a neutral perspective. A global choreography has the potential to achieve an agreement be-tween the partners. Local choreographies enable the configuration of each partner’s system.
4.2.2 Orchestration
In order to illustrate the differences between orchestration and choreography we use the following example that is used throughout this chapter: we take a detailed look on a simplified order management processes at the sales department of the seller which interfaces with the processes of a buyer and a carrier. Once the seller receives an order from the buyer, the seller checks compliance of the order against an offer he made before. In order to fulfill the order the seller reserves necessary products from the stock as well as the resources of the production line. Once these tasks are accomplished he is able to calculate a delivery date for the order. Knowing the delivery date, the seller reserves transport at the carrier. Now the seller is able to accept (or reject) the order of the buyer. Once the order is accepted, the buyer may (repeatedly) ask for the status of the order. The buyer may cancel the order until the goods are shipped. In this case the seller has to clear the reservation of the stock and the reservation of the production line. If the buyer does not cancel the order and the goods are ready to ship the seller sends a notification of shipment to the buyer—this indicates also that he is not able to cancel the order anymore and that status request is not possible anymore since the “final” statusshipped is reached. After shipping takes places, the sales department of the seller hands over the case to the accounting department.
A service-oriented model of the example process described above is presented in Figure 4.1. This example process focuses on the orchestration of the seller’s tasks in the middle lane of Figure 4.1. We do not detail the orchestrations of the buyer and the carrier, but show their choreographies in the left lane and in the right lane, respectively. Each node in Figure 4.1 represents a service executing a specific task.
The abbreviation within the node shows who is offering the service: the seller’s sales department (Ss), the seller’s production department (Sp), the seller’s accounting de-partment (Sa), the buyer (B), or the carrier (C). A new process instance is created when the seller’s sales department receives a call of theorder productservice. The fact that this is an asynchronous incoming call is denoted by the little incoming arrow above the nodeorder product. Afterwards, the seller’s department uses the servicecheck against offerfrom the accounting department which is a synchronous
Order Product
Fig. 4.1 Seller’s orchestration of the order management
call that returns the result of the check. The synchronous call is indicated by the outgoing and incoming arrow above the service check against offer. Note, in or-der to keep the example simple, we only show the regular path and omit to show any exceptions. Consequently, we only show the path following a successful check, which continues by calling the services reserve stock andreserve production line both offered by the seller’s production department in parallel. Since both services are asynchronous outgoing calls a little outgoing arrow is mentioned above each of the nodes.
Having completed the reservation, the synchronouscalculate delivery date ser-vice of the production department is executed. Knowing the delivery data, the seller is able to use the carrier’s servicereserve transport. This asynchronous outgoing call, is followed by an asynchronous incoming call of the confirm transport ser-vice at the seller’s side. Note, that in an economic context one might argue that confirming a transport is an economic service offered by the carrier. However, in an IT context it is always the receiver of an incoming call who has to provide the service. Inasmuch, the seller’s sales department has to provide aconfirm transport service to receive the confirmation from the carrier. One might further argue that it is possible to group thereserve transport and theconfirm transport services into a single service. In order to be consistent and to simplify the overall example we use just asynchronous calls for the inter-organizational services. Following this design decision, theconfirm transportis followed by an asynchronous outgoing call of the response to orderservice of the buyer which represents the answer on the initiating order productservice.
After the order is accepted, the seller’s sales department may receive an asyn-chronous incomingget statuscall which is answered by an asynchronous outgoing call of the buyer’sinform on status. The sequence of these two services is on the one hand optional, but may also be repeated many times until the order is either canceled or shipped. This means either an asynchronous incoming call ofcancel or-derinvoked by the buyer or an asynchronous incoming callready to ship issued by the production department will end the status information loop. In case of receiving cancel order, it is necessary to call bothclear resourcesanddeallocate production line of the production department. In contrary, if aready to ship is received from the production department, it is required to send an asynchronous outgoing call of the buyer’snotify shipment service. Afterwards, an asynchronous outgoing call of transfer to accounting provided by the accounting department ends the successful case.
4.2.3 Local Choreography
In Figure 4.2 we show the local choreographies of the seller, the buyer, and the car-rier. Since we did not detail the internals of the buyer and the carrier in Figure 4.1, their local choreographies remain unchanged in Figure 4.2. In contrary, Figure 4.1 shows the seller’s orchestration. It includes services visible to the outside world,
Order Product Seller
Buyer Carrier
Order Product
Ss
Ss
Reserve Transport
Confirm Transport
Reserve Transport
Confirm Transport
Ss Ss
C C
Response To Order Response To Order
p
B B
S
Get Status
Inform on Status Get Status
Inform on Status
Ss
B
B Ss
Cancel order Cancel order
Ss
Ss
B B
Notify Shipment Notify Shipment
B B
Fig. 4.2 Local choreographies
which are shown as gray nodes, and services visible only within the seller, which are presented as white nodes. By calculating the local orchestration of the seller we have to eliminate the white nodes of the internal services. In other words, we produce a projection of the orchestration including only the gray nodes of the exter-nally visible services. Eliminating some nodes results also in eliminating transitions to/from these nodes. Accordingly, this leads to some tangling nodes that have to be connected in order to complete the graph of a local choreography. Approaches that deal with such transformations are introduced in 4.2.5.
The elimination of the internal white nodes ends up in the local choreography of the seller in the middle lane of Figure 4.2. This local choreography is a multi-party choreography, since it comprises interactions between the seller and the buyer as well as interactions between the seller and the carrier. In Figure 4.2 we have marked the regions of the bilateral interactions by dotted line borders.
If two business partners want to collaborate they must have complementary local choreographies. Accordingly, we have to compare their local choreographies in the context of their bilateral collaboration independent of collaborations with any other partners. In our example, the local choreography of the buyer does not show any interactions with other partners. Accordingly, it stays as it is. In the seller’s local choreography the nodes representing interactions with the carrier have to be elim-inated. The task of calculating a bilateral local choreography from a given multi-party one is the same as calculating a local choreography from a given orchestration.
We omit to show the result in Figure 4.2 , because it is easy to recognize that the bilateral local choreography of the seller with the buyer will include a direct transi-tion fromorder producttoresponse to ordereliminating the two nodes representing interactions with the carrier.
When comparing the bilateral local choreographies of the buyer and seller it is easy to recognize that both of them are composed by exactly the same services. Also the control flow among these services is the same in both local choreographies. The major difference between the two local choreographies, is the fact that a certain ser-vice is called by one partner in one choreography, and the other partner receives the call of this service in the other choreography. For example, the first service in both local choreographies isorder productwhich is provided by the seller’s sales depart-ment. The buyer calls this service which is indicated by an outgoing arrow above the node. In contrary, the seller receives a call of this service which is notated by an incoming arrow above the node. Accordingly, the little arrows indicating incoming and outgoing calls are always in the reverse direction in a partner’s local choreog-raphy. Accordingly, we define a complementary choreography as a local bilateral choreography that uses exactly the same services in the same order, but the call of the service is in the opposite direction.
4.2.4 Global Choreography
In the previous subsection we learned that each business partner describes its local choreography from its own perspective. This means if two business partners col-laborate, there will be two local choreographies—one for each business partner. In order to negotiate the collaboration, the business partners have to adjust their own local choreographies in a way that they are complementary to each other. In or-der to reach agreement and commitment between the business partners, it is more convenient to discuss the choreography between them from a common neutral per-spective. This means that a single global choreography describes the services that are involved in the interaction and the order in which the services are executed. For each of the services being part of the steps of a global choreography it is fixed who calls the service and who receives the call of the service.
Figure 4.3 shows the global choreography between buyer and seller for our ex-ample process. The control flow of the services remains the same as in Figure 4.2.
However, instead of having two local choreographies assigned to the corresponding
Fig. 4.3 Global choreography between buyer and seller
Order Product Ss
B
Out: buyer In: seller
Out: seller In: buyer Response To Order
Get Status Ss
y
Out: buyer In: seller
Inform on Status B Out: seller
In: buyer
O b
Cancel order
Notify Shipment Ss
B Out: seller In: buyer Out: buyer
In: seller
lanes of the buyer and the seller, respectively, the global choreography uses just a single description of this control flow and mentions for each service the outbound and the inbound role. Having reached an agreement on the global choreography it is an easy task for the buyer and the seller to derive their local choreographies.
4.2.5 Approaches to Transform Between Orchestration and Choreography
There exist some approaches that take care of the relationship between orchestra-tion, local choreography, and global choreography. In particular, the different per-spectives can be transformed into each other. The global choreography can be trans-formed into the local choreography, and the local choreography can be transtrans-formed into an orchestration. The basic idea of transforming a global choreography into a local choreography is partitioning the global choreography in a way that the mes-sages used in the resulting local choreographies are matched to the corresponding party. This partitioning is achieved by eliminating messages which are not related to the particular party. Such an approach is described by Aalst in [41]. The transforma-tion of a local choreography into a global choreography can be realized by relating message exchanges of different local choreographies that semantically complement one another. An approach based on workflow nets is proposed by Aalst [36, 37].
Piccinelli et al. [29] propose another transformation approach in particular for peer-to-peer collaborations.