Managing sequences dependencies in service compositions

Transcription

1 Managing sequences dependencies in service compositions Geert Monsieur, Monique Snoeck and Wilfried Lemahieu Katholieke Universiteit Leuven Faculty of Business and Economics The Leuven Institute for Research on Information Systems (LIRIS) Naamsestraat 69, 3000 Leuven (Belgium) Abstract In a service-oriented environment services are often aggregated to coarser grained service compositions in order to form a service-based system that supports a specific business process. For each service composition, there exists coordination logic that describes all service interactions required to compose the coarser service. These service interactions should follow the constraints specified in the business process. In this article we present four patterns that facilitate the systematic development of coordination logic. In particular pattern combinations help to construct a coordination scenario that is optimized for aspects such as flexibility, loose coupling and performance. 1 Introduction In a service-oriented company, activities defined in the company s business process are supported by one or more services. These services are aggregated to coarser grained service compositions in order to form a service-based system that supports a business process. In addition to choosing the most appropriate services, the designer of a service-based system also has to decide on the exact coordination of all component services. The coordination logic describes all service interactions needed for the service composition. Although a typical business process definition specifies the sequencing of activities, extra coordination logic is required to manage access to information and the progress of process execution. In general, coordination can be defined as managing dependencies between activities [12]. This definition is based on the intuitive idea that there is nothing to coordinate without any interdependence. We consider two general types of dependencies that are relevant when composing services into service-based systems: sequence dependencies and data dependencies [20, 14]. In the first place, a business process may set constraints on the sequence in which services should be consumed (i.e. a service B can only be consumed after the consumption of service A), which has consequences for the service interactions (i.e. it is not Writers Workshop F (Software) - paper F3 1

2 1.1 Introductory example and research questions 1 INTRODUCTION Task 3a: Book hotel Task 4: Register payment Task 1: Process customer s request Task 2: Checking for unpaid invoices Task 3b: Book flight Task 3: Arrange online payment Task 3c: Book car Task 5: Send tickets to customer Figure 1: A travel agency business process allowed to invoke a particular operation provided by service B, before a particular operation provided by service A is invoked). Similarly, it may occur that one component service provides the data needed by a second component service (i.e. data held by service A is needed by service B). Unfortunately, there is no universal rule about the best way to manage sequence and data dependencies. In our previous research we have developed a pattern language for the management of data dependencies [13]. In this article we present four patterns that facilitate the management of sequence dependencies. Studying the relationships between these two pattern languages is out of scope of this paper. In the next subsection we describe a concrete example that discusses the problem of managing sequence dependencies. 1.1 Introductory example and research questions In Figure 1 a travel agency business process is represented using the Business Process Modeling Notation (BPMN) [19]. The business process consists of tasks for booking a hotel, flight and car. As shown in Figure 1 the first task (task 1) is about processing a customer s request. It is only after this task that the travel agency knows for which hotel, flight and car it needs to make reservations. In the next task it is checked whether or not the customer has still unpaid invoices (task 2). If this is not the case, the business process continues with the real booking of the desired hotel, flight and car (task 3a, 3b and 3c). These three booking tasks can occur in parallel. Once all three reservations are completed an online payment should be arranged (task 4). Finally, the business process ends by registering the payment (task 5) and sending the tickets to the customer (task 6). In this example we assume that the business process represented in Figure 1 can be supported by seven services: customer service (task 1), finance service (task 2 and 5), hotel booking service (task 3a), flight booking service (task 3b), car rental booking service (task 3c), online payment service (task 4) and mail service (task 6). Hence, coordination logic for this business process consists of interactions with these seven services. These service interactions should manage the sequence dependencies as specified in the business process (e.g. a request to the mail service can only be sent when the finance service has successfully registered the customer s payment). Writers Workshop F (Software) - paper F3 2

3 1.2 Related work 1 INTRODUCTION In Figures 2(b), 2(a), 3(a) and 3(b) different coordination scenarios for the business process represented in Figure 1 are shown. In a service-oriented environment, business processes often are implemented by orchestrating services centrally using a process engine (e.g. BPEL engine). This means that there is central service that manages all sequence dependencies and (simply) interacts with all services in the order that is specified in the business process. For example, in Figure 2(a) one can see that the orchestration engine firstly interacts with the customer service (task 1), before it interacts with the finance service (task 2). Both the coordination scenarios in Figure 2(a) and Figure 2(b) consists of one service that centrally orchestrates the other services. While Figure 2(a) contains a separated orchestration engine, in Figure 2(b) the customer service takes the role of central orchestrator. In contrast, the coordination scenarios represented in Figure 3(a) en Figure 3(b) have no central orchestrator. This kind of coordination scenarios is often referred to as a choreography. While in a central orchestration scenario all sequence dependencies are managed centrally, in a choreography scenario the management of sequence dependencies is distributed among all services. For example, in the coordination scenario represented in Figure 3(a) the sequence between task 1 and 2 is managed by the customer service, while the finance service is responsible for requesting the online payment service. It is easy to understand that in case of central orchestration, the example discussed above has eight possible coordination scenarios. This is so because, in theory, every service can take the role of central orchestrator. Additionally, a separated service can act as the central orchestrator (e.g. BPEL engine). In case of a choreography scenario many more coordination scenarios are possible. Furthermore, one can imagine that the solution space, containing all possible coordination scenario, enlarges when the business process contains transactions (e.g. a transaction for booking the car, flight and hotel). This raises two main research questions concerning a coordination scenario: RQ1 How can we ensure that a service composer considers all possible coordination scenarios as potential solutions? In other words, is there a systematic way of composing coordination scenarios, starting from some basic building blocks, such that we are sure that all possible scenarios are considered? RQ2 What criteria can be used to evaluate different coordination styles against each other? And hence, how does each style score on each criterion? An approach covering these research questions allows service composers to construct a coordination scenario that is optimized for aspects such as flexibility, loose coupling and performance. 1.2 Related work Previous researchers have shown that it is important to make a distinction between business process logic and coordination logic. In their work Desai et. al argued that business processes are conventionally modeled directly as monolithic flows. They state that these flows are often more complex than necessary, lack modularity, are formed by ad hoc intertwining of internal business logic and Writers Workshop F (Software) - paper F3 3

4 1.2 Related work 1 INTRODUCTION Orchestration Engine (e.g. BPEL Engine) Process customer s request Customer s travel requirements Customer Book flight Book hotel Hotel ack Flight ack Unpaid invoices? Yes/No Book car Hotel Booking Flight Booking Car ack Arrange Online Payment Payment completed Register payment Mail tickets Car Rental Booking Online Payment Finance Mail (a) Coordination scenario with orchestration engine Customer Unpaid invoices? Yes/No Book hotel Book flight Book car Hotel ack Hotel Booking Flight Booking Flight ack Car ack Arrange Online Payment Payment completed Register payment Car Rental Booking Mail tickets Online Payment Finance Mail (b) Coordination scenario with Customer as central orchestrator Figure 2: Two orchestration coordination scenarios Writers Workshop F (Software) - paper F3 4

5 1.2 Related work 1 INTRODUCTION Customer Book hotel Book car Book flight Hotel Booking Unpaid invoices? Yes/No Flight Booking Car Rental Flight ack Hotel ack Payment completed Mail tickets Car ack Finance Arrange Online Payment Payment completed Online Payment Mail (a) Customer Book hotel Book car Book flight Hotel Booking Flight Booking Payment completed Unpaid invoices? Yes/No Car Rental Booking Flight ack Hotel ack Mail tickets Car ack Online Payment Payment completed Finance Mail (b) Figure 3: Two choreography coordination scenarios Writers Workshop F (Software) - paper F3 5

6 2 THE PATTERN LANGUAGE external interactions, and are difficult to predict and verify the behavior [8, 7]. Therefore they propose to model business processes as composition of business protocols. Similarly, Benetallah et. al have studied the concept of (Web) services conversations. They define a conversation as a sequence of message exchanges that can occur between a client and a service as part of the invocation of a Web service [4, 3, 5]. This exchange occurs according to a business protocol (also called conversation protocol), i.e. a specification of the set of correct and accepted conversations. Since both business protocols and services conversations focus on service interactions that implement a (high-level) business process, these concepts can be considered as coordination logic that manages sequence dependencies specified in the business process. However, these approaches are mostly studied in the context of modeling coordination logic, checking compatibility between two or more coordination protocols or checking the compliance between service interactions and business process specifications. Hence, these approaches fail to systematically analyse the coordination problem. Although they acknowledge the existence of different coordination scenarios and propose techniques for modeling such scenarios, they do not provide a systematic way of building different styles of coordination nor do they analyse the advantages and disadvantages of each design alternative. As a consequence, they fail to exhaustively identify each possible coordination scenario. Similarly, modeling languages such as the Business Process Execution Language (BPEL) [17], BPEL extensions for choreography modeling (BPEL4Chor) [6], and the Web s Choreography Description Language (WS-CDL) [16] provide the means to model a choreography, but guidelines for designing a coordination logic are insufficiently studied. We present answers to the research questions discussed in Section 1.1 in the form of two patterns. In the past patterns have proved to be a very valuable means to conserve and reuse knowledge about the solution to a generic problem. The management of sequence dependencies is a crucial recurring problem in service composition, which justifies our choice for patterns. Traditionally, patterns were widely known for their use in object-oriented design [10]. More recently, the pattern concept was successfully applied to work flow management [18] and message-based integration solutions [11]. In the context of service composition patterns gained increasing interest in the form of service interaction patterns [1] and in the model-driven development of process-driven SOAs [21, 9]. 2 The pattern language In this section we present four patterns to manage sequence dependencies. These patterns all deal with the same problem, in the same context, and under influence of the same set of forces. The main difference between the patterns is the solution described in the pattern and the consequences that come with that solution. Writers Workshop F (Software) - paper F3 6

7 2 THE PATTERN LANGUAGE Context A service-based system is built by combining the functionality provided by several component services. Typically, a business process description specifies the sequencing of activities. Assuming that activities are directly supported by component services, the business process holds the logic that can be used to find out when and which service should be consumed. Hence, for each task in a business process there exists a set of rules that determines when and which service should be consumed. In the rest of this paper, we refer to this set of rules as the task logic. Problem For each task in a business process there needs to be decided which entity holds the task logic and interacts with the service supporting the business process task. Forces Performance: Intuitively, software engineers tend to create additional logical layers when business (process) logic must be implemented. Typically, such a logical layer contains process or task logic. However, if high levels of performance are required, this approach is less appropriate. In a service-based system additional logical layers increase the interservice communication, resulting in a less performing system. Flexibility: From time to time business processes change, and so servicebased systems need to change. Preferably, business process logic can be easily changed without having to change services dramatically. Loose coupling and autonomy: A frequently discussed aspect of serviceorientation is loose coupling. This aspect means that it should be relatively easy to replace or change services in a service-based system without having to make changes to other services or the global system. This would allow businesses to rapidly adapt their systems when necessary. In that perspective, some researchers propose to combine a service-oriented architecture with the strengths of an event-driven architecture. They consider services to be more autonomous, and implicitly more loosely coupled, when these are positioned in an SOA as entities that both react to events instead of requests and send out event information to other services instead of requests. Complexity: If entity holding the task logic requires event information that is available elsewhere (e.g. the completion of another business process task), the global coordination scenario becomes more complex. This is because event information needs to be transferred between the entity holding the event information and the entity holding the task logic, which needs to consume the event information. Business process progress: A business process forming the basis for a service-based system can be long-running. Therefore, it is potentially required that the business process progress can be easily inspected. Writers Workshop F (Software) - paper F3 7

8 2.1 Patterns overview 2 THE PATTERN LANGUAGE REACTIVE SERVICE OR DELIBERATIVE SERVICE ORCHESTRATED DELIBERATIVE SERVICE AND /OR DELIBERATIVE SERVICE IN COLLABORATION Two not mutually exclusive variants of DELIBERATIVE SERVICE Figure 4: An overview of the pattern language L x S y Y that is a service requestor of X L x requestor of X S x X A request message Event information transfer i Runtime step i Figure 5: Symbols used in this articles Security and policies: In a service-oriented system it can occur that a particular service only accepts requests from a limited set of clients. For example, in a business-to-business environment between two companies often only a limited set of services in one company are allowed to interact with services in the other company. 2.1 Patterns overview In general, we can distinguish between two possible ways of allocating task logic (see figure 4). Either one applies the reactive service pattern or one goes for the deliberative service. Additionally, there are two not mutually exclusive variants of the latter pattern: the orchestrated deliberative service and the deliberative service in collaboration. Each pattern provides a solution to the same problem. However, the pattern consequences are different. In the rest of this paper all patterns are visualised using rectangles, circles and arrows (see figure 5). A rectangle L i denotes the service requestor that both sends a request to S i and holds the set of rules to decide when it should send out this request. s are represented using circles. A rounded rectangle is used to represent a service that includes task logic and thus is also a Writers Workshop F (Software) - paper F3 8

9 2.2 Reactive service 2 THE PATTERN LANGUAGE service requestor. Solid arrows denote requests sent from a L i to a S i, while dashed arrows represent the transfer of event information to a L i. 2.2 Reactive service Solution Use a reactive service that includes the task logic. The reactive service reacts to events so that business process tasks are executed at the right time, as specified in the business process. 1 Event information L 1 2 S 1 React to event(s) Figure 6: A reactive service A reactive service does not start the task execution on request. Instead, it simply receives (see dashed arrow in Figure 6) and processes certain event information. Events are processed using the task logic that is included in the reactive service (see the Task Logic Box L 1 that is combined with S 1 ). If all conditions as specified in the task logic, which are derived from the business process, are met, the reactive service reacts to the events by starting the executing of the business process task. Consequences Since the task logic for a reactive service is included in the service itself, the execution of business process task can start immediately when necessary. A reactive service directly reacts to event information. No additional request messages need to be sent to the reactive service, which has a relatively positive influence on the overall performance. A reactive service negatively effects the flexibility of the service-based system. A reactive service includes some business process logic, in the form of task logic, and this means that a change in the business process potentially requires the modification of the reactive service. As discussed earlier a reactive service reacts to event information. Hence, a reactive service can be considered more autonomous. Furthermore, it is assumed that a reactive service can be relatively easier replaced in a servicebased system, because no explicit requests are sent to the reactive service. The idea is that event information sent to the reactive service can be simply sent to an alternative reactive service. In that sense, the service-based system has a loose coupling with the reactive service. Since a reactive service reacts to event information a complete coordination scenario requires the correct transfer of event information to the reactive service. If this event information comes from several other services (e.g. in case Writers Workshop F (Software) - paper F3 9

10 2.3 Deliberative service 2 THE PATTERN LANGUAGE 1 Event information: Payment completed Task logic: register payment 2 Finance Process event information and register payment Figure 7: The Finance as a reactive service of multiple sequence dependencies between the reactive service and multiple other services, the overall coordination scenario is relatively complex. If one wants to check if a certain task execution is already started, a interaction with the reactive service is necessary. Hence, the more reactive services constitute service-based system, the more interactions with services are needed when one wants to inspect the business process progress. Security issues and policies concerning services that are allowed to send requests to a reactive service are not relevant, because, per definition, a reactive service does not accept requests. Example The reactive service pattern is applied in the example represented in Figure 3(b). In this example the reactive Finance receives event information concerning the payment. In particular, it receives a payment completed message from the Online Payment. Subsequently it is the responsibility of the Finance to react to this event information as specified in the business process. This means that the Finance contains the task logic for the register payment task and registers a payment when it receives event information concerning that payment (see Figure 7). In this scenario, this creates a loose coupling between the Online Payment and the Finance. Related patterns The Event Message as described in [11] is a related pattern, because a reactive service, typically, reacts to event messages by starting the execution of a certain business (process) task. 2.3 Deliberative service Solution Use a deliberative service that does not include task logic, but receives requests from a service requestor that holds the task logic. The service requestor reacts to events by sending a request to the deliberative service so that business process tasks are executed at the right time, as specified in the business process. A deliberative service starts the task execution on request. It receives requests (see solid arrow in Figure 8) from the service requestor (L 1 ). The Writers Workshop F (Software) - paper F3 10

11 2.3 Deliberative service 2 THE PATTERN LANGUAGE 1 Event information L 1 2 Process event information and send request Request S 1 3 Execute task Figure 8: A deliberative service service requestor receives and processes event information. If all conditions as specified in the task logic, which are derived from the business process, are met, a request is sent to the deliberative service (see S 1 ). Consequences A deliberative service does include task logic. This means that the task logic is separated from the deliberative service. Hence a deliberative service introduces an additional logical layer. This increases the interservice communication, because requests must be sent to a deliberative service. A deliberative service does not hold business process logic. Therefore, a change in the business process does not require the modification of the deliberative service. It is relatively difficult to replace a deliberative service, since a deliberative service is used in a service composition by sending requests to the deliberative service. Hence, when the deliberative service is replaced, the service requestor must be adapted so that it can send new requests to the alternative service. As such a deliberative service increases the coupling between services. Furthermore, a deliberative service is less autonomous because it does not react to events, but only accept requests. Example In the coordination scenarios discussed in the introduction of this article, several applications of the deliberative service pattern can be found. For example, in Figure 2(a) the deliberative Finance receives a request register payment from the orchestration engine, which takes the role of service requestor. The orchestration engine receives event information payment completed (see figure 9) and processes this information using its task logic for register payment, before it sends out a request to the Finance (see figure 9). Related patterns The command message as described in [11] is a related pattern, because a deliberative service, typically, receives a command message that is a request for starting the execution of a certain business (process) task. Writers Workshop F (Software) - paper F3 11

12 2.4 Orchestrated deliberative service 2 THE PATTERN LANGUAGE 1 Event information: Payment completed Task logic: register payment 2 Process event information and send request for register payment Request: Register payment Finance 3 Register payment Figure 9: The Finance as a deliberative service 2.4 Orchestrated deliberative service Solution Use a orchestrated deliberative service, which is a deliberative service whereby the service requestor also holds task logic for another business process task. This means that the service requestor orchestrates at least two services, including the orchestrated deliberative service 1 Event information L 0 L 1 2 Process event information and send request Request S 1 3 Execute task Figure 10: A orchestrated deliberative service The interactions between the service requestor and the orchestrated deliberative service are similar to the deliberative service pattern. However, in a orchestrated deliberative service the service requestor also contains task logic for another business task. In figure 10 this is represented by merging the service requestor L 1 with another service requestor L 0. Note that this pattern does not tell anything about the location of S 0, which means that S 0 can be either a reactive service or a deliberative service. Consequences The service requestor that sends requests to the orchestrated deliberative service also holds task logic for another business process task. For both busi- Writers Workshop F (Software) - paper F3 12

13 2.4 Orchestrated deliberative service 2 THE PATTERN LANGUAGE 1 Task Task Process event information logic: logic: 2 and send request for Event information: Book hotel Book car book car Unpaid invoices? (yes/no) Request: Book car Car Rental Booking 3 Book car Figure 11: The Car Rental Booking as a orchestrated deliberative service ness process tasks event information is needed to decide whether the business process task should be executed. In case there is a common need for certain event information, the orchestrated deliberative service pattern decreases the complexity of the overall coordination scenario. This is true because that kind of event information needs to be transferred only once from the source to the consumer. In the orchestrated deliberative service pattern there is one entity containing logic for two business process tasks. This results into an easier inspection of the business process progress, because one would need only one interaction for retrieving information concerning two tasks. Example In each coordination scenario discussed in the introduction (see Figures 2(b), 2(a), 3(a) and 3(b)) the entity that sends the book car request to the Car Rental Booking, also has the responsibility to send requests to the Hotel Booking and Flight Booking. Since for each task logic there is a common need for specific event information (no unpaid invoices), the deliberative service in collaboration pattern results into a preferable coordination scenario. In Figure 11 this pattern is applied to the Car Rental Booking as a deliberative service in collaboration. Related patterns This pattern is related to the orchestration and process centralization patterns as described in [9], because the main idea behind a orchestrated deliberative service is that two or more service requestors are merged into one orchestrating entity. Writers Workshop F (Software) - paper F3 13

14 2.5 Deliberative service in collaboration 2 THE PATTERN LANGUAGE 2.5 Deliberative service in collaboration Solution Use a deliberative service in collaboration, which is a deliberative service whereby the service requestor is another service. 1 2 Process event information and send request Event information L 1 S 1 S 0 Request 3 Execute task Figure 12: A deliberative service in collaboration The interactions between the service requestor and the deliberative service in collaboration are similar to the deliberative service pattern. However, in a deliberative service in collaboration the service requestor is another service. In figure 12 this is represented by merging service requestor L 1 with another S 0. One could say that the service requestor collaborates with the deliberative service. Note that this pattern does not tell anything about the location of service requestor L 0, which means that S 0 can be either a reactive service or a deliberative service. Consequences A deliberative service (in collaboration) does not hold business process logic. Therefore, a change in the business process does not require the modification of the deliberative service (in collaboration). However, if one applies the deliberative service in collaboration pattern, a change in the business process can require the modification of the service ( S 0 in Figure 12) that sends requests to the deliberative service in collaboration. If the event information, that is needed to decide whether a request should be sent to the deliberative service in collaboration, is available at the service taking the role of service requestor ( S 0 in Figure 12), then a deliberative service in collaboration results into a less complex coordination scenario. This is thanks to the fact no event information needs to be transferred, since both event source ( S 0 in Figure 12) and event consumer ( S 0 in Figure 12) are the same. If one wants to check if a certain task execution is already started, a interaction with the deliberative service in collaboration is not necessary. However, one needs to interact with the service taking the role of the service requestor ( S 0 in Figure 12). Hence, the more a service-based system is composed of deliberative services in collaboration with different service requestors, the more interactions with services are needed when one wants to Writers Workshop F (Software) - paper F3 14

15 3 APPLYING THE PATTERNS IN PRACTICE Event information: Hotel ack Event information: Event information: Flight ack 1 Car ack 1 1 Task logic: Arrange Online Payment Finance 2 Process event information and send request for arrange online payment Request: Arrange Online Payment Online Payment 3 Arrange online payment Figure 13: The Finance as a deliberative service in collaboration inspect the business process progress. However, for example, in case of one common service requestor for all deliberative services in collaboration, the business process progress inspection is less complex. This is true because this would imply that the service-based system is built using several orchestrated deliberative services in collaboration. If the deliberative service in collaboration only accepts requests from a limited set of clients, this pattern can be relevant. To be precise, the service ( S 0 in Figure 12) that sends requests to the deliberative service in collaboration needs to be an accepted client for the deliberative service in collaboration. Example In the coordination scenario represented in Figure 3(a) the deliberative service in collaboration is applied for the Online Payment, because it is the Finance that sends a arrange online payment request to the Online Payment (see Figure 13). This coordination scenario is possibly preferable when the Online Payment only accepts requests (to arrange online payments) from the Finance. Related patterns This pattern is related to what is often described as a choreography [15, 2], because the main idea behind a deliberative service in collaboration is that two services collaborate together. 3 Applying the patterns in practice In this section our patterns are evaluated by applying them in practice. In particular we show how the patterns are useful to coordinate both tasks in workflow patterns and transactions. We assume that each task in a workflow pattern or transaction is executed by Writers Workshop F (Software) - paper F3 15

16 3.1 Coordination in workflow 3 patterns APPLYING THE PATTERNS IN PRACTICE consuming exactly one service. We do not reflect on tasks that are executed by consuming more than one service. Nor do we describe the coordination of services that support multiple tasks. The coordination of processes containing that sorts of tasks can be considered as a special case of a coordination problem. We believe our patterns can be similarly applied to that sort of processes. Furthermore we assume that event information concerning the completion or failure of a task is available at the service that completes that task. 3.1 Coordination in workflow patterns Workflow patterns are often used for the evaluation of business process modeling languages, because these patterns are considered as fundamental process constructs. Therefore, we try to prove the value of our patterns by showing that our patterns can be used to coordinate the sequence of activities specified in a workflow pattern. In particular, we will focus in this section on the basic control flow patterns (sequence, parallel split, synchronization, exclusive choice, simple merge) and advanced branching and synchronization patterns (multichoice, synchronizing merge, multi-merge, discriminator). First we will discuss the coordination of the sequence pattern. The other basic workflow patterns can be classified as either a split pattern (parallel split, exclusive choice, multi-choice) or a join pattern (sychronization, simple merge, synchronizing merge, multi-merge, discriminator). Therefore, we will limit our discussion to the coordination of one split pattern (parallel split) and one join pattern (synchronization). Analogously, one can construct coordination scenarios for the remaining patterns Sequence pattern The sequence workflow pattern consists of two tasks 1 and 2, whereby Task 2 can only start when Task 1 is completed. If services 1 and 2 support these tasks, the pattern requires that 2 must start the execution of Task 2 when 1 has completed the execution of Task 1. Event information concerning the completion of Task 1 is available at 1. For both Task 1 and Task 2 one needs to decide which entity holds the task logic and interacts with the service supporting the business process task. In terms of our patterns, this means that for both 1 and 2, we need to choose between either a deliberative service or a reactive service. Additionally, in case of a deliberative service, we can optionally consider a orchestrated deliberative service (meaning that 1 and 2 are orchestrated together by the same orchestrator), deliberative service in collaboration (meaning that one service is the service requestor of the other service) and a combination of the two variants (orchestrated deliberative service in collaboration). Hence, for both 1 and 2 there exist five different solutions, resulting in twenty-five combinations (see Figure 14). Theoretically, this would mean that there are twenty-five ways of coordinating the sequence pattern. However, as shown in Figure 14 some combinations are not possible, while other combinations result in equal coordination scenarios. Writers Workshop F (Software) - paper F3 16

17 3.1 Coordination in workflow 3 patterns APPLYING THE PATTERNS IN PRACTICE These combinations result into the same coordination scenario 1 2 REACTIVE SERVICE DELIBERATIVE SERVICE ORCHESTRATED DELIBERATIVE SERVICE ( 1 and 2 are orchestrated together) DELIBERATIVE SERVICE IN COLLABORATION ( 1 is service requestor of service 2) ORCHESTRATED DELIBERATIVE SERVICE IN COLLABORATION ( 1 and 2 are orchestrated together) ( 1 is service requestor of service 2) REACTIVE SERVICE Implies that 2 is in collaboration Implies that 2 is orchestrated DELIBERATIVE SERVICE Implies that both services are orchestrated Not possible ORCHESTRATED DELIBERATIVE SERVICE ( 1 and 2 are orchestrated together) Implies that 1 is in collaboration Implies that both services are orchestrated Not possible Not possible DELIBERATIVE SERVICE IN COLLABORATION ( 2 is service requestor of service 1) Implies that 1 is orchestrated Not possible Not possible ORCHESTRATED DELIBERATIVE SERVICE IN COLLABORATION ( 1 and 2 are orchestrated together) ( 2 is service requestor of service 1) Not possible Not possible Not possible Not possible These combinations result into the same coordination scenario Figure 14: Combining the patterns to coordinate a sequence. Shaded cells result into the same coordination scenario. Writers Workshop F (Software) - paper F3 17

18 3.1 Coordination in workflow 3 patterns APPLYING THE PATTERNS IN PRACTICE As shown in Figure 14 nine combinations are not possible. This is easy to understand when considering the orchestrated deliberative service in collaboration pattern. Suppose that 1 is an orchestrated deliberative service in collaboration. 1 as deliberative service in collaboration means that 2 is the service requestor of 1. 1 as orchestrated deliberative service means that the service requestor of 1 is also the service requestor of 2. Hence, the service requestor of 2 is 2 itself, which implies that 2 is a reactive service. Therefore, any combination between a orchestrated deliberative service in collaboration and a deliberative service (including its variants) is impossible (see last column and row in Figure 14). If one service is an orchestrated deliberative service and the other service is a deliberative service, then the latter service needs per definition to be an orchestrated deliberative service as well. As such, combinations between an orchestrated deliberative service and an deliberative service in collaboration can be considered as a combination between an orchestrated deliberative service and an orchestrated deliberative service in collaboration. However, as discussed before, any combination between a orchestrated deliberative service in collaboration and any kind of deliberative service is impossible. Therefore, a combination between an orchestrated deliberative service and an deliberative service in collaboration is impossible. If one combines a reactive service with a orchestrated deliberative service, then the reactive service is also service requestor of the orchestrated deliberative service. Hence, the latter service is also a deliberative service in collaboration. Similarly, one can see that any deliberative service in collaboration combined with a reactive service is also a orchestrated deliberative service. Therefore, these combinations result into the same coordination scenario as constructed by the combination of a reactive service and a orchestrated deliberative in collaboration (see shaded cells in Figure 14). A concrete coordination scenario can be evaluated by studying the consequences of the patterns that are combined into the coordination scenario. For example, if one would like to limit the overall complexity of the coordination scenario, it is advisable to design 2 as a deliberative service in collaboration. Since 1 has event information that is needed by the service requestor of 2, the overall complexity of the coordination scenario is decreased if 1 is the service requestor of 2. In the example discussed in section 1.1 there is one sequence workflow pattern (see Figure 1): Checking for unpaid invoices (Task 2) must be executed after the customer s request is processed (Task 1). In the coordination scenarios represented in Figure 2(b) this sequence is coordinated using a combination of a orchestrated deliberative customer service and a orchestrated deliberative finance service. In the coordination scenarios represented in Figures 2(a), 3(a) and 3(b) a combination of a reactive service and a orchestrated deliberative service in collaboration forms the coordination logic. Writers Workshop F (Software) - paper F3 18

19 3.1 Coordination in workflow 3 patterns APPLYING THE PATTERNS IN PRACTICE Task 2 Task 1 Task 3 Task 4 Figure 15: Parallel split pattern represented in BPMN Split pattern (parallel split) In the parallel split workflow pattern the execution of several tasks needs to be started in parallel after the completion of a certain task. In what follows we refer to the latter task as the before-split task, while the other tasks, which are executed in parallel, are referred to as the after-split tasks. Analogously, we refer to the service supporting the before-split task as the before-split service and services supporting after-split tasks are referred to as after-split services. In figure 15 the parallel split pattern is visualised in BPMN. Task 1 is the beforesplit task, while Task 2, 3 and 4 are the after-split tasks. Similar to the discussion above (about the sequence workflow pattern) one could study all possible combinations of our patterns to construct an appropriate coordination scenario for the parallel split workflow pattern. However, since a parallel split consists of at least three tasks, one can, theoretically, consider 125 coordination scenarios. Therefore, it is better to first make a choice between a reactive service and a deliberative service. Subsequently, one can consider variants of the deliberative service in order to optimise some forces. For example, as discussed in this article a orchestrated deliberative service can be valuable in case of common event information needs. Since this is clearly the case in the split pattern (all tasks after the split needs to be executed when the task before the split is completed), it is advisable to construct a coordination scenario in which after-split services are orchestrated deliberative services. As such, the event information available at the before-split services only needs to be transferred once to the entity that is orchestrating the after-split services. Additionally, one can motivate for the use of a deliberative service in collaboration for the after-split services. In particular, this would mean that the before-split services takes the role of service requestor for all after-split services (see figure 16). As explained before, reactive services have a higher degree of autonomy and the use of such services tends to lead to a loose coupling between services. Supposing that after-split services are reactive services, the loose coupling results into a sort of improved flexibility because an after-split can be easily added or removed from the service-based system without having to change the system drastically. This is in contrast to the solution described above, which is based on orchestrated deliberative services and which requires a change in the orchestrating entity for each to be added or removed after-split service. Writers Workshop F (Software) - paper F3 19

20 3.2 Coordination in transactional 3 APPLYING patterns THE PATTERNS IN PRACTICE 1 React to event(s) by starting Task 1 2 L 3 Event Information S 1 If Task 1 is completed, send requests to S 2, S 3 and S 4 3 L L Request 1 2 L 4 S 2 Request 4 Execute task 2 S 3 4 Execute task 3 Request S 4 4 Execute task 4 Figure 16: Coordinated parallel split using a reactive (before-split) service and orchestrated deliberative (after-split) services in collaboration Join pattern (synchronization) In the synchronization workflow pattern the execution of a task needs to be started when all tasks in a set of other tasks are completed. In what follows we refer to the first task as the after-join task, while the other tasks, which needs to be completed before the after-join task can start, are referred to as the before-join tasks. Analogously, we refer to the services supporting the beforejoin tasks as the before-join services and the service supporting the after-join task is referred to as the after-join service. In figure 15 the synchronization pattern is visualised in BPMN. Tasks 1, 2 and 3 are the before-join tasks, while Task 4 is the after-join task. Similar to the coordination of the parallel split workflow pattern one can compose a large set of coordination scenarios for the join workflow pattern by combining our patterns in different ways. For each business process task one first needs to make a choice between a reactive service and deliberative service. Subsequently, one can consider variants of the deliberative service in order to optimise some forces. In contrast to the split pattern, there are no common event information needs in the join pattern, which implies that a orchestrated deliberative service does not decrease the overall coordination complexity. Similarly, designing the after-join service as a deliberative service in collaboration does not simplify the coordination scenario, because the after-join service needs event information available at several services (all before-join services). 3.2 Coordination in transactional patterns Our patterns can also be valuable when coordinating transactions. In Figure 18 a transaction is visualised using BPMN. The transaction consists of three parallel tasks (Tasks 1, 2 and 3). If one or more tasks fail, all other tasks need to be compensated using Tasks 1, 2 and 3. These requirements results in a set of sequence dependencies resulting in the following set of information needs (assuming L x is the service requestor of X, and Tasks X and X are Writers Workshop F (Software) - paper F3 20

21 3.2 Coordination in transactional 3 APPLYING patterns THE PATTERNS IN PRACTICE Task 1 Task 2 Task 4 Task 3 Figure 17: Synchronization pattern represented in BPMN Task 1 Task 1' Task 2 Task 2' Task 3 Task 3' Figure 18: A transaction consisting of three tasks and corresponding compensating tasks represented in BPMN Writers Workshop F (Software) - paper F3 21

22 REFERENCES supported by service S x ): L 1 needs event information concerning service S 2 and S 3 L 2 needs event information concerning service S 1 and S 3 L 3 needs event information concerning service S 1 and S 2 Since L 1 and L 3 both need event information concerning service S 2, it is useful to create one orchestrating entity that is the service requestor of both service S 1 and S 2. This means that services S 1 and S 3 are orchestrated deliberative services. Furthermore, it is also advisable to combine L 2 and L 3 since both need event information concerning S 1. This means that services S 2 and S 3 are orchestrated deliberative services. Hence, in order minimise the complexity of the coordination logic it is preferable to combine logic L 1, L 2 and L 3. Figure 19(b) shows such a coordination scenario using orchestrated deliberative services, while Figure 19(a) shows a more complex coordination scenario using deliberative services. The green arrows represent the required event information transfers. 4 Conclusion In this article we have presented four patterns that facilitate the management of sequence dependencies between component services in a service composition. Furthermore we have proven the value of our patterns by applying these patterns to both workflow patterns and transactional patterns. These applications showed that the patterns support the process of constructing an optimal coordination scenario, that manages sequence dependencies between component services. In the future we intend to study how our patterns for the management of sequence dependencies can be combined with the data dependencies patterns that we have developed in the past. Acknowledgements The authors would like to thank Uwe Zdun for his many constructive and valuable remarks during the shepherding process. This has been written as part of a project funded by the Research Fund K.U.Leuven (OT 05/07 and IOF HB/07/022), whose support is gratefully acknowledged. References [1] A. Barros, M. Dumas, and A.H.M. Hofstede. interaction patterns. Lecture notes in computer science, 3649:302, [2] A. Barros, M. Dumas, and P. Oaks. Standards for web service choreography and orchestration: Status and perspectives. In Business Process Management Workshops, pages Springer, Writers Workshop F (Software) - paper F3 22

23 REFERENCES REFERENCES Task logic: Cancel hotel Task logic: Cancel car Task logic: Cancel flight Cancel hotel Cancel car Cancel flight Hotel Booking Car Rental Booking Flight Booking (a) Complex coordination scenario Task logic: Cancel hotel Task logic: Cancel car Task logic: Cancel flight Event information: Hotel booking failed Cancel hotel Cancel car Cancel flight Event information: Flight booking failed Hotel Booking Car Rental Booking Flight Booking Event information: Hotel booking failed (b) Optimised coordination scenario Figure 19: Coordination scenarios for a transaction such as shown in Figure 18 where Task 1, 2 and 3 are respectively Book hotel, Book car and Book flight, while Tasks 1, 2 and 3 are respectively Cancel hotel, Cancel car and Cancel flight Writers Workshop F (Software) - paper F3 23

24 REFERENCES REFERENCES [3] B. Benatallah, F. Casati, H. Skogsrud, and F. Toumani. Abstracting and Enforcing Web Protocols. International Journal of Cooperative Information Systems, 13(4): , [4] B. Benatallah, F. Casati, and F. Toumani. Web service conversation modeling: a cornerstone for e-business automation. Internet Computing, IEEE, 8(1):46 54, [5] B. Benatallah, F. Casati, F. Toumani, and R. Hamadi. Conceptual Modeling of Web Conversations. Procs of CAiSE, [6] G. Decker, O. Kopp, F. Leymann, and M. Weske. BPEL4Chor: Extending BPEL for modeling choreographies. In IEEE International Conference on Web s, ICWS 2007, pages , [7] N. Desai, AK Mallya, A.K. Chopra, and M.P. Singh. Interaction protocols as design abstractions for business processes. IEEE Transactions on Software Engineering, 31(12): , [8] N. Desai and MP Singh. Protocol-based business process modeling and enactment. Web s, Proceedings. IEEE International Conference on, pages 35 42, [9] T. Erl. SOA Design Patterns. The Prentice Hall -Oriented Computing Series From Thomas Erl, page 800, [10] E. Gamma, R. Helm, R. Johnson, and J. Vlissides. Design patterns: elements of reusable object-oriented software. Addison-Wesley Longman Publishing Co., Inc. Boston, MA, USA, [11] G. Hohpe and B. Woolf. Enterprise integration patterns: Designing, building, and deploying messaging solutions. Addison-Wesley Longman Publishing Co., Inc. Boston, MA, USA, [12] T.W. Malone and K. Crowston. The interdisciplinary study of coordination. ACM Computing Surveys (CSUR), 26(1):87 119, [13] G. Monsieur, M. Snoeck, and W. Lemahieu. A pattern language for input data provisioning. Proceedings of the 16th Conference on Pattern Languages of Programs (PLoP) (to be published), [14] M. Papazoglou, A. Delis, A. Bouguettaya, and M. Haghjoo. Class library support for workflow environments and applications. IEEE Transactions on Computers, 46(6): , [15] C. Peltz. Web services orchestration and choreography. Computer, 36(10):46 52, [16] W3C Candidate Recommendation. Web services choreography description language version 1.0, [17] OASIS Standard. Web services business process execution language version 2.0, Writers Workshop F (Software) - paper F3 24