HYBRID APPLICATION SUPPORT

FOR MOBILE INFORMATION SYSTEMS

Volker Gruhn, Malte Hülder

Chair of Applied Telematics / e-Business, Dept. of Computer Science, University of Leipzig

Klostergasse 3, 04109 Leipzig, Germany

Keywords:

Pervasive/ubiquitous computing, distributed systems, e-commerce/m-commerce, mobile code and systems,

service continuity.

Abstract:

The wide-spread presence of wireless networks and the availability of mobile devices has enabled the de-

velopment of mobile applications that take us a step closer to accomplishing Weiser’s vision of ubiquitous

computing (Weiser, 1991). Unfortunately however, network connectivity is still not given anywhere and at

any time. To increase the beneﬁt of mobile applications, the next logical step is to provide support for an

ofﬂine modethat allows to continuously work with an application, even when the device is not connected to a

network. In this paper typical problems of replicating data are explained, possible solutions are discussed and

two architectural patterns that could be used to implement hybrid support are illustrated.

1 INTRODUCTION

Recent years have brought a wide-spread presence of

wireless networks and a diverse range of mobile de-

vices, pushing forward the development of mobile ap-

plications signiﬁcantly. For quite a number of appli-

cations it is feasible to install the application on the

mobile device. For example, a very popular appli-

cation used on personal digital assistants (PDAs) is

personal information management, usually contain-

ing calendar, address book, and notepad applications.

To manage the data, a number of users synchronize it

between PC and PDA. For certain purposes, one syn-

chronization architecture may be more suitable than

another, as pointed out in (Starobinski et al., 2003).

Mobile devices have very limited resources. For

some applications it is therefore more difﬁcult to syn-

chronize data needed for mobile use. For example,

consider an information system that enables construc-

tion supervisors to carry electronic copies of project

documents while visiting a construction site: Due to

limited memory of the mobile device, the supervisors

have to carefully select which documents to down-

load, and for another construction site, the down-

loaded documents have to be deleted in order to free

up memory for other documents.

Thus, it appears to be very sensible to cope with

these limitations by placing functionality and appli-

cation logic on a server. On the mobile device resides

a thin client (Orfali et al., 1996), often a browser,

which exclusively renders data. Instead of selecting

and downloading data before he attends the place of

work and risking to make a wrong or incomplete se-

lection, the user can choose which data is needed just

in time, and only this data is transferred. The applica-

tion thus depends on a permanent network connection

to the server. Even for traditional web applications for

PCs with a wired connection, network problems like

congestion are problematic. For mobile devices that

can connect only by wireless means, there is also the

problem of complete disconnection. If a disconnec-

tion is due to the limited coverage of mobile telecom-

munication networks, the problem cannot be solved

quickly by dialing in again.

To keep working with the application in such a

case, the application should be be able to switch into

an ofﬂine mode. While in ofﬂine mode, the necessary

application data and application logic will have to be

available in order to continue working.

For this paper, we want to focus on mobile informa-

tion systems with distinct client-server characteristics

since a large base of such information systems, al-

beit without mobile capabilities, already exists today.

Consequently, the implications of enabling mobile ac-

cess to existing information systems are an important

issue in the industry.

232

Gruhn V. and Hülder M. (2005).

HYBRID APPLICATION SUPPORT FOR MOBILE INFORMATION SYSTEMS.

In Proceedings of the Seventh International Conference on Enterprise Information Systems, pages 232-237

DOI: 10.5220/0002522802320237

 SciTePress

2 RELATED WORK

The Rover Toolkit (Joseph et al., 1995) describes

the possibilities that become available by the use of

queued remote procedure calls (QRPCs) and relocat-

able dynamic objects (RDOs). These mechanisms

work for simple applications like e-mail and web

browsers, where calls can be queued in ofﬂine mode

according to the store-and-forward principle and ex-

ecuted after switching to online mode. When the pa-

per was published in 1995, users typically requested

statical web pages which were delivered by the web

server. However, complex applications are available

today that can be entirely controlled in a web browser.

For every single interaction step, the web server gen-

erates a new page, which cannot be stored in cache

because entering different data will lead to different

pages and thus to cache misses. The main ideas of this

work are still relevant, but have to be accomplished by

other means.

(Weinberg and Ben-Shaul, 2002) show a number

of mechanisms which extend the FarGo-framework

(Holder, 1998) to FarGo-DA. Although some points

are discussed that will also be picked up in this pa-

per (especially in section 4.2), it is always assumed

that either application or framework know when a

change between online and ofﬂine mode and vice-

versa is about to happen, so that necessary synchro-

nizations can take place in time. These prerequisites

are not given in a mobile environment, because it

cannot be foreseen when a wireless connection goes

down. Therefore, a framework for mobile applica-

tions should support an ofﬂine mode even when dis-

connections are unforeseeable.

With µCODE, a Java framework based on the Java

Aglets API is proposed in (Picco, 1998). It includes a

"MuServer" and several interfaces that have to be im-

plemented in order produce mobile code. The author

assumes that it is sensible to move certain classes to

the client and execute them there in order to reduce

communication costs. This idea has to be extended

to the possibility of an ofﬂine mode, which allows for

working in a disconnected environment.

Jørstad et al. describe service continuity for generic

mobile services in (Jørstad et al., 2004a) and (Jørstad

et al., 2004b). However, due to their focus on generic

mobile services, it does not become clear whether

their ideas are particularly suitable for mobile infor-

mation systems. We will consider some of their ideas

in more detail in section 5.

3 TERMS AND DEFINITIONS

In this section, we want to introduce some terms and

deﬁnitions used in the rest of this paper.

3.1 Online, Ofﬂine, Hybrid

(Merriam-Webster, 2003) deﬁnes online as "con-

nected to, served by, or available through a system

and especially a computer or telecommunications sys-

tem (as the Internet)". Accordingly ofﬂine is deﬁned

as the opposite: "not connected to or served by a sys-

tem and especially a computer or telecommunications

system". An online application is therefore an appli-

cation that offers its services only when connected to

such a telecommunications system, whereas an ofﬂine

application does not make any use of such a connec-

tion. A hybrid application is an application that com-

bines features of ofﬂine and online applications: it of-

fers some services only when it is connected, while

other services are available even when there is no such

connection. Let us consider an e-mail application as

an example: when the application is in online mode

(i.e. connected to a telecommunications system), it

can send and receive new e-mails. When the appli-

cation is in ofﬂine mode (i.e. disconnected), the user

may still read messages that were downloaded before

entering ofﬂine mode, and he may still write messages

that will be saved locally until entering online mode.

A hybrid application therefore needs to be aware of

its connection state. Switching from online mode to

ofﬂine mode can be done manually, i.e. initiated by

the user, or automatically by some connection detec-

tion algorithm. One advantage of manually switching

from online mode to ofﬂine mode is the possibility to

perform certain tasks before actually entering ofﬂine

mode, e.g. downloading the latest e-mails. Another

one is the possibility to disconnect deliberately in or-

der to save online costs and battery power. A disad-

vantage is the necessity of user interaction – if the user

does not switch to ofﬂine mode before the connec-

tion breaks down, the application might malfunction

as it may assume a working connection. Therefore,

developers of hybrid applications should aim to pro-

vide an automatic connection detection and also allow

for manual mode switching where possible.

3.2 Different Kinds of Mobility

When thinking of mobile applications, the following

deﬁnition (from (Merriam-Webster, 2003)) of mobile

as "capable of moving or being moved" springs to

mind. But which entity exactly is capable of moving

or being moved in context of mobile applications? It

could be the user, it could be the device, and it could

also be the program code of the application. In this

context, (Pandya, 2000) discerns personal mobility,

terminal mobility, and service portability: According

to his deﬁnition, personal mobility means that the user

is not restricted to a single device, but can rather use

different devices in order to use a service. Thus it

does not mean the user’s capability of moving physi-

HYBRID APPLICATION SUPPORT FOR MOBILE INFORMATION SYSTEMS

233

cally, but the possibility to "move" between different

devices. Terminal mobility is given when the device

(the terminal) remains connected to a network while

it is moved physically. Finally, a user experiences ser-

vice portability when he may access the same service

from anywhere, independently of his location or the

device he is using. (Roth, 2002) gives the example

of e-mail access from any location in the world for

service portability.

The notion of service portability is a bit tricky, as

it depends on the service, in which way service porta-

bility can be achieved. Considering the example of e-

mail access, we can see the following: As long as the

user stays in an area where there are enough devices to

let him access his e-mails at any time, personal mobil-

ity could sufﬁce to achieve service portability as well.

As soon as the user wants to access his e-mails be-

yond that area or in between the locations where suit-

able devices are installed, terminal mobility is needed.

The user then carries the device to any place where he

wants to access his e-mails. But true terminal mo-

bility is still not possible: On air, in forests, or even

underground, device connectivity is not available. In

many cases, true terminal mobility is not necessary as

long as the device behaves in a feasible way while it

is disconnected.

It should have become clear that true service porta-

bility cannot be achieved, since it is impossible to

provide connected devices in every location, and also

since true terminal mobility cannot be guaranteed.

Therefore, a way should be found to provide as many

services as possible, even when disconnected.

3.3 Mobile Code

A possible solution to overcome the problem of lim-

ited terminal mobility could be mobile code, which

is deﬁned by (Adl-Tabatabai et al., 1996) as "any

program that can be shipped unchanged to a hetero-

geneous collection of processors and executed with

identical semantics on each processor." In times when

device connectivity is not available, mobile code

might be shipped to the device and executed there in

order to provide the service that would otherwise not

be available in ofﬂine mode. When talking about mo-

bile code, two other terms are used frequently:

A mobile agent is a unit of modularity, execu-

tion and mobility that can migrate from one mobile

host to another (Julien and Roman, 2002). A mobile

host is a container for mobile agents characterized,

among other things, by its location (Julien and Ro-

man, 2002). Put in other words: A mobile host is a

device that can be moved physically and which pro-

vides an environment where mobile agents can be ex-

ecuted.

This deﬁnition by (Julien and Roman, 2002)

does not include the need for mobile agents to au-

tonomously migrate from one mobile host to another.

In the context of mobile information systems, this

does not pose any problems. In fact, a user is in-

terested in using a service continuously with his de-

vice, even when there is no network connection avail-

able. Therefore, the necessary mobile code should

have been moved to the mobile host before the con-

nection was lost – which part of the application de-

cided to move this component is not of interest to

him. The notion of a mobile agent in this context is

thus interesting from the component’s point of view.

A mobile agent is a unit that combines all the classes

or components needed to provide a service, possibly

also in combination with the data needed. The prob-

lems that arise from copying mobile agents and their

data to mobile hosts will be explained in the following

section.

4 TYPICAL PROBLEMS WITH

REPLICATED DATA

When working with local copies of data (replicas),

there are some typical problems. One of them is the

possibility that data is not available when it is needed:

Especially due to limited storage space or network

bandwidth, not all data can be downloaded to the

client, and thus only a restricted set of data can be ac-

cessed during ofﬂine mode. Therefore, it is necessary

to reliably predict which data will be needed in ofﬂine

mode, and to cope with situations when needed data

is not available, e.g. by disabling a service. If ofﬂine

mode was activated manually and not caused by net-

work problems, the application could also suggest to

switch to online mode and access the needed data via

the network (if still available).

4.1 Deciding on Data Transfer

Predictions which data is needed during ofﬂine mode

can be made manually, e.g. the user chooses the pri-

ority for services and data he wishes to have available

in ofﬂine mode. The software will then try to trans-

fer data with highest priority ﬁrst. Data with lower

priority will be transferred only when there is enough

time, bandwidth and storage space left. Alternatively,

it might be possible for the software to decide auto-

matically which data a user will use most likely by

monitoring user interaction over some period of time.

Using such monitoring, one could not only identify

the services used most frequently, but also the use in

certain situations and even the data volume needed to

transfer code and data. With this knowledge it should

be possible to calculate a weighed probability (p) for

each service to be used within a certain amount of

time. From the typical data volume known for each

ICEIS 2005 - SOFTWARE AGENTS AND INTERNET COMPUTING

234

Figure 1: Function f = c − pc < t

service and from the current situation, one could cal-

culate the cost (c) it takes to transfer code and data

for a certain service. Only if the result of the func-

tion f = c − pc is lower than a certain threshold

value (t), code and data for this service are loaded

(ﬁg. 1). Thus it is assured that for a service that will

probably be used (p ≈ 1), code and data are loaded

(f ≈ 0), whereas a service that is less likely to be

used (p → 0) will only be loaded, if the costs are low

as well (c → 0).

4.2 Inner States

Because different instances of software are character-

ized by the possibility to incorporate different inner

states, it has to be considered how to deal with these

inner states. Problems can arise, if data is changed on

the server while the client is in ofﬂine mode:

As long as this data is not the basis of other

processes, there should be no problem – as soon as

the application switches to online mode, it will use the

new data available on the server. Next time it switches

to ofﬂine mode, the current data will be downloaded.

If the changed data was used in other processes

(e.g. certain calculations), those processes might have

to be re-executed after switching to online mode in

order to get the up-to-date results depending on up-

to-date data. It will be an application-speciﬁc de-

cision for each process, whether this re-execution is

necessary or not. Sometimes the execution time of

the process will be decisive, as the results were valid

at the time they were processed, and the data was

changed later – an execution in online mode at the

same time would have given the same result.

Other problems may arise, if an inner state is

changed during ofﬂine mode, as a change of inner

state may be considered as a change of replicated

data. When switching back to online mode, local

changes have to be transmitted to the server. Accord-

ing to (Weinberg and Ben-Shaul, 2002), four ways to

handle this problem can be described:

Purge means that changes of state are discarded. The

client may call methods of the component and read

its state but should not change it, as these changes

are lost when switching to online mode.

Overwrite transfers the state of the client compo-

nent to the server component. If several clients had

copied the component locally, there might be in-

consistencies when switching to online mode.

Merge is supposed to try to solve conﬂicts emerging

from state changes. Unfortunately, there is no gen-

eral strategy for coping with those conﬂicts, but the

developer has to implement solutions when devel-

oping the component.

Last demands timestamps to be given at any change

of state, so that after switching to online mode, the

state with the youngest timestamp is copied to the

server. Concurrent access may lead to inconsisten-

cies as well, and the clocks on the server and all

clients need to be synchronized.

Variants of the last alternative are also possible, e.g.

the state with the oldest timestamp could be copied

to the server, and thus the ﬁrst change "wins". To

show other possibilities, we want to distinguish two

different cases:

1. Data is changed on one client while it is in ofﬂine

mode: Assuming changing the data was an allowed

action for the client, the data has to be transferred to

the server after switching to online mode again. For

other clients that used this data, this case is similar

to the one where data was changed on the server.

Some processes on the other clients may have to be

re-executed. Another severe problem arises from

this: If the changes a client has produced in of-

ﬂine mode can lead to the re-execution of processes

performed by other clients in ofﬂine mode, what

happens to processes performed by clients in on-

line mode? Consequently, these processes would

have to be re-executed as well, if the timestamp of

the changed data is older than the execution of the

process.

2. Data is changed on several clients while they are

in ofﬂine mode: Different strategies can be ap-

plied to decide which changes have to be accepted

by the server and the other clients. According to

the solution with only one client, it can be checked

when the change took place on the different clients.

All processes executed before the ﬁrst change will

not be affected. Processes executed during the ﬁrst

and second change will have to be re-executed us-

ing data after the ﬁrst change. Processes between

the second and third change will have to be re-

executed using data after the second change and so

on. But the problem does not only lie in the num-

ber of changes, but also in the uncertainty of when

a client switches back to online mode and requires

synchronization. As long as a client that switched

HYBRID APPLICATION SUPPORT FOR MOBILE INFORMATION SYSTEMS

235

to ofﬂine mode before another client remains in of-

ﬂine mode while the other client has switched back

to online mode, any processes depending on data

that the ﬁrst client might have changed are still sub-

ject to possible re-execution later on. For a number

of applications, this is not acceptable.

Another possible strategy could be to only al-

low the ﬁrst client which synchronizes to deliver

changes to the server. Other clients that also sub-

mit changed data to the server later on will be told

that their changes are invalid and processes depend-

ing on those changes will have to be re-executed.

The main advantage is that after switching to on-

line mode and connecting to the server, it is known

which processes have to be re-executed and that

processes are to be re-executed at most once.

It should have become clear that multiple changes

on data needed by several clients pose severe prob-

lems. If changes brought about by a client in ofﬂine

mode demand re-execution of processes, the results of

any process executed while another client is in ofﬂine

mode may not be valid. This appears to be feasible for

only very few applications, if any. It therefore seems

to be sensible to restrict the services available in of-

ﬂine mode to those which cannot lead to the named

problems. Also some optimistic strategy may be ap-

plied, as for many applications the probability of con-

current changes to the same data is very low. If such

a conﬂict occurs, it has to be detected and changes

by the different clients have to be discarded (except

maybe for the ﬁrst one).

5 ARCHITECTURAL PATTERNS

To support service availability during ofﬂine mode,

two main architectural patterns spring to mind: a con-

nection manager component or a service continuity

layer as introduced by (Jørstad et al., 2004a). The

connection manager component would be placed be-

sides other components, which may or may not make

use of the connection manager component. Thus,

components offering one or more services need to ac-

tively make use of the connection manager compo-

nent in order to provide their service in online mode

or ofﬂine mode. In a layered approach, the idea is

that any communication needs to go through the ad-

jacent layer, so it should not be possible to bypass a

layer. Therefore, components (or rather their devel-

opers) cannot decide whether to use the service con-

tinuity layer or not – as soon as a component needs

to use a network connection, it will have to commu-

nicate with the service continuity layer.

A connection manager component would be placed

besides other technical components. It can make use

of those components, e.g. an "always best connected"

Figure 2: Service Continuity Layer (Jørstad et al., 2004a)

component that detects available networks and deter-

mines which one is most suitable for a certain purpose

in the actual situation. Other components, technical

ones as well as those implementing application logic,

may use the connection manager component to pro-

vide services in ofﬂine mode. This could be helpful

when migrating an existing application because com-

ponents could be migrated one after another, intro-

ducing ofﬂine mode capability where suitable, while

other components will not (yet) be changed and thus

will not (yet) be available during ofﬂine mode.

The service continuity layer (ﬁg. 2) proposed in

(Jørstad et al., 2004a) and (Jørstad et al., 2004b) con-

tains a monitor, a handover manager, a service com-

position module, an interoperability evaluator, and an

I/O redirector. The monitor is to describe the sur-

roundings of a host so that possible redistributions of

a service can be identiﬁed, in order to provide ser-

vice continuity. A handover manager can instruct the

service composition module to design and implement

a new service composition of an existing service as

soon as it (or the monitor) recognizes that a handover

will be necessary. The service composition module is

supposed to compose a new service out of the com-

ponents that are available. Available components are

checked by the interoperability evaluator for whether

they are compatible on both their interfaces and their

behavior, so that it is safe to compose a service out of

them. The I/O redirector redirects I/O between differ-

ent service components, so that a service can be used

continuously even when it is rearranged by the service

composition module.

As already mentioned in section 3.1, we see a need

for a monitor that observes network connectivity and

initiates ofﬂine mode automatically when the connec-

tion is going to break down, or switches back to on-

line modewhen a connection is available again. On

the other hand, a handover manager should already be

implemented in lower networking layers, e.g. when

roaming between GSM cells is performed. A service

ICEIS 2005 - SOFTWARE AGENTS AND INTERNET COMPUTING

236

composition module will only be necessary, when

new services become available during runtime and

have to be integrated with the services available al-

ready. This focuses on generic devices and generic

services that might compose an application out of

available services, like it is proposed for web ser-

vices. For business applications, where a company

equips their employees with devices and applications,

this is usually not a requirement. The interoperabil-

ity evaluator should check whether a new component

can interact with the existing ones, and if it is safe

to do so. We see a great overlap with the service

composition module here. Again, this may be of in-

terest in very heterogeneous environments – within a

company, interoperability should already be ensured

during development. The I/O redirector again seems

to be a very important component, as it manages ac-

cess to data sources and storage. It has to assure that

data needed during ofﬂine mode is fetched from a lo-

cal data storage, and that data changed during ofﬂine

mode is stored in a local storage and transmitted to

the server upon entering online mode.

6 CONCLUSIONS AND FUTURE

WORK

As mobile hardware and communication costs are

dropping constantly, many organizations may afford

to equip their employees with mobile solutions. Dif-

ferent from some views in the literature of the 1990s

(e.g. (Picco, 1998)), communication costs are not

the main reason for disconnected support and thus

not the main obstacle for mobile applications any-

more. A number of already existing information sys-

tems would gain from mobile support, but due to lacks

in network connectivity, mobile information systems

cannot be available anywhere at any time. To increase

the beneﬁt of those applications, the next logical step

is to provide support for an ofﬂine modethat allows to

continuously work with an application, even when the

device is disconnected from a network.

We have shown that some problems emerging from

hybrid support and replicating data can be overcome

quite easily, while others pose more difﬁcult ques-

tions. As (Jørstad et al., 2004a) and (Jørstad et al.,

2004b) propose service continuity for generic ser-

vices, some of their proposed components are specif-

ically designed to deal with problems arising from

general and often even unknown services. Focus-

ing on mobile information systems, those compo-

nents appear to be superﬂuous while other compo-

nents, namely monitor and I/O redirector are neces-

sary. Implementing a connection manager that tackles

the named problems and reduces the overhead for de-

veloping hybrid support for mobile information sys-

tems from the scratch is one of our current research

projects; ﬁnding the most suitable way of integrating

our connection manager into application architectures

is another.

REFERENCES

Adl-Tabatabai, A.-R., Langdale, G., Lucco, S., and Wahbe,

R. (1996). Efﬁcient and language-independent mobile

programs. In Proceedings of the ACM SIGPLAN ’96

Conference on Programming Language Design and

Implementation (PLDI), pages 127–136.

Holder, O. (1998). The Design of the FarGo System (A De-

sign Document). Technical Report EE Pub No. 1171,

Technion - Israel Institute of Technology.

Joseph, A. D., deLespinasse, A. F., Tauber, J. A., Gifford,

D. K., and Kasshoek, M. F. (1995). Rover: A Toolkit

for Mobile Information Access. In Proceedings of

SIGOPS’95, pages 156–171. ACM, ACM Press.

Jørstad, I., van Thanh, D., and Dustdar, S. (2004a). An

analysis of service continuity in mobile services. 2nd

International Workshop on Distributed and Mobile

collaboration (DMC), WETICE conference.

Jørstad, I., van Thanh, D., and Dustdar, S. (2004b). Towards

Service Continuity for Generic Mobile Services. The

2004 IFIP International Conference on Intelligence in

Communication Systems (INTELLCOMM 04).

Julien, C. and Roman, G.-C. (2002). Egocentric context-

aware programming in ad hoc mobile environments.

Proceedings of SIGSOFFT 2002/FSE-10.

Merriam-Webster (2003). Merriam-Webster’s Collegiate

Dictionary. Merriam-Webster.

Orfali, R., Harkey, D., and Edwards, J. (1996). The Essen-

tial Client/Server Survival Guide. Wiley Publ.

Pandya, R. (2000). Mobile and personal communication

systems and services. IEEE Press.

Picco, G. P. (1998). µCODE: A Lightweight and Flexible

Mobile Code Toolkit. Lecture Notes in Computer Sci-

ence, 1477:160–171.

Roth, J. (2002). Mobile Computing. dpunkt.verlag.

Starobinski, D., Trachtenberg, A., and Agarwal, S. (2003).

Efﬁcient PDA Synchronization. IEEE Transactions

on Mobile Computing, 2(1):40–51.

Weinberg, Y. and Ben-Shaul, I. (2002). A Programming

Model and System Support for Disconnected-Aware

Applications on Resource-Constrained Devices. In

Proc. of the 24th Int. Conf. on Software Engineering

(ICSE’02), pages 374–384. ACM Press.

Weiser, M. (1991). The computer for the twenty-ﬁrst cen-

tury. Scientiﬁc American, 265(3):94–104.

HYBRID APPLICATION SUPPORT FOR MOBILE INFORMATION SYSTEMS

237