According to our example, an open Payment service can be specified using ... that act as gateways for controlling its execution and exchanging data with other ...
Defining and coordinating open-services using workflows Khalid Belhajjame, Genoveva Vargas-Solar, and Christine Collet LSR-IMAG, Université de Grenoble BP 72 38402 Saint-Martin d’Hères, France {Khalid.Belhajjame, Genoveva.Vargas, Christine.Collet}@imag.fr
Abstract. Recently, workflow technology has been widely accepted as a mean for integrating services to build applications (services). Provided a set of services a workflow is used to coordinate and to synchronize their executions. This paper proposes an approach based on workflow technology and an associated mechanism for defining and coordinating services. Given a service provider that exports a set of methods a workflow can be defined for coordinating calls to such methods, in order to program a service. A service definition is decoupled from the capabilities of the service provider, thus a service may be adapted according to different application requirements. Services coordination is carried out by an orchestrator workflow that provides a fine control on their executions. Definition and coordination are characterized by a set of properties that ensure the correct behaviour of the resulting application (service). Key words: services integration, workflow management, service definition, services coordination.
1 Introduction The idea of using workflow technology to build applications out of existing services is not new. Provided a set of services a workflow can be used to coordinate and to synchronize their execution. Activities of such a process are used to control services execution, the controlflow describes dependencies among them, and the dataflow specifies how data are exchanged among them. The diversity of systems [4, 3, 9, 13] and languages [10, 7] that have been recently proposed shows the potential and the relevance of such an approach. Generally speaking, two complementary techniques are used for integrating services: wrapping [4] and coordination [3]. Using the wrapping technique, pre-existing services are wrapped to provide an entry point for activating the service. Wrapped services are then orchestrated by a workflow which is executed by an engine. Existing technology suffers from some drawbacks. In general, a service is a black box accessible through a method call. There is no mean to suspend, resume, or exchange data with a service during its execution. A service cannot be reconfigured or modified to meet new application requirements. Yet, modifying services can be useful when new requirements have to be considered. Our research contributes to the construction of open services that can be synchronized for building out new applications or services. This paper proposes an approach
2
Khalid Belhajjame et al.
based on workflow technology and an associated mechanism called A EROS, for defining and orchestrating services. It describes how it provides openness to services and fine control on their executions. Furthermore, it discusses properties that have to be verified such that resulting applications can be executed correctly. Accordingly, the paper is organized as follows. Section 2 gives an overview of our approach. Section 3 presents a service manager, describes the model it supports and characterizes a service through a set of properties. Section 4 presents the orchestrator manager and it shows how it synchronizes services. Section 5 describes A EROS an infrastructure for instantiating Service managers and Orchestrator managers. Section 6 compares our approach with existing works. Finally, Section 7 concludes the paper and gives some research perspectives.
2 Overview of the approach The following introduces the notion of open service and shows how autonomous service providers (software components) can provide customized services according to different application requirements. It also shows how open services can be finely orchestrated for building applications (services). 2.1 Motivations Consider a flight booking application built out of the following services. Adventurer manages clients needing to book flights. Payment contacts bank servers for executing billing transactions on given customers accounts. Reservation searches flight offers and manages a flight data base. Current approaches [3, 4, 9] assume that services provide an interface of independent methods. Using a service implies executing a method call (service call). Integrating services means ordering method calls in order to build an application. Assuming that getInfo(), reserveFlight() and withdraw() are methods provided respectively by the above services. The resulting application illustrated in Figure 1, consists in calling getInfo() for letting the client express his/her requests about a flight (e.g., Mexico - Paris, 19 may 2003, Air Mexique). In response, a list of possibilities is proposed by the service. The client can then choose and reserve a flight calling reserveFlight() offered by the reservation service. Finally, the Payment service is contacted to withdraw() the corresponding amount of money for paying the flight and validating the reservation. Under this strategy, services integration is hard coded at the application level. Furthermore, the approach used for conceiving services is limited when they need to be configured for fulfilling specific application requirements. For example, assume that the Reservation service returns only flights having available places, and that a client wants to have information even about those flights with no places. In such a case, the service has to be modified but this is often impossible since services are "black boxes"! Suppose now that a client wants to guide the reservation process, for example, to avoid searching flights of a specific airline that he/she does not want to use. In order to enable client interaction, the Reservation service must provide means to control its execution. Again, this implies the re-implementation of the service.
Defining and coordinating open-services getInfo()
reserveFlight ()
3
withdraw () end
beginning
Adventurer service
Reservation service
Payment service
Client
Fig. 1. Booking application
These examples highlight the need of an approach that enables an open definition of a service in order to support (i) customization, (ii) a fine control of its execution and of the way it can be integrated with other services for building applications. In the following we describe an approach that attempts to fulfil these needs.
2.2 Open service According to our approach a service is programmed on top of an autonomous service provider that provides a set of methods specified in an API. Methods are not independent among each other and their dependencies are defined within the API. Figure 2 illustrates the API of the Payment service provider. It is composed of a set of methods. The API also specifies the following relationships among methods. precedence (checkCredit,withdraw) means that withdraw can be called only after checkCredit has been executed. exclusion (withdraw,cancel) means that withdraw and cancel cannot both be executed within the same payment session. A service is a workflow that specifies the coordination of method calls respecting dependencies specified in the API. Activities in the workflow correspond to method calls on the service provider and the control flow defines the execution “semantic” of the service. According to our example, an open Payment service can be specified using such API. In Figure 2 Service 1 is a workflow representing a Payment service. First, payment is initialized (IntializePayment), then, simultaneously (AND-JOIN), the client information (ProcessRequest) and the product purchase amount (GetPurchaseAmount) are requested. If the client has enough money to pay the product then the operation is authorized (GetAuthorization) and the amount is withdrawn from his/her account (Withdraw), otherwise the payment operation is cancelled (Cancel). Finally, the operation is terminated (TerminatePayment). Furthermore, several services can be programmed on top of the same service provider. As shown in Figure 2, a new Payment service (Service 2) can be defined for performing the billing of several purchases instead of one. The amount of each purchase is requested before asking for the billing authorization. This configuration is described by an iterative loop (see Figure 2, Service 2).
4
Khalid Belhajjame et al. Service 1 Service 2 InitializePayment
InitializePayment ProcessRequest
GetPurchaseAmount ProcessRequest
GetAuthorization openSession GetPurchaseAmount getClientInfo withdraw
Payment
cancel
getPurchaseAmount
checkCapacity
service
GetAuthorization TerminatePayment
provider
withdraw
cancel
withdra
cancel
closeSession
TerminatePayment
Method
And−Split
Method Implementation And−Join Service beginning
Service end
Or−Split
Or−Join
Fig. 2. Customized services
2.3 Services orchestration Let us consider a new version of the flight booking application, assuming that services Adventurer, Reservation and Payment have been defined according to our approach (see Figure 3). First the Adventurer service sends information about the customer and his/her destination. Then, the Reservation service replies with a list of available flights. Once the customer has chosen a flight, a request is sent to the Reservation service. The Reservation service contacts the Payment service for executing the payment and waits for an acknowledgment. If the payment operation is accepted then the Reservation service sends reservation details to the Adventurer service, otherwise it sends an acknowledgment notifying the failure of the operation. Note that services executions cannot be independent and that they have to be synchronized in order to build the application. For example, the execution of the Payment service must be interrupted after its initialization until the orchestrator workflow provides it with information concerning the client and the purchase amount. Therefore, it is necessary to have means to interrupt a service execution so that it can be synchronized to send/receive information to/from another service necessary for continuing the execution of each service and of the application as a whole. As shown in Figure 4, in our approach, each service provides a set of entry points that act as gateways for controlling its execution and exchanging data with other services (i.e., interrupt the execution until input data have arrived, continue the execution once input data are delivered). Such entry points are not hardcoded, they are associated to a service according to the global application characteristics. Applications (services) is performed according to control flow and data flow implemented by an orchestrator workflow (see Figure 4). Activities of the orchestrator
Defining and coordinating open-services
Reservation service
Adventurer Service
5
Payment Service
client and destination information
list of available flights
chosen flight
confirmation client information purchase amount
ack ack
Fig. 3. Flight booking application
workflow are used to control the progress of services execution and they correspond to service calls on entry points. The control flow (activities order) specifies services dependencies, and the data flow specifies input and output data exchanged among them. Orchestrator workflow
Adventurer service
Payment service
Entry point
Reservation service
Fig. 4. Services orchestration
2.4 Definition and orchestration mechanisms Services specified under our approach are managed by a service manager. A service manager is a mechanism that orchestrates the execution of a service by interacting with a service provider. It also provides interfaces for accessing services definitions and for adapting services: activities can be added or deleted from the service and their dependencies can be modified. Thereby, services definition is open and it can be customized.
6
Khalid Belhajjame et al.
An orchestrator manager is specialized for managing an orchestrator workflow that synchronizes services executions. Therefore it interacts with existing service managers for exchanging input and output data produced/consumed by services. Given a services orchestration specification, the orchestrator manager contacts the corresponding service managers and specifies entry points that must be associated to a service. At execution time, the orchestrator manager interacts with services managers for instantiating, interrupting and resuming services execution through entry points, thereby acting as an information and control broker among services.
3 Service Manager A service manager is supported by a service model that characterizes service providers, service activities, and the way they have to be synchronized for defining a service. The following details the service model, it then discusses its properties and describes the architecture of a service manager. 3.1 Service model Figure 5 illustrates the UML diagram representing the service model. It is composed of four main classes: Service provider, Method, Dependency and Service.
ServiceProvider IdPE: String Url: String Protocol: String
Service IdService: String
1,N
startCondition () endCondition ()
1,1 pushMethod (Method) popMethod (Method) pushDependency (Dependency) popDependency (Dependency)
methodName correspond (ActivityName, IdService)
1,N
1,N
Ordering 1
1,1
1
Activity
Method MethodName: String
Name: String
1,N
RelevantData Name: String type: Type
Domain: {
