Our research project proposes an approach for providing transactional behavior to services coordination. In service composition functional aspects have been successfully addressed. However transactional properties have been poorly addressed using ad-hoc solutions at the back end of the systems. This situation makes current applications not reliable and not adaptable to existing distributed environments (i.e. Internet). The objective of our research is proposing mechanisms for adding transactional behavior to services coordination.
Service composition is an accepted paradigm for
building information systems. This kind of systems are not
built from scratch, but using existing software
components called services. A service is an autonomous
software that o®ers some functionality through a
network [
Let us consider a simpli¯ed e-commerce application implementing a purchase process (see Figure 1). Given a purchase order and payment information, it is necessary to get the bank authorization. Once the payment °c2006 for the individual paper by the paper' authors. Copying permitted for private and scienti¯c purposes. Re-publication of material on this page requires permission by the copyright owners.
Actually when an application logic is modeled,
application requirements and exceptional situations
are also speci¯ed. Besides, there are non functional
requirements that describe how the execution must
be done with respect to some observable attributes
like performance, security, transactional behavior, etc.
The current approaches for specifying transactional
behavior to services coordination can be classi¯ed in
three groups. Transactional behaviour is speci¯ed:
1. as a part of the application logic, when it is
modeled (e.g. what to do if shipment process fails).
2. as a part of the underlying communication
protocol. This approach is adopted by standards such
as BTP [
Such proposals are mostly based on well known
advanced transaction models (e.g. SAGAs, °exible
transactions, etc.). Although non functional requirements
are independent of functional ones they are in general
weaved within the application logic. This situation
makes applications very complex in the sense that they
are hard to maintain, not °exible and not adaptable
[
This paper introduces our research project that aims at providing transactional behavior to services coordination. Section 2 states the problem of providing transactional behavior to services coordination. Section 3 discusses the main characteristics of existing solutions. Section 4 sketches the transactional coordination approach that we propose. Finally, Section 5 concludes the paper and gives our research perspectives. 2
Transactional behavior models concurrent access to
resources. It is generally related to data. The
consistency and reliability of transactional behavior is
related to four properties: atomicity, consistency,
isolation, and duration [
These concepts need to be addressed to services composition under a new perspective and considering the following aspects: 1. Transactions are not related only to data but to execution processes. In the e-commerce example, ensuring the withdrawal of the account, shipment of the item and that the invoice sent are executed atomically concern processes execution and not data. 2. Applications are built by composing loosely coupled services o®ered by di®erent providers. In our example there are two providers: the bank and the shipment company. These providers do not o®er details about services implementation, and in general they do not share data or execution information which are required for executing transactions. 3. The lifetime of processes involved in a service oriented application is expected to be long (i.e. hours, days or weeks). While a classical transaction takes milliseconds to ¯nish, a long transaction takes hours, days or weeks to ¯nish. Long transactions need to be addressed for ensuring the quality of service (QoS) of the application and for avoiding blocking critical resources. Recalling the e-commerce example, the shipment of the item can take several days to ¯nish.
Given these characteristics, transactions management strategies must be adapted as follows: ² Atomicity must be relaxed to avoid blocking resources for long periods of time, given that the duration of transactions is unpredictable and there are some resources that cannot be blocked during the whole lifetime of a transaction (e.g. bank account). ² Consistency cannot be ensured by serial execution when atomicity is relaxed. ² Isolation cannot be too strict when multiple transactions operate upon common resources. ² Durability to maintain a consistent state across all the transactions executed by the system instead of ensuring persistency. 3
Several research projects have addressed transactional behavior for information systems, ¯rst in the context of DBMS and after for process oriented systems.
In DBMS, transactional behavior has been
tackled successfully to data through the concept of ACID
transactions [
In work°ow systems there are several approaches
that aim at ensuring consistency among computations
using process as execution units. WAMO [
In Web services, transactions are used to ensure
sound interactions among business processes. Web
services transactions (WS-Tx) [
Other approaches provide transactional
frameworks. [
Transaction policies [
In contrast to the above approaches, we consider that transactional aspects can be separated from the application logic and adapted to the characteristics of the services participating in a coordination, and to the application requirements of the target application. 4
In our approach the speci¯cation of transactional behavior for services coordination is addressed as follows: ² Application logic must be captured by using a coordination approach (i.e. work°ow technology). ² Transactional behavior must be de¯ned independently of the application logic by using atomicity contracts and associating a well de¯ned behavior to coordination participants. For example the activities bank authorization and process order of the e-commerce application (see Figure 1) need to be treated as an execution unit that must be atomically executed because according to the application, orders can be processed only if the payment has been authorised by the bank.
We propose an applications development cycle with the following steps (see Figure 2): 1. Speci¯cation. Given a service coordination that speci¯es the dependencies among services and the corresponding exchanged messages a developer can specify the intended transactional behavior (transactional speci¯cation) according to a model and its associated language that we propose (see below). 2. Preprocessing. In this phase, coordination and transactional speci¯cations are weaved by a preprocessor. This process automatically generates a coordination speci¯cation and the information required to enact the speci¯cation. 3. Execution. Transactional coordination is enacted by a transactional coordination engine that has a behavior evaluation module responsible of ensuring the speci¯ed transactional requirements. 4.1
We propose a transactional behavior model based on
the following concepts:
² Activity. It abstracts a service method call. It
can be classi¯ed according to its behavior on
failure [
The model we propose ful¯lls the current spirit of reusing practices existing in software engineering. Consequently, it characterizes existing coordination approaches and advanced transactional models. Thereby we ensure that non functional requirements are well abstracted and the resulting speci¯cation is sound. 4.2
We have speci¯ed the general architecture of an execution engine that consists of two main modules: ² Behavior evaluator detects execution failures and generates actions for ensuring the required transactional behavior according to given contracts for a target application. ² Coordination engine enacts the coordination speci¯cation. We are not interested in proposing a new engine, we de¯ne components that can interact with existing engines (i.e. transactional managers, security controllers, etc.).
We are currently conducting the implementation of an execution engine that uses ECA rules for implementing the behaviour evaluator and that can be plugged to a BPEL engine. 5
Emerging paradigms to build information systems, based on services as building blocks, promise to tackle the problems related to distribution through standardization. There are other QoS aspects that need to be addressed to ensure the success of this approach. Transactional behavior has been addressed successfully for managing data and processes execution in centralized and distributed environments. Proposed strategies and models do not necessary apply to services coordination where data is not the unit of transactions, applications are built by using loosely coupled distributed units and transactions are expected to be long duration (hours, days or even weeks). We noticed that existing coordination approaches have addressed non functional aspects in an ad-hoc fashion. We also noticed that current transactional services approaches are not °exible.
The main contribution of our approach is a transactional behavior model that clearly promotes a separation of concerns among application logic and the transactional behavior of services. Addressing transactional behavior by, i) implementing a separation of concerns strategy, ii) characterizing execution units, and iii) using recovery strategies, instead of implementing well known transactional models, makes our approach °exible and extensible.
We are currently ¯nalizing the state of the art and detailing our approach. Then, we will propose a framework for specifying transactional behavior managers for services oriented systems. We will also explore how to extend our model to other transactional properties such as isolation and durability.
Online
This research is partially related to the project DELFOS of the Franco-Mexican Laboratory of Informatics (LAFMI) of the French and Mexican governments. Alberto Portilla is a ¯rst year PhD student (double program) at the National Polytechnical Institute of Grenoble (INPG), Laboratory LSR-IMAG, and the Universidad de las Am¶ericas (UDLA), CENTIA. He works under the supervision of Prof. PhD. Christine Collet (INPG, France), PhD. Genoveva Vargas-Solar (full time researcher CNRS, France), Prof. PhD. Jos¶e-Luis Zechinelli-Martini (UDLA, M¶exico) and Prof. PhD. Luciano Garc¶³a-Ban~uelos (UATx, M¶exico). His research focusses on non functional aspects of services based applications. His studies are expected to be ¯nished in August 2008. His studies are supported by the Mexican Education Council through the program for improving the teaching system in Mexican public universities (PROMEP-SEP), the Autonomous University of Tlaxcala, M¶exico and the Jenkins Excellence Fellowship Program at UDLA.