Middleware for multi-client and multi-server mobile applications

Bruno P. S. Rocha
Department of Computer Science Federal University of Minas Gerais Belo Horizonte - Brazil Email: bpontes@dcc.ufmg.br

Cristiano G. Rezende
Department of Computer Science Federal University of Minas Gerais Belo Horizonte - Brazil Email: rezende@dcc.ufmg.br

Antonio A. F. Loureiro
Department of Computer Science Federal University of Minas Gerais Belo Horizonte - Brazil Email: loureiro@dcc.ufmg.br

Abstract With popularization of mobile computing, many developers have faced problems due to great heterogeneity of devices. To address this issue, we present in this work 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. Offering a transparent communication API and allowing applications to divide their work amongst server and client sides, the proposed middleware becomes a viable alternative for development of distributed and mobile applications. We present as a case study an event notication service and show how it benets from the proposed middleware.

I. I NTRODUCTION Mobile devices, applications and services are currently part of 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, notication, 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 software design for mobile applications should take into account these limitations, the different operating systems and physical characteristics of different mobile devices. Portability of applications becomes a difcult goal to achieve. A middleware is a solution that allows to overcome some of these problems. It provides to the applications a set of functions 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 servers simultaneously. Applications can access an API available at the middleware that help their design. For instance, all communication between clients and servers is completely transparent to them. We present as a case study of our middleware an event notication service and show how it benets from the proposed middleware. The rest of this work is organized as follows. Section II presents the related work and discusses some of the middleware 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 middleware. Finally, Section VI presents some conclusions and future work. II. R ELATED W ORK Middleware for mobile computing is a relatively new research area. During the last decade, there were several proposals 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 characteristics and differences of wired and wireless environments that impact mobility, and categorize and study some possible middleware solutions. They suggest the use of a reexive middleware [3] in a mobile computing environment. In [4], they describe a reexive 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 applications. 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 middleware 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.

In [8], Bellavista et al. present a middleware for mobile users, also based on mobile agents, to keep services running regardless of users mobility. The middleware provides services to support virtual environment, virtual terminal, and resource manager, also considering less limited devices. In [9], Chan and Chuang propose MobiPADS, a middleware that uses information from the physical environment to perform self-conguration. 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 noties the applications that use those data. Most of the current middleware solutions for a mobile environment 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. M ULTI - CLIENT AND
MULTI - SERVER APPLICATION MIDDLEWARE

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

A pp 1

A pp 2

A pp 3

Authentication Interface

Communication Interface

Fig. 1.

Middleware model for the client side

Communication Interface

In this work, we propose a middleware for a mobile environment that has two sides: server and client. At the client side application development is made over a lightweight, robust and portable 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 between server and client. An application developer must use the API to write server and client application logics, as well as dening 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-dened 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 unied persistence view of the entire system. Finally, the localization

Localization Interface

Authentication Interface Database Interface

A pp 1

A pp 2

A pp 3

Server

Fig. 2.

Middleware model for the server side

The middleware provides to the applications two communication mechanisms. The rst one is the communication between the middleware and clients. In this case, applications receive messages from the clients through the common gateway, which controls the user access to the applications instances 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 application can dene 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.

All these strategies force the applications to execute following 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 communication 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. Authentication, 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 to have 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 congured 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 a larger capacity. IV. S YSTEM D ESIGN
AND

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 different instances 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

A RCHITECTURE

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 dened 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 at both 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 conguration 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

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 instances, 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 Pentium 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

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 messages back 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 middleware. 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. 5. Client-intensive model, in which the server entity only translates and forwards 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]: notication selection that determines the information that best matches the interests of a consumer, and notication delivery that sends the notication to the consumer. A notication service can be employed to monitor different information types such as computational resources (e.g., memory available and network state), and stock investments. In this work, the event notication service monitors different conditions (information types) and noties 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.
Fig. 4. Ad hoc model in which each device works as a server and a client

A. Flight Notication 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 trafc condition from where the person is to the airport, and the status of the persons ight (delayed or on time). With these pieces of information, it is possible to estimate 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 ight information using a mobile device. The event notication service monitors all conditions described above and sends to the person, at the proper time, a notication to go the airport. At any moment, the user can contact the event notication service to know the estimated time left to go the airport or even to know the conditions about trafc and ight schedule. In the following, we describe some details about the implementation and the interaction with the middleware. B. Using the Middleware The process of implementing applications for mobile devices tends to be more difcult since different devices can have

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 possible to 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. C ASE S TUDY: E VENT N OTIFICATION S ERVICE In this section, we describe an application we developed as a case study of the middleware. It is an event notication 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 notication service must match different information 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

different communication protocols. The middleware provides an API that facilitates this process. The event notication service was implemented on the top of middleware as depicted in Figure 6.

Fig. 6.

Overview of the notication systems architecture

Following the middleware architecture, the ight notication 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 ight time schedule, the user location, and the trafc conditions, in order to send to the user the notication to go to the airport. In this model, the client side works as an interface to send/receive a request/notication, and send/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 dened 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 specic communication infrastructure. The ENS has two basic services: notication selection and notication delivery. In our service, we had to implement only the notication selection since the notication delivery was built using the primitives provided by the middleware. Furthermore, the middleware provides the user location, which simplied 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. VI. C ONCLUSION AND F UTURE W ORK 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 middleware or applications already developed. The middleware is based on the client/server model and provides communication primitives to applications to exchange messages transparently between them and independently of a specic 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 devices 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 reexive version of our middleware to allow changes in the system operation during runtime. R EFERENCES
[1] L. Capra, W. Emmerich, and C. Mascolo, Middleware for mobile computing: Awareness vs. transparency, in HOTOS 01: Proceedings of the 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 mobile computing (a survey), in Tutorial Proceedings of the International Conference of Networking 2002. Springer, 2002, pp. 2058. [3] L. Capra, G. S. Blair, C. Mascolo, W. Emmerich, and P. Grace, Exploiting reection in mobile computing middleware, SIGMOBILE Mob. Comput. Commun. Rev., vol. 6, no. 4, pp. 3444, 2002. [4] C. Mascolo, L. Capra, S. Zachariadis, and W. Emmerich, Xmiddle: A data-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 reective 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 multimedia communications, in HPN 97: Proceedings of the IFIP TC6 seventh 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 lightweight coordination middleware for mobile computing, in Proceedings of the 6th 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 reective middleware for context-aware mobile computing, IEEE Transactions on Software Engineering, vol. 29, no. 12, pp. 10721085, December 2003. [10] A. Carzaniga, D. S. Rosenblum, and A. L. Wolf, Design and evaluation of a wide-area event notication service, ACM Transactions on Computer Systems, vol. 19, no. 3, pp. 332383, 2001.