A Hybrid Replication Strategy for Mobile Environments

Salman Abdul Moiz Member

Institute of Electrical & Electronics Engineers (IEEE) Hyderabad, India

Salman.abdul.moiz@ieee.org

Abstract— The exponential increase in the smart phones has considerably increased the access to data services in mobile environments. As the mobile devices are prone to frequent disconnections, mobility issues, battery consumption etc, successful execution of the data services may not always be guaranteed. Replicating the data at several places provides the fault tolerance for the smart database applications. Synchronous replication may not be efficient to implement in mobile environments as the mobile hosts may be disconnected thereby leading to starvation. However to maintain the data consistent, synchronous replication strategy is to be adopted at fixed host. This paper presents a hybrid replication strategy in mobile environments which is realized by the mobile middleware.

Keywords-Synchronous replication, Asynchronous replication, Mobile host (MH), Fixed host (FH), Mobile middleware

I. INTRODUCTION The revolution in the wireless domain enables to access a

service from anywhere on any device at any time. In mobile environments the request for a service or application is initiated at mobile host, the transaction is executed at the fixed host or the execution is partially distributed between the mobile host and the fixed host respectively. In both the execution modes, data has to be replicated to provide availability and fault tolerance.

Synchronous replication is not a feasible mechanism in mobile environments as the mobile host may be disconnected for a longer time. However if the service or transaction request is executed only at the fixed host, synchronous replication can be implemented.

As the offline services are gaining popularity because of mobility issues, a replica has to be stored asynchronously on the mobile host. There is a need for realizing synchronous replication at fixed host & asynchronous replication at mobile host. Data synchronization is an important issue in the implementation of the proposed strategy. This paper presents a hybrid replication strategy which can be managed by the mobile middleware.

The remaining part of this paper is organized as follows: section –II describes mobile middleware characteristics and mobile database architecture, Section –III presents replication concepts and related work. Section-IV describes the Hybrid replication strategy, Section –V presents the design and results of the proposed strategy and section – VI concludes the paper.

II. MOBILE MIDDLEWARE Mobile Middleware is software that acts as an interface

between the wireless device (mobile host) and wired network (fixed host). The functions of Mobile Middleware are as follows:

• It must deliver the information precisely to the right place irrespective of mobility, disconnections, interface constraints etc.

• It has to enable deployment of standardized mobile applications on mobile devices with varied operating systems, screen sizes etc.

• Need to secure data on devices rather than just securing data communications

Figure 1. Mobile Middleware Architecture

Figure 1 depicts the typical mobile middleware architecture. The architecture consists of two components i.e. Mobile Host and Fixed Host and two connectors i.e. wireless and wired connectivity. Mobile host are wireless entities which connects to mobile middleware through wireless links. The fixed hosts are the backend system which has database and processing capability.

The mobile middleware resembles three-tier architecture and has to support cross platform characteristics. This is because the mobile devices works on different platforms and operating systems and the applications need to be accessed from any of the devices. Mobile middleware communicates with the fixed host on behalf of the mobile hosts. The mobile middleware also helps in providing location transparency

thereby reducing the overhead of hard coding the applications on mobile devices. Mobile middleware provides device flexibility & application flexibility. The transaction management in mobile environments can be implemented on the mobile middleware. The data synchronization strategies can be realized by mobile middleware i.e. when a copy of data fragment is modified, the mobile middleware has to ensure consistency of the data items across the replicas. The conflict resolution strategies to maintain the consistency of all replicas is realized by the mobile middleware.

III. REPLICATION CONCEPTS Replication is the process of creating and maintaining

duplicate versions of data objects in a distributed system [1]. Data replication is considered as a better solution to increase the throughput (more replicas can server more requests), decrease response time (distribute the load and access the local replicas) and provide fault tolerance [2]. Replication increases the availability of the applications by providing alternate data access options. If the primary replica fails, the secondary replica will be available for accessing the services. Depending on the type of the application these replicas can be in either active-active or active-passive mode.

A. Types of Replication A replication strategy may be selected based on two

characteristics i.e. Where and When. When the data is updated, the updates have to propagated to respective replicas (where) based on the replication strategy.

In general, there are two types of replication strategies: Synchronous and Asynchronous replication. In Synchronous replication (real time data replication [3]), whenever a write operation is performed at one replica, the same is updated at all replicas at the same time. In Asynchronous replication (store and forward replication [3}), write operations performed on one site is stored locally and later on the new value of data item is propagated to other replicas. Synchronous replication achieves highest level of data integrity but requires permanent availability of the participating sites (holding replicas). If any one of the participating site is not available the updates can’t be propagated. This scheme requires more resources but keeps the participating sites in a consistent state. In asynchronous replication, the updates to all the participating sites may not be propagated at the same time. A time interval is defined for such updates. Further this approach doesn’t require all the participating sites to be available when the updates are propagated.

The data can be updated at one particular site or can be updated at any site based on replica update strategy (where). In update anywhere method, the update propagation can be initiated by any of the participating site. All participating sites are authenticated to perform the write operation and propagate it to other replicas. In a Master-Slave approach, only one replica called master or primary copy can be updated and all other replicas are updated reflecting changes to the primary copy.

B. Related work Several valuable attempts have been made for the fault

tolerance in mobile environments using replication. However each approach implements a subset of operation requirements. Most of the approaches [2, 4, 5, 6, 8] supports either asynchronous or synchronous replication but doesn’t provide the replication for execution of service in connected as well as offline mode. In [7], only those data items are replicated which have higher weighted access frequencies and maximum power. However the replication is not considered for less frequent accessed data items.

IV. HYBRID REPLICATION STRATEGY In Hybrid Replicatin Strategy for mobile environments, the

advantages of both synchronous and asynchronous replication is adapted. At fixed host (wired network), data is replicated at several sites to achieve high availability and better performance. Synchronous replication is adopted at fixed host which also helps in accessing the data services in connected mode. For offline transactions, a data fragment is replicated at mobile host asynchrnously. Whenever the local transaction at mobile host completes successfully, the results are integrated with fixed host. In this approach a transaction replication is used which propogates only the new value of the data item. The hybrid nature of the proposed strategy is managed by the mobile middleware.

A. Replication at Mobile Host Whenever the data service request can be executed on

mobile host, the data items needed for serving the request is read from the fixed host and the fragment is copied onto the mobile host. Since mobile host is prone to soft or hard disconnections, asynchronous replication strategy is adopted. In all offline transaction processing on mobile devices this approach is suitable.

Figure 2. Offline processing

Whenever a mobile host request for an offline processing,

the data items needed to execute the data service are copied onto the mobile host. A mobile host connects to a fixed host via a nearest base station (BS). The information regarding the site which copied the data is maintained by the mobile middleware. As mobile hosts are prone to disconnections, the data fragment is copied asynchronously. After successful completion of offline processing the results are to be integrated with fixed host. The mobile host sends the updated data items to the fixed host. As the final commit decision is taken at the fixed host, asynchronous master slave replication

strategy is adopted at the mobile host. However an application specific time period is set within which the mobile host is expected to propagate the write operation to the fixed host. This is to avoid the starvation of the resources.

B. Replication at Fixed Host Fixed host maintains mirror copies of data items in a

synchronous mode. As specified in figure 3, the base stations are connected to fixed hosts with database mounted on it. Several replicated copies of the database exist and they are connected on wired network.

There are two scenarios where the data items are updated simultaneously at all participating sites at fixed host.

Figure 3. Replication at fixed host In the first scenario, the mobile host is connected to fixed

host and the service request is executed at fixed host (connected mode of operation). In this mode, the mobile middleware blocks all the participating sites till the final commit is reached. A log is used to reduce the blocking time i.e. whenever a commit record appears the data items are updated simultaneously. In the second scenario, the mobile host propagates the write operation to the fixed host. The middleware blocks the participating sites at fixed host and then perform the write operation simultaneously.

In both the scenarios the mobile middleware identifies the conflicting site and sends an invalidation report to the respective mobile host.

If connected mode of operation is used, the mobile host re-initiates the request. If the offline processing mode is used, the mobile middleware sends an updated value of data item to re-execute the service by updating the time period within which the result has to be reconciled.

C. Infrastructure Infrastructure of a system is the major element in

calculating the cost needed to implement a strategy or an application. In the hybrid replication strategy as asynchronous replicas are needed on the mobile host which can perform an offline transaction there is a need of smart clients. As there is an exponential growth in number of smart phones, the cost of these phones is not so high. Further for synchronous replication at the fixed host, backup servers are needed.

As most of the end to end solutions provide a disaster recovery solution by using the mirror copy, it is assumed that such backup servers will exist. Otherwise additional cost has to be incurred for backup servers to provide synchronous replication at the server.

Smart phone helps in downloading of many applications from application store (appstore). Additional server for storing the appstore may be needed or it could be on a cloud.

V. DESIGN & RESULTS Replication increases the availability of data and increases

the performance. However the major task is to maintain consistency when multiple copies of the same data reside either at the fixed host or at mobile host.

A. Design Mobile middleware maintains the consistency of data and

helps in implementation of the hybrid replication strategy. It is responsible for conflict detection and resolution strategies. The Mobile middleware also acts as a service manager or transaction manager responsible for execution of a service or a transaction. Mobile middleware maintains the following data structures:

• Service List

• Current Services under Execution (CSUE)

Service List relation specifies the list of data services which can be requested from the mobile host either in a connected or offline mode. In connected mode the fixed host reads the required data items needed to execute the service.

TABLE I. SERVICE LIST

Service Id Service Name Table name Data Item(s) Timer In offline or a disconnected mode, the middleware reads

the data items for the requested service and sends the same to mobile host for local execution if the data items are not blocked. The data items can be blocked by using locking mechanism if the data is being updated at the fixed host on respective replicas. Timer specifies the time period within which the mobile host is expected to return the result to the mobile middleware.

TABLE II. CURRENT SERVICE UNDER EXECUTION (CSUE)

Site Id Service Id Data Item(s) Synch/Asynch CSUE relation specifies the list of data services that are

currently under execution. Site Id specifies the mobile host or fixed host which is currently executing the service. Asynch specifies that the data required for execution of the service is read by mobile host identified by site id. If another mobile host needs to execute the same service, the middleware sends the data items to the mobile for local execution. When one of the mobile hosts completes the local execution successfully, the results are sent to the middleware. The middleware sets the status to synch as the new value is to be updated on the replicas stored at fixed host. Simultaneously the middleware sends the invalidation report to the sites which were executing

the same service locally. However to reduce the uplink bandwidth, the middleware can send the new values of the data items to all the mobile hosts which were executing the service concurrently. Once the data items are successfully updated at all replicas, the transaction may re-execute locally. This not only reduces the uplink bandwidth, but also increases the throughput of the system.

If the services are to be executed on fixed host, the site id represents the fixed host id and the mode will be in synchronous mode. However if the data items are being used by the mobile host for local processing, the fixed host waits till the result of local operation by the mobile host on same service is return within the specified time period. This is needed to ensure serializability of the service request.

B. Results The results of this strategy are simulated using J2ME and

wireless toolkit simulator for M-Bidding application. In the real environment all the mobile applications can be stored in an application store (usually known as appstore). The mobile host which wants to execute the application locally can download the application from appstore by sending a SMS. Each application will be associated with an identifier. Lookup operation is supported for searching for specific mobile applications from the appstore. These applications can be downloaded onto the smart clients which supports the offline transaction processing.

The fixed host maintains the base relation ITEM, which contains the list of items which the user can request for bidding.

TABLE III. ITEM

Itemno Item name Current Rate Per Unit(CRPU)

1001 I1 1250 1002 I2 1500 1003 I3 1150 1004 I4 2600 1005 I5 2750

The mobile middleware maintains two relations viz. Service List and CSUE for service management. Table –IV specifies the service lists which can be requested by the mobile hosts.

TABLE IV. SERVICE LIST FOR M-BIDDING

Service Id Service Name

Table name Data Item(s) Timer

DS-1 Bid ITEM Itemno, CRPU 3 msec

The service which can be requested is bidding an item. The value of Itemno & CRPU is sent to the mobile host by mobile middleware. The mobile host is expected to return the result within 3 msec only (this value differs from one application to another and from one service to another). If the same service

is implemented in connected mode, then the fixed host waits to ensure serializability. If the transaction is not executed locally within the specified time period, the fixed host waiting for bidding the item will be given the chance for bidding by changing the mode to synchronous. If fixed host is not waiting for the bidding of same item, the mobile host continues the execution irrespective of the timer value. However if some other mobile host is waiting for the same service request it is given a chance for service execution by restarting the timer.

Table –V specifies the requests of mobile hosts received by mobile middleware.

TABLE V. MOBILE HOSTS REQUESTS (M-BIDDING)

Site id Service Id ItemnoM1 DS-1 1001M2 DS-1 1002 M3 DS-1 1001 M4 DS-1 1001 M5 DS-1 1003

The mobile hosts M1 to M5 request for bidding service identified by Service Id. However they are referring to several items. Since M1, M2, M5 are bidding for different item numbers, the mobile middleware sends the value of these data items to the mobile host for local execution. However M3 and M4 will also continue the execution locally as it is in asynchronous mode. If M1 doesn’t return the value within 3 sec to mobile middleware it is aborted thereby giving the chance to the next mobile host i.e. M3 & M4 waiting to bid the same item. Table –VI specifies the contents of Current Service Under Execution relation for the services initiated by various mobile hosts specified in Table – V.

TABLE VI. CSUE FOR M-BIDDING

Site Id Service Id Itemno CRPU Synch/Asynch

M1 DS-1 1001 1250 AsynchM2 DS-1 1002 1500 AsynchM3 DS-1 1001 1150 Asynch M4 DS-1 1001 2600 Asynch M5 DS-1 1003 2750 Asynch

Each mobile host reads the data items Itemno and CRPU

and starts the execution locally. When M3 requests for same Itemno 1001, the middleware checks that the mode is Asynch as such allows the mobile host to read the same data items.

Mobile host M1 complete the execution locally by bidding the new value of Itemno 1001 as 1350. Once the mobile middleware receives it, the new value of data item has to be updated at fixed host. This is done in synchronous mode. Once the mode changes to synchronous, the mobile middleware sends the temporary invalidation report to M3 and M4 which stops the execution locally. This helps in maintaining consistency across all asynchronous replicas (at mobile host) and also provides the transactional replication at synchronous replicas for achieving availability and fault tolerance. Table VII depicts this scenario

TABLE VII. CURRENT SERVICE UNDER EXECUTION (CSUE) FOR AFTER SUCCESSFUL EXECUTION OF LOCAL SERVICE

Site Id Service Id Itemno CRPU Synch/Asynch

M1 DS-1 1001 1300 SynchM2 DS-1 1002 1500 AsynchM3 DS-1 1001 1150 Invalidate M4 DS-1 1001 2600 Invalidate M5 DS-1 1003 2750 Asynch

Once the fixed host completes the synchronous replication

successfully, new value of CRPU is then sent to M3 and M4 by updating the status as Asynch. When the status of particular item is in Synch mode, the other host either mobile or fixed has to wait. It is assumed that the time required for synchronous replication is negligible. Further the replicas at fixed host are assumed to be in active-passive mode. However when the transaction load increases it may be in an active-active mode by providing the load balancing layer above it.

VI. CONCLUSION The hybrid replication strategy helps in using the characteristics of both synchronous and asynchronous replication. The proposed approach specifies that even though asynchronous replication is adopted in mobile environments, the mobile middleware can ensure consistency of data items by providing data synchronization. However it is assumed that

mobile middleware also is having a synchronous replica, so that the failure of mobile middleware is realized. This strategy also works with existing infrastructure, but to realize the high end applications in offline mode, smart phones with reliable application stores are needed.

REFERENCES [1] http://www.orafaq.com/wiki/Advanced_Replication_FAQ. [2] Shuqing Wu, et.Al . “Combining Replica Control with Concurrency

Control based on Snapshot Isolation, 21st IEEE ICDE, 2005. [3] Daniel Barbara Milla, Hector Garcia Molina, “Replicated Data

Management in Mobile Environments: Anything New under the Sun?”, FIP Working Conference on Applications in Parallel & Distributed Computing, pp. 237-246, 1994

[4] M. Cavalleri et. Al, “A set of tools for building PostgreSQL distributed database in biomedical environment, 22nd International Conference on Engineering in Medicine & Biological Society, pp. 540-544, 2000.

[5] Salman Abdul Moiz et.Al. “Replication Strategies in Mobile Environments”, BVICAM’s IJIT, 2010.

[6] Salman Abdul Moiz, et.Al, “Single Lock Manager approach for achieving concurrency in Mobile Environments” , 13th IEEE International Conference on HiPC, Springer LNCS 4873,pp. 650-660,2007.

[7] Prasanna Padmanabham et.Al, “DREAM: A Data Replication for Real-Time MANET Databases”, 22nd ICDE, 2006.

[8] Ding Zhiming et. Al, “A Transactional Replication Asynchrnous scheme for Mobile Database Systems”, Journal of Computer Science & Technology, Vol 17. N0.4, 2002.