TRANSACTION SERVICE COMPOSITION

A Study of Compatibility Related Issues

Anna-Brith Arntsen and Randi Karlsen

Computer Science Department, University of Tromsoe, 9037 Tromsoe, Norway

Keywords:

Flexible Transaction Processing Environment, Dynamic service composition, Compatibility, Integration.

Abstract:

Different application domains have varying transactional requirements. Such requirements must be met by

applying adaptability and ﬂexibility within transaction processing environments.

ReflecTS

is such an envi-

ronment providing ﬂexible transaction processing by exposing the ability to select and dynamically compose

a transaction service suitable for each particular transaction execution. A transaction service (TS) can be seen

as a composition of a transaction manager (TM) and a number of involved resource managers (RMs). Dy-

namic transaction service composition raises a need to examine issues regarding

Vertical Compatibility

between the components in a TS. In this work, we present a novel approach to service composition by eval-

uating

Vertical Compatibility

between a TM and RMs - which includes

Property

and

Communication

compatibility.

1 INTRODUCTION

New application domains and execution environ-

ments have transactional requirements that may ex-

ceed the traditional ACID properties. Such domains,

including workﬂow, cooperative work, medical in-

formation systems and e-commerce, are constantly

evolving and possess varying and non-ACID require-

ments. The travel arrangement scenario is a well-

known example of a long-running transaction with

requirements that goes beyond the ACID properties.

Such a transaction consists of a number of subtasks

(booking ﬂights, hotel rooms, theater tickets, etc),

possible with adjacent contingent transactions and of

dissimilar importance (vital vs. non-vital). Resources

cannot be locked for the entire duration of the trans-

action. So, to increase performance and concurrency,

this transaction must be structured as a non-ACID

transaction with relaxed (i.e. semantic) atomicity

based on the use of compensating activities in case

of failure.

Varying transactional requirements demand a ﬂex-

ible transaction execution environment. Such require-

ments are not met by current transaction processing

solutions where merely ACID transactions are sup-

ported. Thus, there is a gap between offered and re-

quired support for varying transactional requirements.

A number of advanced transaction models (Elma-

garmid, 1992; Garcia-Molina and Salem, 1987) have

been proposed to meet different transactional require-

ments. Many advanced models where suggested with

speciﬁc applications in mind, and with ﬁxed trans-

actional semantics and correctness criteria. Conse-

quently, they do not provide sufﬁcient support for

wide areas of applications.

The characteristics of the proposed transaction

models support our conviction that the ”one-size ﬁts

all” paradigm is not sufﬁcient and that a single ap-

proach to extended transaction execution will not suit

all applications. To close the gap between offered

and required support for varying requirements, we

designed the ﬂexible transaction processing platform

ReflecTS

(Arntsen and Karlsen, 2005).

ReflecTS

is a highly adaptable platform offering an extensi-

ble number of concurrently running transaction ser-

vices, where each service supports different transac-

tional guarantees.

Generally, a transaction service (TS) can be

viewed as a composition of a transaction manager

(TM) and a number of resource managers (RMs),

239

Arntsen A. and Karlsen R. (2007).

TRANSACTION SERVICE COMPOSITION - A Study of Compatibility Related Issues.

In Proceedings of the Ninth International Conference on Enterprise Information Systems - DISI, pages 239-245

DOI: 10.5220/0002392602390245

 SciTePress

one for each involved source. Today’s systems keeps

mainly one TM, giving a predeﬁned and static TS

composition.

ReflecTS

, on the other hand, exposes

the ability to dynamically select a TM and subse-

quently compose a TS suiting particular transactional

requirements. Dynamic service composition raises a

need to evaluate

Vertical Compatibility

between

each TM - RM pair. This must be done both with

respect to

Property

and

Communication

compati-

bility. The goal of this paper is to investigate these

issues, with a particular focus on

Property

compat-

ibility and problems related to the integration of het-

erogeneous commit and recovery protocols.

In the remainder of this paper we ﬁrst, in sec-

tion 2, present the architecture of

ReflecTS

. Sec-

tion 3 presents the service composition procedure and

compatibility related issues. Section 4 follows with

related work, and section 5 draws conclusions and

presents future work.

2 REFLECTS

ReflecTS

(Arntsen and Karlsen, 2005) is a ﬂexible

and adaptable transaction processing system suiting

varying transactional requirements by providing an

extensible number of transaction managers (TMs).

The main functionalities of

ReflecTS

are transac-

tion manager (TM) selection, transaction service (TS)

composition and transaction activation. We present

the architecture of

ReflecTS

and the speciﬁcations

involved in TS composition and compatibility evalu-

ation.

2.1 Architecture

ReflecTS

, shown in Figure 1, is a composition of

components. TSInstall handles requests for TM con-

ﬁgurations and reconﬁgurations, and TSactivate han-

dles requests for transaction executions. The TM-

Framework hosts the TM implementations, and the

InfoBase keeps TM and resource manager (RM) de-

scriptors and results from the compatibility evaluation

procedures.

The

IReflecTS

interface (Arntsen and Karlsen,

2005) deﬁnes the interaction between the application

program (AP) and

ReflecTS

, and is called to demar-

cate global transactions and to control the direction of

their completion. Its design has been inﬂuenced by

the TX-interface deﬁned in the X/Open Distributed

Transaction Processing (DTP) model (Group, 1996),

but differ from it to conform to varying transactional

requirements. This is, among others, done by in-

cluding the transactional requirements and informa-

Framework

Base

Info

TSActivate TSInstall

ReflecTS Framework

Program

Application ReflecTS

Admin

IReflecTS

i.e. XA−compliant interface

Figure 1: Overview of ReﬂecTS.

tion about requested RMs in the TransBegin() request.

The interaction between a TM and a RM is gener-

ally determined by the X/Open standard and the XA-

interface (Group, 1996).

Applications initiating TransBegin() embeds a

XML-document describing the transactional require-

ments and a list of requested RM identiﬁcations.

Based on the transactional requirements and descrip-

tors of available TMs, a suitable TM is selected for

the transaction execution. The mapping of require-

ments to a TM need not be one-to-one. A speciﬁc

set of requirements can be mapped to different TMs,

in which case a list is stored in the system for use if

incompatibility arises. Consecutively, the TM is com-

posed together with required RMs into a TS. This TS

is responsible for coordinating the execution of the

particular transaction while preserving the requested

transactional requirements.

TSactivate

performs TS composition based on

the descriptor of the selected TM,

TM_Descriptor

and the descriptors associated with involved RMs,

RM_Descriptors

. For each pair of TM and RM,

compatibility is evaluated. When this compatibility,

which includes

Property

and

Communication

com-

patibility, is fulﬁlled between the involved parties -

composition takes place, and eventually, the transac-

tion is started.

Transaction activation presupposes successful

evaluation of

Horizontal Compatibility

, which is

compatibility between concurrently active transaction

services. This is part of future work.

2.2 Transaction Service Speciﬁcations

ReflecTS

introduces two speciﬁcations sustaining

service composition and compatibility evaluation: the

TM_Descriptor

and the

RM_Descriptor

ICEIS 2007 - International Conference on Enterprise Information Systems

240

2.2.1 TM Descriptor

The

TM_Descriptor

describes a TM and includes in-

formation about: 1) a TM

ID 2) transactional prop-

erties (ACID or non-ACID), 2) transactional mecha-

nisms (commit/recovery, global concurrency control),

and 3) compatibility with a standard (i.e. XA) or not.

The following is an example of a TM with ACID

guarantees running a 2PC protocol with presumed

abort, supporting the XA-interface:

<ServiceID>TM

ID</ServiceID>

<Task>

</TaskParameters>

</Task>

</TaskList>

</TM

Descriptor>

2.2.2 RM Descriptor

RM_Descriptor

holds information about a regis-

tered RM and includes the following: 1) a resource

identiﬁcation

RM_ID

, 2)

ResourceID

with the DNS

name of the resource, 3) whether the RM is XA-

compliant or not, and 4), information about the RMs

transactional mechanisms.

The speciﬁcation of

ResourceID

corresponds to

the content of the RMlist following the Start

Trans()

request. An example of a XA-compatible RM running

a two-phase commit protocol with presumed abort

(PrA) follows.

<RM

ID>Resource ID</RM ID>

<ResourceID>mypc.mydom.edu</ResouceID>

<Task>

<TaskId>commit</TaskId>

</TaskParameters>

</Task>

</TaskList>

</RM

Descriptor>

3 SERVICE COMPOSITION AND

COMPATIBILITY

3.1 Introduction

A transaction service TS is a composition of a trans-

action manager TM and a set of n compatible re-

source managers TS = (TM,

R M ) where R M

= {RM

, . . . , RM

}. To compose a TS,

Vertical

Compatibility

must be successfully evaluated with

respect to the following:

• Each pair of TM and RM must match with respect

to local and global transaction control to assure

the requested transactional requirements. This we

refer to as

Property

compatibility

• Each pair of TM and RM must be able to commu-

nicate through some common interface while as-

suring requested transactional requirements. This

we refer to as

Communication

compatibility

Results from these evaluations are kept in the

InfoBase

. This means that it is unnecessary to re-

peatedly evaluate the same pair of TM and RM.

3.2 Composition Procedure

This section presents the service composition proce-

dure,

TS_Composition()

, which follows TM selec-

tion.

Code regarding selection, service composition and

incompatibility is presented below. R

represents

the transactional requirements of a transaction T, and

RMlist, the list of RMs requested by T. The proce-

dure

SelectTM()

takes as input the

TM_Descriptors

of the deployed TMs and the transactional require-

ments R

, and returns a list of TMs (TMlist) assur-

ing R

. In the case of unsuccessful composition, an-

other TM may be selected, and

TS_Composition()

restarted. This sequence is repeated either until the

composition completes or there are no available TMs

in the list. If the composition does not complete, in-

compatibility is managed by the

ResolveIncomp()

procedure (see 3.5).

ResolveIncomp()

takes as input

a list of compatible RMs (Complist), returned from

the

TS_Composition()

procedure. If there is no so-

lution to the incompatibility problem, the procedure

stops.

TMlist

= SelectTM(TM Descriptor[]* TM,

)

while TS not composed {

TS_Composition(

RMlist

Complist

)

{

Compose and return TS

} else {

if More TM’s available {

= ChooseNewTM(

TMlist

)

} else {

if ResolveIncomp(TM,Complist,R

)

{

Compose and return TS

} else STOP

}

TRANSACTION SERVICE COMPOSITION - A Study of Compatibility Related Issues

241

}

In the

TS_Composition()

procedure following

below, the procedures

Comm()

and

Property()

are

initiated for each involved RM. Based on the re-

sults of these calls,

InfoBase

and

CompList

are

updated with information about compatible TM-RM

pairs. The

Complist

contains information regard-

ing the transaction service composition for use while

managing incompatibility.

boolean TS Composition(TM Descriptor*

, RM ID[]*

RMlist

)

{

for

(

each RM

in RMlist

)

{

Comm(

)

{

Property(

)

{

Update Infobase

Update Complist

return

true

}

} else return

false

}

3.3 Property Compatibility

Formally, a composition of a transaction service TS

for the execution of a transaction T over a set of com-

patible resource managers

R M

is denoted TS

(TM

R M

), where

R M

= {RM

, . . . , RM

} and

where the transaction manager TM

is selected for

the speciﬁc transaction T. TS

has the properties

P (TS

). The principal goal of TS

is to coordinate

the execution of transaction T while assuring the re-

quested transactional requirements R

Evaluating property compatibility involves exam-

ining the transactional mechanisms of the TM

with

the corresponding mechanisms of each involved RM

with the aim to assure the requested transactional re-

quirements.

3.3.1 Transactional Mechanisms

The main transactional mechanisms of TMs and RMs

are commit/recovery and concurrency control. Gen-

erally, a TM controls global commit/recovery and

global concurrency control, and a RM performs lo-

cal transaction control (logging, concurrency control,

persistency, commit/recovery). When heterogeneous

commit protocols cooperate for the commitment of a

distributed transaction, problems and incompatibility

may arise. In this work, we focus on integration of

heterogeneous commit protocols, and leaves concur-

rency control issues for future work.

Traditionally, two-phase commit (2PC) is the pro-

tocol used to ensure the ACID properties of dis-

tributed transactions, and the X/Open Distributed

Transaction Processing (DTP) model (Group, 1996)

is the most widely used standard implementing the

2PC protocol.

Some optimizations of the 2PC protocol are pro-

posed. For instance presumed abort (PrA), presumed

commit (PrC), presumed nothing (PrN), presumed

any (PrAny), and three phase commit (3PC) (Gupta

et al., 1997; Tamer and Valduriez, 1999; Al-Houmaily

and Chrysanthis, 1999). These 2PC optimizations en-

sures atomic commit of global transactions. Other op-

timizations ensures weaker notions of atomicity, e.g.

semantic atomicity. These include for instance the

Optimistic 2PC (O2PC) protocol (Levy et al., 1991),

the OPT (Gupta et al., 1997) protocol, and one-phase

commit (1PC). Compared with 2PC, 1PC omits the

ﬁrst phase, thereby permitting immediate commit of

subtransactions. Consequently, one-phase commit-

ment is feasible in a X/Open environment. A com-

bination of 1PC and 2PC protocols is realized in the

dynamic 1-2PC protocol (Al-Houmaily and Chrysan-

this, 2004). The 1-2PC protocol switches from 1PC

to 2PC when necessary.

A prerequisite for a RM participating in a 2PC pro-

tocol is to support a visible prepare-to-commit state.

RMs not supporting prepare-to-commit are not able

to participate in a 2PC protocol and can thus not con-

tribute in assuring global atomicity. Integrating the

different commit protocols may cause problems and

a visible prepare-to-commit may not be enough for

a practical integration of commit protocols. For in-

stance, in (Al-Houmaily and Chrysanthis, 1999) they

show that it is impossible to ensure global atomicity

of distributed transactions executed at both PrA and

PrC participants if PrA, PrC or PrN is running at the

transaction manager. Consequently, they presented

PrAny, which is a protocol that successfully integrates

PrN, PrA and PrC.

3.3.2 Evaluating Property Compatibility

Assume a transaction T with the set of transactional

requirements R

. If each RM

requested by the trans-

action can participate in the selected TM

’s commit

and abort protocols so that the requirements R

of T

are assured, the TS

with the properties

P (TS

) will

be composed. The requirements R

and the properties

P (TS

) need not be equivalent.

The following deﬁnition must be sustained.

Deﬁnition 1: (Assured transactional require-

ments). The set of transactional requirements

of a transaction T is assured if and only if

ICEIS 2007 - International Conference on Enterprise Information Systems

242

is semantically a subset of the set of trans-

actional properties

P (TS) of the transaction

service TS

, where TS

=(TM

R M

) and

is the manager selected for this particu-

lar transaction T:

⊆

P (TS

)

The deﬁnition states that the set of transactional

requirements R

of the transaction T must be a se-

mantic subset of the set of properties

P of TS

such

that every element of the set R

is semantically con-

tained in the set P (TS

). This deﬁnition is used dur-

ing evaluation of property compatibility. If the equa-

tion does not hold and R

P (TS

), the composi-

tion will not take place.

Deﬁnition 1 must hold for each TM - RM combi-

nation, and it must hold even though the TM changes

or RMs are added. Consider TS

=(TM

R M

)

where

R M

= {RM

, . . . , RM

i−1

} and R

⊆

P (TS

). Assume adding the resource manager RM

so that

R M

{RM

}. Then, according

to deﬁnition 1, transaction manager TM

and the re-

source manager RM

are property compatible for the

execution of T if and only if R

⊆

P (TS

According to deﬁnition 1 and deduced from our

perception, a semantic subset refers to a set of transac-

tional properties belonging a transaction service that

are powerful enough to assure a speciﬁc set of trans-

actional requirements.

To illustrate the semantic subset relationship, con-

sider a transaction service (TS

) having the following

set of properties: P (TS

) = (A), where A refers to the

atomicity property. Assume a set of requirements de-

duced from a particular transaction speciﬁcation: R

= (SA

saga

), which refers to semantic atomicity as sup-

ported by Sagas (Garcia-Molina and Salem, 1987).

assures atomicity by implementing a variant of

2PC or a 3PC protocol. Since these protocols are able

to commit individual transactions one-phase as is re-

quired to assure semantic atomicity, TS

guarantees

, (SA

saga

) ⊆

(A), and deﬁnition 1 is fulﬁlled. If

the transaction require full atomicity, R

= (A), deﬁ-

nition 1 still holds as TS

assures atomicity, and (A)

⊆

(A).

Next, consider a service TS

with the properties

P (TS

) = (SA

saga

) - semantic atomicity. This service

implements a Sagas-like commit protocol supporting

compensation. The resource managers of the compo-

sition may implement either a 2PC variant, 1PC, or

just committing transactions as soon as they are ﬁn-

ished (like in for instance a web service). If a trans-

action requires semantic atomicity R

= (SA

saga

the equation (SA

saga

) ⊆

(SA

saga

) is fulﬁlled and the

requirements guaranteed. If a transaction requires

ACID, the service TS

will not be composed for the

TM1 TM2 TM3

Sagas

RM3RM2RM1

PrC PrA

XA XA WS

PrAny PrC

Figure 2: Transaction Examples.

transaction unless incompatibility can be solved (see

section 3.5).

3.3.3 Exemplifying Property Compatibility

Assume an environment with three transaction man-

agers, TM

, TM

and TM

. TM

assures ACID by

implementing PrC, TM

implements PrAny, and TM

assures relaxed atomicity as required by Sagas. The

environment also includes three resource managers,

running PrC, RM

running PrA, and a web ser-

vice, RM

, not supporting prepare-to-commit. Fig-

ure 2 illustrates this environment with four proposed

transaction services composed for four different trans-

actions. These are denoted

, and are sur-

rounded with drawn lines.

First, consider a transaction

that requests ACID

and the resources RM

and RM

. For

, TM

im-

plementing PrAny is selected. RM

implements PrC

and RM

PrA. As seen in (Al-Houmaily and Chrysan-

this, 1999), this combination implies compatibility as

PrAny successfully integrates both PrC and PrA.

Next, a transaction

requests the same proper-

ties and resources as

, namely ACID and RM

and

. However, for

, TM

implementing PrC is se-

lected. We know from (Al-Houmaily and Chrysan-

this, 1999) that atomicity cannot be guaranteed when

a PrC protocol controls the execution of transactions

over PrA and PrC protocols. In fact, Deﬁnition 1 will

prevent this service from being composed. Instead,

the procedure managing incompatibility will be initi-

ated, and the problem can be solved by for instance

reconsidering the choice of TM (see 3.5).

Transaction

requests ACID and the resources

, RM

and RM

. TM

is selected for the exe-

cution. RM

does not support prepare-to-commit, so

PrAny implemented by TM

cannot control the exe-

cution of

. Consequently, global atomicity cannot

be assured, incompatibility exists and the procedure

managing incompatibility will be initiated.

TRANSACTION SERVICE COMPOSITION - A Study of Compatibility Related Issues

243

The fourth transaction,

, is a Sagas requesting

semantic atomicity and the execution over RM

, RM

and RM

. For

, TM

is selected. The Sagas-like

commit protocol implemented by TM

require the un-

derlying resources to respond to immediate commit

of individual transactions. This is assured by the in-

volved RMs, compatibility is present and the require-

ments are assured.

3.4 Communication Compatibility

Communication compatibility evaluates the commu-

nication capabilities of a speciﬁc TM - RM pair.

The ultimate goal is to assure requested transactional

properties.

The interface implemented by the involved parties

determines the ability to communicate. At present,

the XA-standard (Group, 1996) deﬁnes the most

widely used interface. XA-compatibility and non-

XA compatibility is a natural classiﬁcation of com-

munication capabilities for TMs and RMs. XA-

compatibility in our sense means conformance to

the XA-interface, not necessarily assuring speciﬁc

transactional requirements. In our deﬁnition, a XA-

compatible TM or RM can assure either ACID or non-

ACID. Non-XA compatible participants may conform

to any other standard (or interface), or none at all.

The XA-interface provides the methods necessary

for transaction coordination, commitment, and recov-

ery between a TM and one or more RMs. The XA-

interface supports both atomic commit by the use of a

2PC variant and relaxed atomicity by having the abil-

ity to perform 1PC.

The

Comm()

procedure (see 3.2) handling com-

munication compatibility, takes as input the particu-

lar TM and RM, and a set of transactional require-

ments R

. The

Comm()

procedure discovers XA-

compatibility by investigating the standard tag of the

TM and the RM descriptor. Then, the transactional

requirements, R

are used in the process of evalu-

ating communication compatibility. Based on R

the requirements regarding communication can be de-

duced. We will see that a speciﬁc TM - RM combi-

nation may satisfy a particular R

set, but not another

one.

If both the TM and the RM are XA-compatible,

communication compatibility exists irrespective of

the content of R

. In this case, the TM most likely im-

plements a 2PC variant, and the XA-compatible RM

supports a visible prepare-to-commit state. Conse-

quently, within this communication, both ACID and

relaxed (i.e. semantic) atomicity are provided.

In the combination of a XA-compatible TM and

a non XA-compatible RM and when R

demand re-

laxed (i.e. semantic) atomicity, communication is

most likely satisﬁed. However, independent of the

content of R

, the descriptors are consulted ahead of

the evaluation. If the R

claims ACID, the communi-

cation might be fulﬁlled even though the RM is non-

XA compatible. For instance, a non-XA compatible

RM may be able to support prepare-to-commit.

Consider a non-XA TM in combination with a XA

RM. If the TM implements a Saga-like commit pro-

tocol and R

requests semantic atomicity, communi-

cation is satisﬁed.

3.5 Managing Incompatibility

Incompatibility may be detected either during eval-

uating property or communication compatibility. In

each case, the following actions are considered:

• Communication incompatibility: 1) add an

adapter (or wrapper) to either RM or TM to make

them conform to each other’s interfaces, or 2)

choose another TM with different communication

characteristics, but with the same transactional

guarantees.

• Property incompatibility: 1) choose another TM

with different transactional mechanisms, but with

the same transactional guarantees, or 2) negotiate

to ﬁnd an alternative way to execute the transac-

tion by either modifying the transactional require-

ments or the list of involved resources.

4 RELATED WORK

Today’s transaction processing platforms supports the

execution of distributed transactions, but with lim-

ited ﬂexibility. Present platforms, like for instance

Microsoft Transaction Server (MTS) (Corporation,

2000), Sun’s Java Transaction Server (JTS) (Subhra-

manyam, 1999) provide merely one transaction ser-

vice with ACID guarantees.

Other approaches support more than one transac-

tion service, although not concurrently. One is given

by the CORBA Activity Service Framework (Hous-

ton et al., 2001), where various extended transaction

models are supported. Others are the WS-transactions

(Group, 2004), the OASIS BTP (Little, 2003) spec-

iﬁcation and the Arjuna XML Transaction Service

(Ltd, 2003) describing solutions providing two differ-

ent transaction services, one for atomic transactions

and the other for long-running business transactions.

Flexibility within transactional systems can be

found in the works of Barga (Barga and Pu, 1996)

and Wu (Wu, 1998), implementing ﬂexible transac-

tion services. Related work on dynamic combination

ICEIS 2007 - International Conference on Enterprise Information Systems

244

and conﬁguration of transactional and middleware

systems can for instance be found in Zarras (Zarras

and Issarny, 1998). References to other works can be

found in (Arntsen and Karlsen, 2005). These works

recognizes the diversity of systems and their different

transactional requirements, and describes approaches

to how these needs can be supported.

Our work on the ﬂexible transaction processing

environment

ReflecTS

, contrasts previous work in

several matters. First, by supporting an extensible

number of concurrently running services, and next, by

providing dynamic transaction service selection and

composition according to the needs of applications.

5 CONCLUSION AND FUTURE

WORK

The transactional requirements of advanced appli-

cation domains and web services environments are

varying and evolving, demanding ﬂexible transaction

processing. On the basis of the ﬂexible transaction

processing platform

ReflecTS

, this work presents a

novel approach to dynamic transaction service com-

position and compatibility related issues. From

ReflecTS

a suitable transaction manager can be se-

lected for a particular transaction execution, and dy-

namically composed together with requested resource

managers into a complete transaction service. To

complete transaction service composition, this work

evaluates

Property

and

Communication

compatibil-

ity between a transaction manager and resource man-

agers. The main contributions of this work are the

procedures and the formalisms related to these com-

patibility issues.

Ongoing and future work includes an in-depth

evaluation of local and global transactional mecha-

nisms (including concurrency control) with respect

to transaction service composition. Further, ongo-

ing work includes developing rules for managing in-

compatibility, and future work includes an exami-

nation of compatibility related to service activation,

Horizontal Compatibility

REFERENCES

Al-Houmaily, Y. J. and Chrysanthis, P. K. (1999). Atomicity

with incompatible presumptions. In PODS ’99: Pro-

ceedings of the eighteenth ACM SIGMOD-SIGACT-

SIGART symposium on Principles of database sys-

tems, pages 306–315, New York, NY, USA. ACM

Press.

Al-Houmaily, Y. J. and Chrysanthis, P. K. (2004). 1-2pc:

the one-two phase atomic commit protocol. In SAC

’04: Proceedings of the 2004 ACM symposium on

Applied computing, pages 684–691, New York, NY,

USA. ACM Press.

Arntsen, A.-B. and Karlsen, R. (2005). Reﬂects: a ﬂexible

transaction service framework. In ARM ’05: Proceed-

ings of the 4th workshop on Reﬂective and adaptive

middleware systems, pages 1–6, New York, NY, USA.

ACM Press.

Barga, R. and Pu, C. (1996). Reﬂection on a legacy trans-

action processing monitor.

Corporation, M. (2000). The .net framework.

Elmagarmid, A. K., editor (1992). Database Transaction

Models for Advanced Applications. Morgan Kauf-

mann Publishers.

Garcia-Molina, H. and Salem, K. (1987). Sagas. In Pro-

ceedings of the 1987 ACM SIGMOD international

conference on Management of data, pages 249–259.

ACM Press.

Group, O. (1996). X/open distributed transaction process-

ing: Reference model, version 3.

Group, W. W. (2004). Web services architecture, working

draft.

Gupta, R., Haritsa, J., and Ramamritham, K. (1997). Revis-

iting commit processing in distributed database sys-

tems. In SIGMOD ’97: Proceedings of the 1997 ACM

SIGMOD international conference on Management of

data, pages 486–497, New York, NY, USA. ACM

Press.

Houston, I., Little, M. C., Robinson, I., Shrivastava, S. K.,

and Wheater, S. M. (2001). The corba activity ser-

vice framework for supporting extended transactions.

Lecture Notes in Computer Science, 2218.

Levy, E., Korth, H. F., and Silberschatz, A. (1991). An

optimistic commit protocol for distributed transac-

tion management. In SIGMOD ’91: Proceedings of

the 1991 ACM SIGMOD international conference on

Management of data, pages 88–97, New York, NY,

USA. ACM Press.

Little, M. (2003). Transactions and web services. Commun.

ACM, 46(10):49–54.

Ltd, A. T. (2003). Web services transaction management

(ws-txm) ver1.0.

Subhramanyam, A. (1999). Java transaction service.

Tamer, . M. and Valduriez, P. (1999). Principles of Dis-

tributed Database Systems. Prentice Hall.

Wu, Z. (1998). Reﬂective java and a reﬂective component-

based transaction architecture. In OOPSLA workshop.

Zarras, A. and Issarny, V. (1998). A framework for system-

atic synthesis of transactional middleware.

TRANSACTION SERVICE COMPOSITION - A Study of Compatibility Related Issues

245