Wireless Middleware Challenges and Requirements

Wireless middleware, as a specialized subset of middleware, has come into demand due to the proliferation of wireless networks. Additionally, in the last few years, there has been an upsurge in the development of the mobile devices sector. Personal Digital Assistants (PDAs) and a new generation of cellular phones have the ability to access different types of data. With this, the role of wireless middleware has become increasingly important in providing a reliable channel for data access between mobile devices and servers on a wired network.

Geier (2002) gave wireless middleware the following definition: "Wireless middleware is an intermediate software component that is generally located on a wired network, between the wireless device and the application or data residing on a wired network." The purpose of the middleware is to increase the performance of applications running across the wireless network by serving as a communication facilitator between components that run on wireless and wired devices. Wireless middleware serves as a communication facilitator by addressing the numerous ways in which communication can fail between components in a distributed application. Sources of communication failure, among many others, include a component going offline voluntarily but unexpectedly, a component unexpectedly terminating, a component failing to respond to a request in a reasonable amount of time, and communication being severed in the midst of a request (Sunsted, 1999).

Wireless middleware is presented with many challenges by the very nature of the wireless environment. These challenges are inadequately addressed by standard data communication methods, such as TPM's CORBA, or RMI, which were designed for wired environments. In the wired world, middleware has been used successfully for almost two decades now to allow applications to run on multiple platforms without the need to rewrite them. As such, wireless middleware should support heterogeneous devices and permit applications to be ported from one device to another. However, most traditional middleware products have not been tailored for mobile devices. For example, they require more memory than is available on a PDA and only support communication protocols that were designed for wired networks, notably TCP/IP.

Wireless middleware on mobile devices requires us to deal with challenges not present in traditional fixed-line systems. The most important additional wireless middleware requirements are listed and discussed below.

Intelligent Restarts

Wireless communication devices tend to lose and regain network connectivity much more often than nonmobile applications. The middleware must be able to cope with intermittent communication links and implement software layers that ensure the delivery of important data between the server and the wireless device. Consequently, the middleware should neither raise communication errors nor lose data when a mobile device loses network coverage. It should incorporate a recovery mechanism that detects when a transmission has been cut, and, when the connection is reestablished, the middleware should resume transmission from the break point instead of at the start of the transmission (Geier, 2002). Intelligent restarts are required in order to enhance the robustness of the distributed system that is built using the middleware. A robust distributed system must detect failures, reconfigure the system so that computations may continue, and recover when a link is repaired.

Store-and-Forward Messaging

Message queuing is implemented to ensure that users disconnected from the network will receive their messages once the station comes back online.

Small Footprint

Mobile applications must be optimized aggressively for small ROM and RAM footprints, as well as for low usage of CPU cycles and battery power. As a result, it is particularly important that the messaging client library, stored in the wireless device, should have a small memory footprint (ROM and RAM).

Open-Bearer Models

Internet applications only need to support HTTP or TCP/IP. Wireless applications are written to perform on many different networks. A bearer in a wireless network is a transport mechanism of which wireless bearers could be SMS, GPRS, Infrared, Bluetooth, and HTTP. An application written for one bearer typically needs to undergo substantial modifications in order to run on another bearer. The middleware should offer the same set of communication abstractions on top of various wireless bearers. This allows applications to be developed once and operate on top of various bearers. This may, however, lead to the least-rich subset of the possible bearers being implemented.

Multi-Platform Language Availability

The API should be compatible with languages available on multiple platforms. This allows applications to be adapted for various platforms more easily.

Security

Security is a key concern in a mobile environment. Security measures must be embedded into wireless middleware applications. As a result, access control, identification, authentication, and end-to-end data encryption are to be provided by the middleware. This dramatically simplifies the development of secure mobile solutions.

Scalability

As a result of the proliferation of wireless devices, scalability of applications can easily grow to hundreds of thousands of client systems. Ensuring the scalability of applications to this number of clients presents a major problem that must be addressed by wireless middleware. The middleware must not become overloaded when repeatedly sending messages and when encountering increasing congestion resulting from disconnect clients. In addition, it must be able to identify and delete messages, which can never be delivered, perhaps by a wireless device becoming broken or stolen.

Heterogeneous Software

There are a number of operating systems prevalent in the wireless device market. Because of the memory restrictions placed on these systems, they do not possess all of the features of server operating systems. Thus, it is often difficult to ensure that the middleware can effectively run on all the required hardware devices. Often, features available on one device are not available on another device with a different OS. For example, object serialization, which is a standard method of communication for components between client/server systems, is not available in Windows CE.NET. Thus, programming communications between components where the device is a CE device requires the applications developer to interface with a middleware product, which cannot serialize objects.

Deployment and Management

Deploying applications to many clients, managing them, supporting them, and ensuring their integrity and support when they are not online, presents another major challenge that must be addressed by middleware.

The basic requirements of wireless middleware can be met by messaging middleware. Messaging middleware serves as a tool for coordinating distributed application components and removes the responsibility for ensuring that messages are delivered reliably and correctly from application components. Messaging products (http://www.softwired-inc.com, http://www.spiritsoft.com) allow distributed application components to communicate and coordinate their activities (via messages) by providing vital services, such as message queuing, message persistence, transactional messaging, guaranteed once-and-only once delivery, and priority delivery (Sunsted, 1999).

As most of the commercial middleware products are based on the Java Messaging System (JMS), we will look at how it can be used as a wireless middleware.