Supporting Coliborative Mobile Applicationsusing Adaptable Transactional Framework

(Invited Paper)

Heri RamampiaroNorwegian University of Science and Technology (NTNU)

NO-7491 Trondheim, NORWAYherigcomputer.org

Abstract- The theme of this paper is on support of mo- The paper is organised as follows. First, in Section IIbile applications using adaptable transactional framework. We we will give an introduction of the CAGISTrans transac-specifically look at the case of the adaptable transactional tional framework. To be able to reveal the challenges withframework approach CAGISTrans. The paper discusses how sucha framework can be used to address the challenges incurred by collaborative mobile applications discussed in Section IV,the collaborative and dynamic nature of mobile applications, as Section III presents the characteristics of such applications.well as its inherited mobile nature. It is widely known that several Then, Section V explains how CAGISTrans can address theseapproaches to this theme already exist. However, many of the challenges and points out how it can be extended towards asolutions are at most proprietary, and do not take all aspects satisfiable support for collaborative mobile applications. Toand challenges of mobile applications and mobile environments

p Section VI discusses related work.into consideration. With CAGISTrans, which was originally putourworin perspective,wecon VIdpotutsutre work.developed for cooperative work support, we have attempted Finally,inSectionVIIweconcludeandpointoutfutureworkallow the transactional support to be adaptable, thus coveringmost situations and needs as possible. Our hypothesis is that II. THE CAGISTRANS APPROACH REVISITEDwith extensions, CAGISTrans can be used to address mobile The premises for the development of the transactionalcollaborative applications. In general, we believe our approach . . .is useful, but we still recognise the fact that it still has rooms for fra ewor a Crans is that is aily iossibleimprovements. There are issues that have still to be addressed to develop a transaction model that is able to cover allsuch as full support for frequent disconnection, replication and types of applications. Most of existing models are proprietary,recovery requirements. customised to support a specific type of application.

CAGISTrans was developed mainly to overcome this lim-I. INTRODUCTION itation. The goal was to have at transactional framework

It is widely accepted that traditional transaction models that allow transaction models to be specified to suit severalare unsuitable for advanced applications such as mobile and different applications. As such, CAGISTrans is a frameworkcollaborative applications as they are too strict, especially in that allow customisation of transaction models to fit differentterms of enforcement of correctness criteria. Therefore, during situations and applications [15]. Unlike a transaction model,the past 20 years researches have attempted to develop more a transactional framework is a vehicle used to define, analyseadvanced models and frameworks to overcome this limitation. and apply the essential properties of transactions. In this sense,However, as applications evolve, new requirements must be a transactional framework consists of a transaction modeltaken into account. For example, the last five years mobile specification facility and a transaction execution managementapplications have become more and more popular. Data are environment.often shared among mobile users or applications through The requirement is that transaction models must be adapt-mobile devices. This makes it crucial to develop transactional able to meet different needs, including those that may changesupport ensuring that data shared among users/applications during runtime. In view of this, the CAGISTrans framework isare always consistent, and that the sharing process is flexible particularly aimed at specifying transaction models that mayenough to allow collaboration and mobility among involved have to be modified while the actual transactions are beingparts (e.g., users and/or applications), at the same time. scheduled. In terms of collaborative and mobile applications,

The challenge addressed in this paper is how develop a this possibility is quite crucial as the underlying requirementstransactional framework that provide suitable support for both may often change. For instance, unplanned disconnectivitycollaborative and mobile applications. It is mainly based on may occure from time to time and the involved parts maythe work we did, in [1], [2], on the development of the change their cooperation mode (e.g., from tight collaborationCAGISTrans trancational framework. CAGISTrans was orig- to no cooperation at all, etc.). This makes it difficult to defineinially developed to support cooparative work. In this paper, in advance how to execute a transaction. Further, finding thewe evaluate the CAGISTrans framework based on mobile way to introduce changes in the transaction model withoutenvironments characteristics, and point out how it can be aborting or interrupting currently executing transactions is notextended to support collaborative mobile applications. stright forward. A way to cope with this in CAGISTrans is

1-4244-0429-O/06/$20.OO ©2006 IEEE

to provide explicit separation of design time and runtime must define how transaction can spawn during execution andspecifications. This means that we must organise the model how responsibilities are delegated among involved subtrans-specification into two separate but connected parts, consisting actions. The dependencies among involved (sub-)transactionsof one that is designed before the transaction is executed, and must be known a priori and specified to, for example, deter-another that can be modified while the involved transactions mine how these (sub-)transactions to terminate, and how thisare being executed. We call the former a transaction charac- termination affect others.teristics specification, and the latter a transaction execution Further, to ensure that correctness is preserved, the transac-specification [13]. The main idea is to collect the elements of tion execution specification includes user-defined correctnesstransaction models that are stable and possible to reason about constraints. These are used to specify how transactions mustand synthesise in advance into the characteristics specification, be executed, and which operations are prohibited and allowedand include the elements of transaction models that are only to run together. The first element is called demands, the secondpartly predictable into the execution specification. conflicts and the third is called permits.

To allow flexible execution of transactions, we have in-A. CAGISThans Thansaction Characteristics cluded advanced operations. These are abstractions of read/

With the transaction characteristics specification, we collect write operations. That is, they are based on the read andall elements that are vital and must be known a priori. This write operations. Advanced operations allow us to capture theincludes the specification of the appropriate ACID proprieties, semantic knowledge about an operation. For example, a "read-transaction structures and the correctness criteria to applied. based" operation can be a "browse" type or "incorporation".By allowing the ACID properties to be customised, we This means that the user's future action will depend on which

are able to adapt transaction models to specific ACID re- type of operations he/she uses. Browse will have no effect,quirements, making it possible to fit them to application while incorporation will.needs. Note that because it is crucial that the results from Finally, to comply with fact that transactions within collabo-committed transactions are permanent and that correctness can rative (and mobile) environments are long-lasted, transactionsbe assured, both consistency and durability must be preserved. within CAGISTrans are executed as open-ended transactions,For this reason, only atomicity and isolation are relaxable - i.e., which means that they may not be terminated within a pre-specifiable. specified time. We also know that requirements may change

Further, with CAGISTrans it is possible to allow the spec- during execution. So, to meet new requirements during run-ification of suitable transaction structures. This makes it time, CAGISTrans allows a user to refine the prevailingpossible to specify transactions to run in a specific structure correctness constraints while his/her transactions are beingas needed by specific applications. Depending on the specified executed.structure we may define the effects of one transaction on Detailed technical presentation of the CAGISTrans frame-other transactions, in terms of transaction dependencies, each work including illustration of how it can be used in practicaldefined based on actual ACID-properties. Such dependency collaborative applications is provided in [1], [2].management enables, for example, our framework to provide III. CHARACTERISTIC ANALYSIS OF COLLABORATIVEa fine grained abort management scheme. MOBILEAPPLYSIONS

Finally, as part of the characteristics elements, we may MOBILE APPLICATIONSdefine appropriate correctness criteria to be applied. This allow A. A Motivating Scenarioto specify whether one should rely on an underlying DBMS In this section will take a look at typical mobile applicationor enable user defined correctness. scenario within an application development environment.

B.TransactionExecutionSpecification DocuSearch Inc.' is software development company spe-B. Thansaction execution specification consists of elementscialised on developing and delivering document search soft-The transaction execution specification consists of elements ware. DocuSearch's network or communication infrastructure

for specification of how transaction must be executed. On one is depicted in Figure 1. As shown, we can divide DocuSe-hand, this must conform to the characteristics specification. arch's collaborative work modes into two categories. TheOn the other hand, they can be seen as an extension to the first category involves collaboration through the fixed networkcharacteristics specification, in that it includes elements that where the users are connected to the company's server viaare not included in this specification. They are specifically WAN/LAN/intranet/intemet. The second category is collab-designated to control and manage the transaction bihaviour oration involving the company's wireless network and usersduring runtime. that work on their own using portable devices such as PDAs

The transaction execution specification includes transaction and portable PCs. They are not always connected to the mainexecution management operations as initiation and termination server but submit their results/modules as these are availableoperations. It also consists of operations needed for dynamic or ready. The users may not always be able to stay connected,restructuring of transactions. This includes spawning of new for example, due to (wireless/mobile) network problems, badtransactions and delegation of reponsibilities. This means for battery capacity, economic issues, etc.example that if we specified a transaction model with nestedstructure in the transaction characteristics specification, we 1DocuSearch Inc. is oniy a fictive, non-existing company.

Mobile/Wireless Units

.,.,== ='".''.witha mobile application the information type is typicallyheterogeneous. Second, the tasks involved in mobile applica-tion in general do not have fixed structure; it may be fullydecomposable, partially decomposable or not decomposable

Moie/iels ... ... ..Base iupport Stati at all. Also, it may be part of a sequence or not. And, it

I .. _/ has diverse types of collaboration, and may be involved inStable/Fixed Network cooperation with other tasks or not. Third, a task's behaviour

can vary a lot. For example, a task can be fully or partially/_ \ \ X !pre-planned or it cannot be planned in advanced at all. It can

/_ 1>1 \ >! Salso be accomplishable or not accomplishable. Finally, as for

Stationary the above elements, the task environment is diverse in nature,Workstations and may fully or partially involve tight security, secrecy, and

reliability demands, or none of these at all.Mainframe/data server The location characteristics deals with the fact that a

Fig. 1. DocuSearch communication setup mobile application may be location dependent, have locationservice awareness, and whether it have to report on location.Seen from transactional support perspectives, these charac-

The document search software consists of two main mod- teristics have minor relevancy. However, location dependencyu : a .consisting must be taken into account, as this means that whether a taskules:a Grahicaluser nterfce (GI) moule -must be executed within specific location or not.

of menus, search interface and results presentation interface, thetiechteristicslocrns nt-and a Search Processing module - a module taking data readthrough the interface module, processing these, ranking the constraints, information required related to time, information

'.f, p eg results on the display. produced related to time and task lifetime. First, a taskdocuent fond and prsntn th within a mobile application can be triggered by events orEach module is developed by groups of several engineers inergee

the divisions located in several locations. They are put together executed/performed as a standalone task, starting by its own.

into a single software artefact at a later project stage. Second, a mobile task has often variable time-constraints,meaning that it may be open-ended, have to be executed at

B. The Mobile Applications Characteristics specific time, or must be completed within specific time spans.After seeing the above scenario, we will now try to char- Third, the information required related to time is variable. That

acterise mobile applications and mobile computing environ- is, information required to execute a task may or may not bements. This is summarised in Table I. dependent on the bandwidth and connectivity. Forth, within

mobile application, a task may have a diverse informationCategories Elements production related to time. This mean that the importanceGeneral Information type, task structure, task of the information produced by the task related to time cancharacteristics behaviour and task environmentLocation Location dependency, location service vary a lot. That is, the production of the information may becharacteristics awareness, and need for report dependent on the bandwidth and connectivity. Finally, the task

on location lifetime may be different from time to time. This means thatTime Event-trigeredness, time-constraints, a task can be terminated within a short time period, normalcharacteristics information required related to time, or long periods of time.

information produced related to timeand task lifetime IV. CHALLENGES SEEN FROM TRANSACTIONAL SUPPORT

TABLE I PERSPECTIVE

SUMMARY OF THE MOBILE APPLICATION CHARACTERISTICS From the above characteristics analysis we can infer thatthe challenges for the transactional support are many. First,all the elements of the general characteristics can be seen as

Collaborative applications, as we can understand from challenges that must be faced and addressed properly. Thestudying DocuSearch, can mainly be characterised by its het- fact that the information type is heterogeneous leads to that aerogeneity and dynamic nature. The work modes are in contin- transaction manager must deal with diverse information basesues changes. These characteristics also apply to collaborative and not only a relational database as in traditional databasemobile applications and mobile computing environments. In environments. Moreover, the task structure variation meansaddition, we must take into account the notion of mobility. that if we model each task as a sub-transaction/transaction, weNow, based on our investigation in [3], we can divide have to deal with transactions with varying structures as well,

mobile mobile applications into general, location, and time and not only flat (acid) transactions. This, in turn, means thatcharacteristics, we have to take into account any dependencies among them.The general characteristics concerns information type, Similarly, with the varying task behaviour where the tasks,

task structure, task behaviour, and task environment. First, for example, cannot be planned in advanced, the transaction

execution cannot be specified completely in advance. This that information shared among applications is heterogeneous.leads to challenges such as allowing transaction execution to Further, by allowing the customisation of the ACID properties,be adjustable at runtime. customisation of the transaction structure, and specification

Second, with the time characteristics we may meet new of the incurred dependency, we can address the challengeschallenges, especially in the way transactions are to be ex- incurred by varying structures. To some extent, such cus-ecuted. As examples, a task may involve short lived transac- tomisation of structures can be accomplished during runtimetions, open-ended transactions, transaction with clear termi- by allowing transactions to dynamically restructure. Also,nation deadline, etc. This will also affect how resources are the challenges on the task behaviour are partially addressedshared among applications/users and interaction among them. by this, and by making transaction execution specificationA resource may be shared synchronously or asynchronously. possible (see Section II-B).

Besides the above, an implicit challenge is the fact that Secondly, to deal with the challenges incurred by the timewe may have frequent connection or disconnection. Loss of characteristics, we have developed the CAGISTrans frame-connection within mobile environments can either be voluntary work to allow transaction to run as open-ended transcation(e.g., because the user wants to stay off-line to save money) and that they can be long-lived. However, the framework doesor involuntary (e.g., the user cannot stay online due to bad not provide any explicit possibility for setting a deadline forbandwidth, low battery capacity, out of the network coverage). transaction execution. This is left to application to set.This also means that transaction can be aborted while still Mobile/Wi reless Unitsexecuting. Although, many of the transactional solutions todayhave attempted to address this issue (see Section VI), theauthor believes, finding a properly way to deal with this is *ustill a challenge. PrWS

Further, as also can be inferred from above, in mobileMobi1/ rl es

applications users tend to have different work modes all the Bas prBase tio

time. This is challenging as it requires the transaction to always G iWShave to deal with different situation. For example, engineers =at DocuSearch may in one time, want to work together in a GWStight collaboration (with real time cooperation) for exampleduring a module integration or testing phase, while in other _ P PrWStime they may to work on their own without involving others __during coding processes. Stationary

Handling correctness in these situations is also a main ii Workstationsconcern. Finding a sensible trade-off between strict con- -- J mPrWS :Private Workspace

currency control to preserve consistency and anarchy has Mainframe/dataserver rWS Private WorkspaceGWS Private Workspace

always been a big issue within this research area. Frequent PWS Private Workspaceconnection/disconnection and varying work modes have madethe provision of suitable support for shared data consistencychallenging.And last but not least, finding appropriate transaction model Nevertheless as part of the transaction support for long-

to deal with more than one needs or situation is not feasible. livedness and varying sharing and work modes, we haveThis is a challenge that we have to address. developed a workspace concept, as illustrated in Figure 2.

Originally, our workspace concept distinguish between pub-V. ADDRESSING THE CHALLENGES WITH lic workspace (PWS), group workspace(GWS) and private

CAGISTRANS workspace (PrWS) in a generic workspace hierarchy (seeOne of the main goals with the development of the CAGIS- Figure 3). The operations used to interact with the workspaces

Trans framework was to enable the transactional support to are specified as advanced operations. In CAGISTrans, we havefit different needs in cooperative work or cooperative applica- used the following operations:tions. In addition, we wanted to allow the transactional support . write-check-out (wco) and read-check-outto be adjustable during runtime. In this way, the support can (rco): check out data from the public workspace foralso be adapted to situation changes. write and read, respectively (thus distinguishing the

Referring our presentation of CAGISTrans in Section II) we intention behind the check-out operation).can address the challenges described in Section IV as follows. . upward-check-in (uci): check in data to a parent

Firstly concerning general characteristics, we developed the group workspace i.e., up one level only.CAGISTrans framework and system to not to bedependent on . check-in (ci): check in data from any workspace toany underlying database. The framework was supposed to be the public workspace.built on top of a DBMS, Web-server, file systems etc. [1]. . refresh: update a copy of data in the private workspaceFor this reason, we can in most of cases deal with the fact with the one residing in the parent workspace e.g, check-

out from a group workspace to a private workspace. data on a mPrWs are lost due to loss of device (e.g., theft).Workspace data operations such as read, write, update Full address of disconnection challenges would therefore still(i.e., read and then write), and some advanced opera- be an issue for further studies and development.tions which are needed to manipulate data at a specificworkspace. Advanced operations include those needed for VI. RELATED WORKconsistency level upgrade, after an upward-check-in. Related work can be divided into two categories.

The first category includes transaction models developedw - t b PWSrco specifically to support mobile applications. Several so-called

mobile transaction models have been developed the last 10years.

GWS | (W5 One of the earliest is Reporting and Co-transactions model[4]. It is a transaction models developed as an extension to

ulci / |refresh the open nested transaction model [5] by addressing issueson cell migration. Although this model address the issues

PrWS PrWS ... PrWS of mobility and it is indeed an advanced transaction model,refresh < , <1 lCi it has its weaknesses with respect to collaboration support

since it enforce serialisability. The next model is the Weak-Strict Transaction model [6], [7], proposing a transactionmodel to allow transaction execution in a disconnected mode

Fig. 3. Workspace Hierarchy by allowing data to be replicated at a mobile host via so-called clusters. This transaction model is flexible with re-

With only these three workspace types, we cannot deal with spect to frequent disconnection by allowing compensationthe mobility aspect. As a proposed extension to address this, of transactions. However, it enforce isolation of transactions,we add a new workspace type called mobile private workspace thus it is not necessarily suitable for cooperative applications(mPWS) (see Figure 3). The idea is that for users working on in general. Another model that also addresses the issues ofapplications on mobile devices they have their own mobile disconnection is the two-tier transaction model[8]. It proposesprivate workspaces that are to be connected to a stationary a method for devised replication of data and transactionone. This is a mirror copy of this stationary workspace. So, processing to allow mobile hosts that are occasionally dis-for example, when an engineer at DocuSearch works on his/her connected to run properly. It distinguish between master andlaptop or PDA, he/she has both a stationary private workspace tentative versions of (replicated) data, and base and tentativeand mobile private workspace at the same time. In a way transactions. Correctness is ensured by enforcing isolation andwe can see a mPrWS as a child of the PrWS. Thus, new atomicity of the base transactions. In this way, this transactionworkspace operations are not needed. Instead, for example, to model would also be too strict for cooperative applications.update a copy on a mobile device we can use refresh (on A newer transaction model, the Kangaroo transaction modela previously checked-out data) and uci to check-in data to [9] proposes a model that allow transactions to jump fromthe PrWS from mPrWS. one stationary host to another through a mobile host as it

To illustrate, consider that an engineer at DocuSearch, is on move through cells. It is built on the concepts ofTom, is working on the GUI module, which he has checked open-nested transaction model and the split-transaction model.out from a group workspace (GUI is now on a private With the Kangraoo model, it seems that neither atomicity norworkspace). Suppose first, Tom is working on his laptop that isolation is enforced/guaranteed therefore it might be used tois connected to the companys wired LAN. His workspace is support mobile collaborative applications. However, the issuesat this time a stationary PrWS. Then, Tom wants to switch of disconnection and replication are not addressed. Finally, theto a WiFi connection so he can move around. Before he Moflex transaction model [10] has been proposed as a gener-goes wireless he leaves a copy (a backup) at his private area alisation of the flex transaction model [11]. It was developedat the companies server. For this he uses upward-check-in specifically to support location-dependent subtransactions in(uc i (GUI modul e)). Then, he can proceed working on his heterogenous multidatabase systems. As with the flex model,module at his local drive, which now becomes his mobile Moflex also enforces isolation, which makes it too strict forworkspace (mPrWS). When he wants to update his stationary collaborative applications.copy at a later stage, he just executes uci (GUI module) The second category consists of transaction framework thatagain, but if/when he needs the copy of the stationary one, for can be extended to support mobile applications.example due to some fatal error, and that this copy is the last Transactional framework to overcome the limitation trans-working one, he uses refresh. action models have with respect to the broad nature of

Because of the use of the mobile workspaces, we can application areas. An ideal model would be a model thatsomehow also deal with the aforementioned disconnection are able to cover all kinds of applications. However, thisissues. Problems first occur when the connection is loss during neither feasible nor practical. This has call for the developmentoperation execution - for example during check-in, and when of frameworks for transaction models that are tailorable to

different situations. One of the earliest frameworks in this at specifying and implementing application specific ETMs.category was ACTA [12], [13]; a framework providing a Unlike ASSET and TSME, the main focus of RTF was tofoundation for synthesizing and reasoning about transactions. develop modules that implement existing ETMs on top of com-However, although ACTA is a very useful formal tool for mercial TP-monitors. The basis components are transactionspecification and verification of new transaction models, it adapters i.e., add-on software modules providing extensibleis only a formal and theoretical framework, that does not transactional services for advanced applications. Using theseprovide any means of making transactions operational during adapters, RTF extends the facilities of a TP-monitor, allowingruntime. Nevertheless, ACTA has been used to reason about it to execute transactions beyond the ACID models. Initially,the reporting and co-transaction model [4] RTF was implemented on top of Encinal, demonstrating the

With this as a motivation, ASSET A System for Supporting applicability of the framework. It is worth noting, however,Extended Transactions [14] was suggested to implement the that RTF does not provide support for user-defined correctnessideas of ACTA with O++ language primitives. The idea is criteria. This was beyond the scope of RTF, and was leftto allow the coding of extended transaction models (ETMs) for future studies [8]. Rather, the focus was on provisionusing the O++ programming language, and to make these of extensible lock protocols handling concurrency. Moreover,models operative on top of a DBMS. The ASSET primitives RTF is mainly a database-centred framework, and does notare begin, abort, commit, delegate, and permits, allowing a explicitly address the support for other resource bases that aretransaction models designer to create transactions, delegate not supported by the actual underlying TP-monitors.resources among transactions, and permit dirty reads etc. The CAGISTrans framework is aimed at providing theamong them. In [14], the authors have shown the use of possibility to specify and implement transaction models fittingthese primitives to specify ETMs, demonstrating the use- different situations. In this sense, it shares the basic objectivesfulness of the framework. However, requiring a transaction with the frameworks described above. However, with CAGIS-models designer to step down and program transactions might Trans we attempted to go further by extracting the beneficialintroduce some risks with respect to bugs. Moreover, since a features from existing models and frameworks, and extendtransaction model has to be coded and compiled before the these to cope with the remaining problems that are not fullyinvolved transactions are executed, it is necessary to have of addressed in the previously developed models and frameworkscomplete a priori knowledge about the tasks to be carried out i.e., means of supporting mobility, as well as fully dynamicas well as the induced sharing patterns. This makes it rather and fully heterogeneous environmentsdifficult to provide adequate support for dynamically evolvingcollaborative activities, including mobile applications. VII. CONCLUDING REMARKS

Another framework that is similar to ASSET, that allowsspecification~~~~~~~~~~animlmnaino,Ts sTM h In this paper we have discussed and evaluated how anTransactionSpecification andimplementatinagem Envsiro nT [ adaptable transactional framework such as CAGISTrans wouldTransaction Specification and Management Environment [15].

wr nclaoaiembl plctos ehv icseUnlike ASSET, TSME was developed as a complete trans- wor inpollaboratemile applications.avdicse' . .~~~~~tasato the important characteristics of such applications and howaction management system with a programmable transacon e challene the transactional suort. Usin CAGISTransmanager that enforces the specified transaction models dur- y g ging~~~~~~~rutieTh.anbidn lcso h rnato as a starting point we, discussed how these challenges can

be addressed with an adaptable transactional framework. Wespecification in TSME are dependencies. These are classified have found out at that it is crucial to allow the transactionalinto state dependencies, specifying dependencies related totransaction states; begin, abort and commit, and correctness support tosfit dferent neseds tenionsotohewiorkpcetnddependencies, specifying dependencies related to correctness changngconnecthon modes. From these vewsd we believe ourcriteria; determining which concurrent executions of com-

approachiS useful. However, there are s wllissues that we haveplex transactions preserve consistency and produce correct apoc sueu.Hwvr hr r tl susta ehvrlesutrns.ctSEios apromisingconframewor tha has fureth to deal with. Examples are frequent disconnection and datademsutrateThMEi advantagesofallowingarar

m e des i ert replication. So, one of our future work is to further develop thespecifynseverale applicantigesonspifi transaco modeldeswitinet mobile workspace concept to fully deal with the disconnection

issues. As part of this, there is also a need to further developa single environment, and supporting them during runtime. the support for replication and system recovery.One of the main strengths of TSME is its extensive supportfor execution control, allowing sophisticated coordination of ACKNOWLEDGMENTtransaction execution. However, TSME do not seem to providesupport for dynamic restructuring, making it less appropriate We would like to thank Mads Nygard for his previousfor dynamically evolving environments. Moreover, the trans- contributions to this work.action manager component in TSME is apparently built fromscratch, and integration with existing DBMSs seems to be REFERENCESdifficult. [1I] Heni Ramampiaro, CAGISTrans: Adaptable Transactional Support forRTF the Reflective Transaction Framework [16] is an- Cooperative Work, Dr.ing thesis no. 2001:94, Norwegian university ofother framework similar to those described above which aims science and Technology (NTNU), 2001.

[2] Heri Ramampiaro and Mads Nygard, "CAGISTrans: Providing adaptable [10] Kyong-I Ku and Yoo-Sung Kim, "Moflex transaction model for mobiletransactional support for cooperative work - an extended treatment", heterogeneous multidatabase systems.", in RIDE, 2000, pp. 39-46.International Journal ofInformation Technology and Management, vol. [11] Dennis McLeod, Ron Sacks-Davis, and Hans-Jorg Schek, Eds., 16th5, no. 1/2, pp. 23 - 64, January/April 2004. International Conference on Very Large Data Bases, August 13-16,

[3] Alf Inge Wang, Carl-Fredrik S0rensen, Heri Ramampiaro, Hien Nam Le, 1990, Brisbane, Queensland, Australia, Proceedings. Morgan Kauf-Reidar Conradi, and Mads Nygard, "Using the mowahs characterisation mann, 1990.framework for development of mobile work applications", in 6th Inter- [12] Panos K. Chrysanthis and Krithi. Ramamritham, "ACTA: A frameworknational Conference on Product Focused Software Process Improvement for specifying and reasoning about transaction structure and behavior",(PROFES'2005). 2005, Springer Verlag LNCS. in Proceedings of the 1990 ACMSIGMOD International Conference on

[4] Panos K. Chrysanthis, "Transaction processing in mobile computing en- Management of Data (SIGMOD92), Hector Garcia-Molina and H. V.vironment", in IEEE Workshop on Advances in Parallel and Distributed Jagadish, Eds. May 1990, pp. 194-203, ACM Press.Systems, 1993, pp. 77-83. [13] Panos K. Chrysanthis and Krithi Ramamritham, "Synthesis of extended

[5] Gerhard Weikum and Hans-J Schek, "Concepts and applications of transaction models using ACTA", ACM Transactions on Databasemultilevel transactions and open nested transaction", in Database Systems, vol. 19, no. 3, pp. 450-491, sept 1994.Transacation Models for Advanced Applications, Ahmed K. Elma- [14] Alexandros Biliris, Shaul Dar, Narain H. Gehani, H. V. Jagadish, andgarmid, Ed., pp. 350-397. Morgan Kaufmann, 1992. Krith Ramamritham, "ASSET: A system for supporting extended

[6] Evaggelia Pitoura and Bharat K. Bhargava, "Maintaining consistency of transactions", in Proc. of the ACM SIGMOD International Conferencedata in mobile distributed environments", in ICDCS, 1995, pp. 404-413. on Management of Data (SIGMOD 94), Richard T. Snodgrass and

' ' ' .~~i Marianne Winslett, Eds. May 1994, ACM Press.[7] Evaggelia Pitoura and Bharat K. Bhargava, "Data consistency inMaian Wiset Eds Ma 194 CMPes

[7]evagtentlaPiouracand BhatrabutedK.yBharga, "DaETracnsistencyD [15] Dimitrios Georgakopoulos, Mark F. Hornick, and Frank Manola, "Cus-

Engt, vol. co,no. 6, pp. 896-915, 1999. tomizing transaction models and mechanisms in a programmable envi-

[8] Jim Gray, Pat Helland, Patrick E. O'Neil and Dennis Shasha "The ronment supporting reliable workflow automation", IEEE Transactions[8JiGry Pa eln,PtikE 'el n ensSah,"h on Knowledge and Data Engineering, vol. 8, no. 4, pp- . 630-649, Augustdangers of replication and a solution.", in SIGMOD Conference, 1996, 1996.pp. 173-182. [16] Roger Barga, A Reflective Framework for Implementing Extended

[9] Margaret H. Dunham, Abdelsalam Helal, and Santosh Balakrishnan, "A Transactions, Ph.d. dissertation, Oregon Graduate Institute of Sciencemobile transaction model that captures both the data and movement and Technology, April 1999.behavior", Mobile Networks and Applications, vol. 2, no. 2, pp. 149-162, 1997.