J Supercomput (2012) 60:62–86 DOI 10.1007/s11227-009-0277-6
Context-adaptive and energy-efficient mobile transaction management in pervasive environments Feilong Tang · Minglu Li
Published online: 1 April 2009 © Springer Science+Business Media, LLC 2009
Abstract Pervasive computing is a user-centric, scalable, parallel, and distributed computing paradigm, allowing users to access to their preferred services even while moving around. Transaction management for pervasive environments has to provide mobile users with reliable and transparent services anytime anywhere. To make such a vision a reality, the communication of pervasive transaction processing should be context-aware for adapting to dynamically changing execution environments, and energy-efficient for prolonging the lifetime of battery-powered mobile devices. In this paper, we propose a context model and a context-aware transaction model for pervasive transactions, and present a context-adaptive and energy-efficient transaction management mechanism (CETM) that can dynamically adjust transaction execution behaviors in terms of current context information. Moreover, we model and verify the correctness of the CETM through Petri nets. The simulation results have demonstrated that our transaction management mechanism CETM can significantly reduce the failed probability of concurrent pervasive transactions. Keywords Context awareness · Transaction processing · Pervasive computing · Petri net
F. Tang () · M. Li Department of Computer Science and Engineering, Shanghai Jiao Tong University, Shanghai 200240, China e-mail:
[email protected] M. Li e-mail:
[email protected] F. Tang School of Computer Science and Engineering, The University of Aizu, Aizu-Wakamatsu, Fukushima 965-8580, Japan
Context-adaptive and energy-efficient mobile transaction management
63
1 Introduction Pervasive computing has been emerging rapidly as an exciting new paradigm for scalable parallel systems (SPS), with the goal for users to share physical resources and computing services anytime anywhere while moving around. Owing to the high mobility of users, pervasive systems run in an extremely dynamic and heterogeneous environment, where various networked devices and communication protocols coexit; and network topology and bandwidth are volatile dynamically and frequently [1–5]. Therefore, open pervasive environments are prone to various failures from networks, devices, applications, and basic services of pervasive systems [3]. To facilitate users as much as possible, pervasive systems have to intelligently handle failures and recovery and hide complex processes from users, providing communication and computing services in a transparent way [1, 3]. As a result, transaction management technology, which has widely been used to guarantee system consistency for various distributed computing paradigms, is an important enabling technology to make user-centric pervasive computing a reality. Context adaptation is an important characteristic distinguishing pervasive systems from traditional distributed environments. Pervasive transactions, therefore, have to be aware of time- and space-changing context and accordingly adjust execution behaviors dynamically. Specifically, pervasive environments have the following features: – high mobility—Pervasive systems support for mobile users with online transparent services. With the movement of a node, its neighbors that can be directly accessed keep on continuously changing. As a result, the context-aware communication mechanism characteristic to pervasive environments is an important issue for pervasive transaction processing. – limited resources—Networked mobile devices have limited energy, computing capacity, and storage resources. Energy-efficient communication has to be considered [25, 26]. – uncertain support from fixed communication infrastructure—Traditional mobile transaction models rely on wired fixed networks. In pervasive environments, however, networks cover almost every area and computing and service extend from fixed networks to various wireless networks. The fixed infrastructure such as base stations is not requisite any more. – heterogeneous and dynamical environment—Networks, data, and devices are different from each other in pervasive environment. Various wireless networks with different communication protocols (e.g., Bluetooth, Wi-Fi) and wired networks coexist while at the same time the network connection and bandwidth are extremely unstable. The above features present the requirements for context-aware and energyefficient transaction management. We use an example of medical treatment assistance in Fig. 1 to illustrate our research issues. Let each hospital in a city scatter a few of mobile medical assistants (MMA) equipped with mobile devices, which keep on moving around the city for medical treatment assistance to potential patients. A traveler Alice, driving a car with a mobile device (MD), suddenly suffers from an acute
64
F. Tang, M. Li
Fig. 1 A scenario of pervasive transactions
illness and needs to find a hospital immediately. Alice first discovers and then requests the nearest MMA (T1 ). The MMA checks its lightweight mobile database and reserves a sickbed in terms of Alice’s requirements (T2 ). If the MMA does not hold the corresponding data (e.g., the number of currently available sickbeds) in the local database, it downloads the data from the hospital central database on a fixed network or transfers the reservation request to the central database server (T3 ), in the energyefficient way. After a sickbed is successfully reserved, Alice queries public traffic service to query the best path to that hospital (T4 ). In the case that Alice cannot find out a MMA within a given distance, however, she queries the Health Service Central Hospital for sickbed reservation (T5 ), which is far away, but can provide versatile medical services. The above scenario reveals the following characteristics of transactional applications in pervasive environments. – context-dependent—High mobility of networked nodes makes transaction context continuously changing, including network connection and bandwidth, device states, location, user behaviors and so on. – energy-constrained—Mobile devices are not connected to power supplies and many of them are small and battery-powered. There have been many transaction models proposed for traditional mobile systems [6–9], paying great attention to movement, disconnection, and hand-off of mobile hosts. But they cannot be directly applied to mobile and pervasive systems because of the following: (1) insufficient support for the mobility—Existing mobile transaction models are built on the client–server–proxy architecture [10], where fixed hosts are data sources and servers of transactions. Therefore, these models only address the mobility of clients, without considering the mobility of data servers. In pervasive environments, however, mobile devices interact with each other in the peer-topeer way and both the client and the server will be moving during transaction processing. (2) few considerations on context awareness—Pervasive transaction management has to adapt to transaction context. Existing proposals have not solved such an issue. (3) energy limitation—Energy is a serious limitation to battery-powered mobile devices. But existing proposals little considered the energy efficiency issue of mobile hosts. This paper presents solutions to above three issues, targeting on context awareness based transaction management especially on network-aware and energy-efficient
Context-adaptive and energy-efficient mobile transaction management
65
message communication and transaction processing modes. First, we model the context in mobile and pervasive transaction environments. We then propose a contextaware transaction model. Next, we present a context-aware and energy-efficient transaction management (CETM) mechanism. Finally, we model and verify the correctness of the CETM through Petri nets. Our motivation is to provide a context-aware and energy-efficient transaction service characteristic to mobile and pervasive environments, as well as reduce energy consumption of battery-powered mobile devices. The remainder of this paper is organized as follows. In the next section, we review related work. Section 3 proposes a context model for pervasive transactions and a context-aware pervasive transaction model. In Sect. 4, we present a context-aware and energy-efficient transaction management mechanism (CETM). Section 5 models the CETM and validates its correctness through Petri nets. Experiments and evaluation on our CETM are reported in Sect. 6. Finally, Sect. 7 concludes this paper with a discussion on future work.
2 Related work Traditional mobile transaction models focused on variable bandwidth, network disconnection, replication and synchronization, and hand-off of mobile hosts. Clustering [11] (also called Weak-Strict) groups semantics-related databases within a cluster. Each data is kept two versions: weak consistency (local consistency) version for weak transactions and strict consistency (global consistency) version for strict transactions. Strict and weak transactions are executed when a MH (mobile host) is strongly and weakly connected with fixed networks, respectively. Similar to the clustering, two-tier replication [12] (also called base-tentative) maintains a master copy for base transactions and multiple replicated copies for tentative transactions. High Commit Mobile (HiCoMo) [13] keeps two kinds of tables: base tables for base transactions and aggregate tables for HiCoMo transactions. Isolation Only Transaction (IOT) [14] also includes two kinds of transactions for MHs’ connected and disconnected states, respectively. On the coordination of mobile transactions, the Moflex model [15] submits subtransactions to mobile transaction managers running in base stations, which then submits the subtransactions to databases. Each Moflex transaction is composed of a set of dependency relationships, handoff rules, and expected final states. Kangaroo [16] deploys a Data Access Agent (DAA) in each base station for mobile transaction management. Promotion [17] is a nested long-lived transaction model where top transactions are executed on fixed hosts and subtransactions on MH controlled by the compact. In preserialization [18], each base station runs a global transaction coordinator responsible for transaction coordination, and disconnect and mobility management. TCOT [19] is a one-phase commit protocol for a transaction termination decision (e.g., commit, abort, etc.) in message-oriented systems. This protocol uses a timeout mechanism to reduce the impact of the slow and unreliable wireless link, where the timeout not only enforces the termination condition but also the entire execution duration as well. In 2002, Lim et al. [20] proposed a hierarchical concurrency control algorithm—v-lock, which uses global locking tables to serialize global transactions,
66
F. Tang, M. Li
detect and remove global deadlocks. The global locking tables are created with semantic information contained within the hierarchy. A data replication scheme, which caches queries and the associated data at the mobile unit as a complete object to alleviate the limited bandwidth and local autonomy restrictions, was also used in this research. Some proposals on data management and transaction management for pervasive environments have also been reported. Franklin [21] at UC Berkeley discussed requirements for pervasive data management, and analyzed how to manage data according to features of pervasive computing from three aspects: support for mobility, context awareness, and support for collaboration. MoGATU [22] set up a data management framework for pervasive computing, which abstracts all P2P devices in information providers, information consumers and information managers (InforMa). InforMa keeps information of neighboring devices, and provides dynamical information query for pervasive applications. The above client–proxy–server based mobile transaction models need base stations for communication and transaction management and fixed data servers for transaction execution. So, they address the mobility of clients only. In pervasive environments, however, users and devices keep on highly moving so there are no fixed base stations. Instead, mobile devices can work as both clients and servers in the peer-topeer way. As a result, the pervasive transaction model needs to support the mobility of not only clients but also servers. Next, pervasive transaction context continuously changes, which significantly affects the successful ratio and performance of pervasive transactions. Pervasive transaction management has to self-adapt dynamical transaction context. Finally, The reviewed techniques do not address the energy-related issues. This paper will investigate these issues and propose a context-adaptive and energy-efficient management mechanism for pervasive environments.
3 Context-aware transaction model Context awareness enables systems to automatically configure and adjust to provide better services for users. In this section, we will present a context model and a context-aware transaction model because they are prerequisite to adaptive transaction management. 3.1 Context model for pervasive transactions Context model is a formal representation of physical space, information space, and human activities. Pervasive transaction context involves the information relevant to individuals, networks, and devices within the activity space, specifically including the following dimensions: – – – –
Person: profile, preferences, and requirements of users; Wireless network: connectivity and performance of networks; Mobile device: computing and storage capacity of mobile devices; and Location: longitude and latitude (or relative position) of mobile devices.
Context-adaptive and energy-efficient mobile transaction management
67
Table 1 Context of pervasive transactions Entity Person
Wireless Networks (WN)
Mobile Devices (MD)
Location
Attribute
Value
Name
user’ name
Sex
male or female
Age
value of age
Requirement
requirement description
Preference
behavior preference
Connectivity
connected, disconnected
Bandwidth
high, medium, low
Delay
high, medium, low
Lost_ratio
high, medium, low
Cost
expensive, cheap, free
Stability
good, medium, bad
Available_battery
full, half, low
Available_data
available, unavailable
Computing_capacity
high, medium, low
Available_memory
full, half, low
Available_cache
full, half, low
Security
secure, open
Location
pairs of longitude and latitude
Table 1 lists the context of pervasive transactions in detail, where some attributes may be described more accurately. We can represent, for example, computing capacity by the main frequency of a mobile device and available memory by the size of available storage. We abstract transaction context using entities, attributes, and relationships among entities and accordingly model the context using entity-relationship (E-R) diagram. The graphic context model for pervasive transactions is shown in Fig. 2, where we only illustrate attributes of the entity person. Attributes of other entities can be easily complemented in the same way according to Table 1. Note that some attributes (e.g., preference of a user) cannot be directly abstracted from entity profiles and data mining-like technologies have to be used for this purpose. Any entity is described through pairs of attribute and value. There is a relationship between any two entities, for example, the relationship “Person m n Location” means that a person may locate at many locations while a specified location can be visited by many persons. We divide attributes of entities into two kinds: static attributes (e.g., name of a person) and dynamical attributes (e.g., bandwidth of a wireless network). Dynamical attributes need to be collected dynamically during the execution of a transaction. We will concentrate on how to adapt to dynamical context to improve transaction efficiency and reduce energy consumption of mobile devices.
68
F. Tang, M. Li
Fig. 2 Context model for pervasive transactions
3.2 Context-aware transaction model A context-aware transaction model has the ability to adjust dynamically behaviors in terms of changing transaction context. We present its formal definition as follows. Definition 1 A pervasive transaction is a 6-tuple (T, CT, ECA, D, TS, FS) where: – T = {Ti |1 ≤ i ≤ n}: the set of all subtransactions in a pervasive transaction; – CT = {CT i |1 ≤ i ≤ n}: the set of compensating transactions for all the subtransactions. – ECA = ECAi : the list of ECA rule descriptors for all the subtransactions. – ECAi = Ei , Ci , Ai : the list of 3-tuple with event, context, and action for the subtransaction Ti ; – D: the set of intradependencies that specify relationships between Ti and Tj (Ti , Tj ∈ T ); – TS = {Si |1 ≤ i ≤ n}: the set of states of all subtransactions; – FS: the set of acceptable final states. We explain each element in the above transaction model in detail. T denotes all subtransactions in a pervasive transaction. In this paper, we only consider compensable transactions, i.e., each subtransaction Ti (Ti ∈ T ) can associate at least one compensating transaction CTi such that CTi can semantically undo the affects of Ti commit. CT is the set of all compensating transactions CT i (1 ≤ i ≤ n). Note that some subtransactions, for example, a best path query described in the scenario, do not need to be compensated so that corresponding compensating transactions are empty. ECA = ECAi |1 ≤ i ≤ n is a list of ECA rule descriptors, where ECAi is a rule descriptor for a subtransaction Ti and ECAi has a higher priority than ECAi+1 . In particular, each ECAi = Ei , Ci , Ai is also a list of 3-tuple (event, context, and corresponding action), describing multiple context-based execution policies for a subtransaction Ti , where – Ei = {Eij }: the set of events that occur during the execution of Ti ;
Context-adaptive and energy-efficient mobile transaction management
69
Table 2 Transaction state description Symbol
State
Description
I
Initiation
Ti does not start to execute
E
Executing
Ti is executing and has not committed
S
Committed
Ti has successfully committed
F
Failed
Ti has failed to commit and rollbacked to previous state
C
Compensating
compensating transaction Ci is been executing
Fig. 3 State conversion diagram of transactions
– Ci = {Cik }: the set of context associated with a subtransaction Ti . We take Ci as the conditions that executing Ti has to meet. Ci covers four dimensions: WN, MD, Location, and Person described in Table 1. – Ai = {Ail }: the set of corresponding actions. D is the set of intradependencies between Ti and Tj (Ti , Tj ∈ T ). We define two kinds of intradependencies: success dependency (≺s ) and failure dependency (≺f ). Ti ≺s Tj means that Tj cannot be executed until Ti successfully commits. Ti ≺f Tj denotes that Tj can start to execute only if Ti fails to commit or is compensated in the case that Ti has committed. TS = {S1 , S2 , . . . , Sn } is the set of states of all subtransactions in a pervasive transaction. Si , the state of subtransaction Ti , is one of five possible states: I , E, F , S, and C (see Table 2). Each subtransaction starts with state “I ” and ends with state “S” (Ti is successfully committed) or “F ” (Ti is aborted). Figure 3 illustrates the state conversion of transactions. FS is the set of acceptable final states. A pervasive transaction may have multiple proper final states acceptable by a user, probably with different priorities. For example, Alice firstly discovers the shortest qualified devices for the sickbed reservation and after a failure, he will contact with the Health Service Central Hospital to reserve a sickbed. 3.3 A case for pervasive transactions We model the medical treatment reservation scenario mentioned in Sect. 1 as a mobile pervasive transaction (T, CT, ECA, D, TS, FS). As described above, MD is a mobile device used by Alice; MMA is a mobile medical assistant, which is equipped with mobile device(s), and keeps on moving around. According to Definition 1, we have: – T = {T1 , T2 , T3 , T4 , T5 }. The global transaction T consists of five subtransactions. For the meaning of each subtransaction, please refer to the scenario in Sect. 1.
70
F. Tang, M. Li
– CT = {∅, CT 2 , CT 3 , ∅, CT 5 }. CT 2 , CT 3 and CT 5 are compensating transactions of T2 , T3 , and T5 , respectively. T1 and T4 do not need to be compensated. – D = {T1 ≺s T2 , T2 ≺s T4 , T2 ≺f T3 , T3 ≺s T4 , T1 ≺f T5 , T5 ≺s T4 }. The intradependency D specifies T may be executed in one of three sequences σ1 = {T1 , T2 , T4 }, σ2 = {T1 , T3 , T4 } and σ3 = {T5 , T4 }. – TS = {S1 , S2 , . . . , S5 }. Si is the state of subtransaction Ti . The transaction initiator MD updates TS once a subtransaction is executed. – FS = {(S, S, −, S, −), (S, F, S, S, −), (F, −, −, S, S)}, where “S” and “F ,” respectively, stands for a successful commit and an abort of the corresponding subtransaction while “−” means that the execution state of the subtransaction does not affect the decision. ECA describes how to adapt the transaction context and thus is a central element of our pervasive transaction model. In this example, ECA consists of five rule descriptors (each for a subtransaction) such that ECA = ECA1 , ECA2 , ECA3 , ECA4 , ECA5 , where – ECA1 = E1 , C11 , A11 , E1 , C12 , A12 . E1 , C11 , A11 and E1 , C12 , A12 describe that MD successfully connects with and fails to discover the nearest MMA, respectively, where – E1 : Alice tries to discover the nearest MMA; – C11 : network link and bandwidth among the MD and qualified MMAs are good enough for communication; and a discovered MMA is able to handle the transaction request; – A11 : MD selects the MMA as a transaction participant, on behalf of Alice; – C12 : network link or bandwidth between the MD and any MMA is not qualified for communication; – A12 : MD connects with the Health Service Central Hospital. Note that in that case, subtransaction T1 has failed. – ECA2 = E2 , C2 , A2 . The MMA checks its local database to reserve a sickbed in terms of Alice’s requirements. If the data is locally available, T2 can successfully commit. Otherwise, T2 will fail. – ECA3 = E31 , C31 , A31 , E32 , C32 , A32 . In the case that the MMA cannot find the needed data in its local database, it continues to handle the sickbed reservation in the following way: – E31 : subtransaction T2 failed; – C31 : the MMA has enough computing and storage capacity; – A31 : the MMA downloads the needed data from the central database; – E32 : the MMA finds that it is not able to store the needed data; – C32 : link between the MMA and the central database server is qualified; – A32 : the MMA transfers the sickbed reservation request to the central database server. – ECA4 = E4 , C4 , A4 . After finishing the sickbed reservation, MD queries public traffic information service to discover the best path to that hospital. – ECA5 = E5 , C5 , A5 . MD requests the Health Service Central Hospital to reserve a sickbed. We assume the central database server of the Health Service Central Hospital can handle transactional medical treatment request all the time.
Context-adaptive and energy-efficient mobile transaction management
71
4 Context-aware and energy-efficient transaction management We first analyze the limitation of traditional client–server–proxy structure to pervasive transactions, and accordingly propose a new transaction processing architecture characteristic to mobile and pervasive environments. We then present a context-aware and energy-efficient transaction management mechanism (CETM). 4.1 System model In the client–proxy–server based traditional mobile transaction systems, base stations in the fixed network are at the center, working as gateways among mobile clients and fixed servers as well as mobile transaction managers. A mobile host (MH) can communicate with a base station only when it locates within the corresponding cell, i.e., the MH disconnects with any database server if the MH moves out of the range of any base station. We call such a situation as the unavailable service problem (USP). Figure 4 illustrates an example of the USP problem, where a MH cannot connect any base station when it moves to the location B because the radio range of MH is not able to cover any base station. The USP problem seriously restricts online services while users are moving around. But the online service is one of the most attractive scenes distinguishing pervasive computing from a traditional mobile computing paradigm. Accordingly, participants of a pervasive transaction should communicate with each other anytime anywhere. To solve the USP problem, we propose a new architecture for pervasive transactions, as shown in Fig. 5, where mobile devices that support the same wireless communication protocols (e.g., Wi-Fi) automatically discover and interconnect with their neighbors to set up wireless mesh networks. The proposed pervasive transaction architecture consists of three layers: fixed network in top layer, wireless routing backbone in middle layer, and wireless mesh subnetwork in the lowest layer. In such a layered mesh network, each wireless node can forward data for other nodes so that any two nodes may communicate by multiple hops. In Fig. 5, dashed and solid lines respectively represent wireless and wired communications; and thicker lines mean that corresponding links have higher bandwidth. Fig. 4 Unavailable service problem (USP)
72
F. Tang, M. Li
Fig. 5 The architecture for pervasive transaction processing
Mesh nodes may be deployed on buildings and traffic lights, as well as equipped on vehicles. MR is only a mesh router while MRG both a router and a gateway for communicating with mobile devices and/or a fixed network. Symbols used frequently in this paper are given in Table 3. We divide mobile devices as two kinds: MD (a mobile device without any database, e.g., a smart mobile phone) and MD-D (a mobile device with a lightweight database, e.g., a powerful laptop). MDs and MD-Ds with an identical communication protocol interconnect into a wireless mesh subnetwork automatically and dynamically. A pervasive transaction is initiated by a mobile device (MD or MD-D). A MD only initiates global pervasive transactions as a client while a MD-D can also execute subtransactions as a server. In summary, a pervasive transaction T possibly is executed in the following execution models: – T is entirely executed by MD-D(s), – T is distributed between MD-D(s) and FHs, and – T is entirely executed by FHs when no qualified MD-Ds are found out. 4.2 Context-aware and energy-efficient transaction management A pervasive transaction is initiated by a mobile device (MD or MD-D), called initiator. The initiator then in the multiple-hop way distributes subtransactions to neighboring MD-Ds or FHs, called executors. In wireless networks, data communication consumes more energy than application operations themselves. Our transaction management mechanism works in the following principles:
Context-adaptive and energy-efficient mobile transaction management
73
Table 3 List of notations Symbol
Description
FH
fixed host
MD
mobile device without a database
MD-D
mobile device with a lightweight mobile database
MR
mesh router
MRG
mesh router with gateway functions
n
the number of subtransations in a global pervasive transaction
find (Pi , Ti )
an initiator discovers a qualified participant for Ti
send (x, y)
a device sends x to y
R(Ti )
execution result of subtransaction Ti
receive (R(Ti ), Pi )
an initiator waits for R(Ti ) from Pi
REQ
a query message for discovering a qualified participant
RES
a response to a REQ message
S
a source node in a participant discovery (i.e., initiator)
D
a destination node (i.e., a candidate of participants)
SD
a service description for executing subtransaction Ti
Hmax
a maximal hop away from the initiator in a participant discovery
h
the number of hops from S to D
DS
device state (e.g., available battery)
path
a set of routing nodes from S to a qualified node D
SUCCESSFUL
a message from a transaction participant committed successfully
FAILED
a message from an aborted participant
CONFIRM
a message by which an initiator commits the global transaction
CANCEL
a message by which initiator undoes subtransactions finished previously
– An initiator discovers the shortest and qualified executors. By qualified, we mean the executors have enough computing and storage capacity and bandwidth among the initiator and the executors. Shortest means the executor has the least number of hops away from the initiator. The less the number of hops, the less energy is consumed for a unit of data transmission. Therefore, our approach reduces the energy consumption of energy-limited mobile devices while at the same time improves the probability of successful transaction commit. – An executor (MD-D) actually performs application operations in the subtransaction. Resource-limited MD-D in general has a lightweight mobile database that holds partial data of the central databases running on the fixed host. If accessed data is available locally, the executor directly performs the subtransaction. Otherwise, the executor will download the accessed data from the central database or transfer the subtransaction to the fixed central database server, in the energy-efficient way. 4.2.1 Transaction coordination Let a global pervasive transaction T consists of n subtransactions such that T = {T1 , T2 , . . . , Tn }. The state of T is a set of states of all subtransactions such that
74
F. Tang, M. Li
TS = {S1 , S2 , . . . , Sn }, where Si (i.e., the state of Ti ) is one of five possible states: I, E, F, S, and C. TS is updated once a subtransaction is executed. Based on TS, states of global transactions can be divided into the following three kinds: – acceptable state: TS reaches one of states acceptable by a user, i.e., TS ∈ FS; – executing state: TS has not reached any acceptable state and a part of subtransactions have not been executed such that TS ∈ / FS ∧ ∃Si = ‘I ’; – failed state: TS has not reached any acceptable state but all subtransaction have been executed such that TS ∈ / FS ∧ ∀Si = ‘I ’. In our target environment, MD-Ds have abilities to handle pervasive transactions. Our transaction coordination mechanism CETM first dynamically discovers qualified devices as transaction executors and then sends subtransactions to them. If data at will is accessed in the execution of a subtransaction is locally available, the executor finishes application operations and commits the subtransaction locally. Otherwise, the executor will decide whether it downloads the data from its central database on a fixed host to local database or transfers the subtransaction to the fixed host. From the system point of view, our transaction management involves an initiator, a set of mobile and/or fixed executors, where the initiator controls the pervasive transaction processing. Figure 6 illustrates the execution flow of our transaction management mechanism. An initiator coordinates a pervasive transaction as follows: (1) find (Pi , Ti ): an initiator discovers a qualified neighboring node as a participant Pi to execute a subtransaction Ti , which will be presented in the Sect. 4.2.2 in detail. It is context-aware which subtransaction will be executed, based on eventcontext-action rule descriptors defined in pervasive transaction T . For the example described in Sect. 3.3, after the event E1 happened, the action A11 (i.e., T2 ) or A12 (i.e., T5 ) will respectively be executed if the context C11 or C12 is qualified. (2) send (Ti , Pi ): the initiator sends Ti to the participant Pi found in the first step. (3) Receive (R(Ti ), Pi ): the initiator waits for execution result R(Ti ) from the Pi . R(Ti ) is a SUCCESSFUL or a FAILED message, which means that Pi has successfully committed or failed to commit, respectively. (4) global decision: based on the T current state TS, the initiator makes a global decision: – global commit: if T reaches the acceptable state, the initiator confirms all committed subtransactions by sending CONFIRM messages to them. At that time, the pervasive transaction T successfully commits. – global abort: if T reaches the failed state, the initiator undoes the committed subtransactions, sending COMPENSATION messages to such participants. In that case, T is aborted. – selection of the next subtransaction: if T is still at the executing state, the initiator selects the next subtransaction Tj based on the R(Ti ) and the intradependency D between Tj and Ti and then goes to step (1). An executor actually performs the incoming subtransaction Ti under the control of the initiator in the following way:
Context-adaptive and energy-efficient mobile transaction management
75
Fig. 6 Execution process of pervasive transactions
(1) data verification: the executor checks the data that will be accessed during the execution of Ti in its local lightweight database. If there is not such data, the executor goes to step (3). (2) subtransaction execution: if the accessed data is locally available, the executor performs Ti : – executing application operations in Ti ; – sending a SUCCESSFUL (or FAILED) message to the initiator when Ti is successfully committed (or fails to commit); – executing a compensating transaction and recording a Failure in a log if it receives a CANCEL message; – recording a Success after it receives a CONFIRM message. (3) data or subtransaction transfer: in the case that the executor cannot find the data in its own local database, it needs to download the data from the central database server or transfers Ti to the central database server. The central database server refers to a main database of an organization, which holds all data needed by the organization activities and is connected with a fixed network. When the central database server receives a subtransaction, it executes the subtransaction
76
F. Tang, M. Li
using the policy described in the step (2). We will present how to transfer data or subtransaction in Sect. 4.2.3. 4.2.2 Participant discovery In pervasive environments, precise places of users and mobile devices cannot be located in advance because of mobility of the users so that the mechanism based on centralized registry is impracticable to pervasive transactions. Before submitting a subtransaction, accordingly, an initiator has to find a qualified (mobile) device, which is able to provide the specific services (e.g., sickbed reservation) for the subtransaction, as a participant. Mobile devices are generally battery-powered so that power saving is one of the most important performance metrics. Generally speaking, the less the number of hops of message transmission in multiple-hop mesh networks, the lower the energy consumption of mobile devices. For reducing total energy consumption, the transaction initiator finds and selects participants based on the two principles. The first one is to find out a mobile device with the shortest distance. The second is to select the mobile device with the most remaining energy. In this paper, we use the number of hops between the initiator and a participant to measure the distance. The initiator discovers a qualified participant for a subtransaction Ti through the following mechanism: (1) Participant query. An initiator broadcasts a query message REQ with the format shown in Fig. 7(a). SD is a service description and only mobile devices that can provide the specified services respond to the REQ message. h is the number of hops between the source node S and a destination node D. (2) Forwarding and response. On receiving a REQ message, any mobile device – appends itself to the path field and increases h field by 1; – constructs and returns a response message RES along with the current device states, shown in Fig. 7(b), only if it can provide services specified in the SD field; otherwise, – further broadcasts the updated RES message if h is less than Hmax . However, if h is equal to Hmax it drops the message. Note that any device ignores the messages received previously. (3) Participant selection. the initiator collects response messages within a given period of time, and then
Fig. 7 Participant query and response messages
Context-adaptive and energy-efficient mobile transaction management
77
– extracts the number of hops from the h field of each RES message, marking h(k); – calculates the minimal number of hops Hmin = Minfor all RES (h(k)); – selects a mobile device with Hmin hops and qualified context (e.g., enough network bandwidth) as a participant. When many devices have the same Hmin hops, if there is a fixed host with Hmin hops, the fixed host will be selected as a participant; otherwise, the mobile device with the most remaining energy will be selected as a participant. (4) Default participant. In this case, the initiator has failed to find out any qualified device within Hmax hops. We assume that there are well-known fixed hosts to provide public services in a city. If there is no response, which means any mobile device within the range of Hmax hops cannot execute Ti , the initiator selects a well-known fixed host eligible for execution of Ti . 4.2.3 Data or transaction transfer In our target environment, an organization (e.g., a hospital) maintains a central database server on a fixed host with all data, as well as a set of mobile assistants. A database on the mobile assistant has to be lightweight because of the limitation of computing and storage resources, i.e., the mobile database can hold only partial copy of data in its central database. A mobile traveling agent can reserve an airline ticket for a user, for example, but it possibly cannot handle a hotel reservation from the user. Data or transaction transfer just solves how to handle a subtransaction whenever an executor does not hold locally the data needed in the subtransaction. Specifically, if an executor does not have the data locally, it will – check its current state to find whether it is able to store the data; – download the data from its own central database server on a fixed network if the executor can locally store the needed data; otherwise, – upload the subtransaction to its central database server.
5 Petri-net-based correctness validation In this section, we set up the Petri net of our context-aware and energy-efficient transaction management mechanism (CETM), and then validate its correctness using the reachability tree analysis technology of Petri nets. 5.1 Petri net of CETM A Petri net is an abstract and formal modeling tool that can model systems’ events, conditions, and relationships among them. The occurrence of these events may change the state of the system, causing some of the previous conditions to cease holding and other conditions to begin to hold [23]. A Petri net consists of two kinds of nodes: places and transitions, which are connected by directed arcs from a place to a transition (P × T ) or from a transaction to a place (T × P ). In a Petri net,
78
F. Tang, M. Li
Fig. 8 Conditional activity and selective transition
Fig. 9 Petri net of the CETM
places and transitions represent conditions and events, respectively. In this paper, we introduce a selective transition concept to express the selective activity. Before the definition of selective transition, we assume a transition t have m output arcs such that O(t) = {O(t)(i) |O(t)(i) is one of output arcs of t, 1 ≤ i ≤ m}. Definition 2 A transition t is selective if (1) any output arcO(t)(i) ∈ O(t) associates with a condition O(t)(i) .cond(i), and (2) when a firing occurs, only the output arc O(t)(i) with O(t)(i) .cond(i) = true (1 ≤ i ≤ m) is fired. Selective transition concept extends the modeling ability of Petri nets by introducing conditional firing for output arcs. For a activity graph with a conditional loop shown in Fig. 8(a), for example, we model such a activity sequence in a selective Petri net (see Fig. 8(b)). When transition t2 is fired, only the output arc O(t)(i) with O(t)(i) .cond(i) = true is actually fired. Based on the selective transition concept, we model the CETM as the graphic Petri net (see Fig. 9). In particular, transaction t1 has two exclusively input arcs: p1 × t1 and p7 × t1 , where a white circle means t1 can be fired if and only if one of input arcs has a token. Places and transitions are described in Table 4. Two selective transitions t3 and t5 denote judging the state of global transaction T and the situation of subtransactions respectively, more specifically: – – – –
O(t3 )(1) .cond(1): T reaches one of acceptable states; O(t3 )(2) .cond(2): T has not reached any acceptable state; O(t5 )(1) .cond(1): all subtransaction have been executed, i.e., ∀Si = ‘S’ or ‘F ’; O(t5 )(2) .cond(2): some subtransaction have not executed, i.e., ∃Si = ‘I ’.
Context-adaptive and energy-efficient mobile transaction management
79
Table 4 Places and transitions of Petri net of the CETM Elements
Description
Meaning
p1
Active
A pervasive transaction T is initiated
p2
Executing
T is been executing
p3
Waiting
Initiator is receiving the R(Ti )
p4
Committing
Initiator is committing globally
p5
Success
T is successfully committed
p6
Pending
T enters the pending state
p7
Select subtransaction
Initiator selects the next subtransaction based on dependency
p8
Compensating
Initiator is undoing subtransactions committed previously
p9
Failure
T has been undone
t1
Initiator discovers a participant Pi and sends Ti to Pi
t2
Initiator updates the state of global transaction T
t3
Initiator judges whether T reaches one of acceptable state
t4
T is committed globally
t5
Initiator judges whether all subtransactions are executed
t6
Subtransactions committed previously are undone by compensating transactions
5.2 Correctness validation of CETM Petri nets can analyze systems’ behavioral properties, including reachability, boundedness, liveness, coverability, reversibility, persistence, and so on. For a bounded Petri net, these problems can be solved by the reachability tree [24]. Peterson [23] also pointed out that in Petri nets, many questions can often be reduced to the reachability problem. In this subsection, we first construct the reachability of the CETM’s Petri net and then validate the correctness of the CETM by the reachability tree analysis technology of Petri nets. Figure 10 illustrates the reachability tree of CETM’s Petri net, which intuitively describes all the states from the initial state M0 by the movement of tokens. In a reachability tree, a marking M is an assignment of tokens to each place. M is reachable from another marking M if M may be transformed to M through a sequence of firings. The set of all markings reachable from an initial marking M0 in a Petri net (N, M0 ) is marked by R(M0 ). The boundedness and liveness of Petri nets are often used as correctness criteria in protocol validation. This paper discusses these two properties by analyzing the reachability tree of the CETM’s Petri net. In a reachability tree, nodes denote M0 and its successors; M0 is the root and leaf nodes correspond to final state. A path from the M0 to a leaf node means an execution sequence. The following theorems collaboratively prove the correctness of the CETM. Theorem 1 The Petri net of the CETM is bounded. Proof A Petri net (N, M0 ) is said to be k-bounded (or simply bounded) if number of tokens in any place does not exceed a finite number k for any marking reachable
80
F. Tang, M. Li
Fig. 10 Reachability tree of the CETM’ Petri net
from M0 , i.e., ∀mi ≤ k for every place pi in every marking M R(M0 ) [24]. In the reachability tree of the CETM’s Petri net, the number of tokens in each place is never more than 1. Therefore, the Petri net of CETM is bounded and the k equals to 1. For a bounded Petri net, its reachability tree contains all possible markings. Let MS be marking set of the Petri net of the CETM. We have MS = R(M0 ) = {M0 , M1 , M2 , M3 , M4 , M5 , M6 , M7 , M8 }, i.e., any marking M in the CETM’s Petri net is reachable from M0 such that Mi ∈ R(M0 ) for any Mi ∈ MS. Therefore, there is not useless or dead state during the execution of a pervasive transaction. Theorem 2 The Petri net of the CETM is L1-live. Proof A transition t is L1-live if t can be fired at least once in some firing sequences. Furthermore, a Petri net (N, M0 ) is said to be L1-live if each transition in the net is L1-live [24]. By observation of the reachability tree of the CETM’s Petri net, we find that each marking is reachable and each transition can be fired at least once from M0 . Therefore, the Petri net of the CETM is L1-live. Theorem 2 indicates that CETW is deadlock-free as long as the firing starts with the initial marking M0 . According to Theorem 1 and Theorem 2, we can draw a conclusion: the transaction management mechanism CETM is correct.
6 Experiments and evaluation We have implemented a simulation system to test the feasibility of the proposed pervasive transaction model, and investigated how much the successful commit ratio of pervasive transactions is improved by using the CETM mechanism. The system was structured as Fig. 11, where Coordinator and Participant execute our transaction coordination mechanism CETM to orchestrate activities in a pervasive transaction by interacting a set of coordination messages. During the execution
Context-adaptive and energy-efficient mobile transaction management
81
Fig. 11 Architecture of pervasive transaction systems
of pervasive transactions, the Context Awareness module collects and monitors transaction context for dynamically adjusting transaction execution policies. Log service records necessary coordination and state information in order to recover systems from potential failures. Compensating transaction generator (CTG) automatically generates compensating transactions during the execution of pervasive transactions. Communication Unit sends and receives messages. Local transaction manager (LTM), generally a part of local database, is responsible for ensuring the ACID properties (Atomicity, consistency, isolation, and durability) of local subtransactions while our CETM manages a global pervasive transaction to achieve one of acceptable states. 6.1 Experiment environment There were a total of 100 mobile devices that simulate MD-Ds and 10 fixed hosts in our simulation system, where 20 mobile devices (i.e., executor) provide sickbed reservation service and other 20 mobile devices (also executor) are able to handle public traffic queries. Fixed hosts support either sickbed reservations or public traffic queries. Any mobile device can issue global pervasive transactions, but only the executor is able to perform subtransactions initiated from other devices. Our CETM protocol is energy-saving because (1) an initiator discovers the shortest executors with the least number of hops away from the initiator, and (2) an executor actually performs a subtransaction in the energy-efficient way. In this stage, our experiments focused on how to adapt to changing network connectivity and bandwidth. We simulated the mobility of nodes by changing link states among them, and furthermore, let the wireless links disconnect in the probability DisconnectProb. In addition, we modeled system load in the number of concurrent pervasive transactions (simplified NumMobiTran). Pervasive transactions were randomly initiated and concurrently executed in the system. Each of them consisted of two subtransactions such that T = {T1 , T2 }. We tested and compared two kinds of transactions: context-aware transaction (CATran) and noncontext-aware transaction (NonCATran). During the transaction
82
F. Tang, M. Li
Fig. 12 Failed ratio vs. the number of concurrent pervasive transactions
processing, CATran dynamically discovers a qualified participant for a subtransaction Ti and can select the next subtransaction Tj substitutable for Ti if Ti was aborted. In the medical treatment reservation described in this paper, for example, the coordinator will request the subtransaction T5 after T1 failed. By comparison, NonCATran dispatches subtransactions to well-known devices that provide the corresponding services only once so that a NonCATran transaction is aborted if the network link between an initiator and an executor is unqualified. 6.2 Results and evaluation High mobility and frequent network disconnection significantly decreases the probability of successful commits. As a result, the Failed Ratio (FR) is an important and accepted criterion for measuring the effectiveness and performance of transaction management mechanism. FR refers to the fraction of failed transactions. It can be formulated as FR = (FN÷TN) × 100%, where FN is the number of failed transactions and TN is the total number of transactions in the system within a given period of time. 6.2.1 System load In this experiment, we varied the number of concurrent pervasive transactions from 100 to 500, where link disconnection probability is fixed such that DisconnectProb = 0.1. The performance results obtained for the two kinds of transactions CATran and NonCATran are shown in Fig. 12. From this figure, we can see that the failed ratio of the system upgrades for both strategies as the transaction load increases, and for all ranges of the transaction load CATran performs better than NonCATran. This is because CATran selects a qualified mobile device with qualified context as well as can execute substitutable subtransaction(s) if the previous request failed. By comparison, NonCATran directly sends a transaction request without context awareness. The reason for the increase in the failed ratio with both execution strategies is that more load on the physical resources caused more heavy data conflicts. 6.2.2 Link states When a link disconnects or has no enough bandwidth, nodes connected with the link can no longer communicate with each other. Therefore, for both CATran and NonCATran transactions, link states have significant impact on the failed ratio.
Context-adaptive and energy-efficient mobile transaction management
83
Fig. 13 Failed ratio vs. the disconnection probability of wireless links
Fig. 14 Failed ratio vs. the number of interaction operations in a pervasive transaction
In this experiment, we measured the performance of the CETM by varying the DisconnectProb from 0.1 to 0.7 in increments of 0.1. The performance results are shown in Fig. 13, where the number of concurrent pervasive transactions in the system was fixed. As we can see, as disconnection probability of wireless links increases, the performance of the system becomes worse with both execution strategies, CATran and NonCATran. The reason is that with the increment of failure probability of links, more subtransactions cannot be sent to targeted nodes. However, the relative performance of CATran and NonCATran is not affected by the probability of wireless link failure because CATran transactions discover and select qualified devices before the transaction processing. 6.2.3 Interaction operation Interaction operations refer to the requests initiated by a mobile device during the execution of a transaction. In this experiment, we varied the number of interaction operations in pervasive transactions from 1 to 7 in increments of 1 to evaluate the impact of interaction operations. Performance results obtained are illustrated in Fig. 14, where NumInteration means the number of interaction operations in a pervasive transaction. As the degree of interaction operations was increased, the performance of CATran gets only a little bit worse because the CATran transactions select qualified participants. By comparison, a steeper degradation in the performance was observed in NonCATran strategy as the number of interaction operations increased. The reason is
84
F. Tang, M. Li
that NonCATran transactions are directly dispatched to a well-known device without a selection so that failure probability of these transactions was accumulated with more interactions among an initiator and executors through unstable wireless connections.
7 Conclusions and future work We have proposed a context model and a context-aware transaction model characteristic to pervasive environments, designed a mesh network based architecture for online pervasive transactions, and presented a context-aware and energy-efficient transaction management mechanism (CETM). Proposed transaction processing architecture breakthroughs the limitations of traditional client–proxy–server framework, allowing users to access pervasive services anytime anywhere. Our CETM can adapt to dynamical transaction context and reduce energy consumption for a transaction processing. We validated the correctness of the CETM through Petri nets. Experimental results demonstrated the CETM significantly reduced the failed probability of concurrent pervasive transactions. We are going to investigate flexible and lightweight mechanisms to automatically generate compensating transactions in mobile and pervasive environments. Further, we also plan to design efficient commit protocols for noncompensable pervasive transactions. Acknowledgements This work was supported by the National Natural Science Foundation of China (NSFC) (Grant Nos. 60773089, 60533040, and 60725208), the National High Technology Research and Development Program (863 Program) of China (Grant Nos. 2006AA01Z172, 2006AA01Z199 and 2008AA01Z106), and Shanghai Pujiang Program (Grant No. 07pj14049).
References 1. Kanter TG (2002) HotTown, enabling context-aware and extensible mobile interactive spaces. IEEE Wirel Commun 9(5):18–27 2. Ranganathan A, Campbell RH, Ravi A, Mahajan A (2002) ConChat: a context-aware chat program. IEEE Pervasive Comput 1(3):51–57 3. Bottazzi D, Montanari R, Toninelli A (2007) Context-aware middleware for anytime, anywhere social networks. Intell Syst 22(5):23–32 4. Rehman K, Stajano F, Coulouris G (2007) An architecture for interactive context-aware applications. IEEE Pervasive Comput 6(1):73–80 5. Yu ZW, Zhou XS, Zhang DQ et al (2006) Supporting context-aware media recommendations for smart phones. IEEE Pervasive Comput 5(3):68–75 6. Tu MH, Li P, Xiao LL et al (2006) Replica placement algorithms for mobile transaction systems. IEEE Trans Knowl Data Eng 18(7):954–970 7. Pitoura E, Chrysanthis PK (2002) Multiversion data broadcast. IEEE Trans Comput 51(10):1224– 1230 8. Chen I, Phan N, Yen I (2002) Algorithms for supporting disconnected write operations for wireless web access in mobile client-server environments. IEEE Trans Mobile Comput 1(1):46–58 9. Lee V, Son S, Chan E (2002) On transaction processing with partial validation and timestamp ordering in mobile broadcast environments. IEEE Trans Comput 51(10):1196–1211 10. Barbará D (1999) Mobile computing and databases—a survey. IEEE Trans Knowl Data Eng 11(1):108–117
Context-adaptive and energy-efficient mobile transaction management
85
11. Pitoura E, Bhargava BK (1999) Data consistency in intermittently connected distributed systems. IEEE Trans Knowl Data Eng 11(6):896–915 12. Gray J, Helland P, O’Neil P et al (1996) The dangers of replication and a solution. ACM SIGMOD Rec 25(2):173–182 13. Lee M, Helal S (2002) HiCoMo: high commit mobile transactions. Distributed Parallel Databases 11(1):73–92 14. Lu Q, Satynarayanan M (1994) Isolation-only transactions for mobile computing. ACM Oper Syst Rev 28(2):81–87 15. Ku KI, Kim YS (2000) Moflex transaction model for mobile heterogeneous multidatabase systems, Res Issues Data Eng, pp 39–46 16. Dunham MH, Helal A, Balakrishnan S (1997) A mobile transaction model that captures both the data and movement behavior. Mobile Netw Appl 2(2):149–162 17. Walborn GD, Chrysanthis PK (1999) Transaction processing in PROMOTION. ACM symposium on applied computing (SAC), pp 389–398 18. Dirckze RA, Gruenwald L (2000) A pre-serialization transaction management technique for mobile multidatabases. Mobile Netw Appl 5(4):311–321 19. Kumar V, Prabhu N, Dunham MH, Seydim AY (2002) TCOT-a timeout-based mobile transaction commitment protocol. IEEE Trans Comput 51(10):1212–1218 20. Lim JB, Hurson AR (2002) Transaction processing in mobile, heterogeneous database systems. IEEE Trans Knowl Data Eng 14(6):1330–1346 21. Franklin M (2001) Challenges in ubiquitous data management. Informatics, pp 24–33 22. Perich F, Joshi A, Finin T et al (2004) On data management in pervasive computing environments. IEEE Trans Knowl Data Eng 16(5):621–634 23. Peterson JL (1977) Petri nets. Comput Surv 9:223–252 24. Murata T (1989) Petri nets: properties, analysis and applications. Proceedings of the IEEE, pp 541– 580 25. Heysters P, Smit G, Molenkamp E (2003) A flexible and energy-efficient coarse-grained reconfigurable architecture for mobile systems. J Supercomput 26(3):283–308 26. Liu M, Cao JN, Zheng Y et al (2008) An energy-efficient protocol for data gathering and aggregation in wireless sensor networks. J Supercomput 43(2)
Feilong Tang received a Ph.D. degree in Computer Science from Shanghai Jiao Tong University, China. Now, he works with the Department of Computer Science and Engineering, Shanghai Jiao Tong University, China. His research interests focus on pervasive and grid computing, transaction processing, wireless sensor network, and distributed computing.
86
F. Tang, M. Li Minglu Li is Full Professor and Deputy Director in Department of Computer Science and Engineering, Shanghai Jiao Tong University, China. He also is a director of Grid computing center of Shanghai Jiao Tong University. His research interests mainly include grid computing, web services and multimedia computing.
