Verifying Composite Service Transactional Behavior Using Event

1 downloads 0 Views 1MB Size Report
BPM (Business Process Management) and integrate applications in diverse and het- ... providing a nice theoretical framework, ATMs are too database-centric, ...
Verifying Composite Service Transactional Behavior Using Event Calculus Walid Gaaloul1 , Mohsen Rouached2, Claude Godart2 , and Manfred Hauswirth1 1

DERI-NUIG IDA Business Park, Galway, Ireland {walid.gaaloul,manfred.hauswirth}@deri.org 2 LORIA-INRIA-UMR 7503 BP 239, F-54506 Vandœuvre-les-Nancy Cedex, France {rouached,godart}@loria.fr

Abstract. A key challenge of Web service (WS) composition is how to ensure reliable execution. The lack of techniques that support non-functional features such as execution reliability is widely recognized as a barrier preventing widespread adoption. Therefore, there is a growing interest for verification techniques which help to prevent WS composition execution failures. In this paper, we propose an event driven approach to validate the transactional behavior of WS compositions. Using the Event Calculus to formally specify and check the transactional behavior consistency of WS composition, our approach provides a logical foundation to ensure recovery mechanisms consistency at design time and report execution deviations after runtime.

1 Introduction Service oriented architecture is gaining prominence as a key architecture to support BPM (Business Process Management) and integrate applications in diverse and heterogeneous distributed environments. Enterprises are able to outsource their internal business processes as services and make them accessible via the Web. Then, they can dynamically combine individual services to provide new value-added WS compositions or composite services (CS). It is widely recognized that one of the barriers preventing widespread adoption of this technology is a lack of products that support nonfunctional features of applications, such as execution reliability. Due to the inherent autonomy and heterogeneity of Web services, the guarantee of correct CS executions remains a fundamental problem issue. Service execution reliability is a challenging aspect of service composition that has not been deeply investigated so far despite its importance. In order to ensure a correct and reliable CS execution, our interest is on analysing and checking Web service transactional behavior consistency. An execution is correct 

The work presented in this paper was supported by the EU funding under the SUPER project (FP6-026850) and by the Lion project supported by Science Foundation Ireland under Grant No. SFI/02/CE1/I131.

R. Meersman and Z. Tari et al. (Eds.): OTM 2007, Part I, LNCS 4803, pp. 353–370, 2007. c Springer-Verlag Berlin Heidelberg 2007 

354

W. Gaaloul et al.

if it reaches its objectives or fails (properly) according to the designers requirements. In this paper, we propose a formalism based on the Event Calculus (EC) [1] for specifying CS failure handling policies and formally validate the transactional behavior of the CS model, and for checking and analyzing CS execution consistency. EC is interesting because it supports the direct representation of events that are used in such policies, and the advantage of such a formalism is that it facilitates a common representation for transactional behavior and supports the same logical foundation for verification at both design time and after execution time. The transactional behavior verification can be done either a-priori, i.e., at design time, or a-posteriori, i.e., after runtime to test and repair design errors, and formally verify whether the process design does have certain desired properties. For the a-priori part of the work, we must be able to express CS using a formalism we can reason on. For the a-posteriori part of the verification, CS execution should be auditable by providing functionalities to collect execution logs. In our approach, WS logs are used not for mining but for a-posteriori verification of CS transactional behavior.

Fig. 1. CRB illustrative example

In the following, we introduce a scenario to illustrate our approach. Let us consider a Car Rental Broker (CRB) application (Figure 1). This CS acts as a broker offering its customers a set of choices during the Customer Requirements Specification (CRS) service. The CIC service checks the customer ID while the Car Checking Availability (CCA) service provides available cars information and the respective car rental companies. Afterwards, the customer makes his choice and agrees on rental terms in the CA service. Finally, the customer is requested to pay either by credit card (CC), by check (CH), or cash (SH). To deal with failures, the designers of the composite service may augment this control flow with a set of transactional requirements. For instance, they may require to compensate CCA and CRS if CIC fails. Also, they may specify CH as an alternative if CC fails and SH should be re-executed until success in case of failure. Failure handling mechanisms are not provided for the other services that are supposed to never fail. The main problem is how to ensure that the specified CS model is consistent or valid and guaranties reliable executions. In this paper, we introduce in Section 2 our transactional CS model. In Section 3, we present how we specify the transactional behavior using the EC. The validation of our model is explained in section 4. Section 5 is dedicated to implementation issues. Finally, section 6 outlines some related works before concluding.

Verifying Composite Service Transactional Behavior Using Event Calculus

355

2 Transactional Behavior in Composite Web Services In the loosely coupled environment represented by Web services, long running applications will require support for recovery and compensation, because machines may fail, processes may be cancelled, or services may be moved or withdrawn. Web services transactions also must span multiple transaction models and protocols native to the underlying technologies onto which the Web services are mapped. However, handling failures using the traditional transactional model for long running, asynchronous, and decentralized activities has been proven to be unsuitable. Advanced Transaction Models (ATMs) [2] have been proposed to manage failures, but, although powerful and providing a nice theoretical framework, ATMs are too database-centric, limiting their possibilities and scope [3] in this context (e.g. their inflexibility to incorporate different transactional semantics as well as different behavioural patterns into the same structured transaction). In the same time, workflow has became gradually a key technology for business process automation [3], providing a great support for organizational aspects, user interface, monitoring, accounting, simulation, distribution, and heterogeneity. In our transactional CS model, we propose to combine workflow flexibility and transactional reliability to specify and orchestrate reliable Web services compositions. In this section, we show how we combine a set of transactional services to formally specify the transactional CS model in Event calculus. We illustrate in particular how we model the composed services scheduling at various levels of abstraction. At the beginning, we show how a transactional CS defines axioms on the transitions of its composing services (Section 2). Then, we show how these axioms enable to express services dependencies on a higher level of abstraction (Section 2.3). These dependencies define the control flow (workflow flexibility) and the transactional flow (transactional reliability). 2.1 Event Calculus Our approach uses the Discrete EC proposed by Mueller [4] as an extension of the classic EC, to declaratively model event based requirements specifications. The approach, that we present, adopts an EC reasoning to verify CS transactional behavior. This approach is defined by the specification of the axioms describing the transitions carried out and their effects on the services states during CS instance executions. Compared to other formalisms, the choice of EC is motivated by both practical and formal needs, and gives several advantages. From a formal point of view we have three major advantages: First, in contrast to pure state-transition representations, the EC ontology includes an explicit time structure. This helps managing event-based systems where a number of input events may occur simultaneously. Second, the EC ontology is close enough to popular standards like WSBPEL support automatic into the logical representation. Thus, we use the same logical foundation for verification at design time (a-priori analysis) and after runtime (a-posteriori analysis). Third, the semantics of non-functional requirements can be represented in EC, so that verification is once again straightforward. We adapt a simple classical logic form of the EC, whose ontology consists of (i) a set of time-points isomorphic to non-negative integers, (ii) a set of time-varying properties called fluents, and (iii) a set of event types. The logic is correspondingly sorted, and includes the predicates Happens, Initiates, T erminates and HoldsAt, as well

356

W. Gaaloul et al.

as some auxiliary composite predicates defined in terms of these. Happens(a, t) indicates that event a actually occurs at time-point t. Initiates(a, f, t) (resp. T erminates (a, f, t)) means that if event a were to occur at t it would cause fluent f to be true (resp. f alse) immediately afterwards. HoldsAt(f, t) indicates that fluent f is true at t. 2.2 Transactional Web Service Model Definition 1 (Transactional Service). A transactional service, ts , is a triplet ts = (ID ∈ Object, E ⊂ States, T ⊂ T ransition) where ID is an object designating service ID, E is the set of its states and T is the set of transitions performing the changes between states. We denote T WS as the set of all transactional Web services.

By Web service we mean a self-contained modular program that can be discovered and invoked across the Internet. Each service (Definition 1) can be associated to a life cycle statechart. A set of of states (initial, active, cancelled, failed, compensated, completed) and a set of transitions (activate(), cancel(), fail(), compensate(), complete()) are used to describe the service status and the service behavior. A transition1 is performed through two predicates: The first predicate initializes a new state e2 (initiates (ts .tr(),e2 (ts ), t1)) and the second predicate finishes another state e1 (terminates (ts .tr(), e1 (ts ), t2)); t2