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.
(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.
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
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.
Message queuing is implemented to ensure that users
disconnected from the network will receive their messages once the station comes
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).
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.
The API should be compatible with languages available on
multiple platforms. This allows applications to be adapted for various platforms
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.
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.
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
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