A Component-Based Approach to Compose Transaction Standards

A Component-Based Approach to ComposeTransaction Standards

Romain Rouvoy1, Patricia Serrano-Alvarado2, and Philippe Merle1

1 INRIA Futurs, Jacquard Project,LIFL - University of Lille 1,

59655 Villeneuve d’Ascq Cedex, France{romain.rouvoy, philippe.merle}@inria.fr

2 ATLAS-GDD Team,LINA - University of Nantes,

44322 Nantes Cedex 03, [email protected]

Abstract. This paper tackles the problem of composition of transactionservices, which are governed by various transaction standards. Amongothers, we can cite the Object Transaction Service, Java Transaction Ser-vice, or Web Services Atomic Transaction. However, the Web ServicesAtomic Transaction standard encloses legacy transaction standards tosupport the Web Services application platform. This encapsulation in-troduces an additional complexity to the system and hides the speci-ficities of legacy transaction standards. When composing heterogeneouslegacy applications, the underlying transaction services are basically notcomposed transparently. This paper presents an approach to build anAdapted Transaction Service, named ATS, which supports several trans-action standards concurrently. The objective of ATS is to facilitate thetransaction standards composition. To introduce ATS we detail how theObject Transaction Service, Web Services Atomic Transaction, and JavaTransaction Service standards can be composed. Besides, an ATS imple-mentation is introduced using the GoTM framework. We show that thisfine-grained component-based approach does not introduce an additionaloverhead to legacy applications and supports well scalability. Moreover,this approach can be extended to other standards.

1 Introduction

For years, the number of transaction standards grows drastically. Among others,we can cite the Object Transaction Service (OTS) from the Object Manage-ment Group [1], the Java Transaction Service (JTS) from Sun Microsystems [2],or the Web Services Atomic Transaction (WS-AT) [3] published by Microsoft,IBM, IONA, BEA Systems, Hitachi and Arjuna Technologies. Current trendsdefine new transaction standards by encapsulating existing ones. For example,the WS-AT standard encloses the JTS standard, which encapsulates the OTSstandard. But this approach introduces an additional complexity for each layer,while loosing the specificities of each encapsulated transaction standard. When

W. Lowe and M. Sudholt (Eds.): SC 2006, LNCS 4089, pp. 114–130, 2006.c© Springer-Verlag Berlin Heidelberg 2006

A Component-Based Approach to Compose Transaction Standards 115

composing heterogeneous legacy applications, the underlying transaction servicesare basically not composed transparently.

This drawback leads us to propose a practical approach to compose trans-action standards. In this paper, we present an approach to build an AdaptedTransaction Service (ATS) and its implementation based on fine-grained com-ponents. The ATS composes several transaction standards simultaneously andensures the compliancy of the different functions. To design ATS, we analyze theinterfaces of the transaction standards, and we identify the required functions.Each function is derived into various strategies depending on the specific seman-tics. Therefore, ATS is built by composition of these strategies and adapters.Adapters ensure the compliance with transaction standards interfaces. Finally,we use GoTM to build the resulting ATS. GoTM is a framework that providesvarious fine-grained transaction components [4]. These components are imple-mented with Fractal, a component model that provides good properties in termsof modularity and performances [5]. To illustrate our approach, we build a trans-action service that composes the CORBA, Web Services and Java transactionstandards.

This paper is organized as follows. The problem of transaction standard com-position is presented in Section 2. Section 3 describes our approach to achievetransaction standard composition. The implementation of our solution with theGoTM framework is detailed and evaluated in Section 4. Section 5 discussesrelated works, and Section 6 concludes.

2 The Problem of Transaction Standard Composition

To illustrate the problem related to transaction standard composition, we usethe example of Flight Booking and Hotel Reservation applications, as depictedin Figure 1.

ThirdApplication

Web Services Application PlatformCORBA Application Platform

Web Services Atomic Transaction

Object Transaction Service

Java Transaction Service

WS Hotel

ReservationApplicationC

OR

BA

Flight Booking Application

Fig. 1. Illustration of the problem of transaction standard composition

These applications are hosted by different distributed application platforms(CORBA and Web Services), which support their own transaction standard. Inparticular, the CORBA application platform provides the Object TransactionService (OTS). The Web Services application platform provides the AtomicTransaction Service (WS-AT). The Third Application uses locally the Java

116 R. Rouvoy, P. Serrano-Alvarado, and P. Merle

Transaction Service (JTS). This third application can interact with both ap-plications remotely using the functionalities provided by each distributed appli-cation platforms.

Even if this architecture allows heterogeneous application platforms to inter-act, the transaction context1 is not implicitly propagated from an application toanother. That is, WS-AT, which handles Hotel Reservation transactions, doesnot cooperate with OTS, which controls the Flight Booking transactions. And,the third application, using JTS, can not synchronize its execution with the twoother applications.

Usually, to achieve such a synchronization, the third application should controlall the transaction services, and therefore use three different transaction Appli-cation Programming Interfaces (APIs). Thus, when it begins a new transaction,the third application should explicitly begin transactions in the three transactionservices. But, when the transaction commits, the third application should find away of coordinating the commit protocol of each transaction service. Existing ap-proaches use compensation mechanisms to support the coordination of multipletransactional activities [6]. But applications can not always define compensatingactions (e.g.: compensating the sending of an email). Therefore the compensatingactions may be limited in some coordination situations. Moreover, the definitionof a coordination algorithm at the third application level weaves the code relatedto non-functional properties (i.e., transaction services synchronization) with thebusiness code.

This paper proposes an approach to deal with the heterogeneity of existingtransaction standards. Instead of proposing to use a unified language or a newtransaction standard, we propose to build Adapted Transaction Services (ATS)that support several transaction standards concurrently. Therefore the third ap-plication uses only the interfaces provided by JTS and transactions are auto-matically coordinated in the two other transaction services. With this approach,legacy systems can be transparently composed together from a transactionalpoint of view.

3 ATS Design

This section begins with an overview of an ATS built to answer to the problem oftransaction standard heterogeneity depicted in Figure 1. Thus, the approach ap-plied to build this ATS is detailed. First, the considered transaction services areanalyzed to highlight the functions involved in each transaction standard. Next,these functions are abstracted and dependencies are identified. Each functionis extended into various strategies according to the semantics imposed by theconsidered standards. These strategies are then composed (i.e., linked together)to build the content of the Common Transaction Service (CTS). Finally, theATS is built by adding to the CTS necessary adapters to support JTS, WS-AT,and OTS standards.

1 Information related to the execution of the current transaction.


3.1 Overview of an ATS

Figure 2 introduces an ATS supporting OTS, JTS, and WS-AT standards.

Adapted Transaction Service (ATS)Common Transaction Service (CTS)

ThirdApplication

Web Services Application Platform

CORBA Application Platform

Web Services Transaction Adapter

Object Transaction Service Adapter

Java Transaction Service Adapter

HotelReservationApplication

Flight Booking Application

Fig. 2. An example of ATS supporting transaction standard composition

An ATS is composed of a set of adapters and a CTS. The CTS provides animplementation of a generic transaction engine. The CTS groups the behaviour ofall the functions supported by the ATS. The adapters provide compliance withthe considered transaction standards (OTS, JTS and WS-AT). The adaptersare responsible for mapping the operation performed on a particular transactionstandard to the functions provided by the CTS. The functions, required by theadapters, are provided by the CTS.

Thus, this modular architecture can be easily modified to support new trans-action standards. In this case, the content of the CTS is adapted according tothe chosen adapters to provide the minimal set of functions required.

3.2 Function Analysis

A function is a set of operations linked by their semantics. In particular, wemake the hypothesis that transaction services are based on the minimal set ofStatus, Coordination, and Participants functions. Then, we identify these func-tions for each APIs used by the applications to ensure transactional behaviour.More specifically, we consider the CosTransactions API, Java Transaction API,and Atomic Transaction Services provided by the OTS, JTS and WS-AT stan-dards, respectively. This analysis aims at confirming that the three identifiedfunctions are enough to compose transaction services.

JTA Analysis. The Java Transaction API (JTA) defines a set of Java inter-faces that provide transaction support to any Java application. Figure 3 lists theinterfaces involved in JTA.

Based on an analysis of this API, we establish the interface dependencies. Thesedependencies are illustrated with the ”uses” UML stereotype [7] in Figure 3. Forexample, the Transaction interface depend on the Status, Synchronizationand XAResource interfaces. The operations described in the Transaction inter-face require Synchronization and XAResource interfaces, while providing theStatus interface.


Fig. 3. Java Transaction API analysis

Next, we classify JTA interfaces according to the function indicated by theirsemantics. The identified functions are indicated with the ”function” UMLstereotype in Figure 3. For example, the semantics of the UserTransaction,Transaction, and TransactionManager interfaces refer to a Two-Phase Com-mit protocol [8]. Thus, we define the Coordination function to abstract the iden-tified semantics. We apply the same approach to each operation making up theAPI. As a result, we extract three functions: Coordination, Status and Partici-pants. The Status function controls the state of the transaction. The Participantsfunction manages the participants involved in the transaction.

CosTransactions Analysis. The CosTransactions API is defined using theOMG Interface Description Language and allows CORBA applications writtenin different programming languages to use it. Figure 4 identifies the interfacesinvolved in the CosTransactions API.

CosTransactions

«function»Coordination

«function»Status

«function»Participants

«interface»Terminator

«interface»Coordinator

«interface»Control

«interface»Current

«interface»TransactionFactory

«interface»RecoveryCoordinator

«interface»SubtransactionAwareResource

«interface»Resource

«interface»Synchronization

«interface»Status

«uses»«uses»

«uses»

«uses»

«use

s»

«use

s»

«use

s»

«uses»

«use

s»

Functions

Fig. 4. CosTransactions API analysis

We apply the same process as with JTA. Interface dependencies are first inferredfrom the transaction API. The functions involved in the CosTransactions API areidentified and we obtain the Coordination, Status and Participants functions.


WS Atomic Transaction Analysis. Web Services Atomic Transaction (WS-AT) is the last transaction standard specified. This standard allows transaction-aware Web Services distributed across a network to be synchronized withdifferent policies. The WS-AT standard is structured in several services, eachservice providing a specific function. Figure 5 identifies the services involved inthe Web Services Atomic Transaction standard.

Coordination AtomicTransaction


«function»Status


«uses»

«service»Activation

«service»Registration

«service»Completion

«service»CompletionWithAck

«service»PhaseZero

«service»2PC

«service»OutcomeNotification

«uses»

«uses»

«uses»«uses» «uses»

Functions

Fig. 5. WS Atomic Transactions analysis

The granularity of this standard is not the same than the two previous ones.Indeed, Web Services are based on message exchanges rather method invocations.Thus, we analyze the interaction between the services involved in the WS-ATstandard. The Registration service depend on the Activation service. This isbecause a Coordination Context should be created before participants can reg-ister with the transaction. The Completion, CompletionWithAck, PhaseZero,2PC and OutcomeNotification services encapsulate the WS-Atomic Transac-tion business logic. These additional services depends on the Registration serviceto interact with transaction participants. As a consequence, functions involvedin WS-Atomic Transaction are: Coordination, Status and Participants.

3.3 Strategy Definition

Function Summary. In this step, we associate each identified function with aset of generic operation signatures. This association depends on the operationsdeclared in the CosTransactions, WS Atomic Transaction and Java Transac-tion APIs. Next, the dependencies between the functions are inferred from theinterface dependencies established in the section 3.2.

As shown in Figure 6, the Status and Participants functions are not depen-dent on any other function. The Status function provides the operations requiredto handle the transaction status allowed by a given transaction model. The Par-ticipants function provides operations to manage the transaction participants.

The Coordination function updates the transaction status using the Statusfunction. It also ensures the coherence between the transaction status and theresource states. For example, updating the transaction status to commit impliesthat participants validate their modifications using the Participants function.Thus, the execute() operation changes the transaction status and notifies theparticipants involved in the transaction.


+setStatus()+getStatus()

«function»Status

«requires»

«requires»

«strategy»TwoPhaseCommit

«strategy»XAResources

«strategy»Synchronizations

«strategy»AtomicTransactionState

«strategy»SubTransactionAwareResources

+execute()


«strategy»SynchronizationsJTA

«strategy»Resources

+enlist()+delist()+notify()


«strategy»TransactionAwareParticipants

Fig. 6. Illustration of the function abstraction

However, transaction standards define also some semantics that should be re-spected by the implementations. These semantics are named strategies and areassociated to identified functions. A strategy can be an implementation of analgorithm, a protocol (e.g., the Two-Phase Commit protocol) or a specializationof an entity (e.g., XAResource). Figure 6 shows an overview of the possible strat-egy derivations for JTS, WS-AT and OTS from the identified functions. Thesestrategies are described in the following sections.

Two-Phase Commit Strategy. The TwoPhaseCommit strategy represents animplementation of the Two-Phase Commit (2PC) protocol for the Coordinationfunction. This protocol defines, among other things, a sequence of messagesthat ensures atomicity. Figure 7 shows the UML Interaction diagram [7] used todescribe a basic 2PC protocol.

Fig. 7. 2PC Interaction Diagram

As shown in Figure 7, the TwoPhase-Commit strategy extending the Coordina-tion function emits a prepare message.The Participants function answers to thismessage with a votecommit or vote--abort message. Depending on the collectedvotes, the TwoPhaseCommit strategy sendsa commit or an abort message to Partici-pants function. Once the participants haveachieved the validation process, the Partic-ipants function sends an ack message toacknowledge the coordination process. Ad-ditional strategies can be defined to imple-ment optimized versions of 2PC, such as Two-Phase Commit Presumed Commit(2PCPC) or Two-Phase Commit Presumed Abort (2PCPA) protocols (see [8]for more details).

Participants Strategies. The Participants function is extended by six strate-gies, which are adapted to the different types of resources defined in the


transaction standards. These strategies are the SubTransactionAwareResources,Synchronizations and Resources for OTS ; TransactionAwareParticipants forWS-AT and SynchronizationsJTA and XAResources for JTS. The differencesbetween these strategies are the list of messages that the resources can handle.For example, the Synchronization strategy handles commit and abort messages.The Resource strategy handles these two messages plus the prepare message.Each strategy is based on a set of specific ECA rules (Event/Condition/Action).These rules define the behaviour to apply on the participants involved in thetransaction depending on incoming messages.

1 global synchronizations23 on prepare? count(synchronizations)>0:4 foreach s in synchronizations do:5 s.beforeCompletion()6 on commit? count(synchronizations)>0:7 foreach s in synchronizations do:8 s.afterCompletion(Status.STATUS_COMMITTED)9 on abort? count(synchronizations)>0:

10 foreach s in synchronizations do:11 s.afterCompletion(Status.STATUS_ROLLEDBACK)

Fig. 8. SynchronizationsJTA Strategy ECA Rules

Figure 8 depicts the example of the SynchronizationsJTA strategy. The Eventpart corresponds to the messages received by the strategy prefixed by the on key-word. The Condition part checks that at least one participant is involved in thetransaction. The Action part applies a treatment to all the participants registeredin the transaction. These participants are notified before and after the comple-tion of the transaction in which they are involved. The afterCompletion()operation parameter depends on the outcome of the transaction (i.e., commit-ted or aborted). Additional ECA rules are defined for each strategy extendingthe Participants function.

Atomic Transaction State Strategy. The Status function is extended by theAtomicTransactionState strategy. This strategy can be configured using a stateautomaton describing the transaction state transitions.

The state automaton used in our example describes an atomic transaction asdepicted in Figure 9. We use the UML diagram State Machine [7] to describethe states involved in the lifecycle of an atomic transaction. These states arecommon to each transaction standard because all of them are related to atomictransactions. As shown in Figure 9, an atomic transaction starts in an Inactivestate. When it receives the start message, the atomic transaction moves to theActive state. Thus, an atomic transaction can be suspended and resumed usingstart and stop messages. To move to the validation phase, the atomic transactionshould be in the Active state and receives a prepare, abort or aborted message.


Preparing

Prepared

start

prepare

aborted

prepared

commitabort

committedaborted

abort

abort

aborted

stop

Committing Aborting

Committed Aborted

ActiveInactive

Fig. 9. Atomic Transaction State Diagram

The prepare message begins theTwo-Phase Commit protocol,moving the Transaction to thePreparing state. The abort mes-sage causes the transaction toabort unilaterally. The abortedmessage ends the transactionwithout applying the Two-PhaseCommit protocol. The abort andaborted messages result in thesame behaviour independently ofthe current state of the transac-tion. When a transaction in thePreparing state receives the pre-pared message, it moves to thePrepared state to decide the out-come of the transaction. When this decision is taken by the Coordination Proto-col, the transaction can commit if it receives the commit message. In this case, thetransaction enters in the Committing state to validate the transaction and thenmoves to the Committed final state once the decision is acknowledged. Any abortmessage received by a transaction state results in moving the in the Abortingstate to cancel the transaction before moving to the Aborted final state. Addi-tional State Machine diagrams can be defined to handle new transaction statessuch as the Compensating state [9].

3.4 Composition of the ATS

Once the transaction standards have been described in terms of functions andstrategies, the next step builds the Common Transaction Service (CTS) by com-position of strategies following function dependencies. The CTS is a generictransaction engine that provides common facilities to the three transaction stan-dards. This composition is implemented with the paradigm of a software bus [10].A software bus provides facilities to compose the strategies interacting usingmessages. For example, the commit or abort messages are propagated from theTwoPhaseCommit strategy to the Synchronizations strategy according to thedependency that links their associated functions (Coordination and Participantsrespectively).

Figure 10 gives an overview of the strategy composition used to build the CTS.This composition meets the requirements of JTS, WS-AT and OTS standards.The MessageBus bus propagates the messages between the strategies involvedin the CTS. Associations link a strategy to either a dependent strategy or theMessageBus in order to connect required to provided functions.

Once the CTS is built, it needs to be made compliant with the APIs of each ofthe considered transaction services. The result of this adaptation is the AdaptedTransaction Service (ATS). In practice, the adaptation is done by constructing


«bus»MessageBus

«strategy»TwoPhaseCommit

«strategy»AtomicTransactionState

«adapter»JTS

«adapter»OTS

«strategy»XAResources

«strategy»Synchronizations

«strategy»SubTransactionAwareResources

«strategy»SynchronizationsJTA

«strategy»Resources

«adapter»WS-AT

«strategy»TransactionAwareParticipants

Fig. 10. CTS: composition of JTS/WS-AT/OTS-compliant strategies

adapters that provide the operations required by the associated standard APIs,and require the CTS functions identified in Section 3.2.

Figure 10 illustrates the adaptation of CTS to JTS, WS-AT and OTS trans-action interfaces. In this step, an adapter for each of the transaction services isdefined. Each adapter is bound to the strategies it requires. The JTS adapterrequires the TransactionState, TwoPhaseCommit, XAResources and Synchro-nizationsJTA strategies. The OTS adapter requires the TransactionState, Two-PhaseCommit, Synchronizations, Resources and SubTransactionAwareResourcesstrategies. The WS-AT adapter requires the TransactionState, TwoPhaseCom-mit, TransactionAwareParticpants strategies.

3.5 ATS Use Case

This section introduces how the ATS is used in practice. This use case describesa simple scenario applied on the example depicted in Figure 2.

1. The Third Application creates a new transaction in the ATS via the JTSadapter. An adapted transaction context is automatically initialized by theATS. The transaction context associates the method invoked by the ThirdApplication with the created transaction.

2. The Third Application calls the Flight Booking Application using the CORBAplatform facilities. The transaction context is propagated to the target appli-cation via the CORBA Portable Interceptors mechanism [11]. In particular,the Client Portable Interceptor defines the OTS adapter of the ATS as thecurrent transaction service. The Server Portable Interceptor replaces the ex-isting transaction service by the OTS adapter during the execution of the ap-plication. As a consequence, the Flight Booking Application enlists Resourceand Synchronization participants in the OTS adapter of the ATS.

3. The Third Application invokes the Hotel Reservation Application (see Figure 2)using the Web Services application platform. The transaction context ispropagated as a WS-Coordination Context [12] in the header of the WebService request. This means that the Hotel Reservation Application will enlistits TransactionAwareParticipants in the ATS via the Registration Serviceprovided by the WS-AT adapter of the ATS.


4. The Third Application commits the transaction. The ATS synchronizes all theheterogeneous participants using the commit protocol embedded in the CTS.This means that the completion of the transaction is done independently ofthe transaction standard (i.e. OTS, JTS, WS-AT) used by the applications.Each participant is notified depending on its associated strategy.

4 Implementation Issues

In this section, we present the ATS implementation, which is based on the Fractalcomponent model and the GoTM framework.

4.1 The Fractal Component Model

The hierarchical Fractal component model uses the usual component, interface,and binding concepts [5]. A component is a runtime entity that conforms tothe Fractal model. An interface is an interaction point expressing the providedor required methods of the component. A binding is a communication chan-nel established between component interfaces. Furthermore, Fractal supportsrecursion with sharing and reflective control [13]. The recursion with sharingproperty means that a component can be composed of several sub-componentsat any level, and a component can be a sub-component of several components.The reflective control property means that an architecture built with Fractalis reified at runtime and can be dynamically introspected and managed. Frac-tal provides an ADL, named FractalADL, to describe and deploy automaticallycomponent-based configurations [14].

run

compositecomponent

primitive component

sharedcomponent

serverinterface

clientinterface

controller

bindingcontent

internalinterface

collectioninterface

Fig. 11. The Fractal component model

Figure 11 illustrates thedifferent entities of a typi-cal Fractal component archi-tecture. Thick black boxesdenote the controller part ofa component, while the in-terior of the boxes corre-sponds to the content partof a component. Arrows cor-respond to bindings, andtau-like structures protrud-ing from black boxes are in-ternal or external interfaces.Internal interfaces are only accessible from the content part of a component. Astarry interface represents a collection of interfaces of the same type. The twoshaded boxes C represent a shared component.

4.2 The GoTM Transaction Framework

Like Fractal, GoTM [4] is a project developed as part of the ObjectWeb ini-tiative. It is a software framework that provides a set of Fractal components


developed in Java and implementing generic transaction-related strategies. Thestatic configuration of the transaction service is described using the Fractal ADL,which allows the transaction service designer to select the default strategies touse. GoTM implements efficiently various validation protocols (e.g., 2PC, 2PC-PA, and 2PC-PC) [8] and a variety of resource handlers (e.g., XAResource,Resource, and Synchronization). This list of components is not exhaustive; theGoTM framework can be extended to include new components.

The GoTM framework additionally includes different optimizations to providegood performance to the transaction services built with GoTM. These optimiza-tions include the use of a pool of components and a caching controller to reducethe cost of component creation. GoTM uses configurable factories to describe andconfigure the created component instances. Finally, threading strategies (e.g., se-quential, threaded, or pooled) control the propagation of messages between thecomponents of the ATS. GoTM supports both Julia [5] and AOKell [15] imple-mentations of the Fractal component model.

4.3 ATS Implementation with GoTM

Implementing ATS with the GoTM framework requires implementing the enti-ties identified in Section 3 (functions, strategies, bus, etc.) with existing GoTMcomponents when possible. GoTM provides most of the identified strategies (e.g.,TwoPhaseCommit, AtomicTransactionState) as Fractal components.

The bus entity is mapped to an existing GoTM component that implementsa message bus. This message bus provides various message propagation poli-cies (e.g.: synchronous ordered, synchronous unordered or asynchronous). Thesepolicies allow implementing various 2PC protocols [8] and to provide variousoptimizations (e.g.: resources synchronization).

The strategy elements are mapped to similar GoTM components dependingon their characteristics. As an example, the 2PC strategy is implemented by the2PC component provided by GoTM. This composite component contains smallercomponents that describe the different steps of the 2PC protocol. Strategy com-ponents are composed with the message bus to form the Common TransactionService (CTS).

The adapter components ensure the compliance with the API of each trans-action standard. Therefore, the adapter components provide the standard APIsas server interfaces. The adapter component requires as client interfaces all thedependencies corresponding to the interfaces expressed in dependencies graphof Figures 3, 4 or 5. It can be easily automatically generated because all thetransaction-related algorithms are implemented by strategies. To allow this gen-eration, we use a conversion model describing how to redirect the incoming trans-action standard invocations to the interfaces provided by the GoTM components(see [16] for more details).

To obtain the ATS component, the CTS component is shared between the OTS, the WS-AT and the JTS adapter components. This architecture allows the OTS,WS-AT and JTS adapters to cooperate transparently via the CTS. Figures 12and 13 depict the resulting implementation of ATS. This implementation


is composed of a static and a dynamic part. The static part describes the architec-ture of the transaction service. The dynamic part describes the behaviour of onetransaction. Nevertheless the pattern of a common component shared betweenseveral adapter components is applied in the two parts.

Common Transaction Service (CTS)

Adapted Transaction Service (ATS)

TransactionFactory

TransactionCurrent

TransactionsCreated

TransactionModel

TransactionsActive

OTSAdapter

JTSAdapter

WS-ATAdapter

JTA

Cos

-T

rans

actio

nsW

S-A

tom

icT

rans

actio

n

Fig. 12. An Adapted Transaction Service implementation

The static part of the service is depicted in Figure 12. This part corre-sponds to the entry point of the service. The strategies available in the sta-tic part of the CTS consist in the management of activated transactions usingthe TransactionCurrent component. The active transactions are stored in theTransactionsActive component. The TransactionFactory component pro-vides facilities to create new instances of transactions. The transaction architec-ture is described in the TransactionModel component.

Common Transaction (CT)

2PCProtocol

MessageBus

JTS Resource Manager

AtomicTransactionState

OTS Resource Manager

JTS

Ada

pter

OT

SA

dapt

er

Adapted Transaction (AT)

Cos

Tra

nsac

tions

JTA

WS

-AT

Ada

pter

WS

-Ato

mic

Tra

nsac

tion

TransactionAwareParticipantsManager

Fig. 13. An Adapted Transaction implementation

Figure 13 illustrates the model of transactions created by the transactionservice. The behaviour of the transaction is grouped in the Common Transaction(CT). Similarly to the ATS architecture, the Adapted Transaction is composed


of one CT and three Adapter components. The strategies composing the CT areGoTM components implementing the TwoPhase Commit, Atomic TransactionState, and a Message Bus. Given that JTS, WS-AT and OTS standards handledifferent types of resources, the associated resource managers are not placed inthe CT. Finally, only the standard APIs, which are provided by the adapters,are exposed by the AT component.

4.4 Performance Analysis

This section presents a performance benchmark, which illustrates the efficiency ofour approach. In particular, it shows that introducing fine-grained componentsto build transaction services has not a negative performance impact. ATS iscompared to the JOTM 1.5.10 transaction service depending on the number ofinvolved participants and threads. ATS uses the AOKell implementation of theFractal component model. JOTM, a project developed as part of the ObjectWebinitiative, is a Java implementation of the JTS specification [17]. It is recognizedfor its reliability and efficiency. It is integrated into the JOnAS J2EE ApplicationServer.

0

0,2

0,4

0,6

0,8

1

1,2

1,4

1,6

1,8

2

2,2

2,4

2,6

0 2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46 48 50

Number of involved participants (#)

Ave

rag

e C

om

ple

tio

n T

ime

(ms)

ATS JOTM

Fig. 14. Participants scalability

0

10

20

30

40

50

60

70

80

90

100

110

1 6 11 16 21 26 31 36 41 46 51

Number of concurrent transactions (#)

Tra

nsa

ctio

n T

hro

ug

hp

ut

(tx/

s)

ATS JOTM

Fig. 15. Concurrent transactions

Figure 14 illustrates the result of the following scenario. A single client ap-plication creates transactions involving an increasing number of participants.The completion time of each transaction is observed depending on the num-ber of participants. Figure 14 shows that the ATS transactions complete fasterthan JOTM ones. Thus, the use of a fine-grained component-based architecturedoes not introduce an overhead to the transaction service. This result can beexplained by the optimizations available in AOKell [18].

Figure 15 applies the following scenario. An increasing number of clients createconcurrent transactions involving 40 participants. The number of transactionscompleted per second is observed depending on the number of concurrent trans-actions started. Figure 15 shows that the ATS transactions complete faster thanJOTM ones when the number of concurrent transactions grows. This is mainlybecause ATS delegates the coordination process to the transaction rather imple-menting this protocol at the transaction service level. This choice isolates each


transaction, which completes independently. Thus, the ATS provides better scal-ability properties than JOTM. This speedup, estimated to 1.5 when using mockobjects as transaction participants, demonstrates that the use of a fine-grainedcomponent-based transaction service introduces no additional overhead in a realapplication context.

5 Related Work

The Java Transaction Service (JTS) specification provides a practical solution totransaction interoperability and composition problems. Indeed JTS relies on theObject Transaction Service (OTS) to propagate transaction contexts betweenapplications. Thus, OTS and JTS could be composed to allow heterogeneousapplications to interoperate from a transactional point of view. The ArjunaTransaction Service [19] is the only transaction service that supports this archi-tecture. Nevertheless, such a mapping is not always simple and therefore a stan-dard may not directly depend on another one. Our approach makes abstractionof the transaction standards to avoid such dependency. Therefore, the transac-tion context could be propagated independently of the composed transactionstandards. Moreover, our approach can be applied to consider other transactionstandards (e.g., Activity Service [6,9]).

More recently, Web Services-Atomic Transactions (WS-AT) have provided anabstraction of transaction services to allow heterogeneous transaction services tobe coordinated [3]. This approach extends the Web Services-Coordination (WS-Coordination) framework to handle transaction contexts [12]. Heterogeneoustransaction services are reified as Participant of a global transaction service,which will act as coordinator during the execution of the validation protocol.Transaction-aware Web Services are responsible for creating a new transactioncontext and registering participants to the global transaction service. However,this approach requires the legacy applications to be modified to support theAPI introduced by the global transaction service. Our approach does not mod-ify legacy applications because we preserve the transaction standards and wecompose them rather introducing an API to support heterogeneity. Neverthe-less, our approach is not orthogonal with Web Services tendency. Therefore,WS-AT can be used as an input transaction standard.

Finally, several component-based approaches have been proposed to buildtransaction services [20,21]. These approaches focuses on the definition oftransaction services as software components to facilitate their integration inapplicative systems. In this coarse-grained approach, the transaction service isencapsulated in a single component. Thus, the transaction services are hostedby a dedicated framework and made available to the application via a trad-ing mechanism. Nevertheless, none of these works addresses the composition ofthe transaction standards related to the services. Our approach promotes fine-grained components, which can be reused easier than coarse-grained componentsto adapt the transaction service to any transaction standard.


6 Conclusion

This paper has presented an approach to build an adapted transaction service,named ATS, which supports transaction standards composition. The design ofATS has been guided by the analysis of the OTS, WS-AT and JTS transactionservices. The ATS has been implemented with the GoTM framework and theFractal component model. Our ATS implementation has been compared to theJOTM transaction service. This evaluation has shown that our approach intro-duces no overhead compared to existing products and supports well scalability.Our approach can be easily extended to support extended transaction standardssuch as Activity Services [6,9]. Consequently, the proposed solution facilitatestransaction standard composition because (1) the ATS is used transparently, and(2) it increases neither complexity of existing platforms nor their performance.

Acknowledgments. This work is funded by the national institute for researchin computer science and control, and the Region Nord - Pas-de-Calais.

Availability. GoTM is freely available under an LGPL licence at the followingURL: http://gotm.objectweb.org.

References

1. OMG: Object Transaction Service (OTS). 1.4 edn. (2003)2. Cheung, S.: Java Transaction Service (JTS). Sun Microsystems, Inc., San Antonio

Road, Palo Alto, CA. 1.0 edn. (1999)3. Cabrera, L.F., Copeland, G., Feingold, M. et al.: Web Services Atomic Transaction

(WS-AtomicTransaction). 1.0 edn. (2005)4. Rouvoy, R., Merle, P.: GoTM : Vers un canevas transactionnel a base de com-

posants. In: Langages, Modeles et Objets Conf. (LMO). Volume 10 of L’Objet.Lille, France, Hermes Sciences (2004) 131–146

5. Bruneton, E., Coupaye, T., Leclercq, M. et al.: An Open Component Model andIts Support in Java. In: 7th Int. Symp. on Component-Based Software Engineering(CBSE). Volume 3054 of LNCS. Edinburgh, United Kingdom, Springer (2004) 7–22

6. Cabrera, L.F., Copeland, G., Feingold, M. et al.: Web Services Business ActivityFramework (WS-BusinessActivity). 1.0 edn. (2005)

7. OMG: Unified Modeling Language (UML): Superstructure. 2.0 edn. (2005)8. Serrano-Alvarado, P., Rouvoy, R., Merle, P.: Self-Adaptive Component-Based

Transaction Commit Management. In: 4th Work. on Adaptive and Reflective Mid-dleware (ARM). Volume 116 of AICPS. Grenoble, France, ACM (2005) 1–6

9. OMG: Additional Structuring Mechanisms for the OTS. 1.1 edn. (2005)10. Eskelin, P.: Component Interaction Patterns. In: 6th Annual Conf. on the Pattern

Languages of Programs (PLoP). Urbana, IL, USA (1999)11. Wang, N., Parameswaran, K., Schmidt, D. et al.: The Design and Performance

of Meta-Programming Mechanisms for Object Request Broker Middleware. In:6th USENIX Conf. on Object-Oriented Technologies and Systems (COOTS). SanAntonio, Texas, USA (2001)

12. Cabrera, L.F., Copeland, G., Feingold, M. et al.: Web Services Coordination (WS-Coordination). 1.0 edn. (2005)


13. Bruneton, E., Coupaye, T., Stefani, J.B.: Recursive and dynamic software com-position with sharing. In: 7th Int. Work. on Component-Oriented Programming(WCOP). Malaga, Spain (2002)

14. Medvidovic, N., Taylor, R.: A Classification and Comparison Framework for Soft-ware Architecture Description Languages. IEEE Transactions on Software Engi-neering 26(1) (2000) 70–93

15. Seinturier, L., Pessemier, N., Coupaye, T.: AOKell: An Aspect-Oriented Imple-mentation of the Fractal Specifications. Objectweb Fractal Workshop (2005)

16. Rouvoy, R., Merle, P.: Towards a Model Driven Approach to build Component-Based Adaptable Middleware. In: 3rd Work. on Adaptive and Reflective Mid-dleware (ARM). Volume 80 of AICPS. Toronto, Ontario, Canada, ACM (2004)195–200

17. Mesnil, J.F.: Overview of JOTM: a Java Open Transaction Manager. In: 10thBiennal Work. on High Performance Transaction Systems (HPTS). Pacific Grove,California, USA (2003)

18. Demarey, C., Harbonnier, G., Rouvoy, R. et al.: Benchmarking the Round-Trip La-tency of Various Java-Based Middleware Platforms. Studia Informatica UniversalisRegular Issue 4(1) (2005) 7–24

19. Little, M.: The Evolution of a Transaction Processing System. In: 11th BiennalWork. on High Performance Transaction Systems (HPTS). Pacific Grove, Califor-nia, USA (2005)

20. Herault, C., Nemchenko, S., Lecomte, S.: A Component-Based Transactional Ser-vice, Including Advanced Transactional Models. In: 5th Int. Symp. and Schoolon Advance Distributed Systems (ISSADS). Volume 3563 of LNCS. Guadalajara,Mexico, Springer (2004) 545–556

21. Arntsen, A.B., Karlsen, R.: ReflecTS: a flexible transaction service framework. In:4th Work. on Adaptive and Reflective Middleware (ARM). Volume 116 of AICPS.Grenoble, France, ACM (2005) 1–6

A Component-Based Approach to Compose Transaction Standards

Documents