Multi Client Server

7/28/2019 Multi Client Server

1/5

Middleware for multi-client and multi-server mobile

applicationsBruno P. S. Rocha

Department of Computer Science

Federal University of Minas Gerais

Belo Horizonte - Brazil

Email: [email protected]

Cristiano G. Rezende





Antonio A. F. Loureiro





Abstract With popularization of mobile computing, manydevelopers have faced problems due to great heterogeneityof devices. To address this issue, we present in this work amiddleware for multi-client and multi-server mobile applications.We assume that the middleware at the server side has no resourcerestrictions, whereas at the client side it is light and does notincur much overhead to the applications, since the mobile devicehas several limitations. Offering a transparent communicationAPI and allowing applications to divide their work amongstserver and client sides, the proposed middleware becomes aviable alternative for development of distributed and mobileapplications. We present as a case study an event notificationservice and show how it benefits from the proposed middleware.

I. INTRODUCTION

Mobile devices, applications and services are currently partof peoples daily lives on a personal and professional level.

Currently, there is a trend to create new applications for small

and light computing devices such as cell phones and PDAs.

Amongst the new applications, push-based services, such

as voice and video streaming, notification, and localization,

deserve special attention.

Users mobility is certainly the main driving force for the

availability of a large number of new applications but it is

also the source of new challenges in the design of distributed

software. In a mobile environment, wireless communication

is intermittent, mobile devices have hardware restrictions and

energy is very limited. This means that an appropriate soft-ware design for mobile applications should take into account

these limitations, the different operating systems and physi-

cal characteristics of different mobile devices. Portability of

applications becomes a difficult goal to achieve.

A middleware is a solution that allows to overcome some of

these problems. It provides to the applications a set of func-

tions that facilitate their development. For instance, it hides

from the applications details about the mobile environment

where they run, and provides fault-tolerance mechanisms to

the applications.

In this work, we present a middleware for multi-client

and multi-server mobile applications. We assume that the

middleware at the server side has no resource restrictions,

whereas at the client side it is light and does not incur much

overhead to the applications, since the mobile device has

several limitations. The main advantage of our middleware

is its capacity to deal with different clients and serverssimultaneously. Applications can access an API available at

the middleware that help their design. For instance, all commu-

nication between clients and servers is completely transparent

to them. We present as a case study of our middleware an

event notification service and show how it benefits from the

proposed middleware.

The rest of this work is organized as follows. Section II

presents the related work and discusses some of the mid-

dleware currently available. Sections III and IV describe

the middleware we propose, and its architecture and design,

respectively. Section V presents a case study using our mid-

dleware. Finally, Section VI presents some conclusions and

future work.

II. RELATED WOR K

Middleware for mobile computing is a relatively new re-

search area. During the last decade, there were several propos-

als presented in the literature and, some of them, we discuss

in the following.

In [1], [2], Capra and Mascolo identify new requirements

for a middleware that supports mobility, discuss the main char-

acteristics and differences of wired and wireless environments

that impact mobility, and categorize and study some possible

middleware solutions. They suggest the use of a reflexivemiddleware [3] in a mobile computing environment. In [4],

they describe a reflexive middleware for ad hoc networks that

allows data sharing and uses XML to encapsulate information,

but it does not clearly distinguish the client and server appli-

cations. In [5], they present another middleware that allows

changes in the context based on a set of rules.

In [6], Campbell et al. propose a middleware to support

multimedia applications, considering QoS requirements, in a

mobile environment. Their proposal uses an ATM network as

the core data communication infrastructure, which was a trend

at that time.

More recently, Fok et al. [7] propose a coordination mid-

dleware for ad hoc networks based on mobile agents. Their

middleware is written in Java Standard Edition, and was

designed for less limited devices such as a laptop.


2/5

In [8], Bellavista et al. present a middleware for mobile

users, also based on mobile agents, to keep services running re-

gardless of users mobility. The middleware provides services

to support virtual environment, virtual terminal, and resourcemanager, also considering less limited devices.

In [9], Chan and Chuang propose MobiPADS, a middle-

ware that uses information from the physical environment

to perform self-configuration. It allows to perform dynamic

adaptation in both the application and the middleware itself.

MobiPADS, as our proposal, has two parts: a client and a

server, but contrary to ours, the server side is unique for a given

system/solution. MobiPADS collects some metrics about the

environment such as bandwidth, latency, and processor usage,

and notifies the applications that use those data.

Most of the current middleware solutions for a mobile envi-

ronment do not distinguish the server side from the client side.This can be useful and lead to easier application development

in some scenarios but there are applications that clearly need a

server side with more computational resources. Furthermore,

some applications are written using the Java standard edition or

a native language, which are not portable directly to a mobile

device.

In the following, we describe our middleware.

III . MULTI-CLIENT AND MULTI-SERVER APPLICATION

MIDDLEWARE

In this work, we propose a middleware for a mobile envi-

ronment that has two sides: server and client. At the client side

application development is made over a lightweight, robust andportable platform. At the server side the middleware allows

high scalability and the full use of resources of machines it

is installed. It is possible to have multiple instances of an

application at each side.

The middleware provides an API to develop applications

for a mobile environment. The development of a typical

application involves extensions and program calls to the API.

The middleware has three parts: client, server, and common

classes. The client and server sides offer directives to the

development of the respective side of the application. The

common classes are those available for both sides and provide

a message abstraction mechanism for communication betweenserver and client.

An application developer must use the API to write server

and client application logics, as well as defining messages

using common classes. The server side can execute multiple

instances, each one representing a different application or even

the same application. Whenever this scenario happens, one of

the server instances must assume a gateway role responsible

for interacting with the clients. All applications must register

with the middleware, which manages the message passing

among them.

The middleware has three pre-defined modules that can

be easily replaced. The authentication module performs the

user login and keeps it during a reconnection. The persistence

module provides to the server side of an application a unified

persistence view of the entire system. Finally, the localization

module gets the information about the clients location and

makes it available for applications. Figures 1 and 2 present

the logical scheme of the client and server sides, respectively.

Client

App 1 App 3App 2

Authentication

Interface

Communication

Interface

Fig. 1. Middleware model for the client side

Server

App 1 App 3App 2

Authentication

Interface

Communication

Interface

DatabaseInterface

Localization

Interface

Fig. 2. Middleware model for the server side

The middleware provides to the applications two commu-

nication mechanisms. The first one is the communication

between the middleware and clients. In this case, applica-

tions receive messages from the clients through the common

gateway, which controls the user access to the applicationsinstances on different mobile devices. The second mechanism

is the communication between applications on the server side.

An application can send a message to other instances of the

same application type or to a different application.

Using these communication mechanisms, the middleware

provides a systematic way to create new services. An appli-

cation can define a new service using functionalities provided

by another application.

The division of the middleware into server and client sides,

allows to design an application that is server intensive or client

intensive by simply putting most of the processing logic on

the appropriate side. Server instances can even be executed on

mobile devices, in case they have enough resources. Design

and implementation technologies are discussed on the next

section.


3/5

All these strategies force the applications to execute fol-

lowing some necessary principles in order to guarantee some

properties. In the following, we present the main advantages

of our model.Scalability: the client side of a middleware is light and

introduces a minimum overhead to applications and data com-

munication network. It is possible to distribute the computation

on the server side among different platforms.

Openness: applications are modules that can be inserted

and removed at any instant, even during runtime. Authen-

tication, persistence and localization modules can be easily

updated.

Heterogeneity: the client side is robust and can execute

on different platforms of mobile devices such as PDAs and

smartphones. On the server side, the middleware can also

execute on different platforms. The only requirement is tohave a TCP connection between those platforms and only the

gateway needs to have a wireless link to communicate with

the clients.

Fault tolerance: the server side can be distributed, in

order to overcome machines failures. In case the gateway

fails, another entity can be configured to assume that role

during runtime. Redundancy can be obtained with multiple

instances of the same application. The client side deals with

disconnections and reconnections in a transparent way.

Resource sharing: multiple mobile clients can use storage

of application servers, which can access a common database

provided by the persistence module. Server applications share

the gateway data communication link, which possibly has alarger capacity.

IV. SYSTEM DESIGN AND ARCHITECTURE

Our middleware is based on the Java technology. The server

side is written in Java Standard Edition (J2SE) and the client

side in Java Mobile Edition (J2ME), taking advantage of its

portability. The common classes of both sides are implemented

using Java classes present in both editions. For such, we have

defined our own message serialization mechanism.

Applications are developed by extending Java classes, which

must overwrite some methods and have access to supporting

directives. The main class of each application must register atboth sides of the middleware to become part of the system.

The client and server sides of the middleware differ in

size and resources. The client side is comprised of only three

classes that offer support to communication and authentication.

The server side has a larger number of Java classes and offers

authentication directives, communication between clients and

applications, persistence, localization and the management of

multiple instances in different platforms.

All communication is based on the TCP/IP protocol stack.

From the point of view of communication, all server instances

and clients must be able to communicate with the gateway.

The middleware re-establishes a connection with the same

configuration whenever it is interrupted. In a client-server

communication, the client is the one responsible for requesting

a connection, which means that the IP address of the gateway

is the only one that needs to be well-known. In this scenario,

any device can perform the role of a server if it is connected

to a TCP/IP network and runs the Java Standard Edition. The

persistence and localization modules can be stored at differentinstances of a server, running in a dedicated hardware. Figure 3

shows a scenario with different mobile devices connected to

a set of servers.

Fig. 3. Scheme with multiple clients and servers running over the middleware

The middleware also controls the execution threads in both

sides of the application. In the client side, more robust, the

main thread calls the current application and passes to it

information about the devices display. Two auxiliary threads

for receiving and transmitting messages are also started. In the

server side, there are threads for managing connections with

each of the clients, exchanging messages between server in-

stances, and sending messages using a communication queue.

All these tasks are transparent for the application, which also

can create its own treads.Our middleware was developed and tested in different

platforms. The server side was installed in desktops Pen-

tium 4 with 512MB RAM and connected to Internet and

IEEE 802.11g wireless local area network. The client side

was installed in PDAs HP iPAQ Pocket PC H5500 and

Palm Tungsten C, both connected to the same WLAN and

a Bluetooth access point. The client was also installed in

two EDGE cell phones from Nokia and Motorola with less

resources than those available in the PDAs.

It is important to notice that other scenarios can be explored.

For instance, in a MANET (mobile ad hoc network) with

no powerful server but with clients with enough resources

to run the Java Standard Edition, we can have a different

scheme. We could install both sides of the middleware at

each client, as depicted in Figure 4. Therefore, each mobile


4/5

device implements a server and a client, and executes both

roles, offering local services through the server instance,

and accessing remote ones through the client instance. The

gateway is still present and works as a bridge passing messagesback and forth between the server and clients. In order to

have load balancing, applications could periodically change

the device that acts as gateway.

In another scenario, similar to the previous one, we can

design the client to perform more processing. In this case,

the server is extremely simple, running on a laptop or PDA,

responsible for receiving and forwarding messages between

clients, and controlling the user access provided by the mid-

dleware. As depicted in Figure 5, clients invoke a server and

use it similarly to an access point of the wireless network, but

with transparent communication for applications, which send

messages directly to user names, instead of network addresses.

Fig. 4. Ad hoc model in which each device works as a server and a client

In our middleware, currently, the authentication module

authenticates passwords not encoded, the persistence module

implements serialization of Java objects and the localization

module uses a localization emulator. Note that it is possibleto have an authentication module that uses cryptography, a

persistence module that accesses a distributed database, and a

localization module that uses real localization provided by a

wireless infrastructure.

V. CAS E STUDY: EVENT NOTIFICATION SERVICE

In this section, we describe an application we developed as a

case study of the middleware. It is an event notification service

(ENS), which is a well-known service in wired networks. An

ENS allows to build more sophisticated services, and, thus,

can be viewed as building block.

An event notification service must match different infor-

mation types to different entities. There are two fundamental

roles in this service: the information producerthe entity that

makes available the information, and the information consumer

Fig. 5. Client-intensive model, in which the server entity only translates andforwards messages

or clientthe entity that registers a given interest about some

information. Note that the producer and consumer can be

either a person or an application. An ENS must provide two

basic services [10]: notification selection that determines the

information that best matches the interests of a consumer,

and notification delivery that sends the notification to the

consumer.

A notification service can be employed to monitor differ-

ent information types such as computational resources (e.g.,memory available and network state), and stock investments.

In this work, the event notification service monitors different

conditions (information types) and notifies a user the best

moment to go to the airport to catch a plane.

In the following, we detail this service and discuss how the

middleware helped its development.

A. Flight Notification Based on User Location

In order to estimate the best moment a person should go

to the airport we need to know, from a given moment on, the

persons location, the traffic condition from where the person

is to the airport, and the status of the persons flight (delayed

or on time). With these pieces of information, it is possible toestimate the moment a person should leave to the airport to

arrive there at the time scheduled by the air company.

A person sends a request to the ENS with the flight

information using a mobile device. The event notification

service monitors all conditions described above and sends to

the person, at the proper time, a notification to go the airport.

At any moment, the user can contact the event notification

service to know the estimated time left to go the airport or

even to know the conditions about traffic and flight schedule.

In the following, we describe some details about the imple-

mentation and the interaction with the middleware.

B. Using the Middleware

The process of implementing applications for mobile de-

vices tends to be more difficult since different devices can have


5/5

different communication protocols. The middleware provides

an API that facilitates this process. The event notification

service was implemented on the top of middleware as depicted

in Figure 6.

Fig. 6. Overview of the notification systems architecture

Following the middleware architecture, the flight notifica-

tion service has two parts: a server and a client. The users

send their service requisitions to the server side that receives

and processes them. From this moment on, the server monitors

constantly the flight time schedule, the user location, and the

traffic conditions, in order to send to the user the notification

to go to the airport. In this model, the client side works

as an interface to send/receive a request/notification, andsend/receive a query/response.

The middleware provides a set of primitives for message

exchanges between client and server that are transparent to

the application, which does not need to know anything about

the communication infrastructure. At each side, it is defined a

class that extends the corresponding middleware API class.

The server has an application class that provides the user

location. This class invokes the middlewares API, which

in turn calls a location module and returns this information

to the application. There might be different ways to get

the user location, depending on the specific communication

infrastructure.

The ENS has two basic services: notification selection andnotification delivery. In our service, we had to implement

only the notification selection since the notification delivery

was built using the primitives provided by the middleware.

Furthermore, the middleware provides the user location, which

simplified the development of the selection process.

It is clear that the middleware facilitated the implementation

of the ENS, as it made the communication process transparent.

The middleware provides a set of functionalities that allow

the software designer to concentrate on the development of

applications rather than the details of a mobile computing

environment.

V I. CONCLUSION AND FUTURE WOR K

The proposed middleware aims to simplify the development

of applications for mobile computing. Using an API, software

designers can use the functionalities provided by the middle-

ware or applications already developed. The middleware is

based on the client/server model and provides communication

primitives to applications to exchange messages transparentlybetween them and independently of a specific communication

protocol.

The middleware was conceived for mobile devices that

have restrict resources and operate in an environment with a

lower quality when compared to a wired network. This aspect

differs our proposal from others present in the literature that

consider the mobility as the capacity of using a given service at

different access points. The ability of splitting the processing

into servers and clients allows to design systems that are more

server intensive, with clients running lightweight application

logic.

The proposed middleware can run on different mobile de-vices and we evaluated it in the following scenarios: notebooks

(with no resource restrictions) and PDAs (with restrictions

to processing, memory, and energy) connected to WiFi and

Bluetooth networks; and cell phones (with more restrictions)

connected to a GPRS network. Our model is versatile since

we can use it on mobile devices that sometimes cannot receive

a connection, such as a cell phone in a GPRS network.

There are several interesting extensions that we can consider

as future work. An interesting issue is the possibility of having

multiple gateways which enhances the fault tolerance of the

system design. We also plan to design a reflexive version of our

middleware to allow changes in the system operation during

runtime.

REFERENCES

[1] L. Capra, W. Emmerich, and C. Mascolo, Middleware for mobilecomputing: Awareness vs. transparency, in HOTOS 01: Proceedings ofthe Eighth Workshop on Hot Topics in Operating Systems. Washington,DC, USA: IEEE Computer Society, 2001, p. 164.

[2] C. Mascolo, L. Capra, and W. Emmerich, Middleware for mobilecomputing (a survey), in Tutorial Proceedings of the InternationalConference of Networking 2002. Springer, 2002, pp. 2058.

[3] L. Capra, G. S. Blair, C. Mascolo, W. Emmerich, and P. Grace,

Exploiting reflection in mobile computing middleware, SIGMOBILEMob. Comput. Commun. Rev., vol. 6, no. 4, pp. 3444, 2002.

[4] C. Mascolo, L. Capra, S. Zachariadis, and W. Emmerich, Xmiddle: Adata-sharing middleware for mobile computing, Wirel. Pers. Commun.,

vol. 21, no. 1, pp. 77103, 2002.[5] L. Capra, W. Emmerich, and C. Mascolo, Carisma: Context-aware re-

flective middleware system for mobile applications, IEEE Transactions

on Software Engineering, vol. 29, no. 10, pp. 929945, October 2003.

[6] A. T. Campbell, Mobiware: Qos-aware middleware for mobile mul-timedia communications, in HPN 97: Proceedings of the IFIP TC6seventh international conference on High performance netwoking VII.London, UK, UK: Chapman & Hall, Ltd., 1997, pp. 166183.

[7] C. L. Fok, G. C. Roman, and G. G. Hackmann, A lightweightcoordination middleware for mobile computing, in Proceedings of the6th International Conference on Coordination Models and Languages

(Coordination 2004), February 2004, pp. 135151.[8] P. Bellavista, A. Corradi, and C. Stefanelli, Mobile agent middleware

for mobile computing, Computer, vol. 34, no. 3, pp. 7381, 2001.[9] A. T. Chan and S.-N. Chuang, Mobipads: A reflective middleware

for context-aware mobile computing, IEEE Transactions on SoftwareEngineering, vol. 29, no. 12, pp. 10721085, December 2003.

[10] A. Carzaniga, D. S. Rosenblum, and A. L. Wolf, Design and evalu-ation of a wide-area event notification service, ACM Transactions onComputer Systems, vol. 19, no. 3, pp. 332383, 2001.

Documents

Multi Client Server