Wireless Middleware


Middleware is not a new concept in distributed computing. It was first accepted as a term used to describe distributed software architecture during the 1990s and has evolved significantly since then with the increase in computer networking and the resulting use of distributed systems. The following is aA definition of middleware that was proposed by Emmerich (2000) and embodies the concepts of middleware: “Middleware is a layer between network operating systems and application components which facilitates communication and coordination of distributed components” (p.120).
Middleware has become widely adopted in industry to simplify the problem of constructing distributed systems as it resolves the heterogeneity between systems and provides higher-level primitives for application engineers to focus on application requirements and not their connectivity.
Wireless middleware, as a specialized subset of middleware, has come into increased significance in the current decade 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 network services and run many applications. To cope with these innovations, 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. This provides applications running on the mobile client to synchronize with and participate in the application dialogues that are hosted on the enterprise servers.
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 performance of applications running across the wireless network by serving as a communication facilitator between components that run on wireless and wired devices (Wireless Nets). Wireless middleware serves as a communication facilitator by addressing the numerous ways in which communication can fail among components in a distributed application. Sources of communication failure, among many others, include a component going off line 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).


Currently there are two distinct types of wireless networks that can be categorized by their transmission range and that differ significantly in the latency and bandwidth characteristics of the transmission.

Fixed Wireless Networks

Fixed Wireless Networks use wireless transmitters with a relatively short transmission distance and normally correspond to one of the IEEE 802.11 standards. Networks of this type have many of the characteristics of fixed wire networks, such as low latency, high bandwidth, and relatively good reliability. These networks tend to be used in a specific area such as a Starbucks coffee shop, an airline lounge, or a corporate office. For wireless networks of this type, the standard middleware that is normally employed in wired networks and can be used as such are the de facto standard interprocess communication mechanisms such as XML and SOAP, which are becoming increasingly common.

Highly Mobile Wireless Networks

These wireless networks are used predominately to serve highly mobile clients such as mobile cellular phones or satellite communications. Networks of this type have extremely high latency, relatively low bandwidth, and greater unreliability, as any number of interruptions can occur to disrupt the communication with the client. As this type of network is increasingly becoming used for M-commerce, specialized middleware is required to cater to the additional challenges.
It is this type of wireless network (i.e., high latency, low bandwidth, unreliable, and insecure networks) to which the remainder of this entry refers.


Wireless middleware is presented with many challenges by the very nature of the wireless environment. These challenges are not adequately addressed by standard data communication methods that were designed for wired environments. One of the main advantages of middleware is to allow applications to run on multiple platforms without the need to rewrite them. As such, wireless middleware should support heterogeneous devices, permit applications to be ported from one device to another, and, in addition, handle the limitations of mobile devices, among which are the small amount of memory and the lack of processing power. Wireless middleware on mobile devices has some distinct issues not present in traditional fixed line systems.

Disconnected Operation

Wireless communication devices tend to lose and regain network connectivity much more often than non-mobile 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.

Resource Constraints

Mobile applications must be optimized aggressively for small ROM and RAM footprints, as well as for low usage of CPU cycles and battery power.

Multiple Bearers

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, or HTTP. An application written for one bearer typically needs to undergo substantial modifications in order to run on another bearer.

Heterogeneous Software

There are a number of operating systems that are prevalent in the wireless device market. Because of the memory restrictions placed on these systems, they do not possess all 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 that are available on one device are not available on another device with a different operating system. For example, object serialization, which is a standard method of communication for components between clients and server systems, is not available in Windows CE.Net. Thus, programming communications between components where the device is a CE device require the applications developer to interface with a middleware product that cannot serialize objects.


Security is a key concern in a mobile environment. Identification, authentication, and data encryption must be embedded into wireless middleware applications.


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.

Deployment and Management

Deploying applications to many clients, managing them, supporting them, and ensuring their integrity and support when they are not online, present another major challenge to the middleware.


The development of application software such as M-Commerce applications and client/server applications should not be designed so they are independent of the network over which they are deployed. This ensures that applications do not require to be rewritten for new technologies, and the applications developer and business enterprise can concentrate on the business benefits of the application and not the technology on which they reside. For example, a stock ordering application running on a PDA for a manufacturing concern should integrate with the manufacturing schedule in the corporate head office. The speed of taking the orders, scheduling them, and getting them in the production schedule is what is important to the manufacturing company. Wireless middleware provides this network transparency and enables wired applications to be ported to wireless environments with the minimum of software modification.

Wireless Network Requirements

In order to meet the needs of the applications running on them, typical wireless middleware solutions have the following basic requirements:
• Intelligent restarts
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 resumes transmission from the break point instead of at the beginning of the transmission.
• 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. This, however, can lead to a large number of messages being stored for stolen or broken clients.
Small Footprint
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
The middleware should offer the same set of communication abstractions on top of various wireless bearers. Modern wireless communications use GSM, GPRS, and possibly 3G mobile communication protocols. This allows applications to be developed once and operate on top of various bearers. This, however, may lead to the least rich subset of the possible bearers being implemented.

Multi-Platform Language Availability

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


Security is essential in a wireless system, particularly for applications such as M-Conmmerce, which are becoming increasingly widespread (Allnet, 2002). As wireless communications cannot be physically secured, the needs of wireless access present a new series of challenges. Wireless access to enterprise systems puts not only the client device, but also the data, well beyond the physical control of the organization. Sniffing of data traffic can be done without any risk of detection over a much wider range of locations. Furthermore, the client device, in the case of a cell phone or PDA, is even easier to steal than a laptop computer with the additional loss of security. Compromise of the wireless client thus poses a double threat to data: the remote access to data that the device enables, and immediate access to the downloaded data which is stored within it. The wireless middleware should incorporate a security mechanism. Thus, access control, identification, authentication, and end-to-end data encryption should be provided by the middleware. Providing these facilities in the middleware and not in the application dramatically simplifies the development of secure mobile solutions.


The middleware must support scalability, as many thousands of clients could be connected. It must not become overloaded when repeatedly sending messages, and must handle increasing congestion resulting from disconnect clients. In addition, it must be able to identify and delete messages that can never be delivered perhaps due to a wireless device becoming broken or stolen.
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.


These basic requirements of wireless middleware can be met by messaging middleware.Messaging middleware allows general-purpose messages to be exchanged in a client/server system using message queues. Applications communicate over networks by putting messages in queues and getting messages from queues. This messaging and queuing allows clients and servers to communicate across a network without being linked by a private, dedicated, logical connection. The clients and servers can run at different times. All communication is by putting messages on queues and by taking messages from queues. It is used when a distributed application can tolerate a certain level of time-independent responses. For example, nomadic client/server systems can accumulate outgoing transactions in queues and do a bulk upload when a connection can be established with an office server.
Since most of the commercial middleware products are based on the Java Messaging System (JMS) (JMS
Specification, 2002), we will look at how it can be used as a wireless middleware.
JMS, developed by Sun Microsystems, Inc., is part of the Java2 Enterprise Edition (J2EE) platform. JMS is an Application Programming Interface (API) for accessing Messaging applications in Java Programs. The JMS API is not specifically intended for the wireless domain. Traditional JMS was designed to allow Java applications to communicate with existing wireline messaging systems. As a result, a full JMS implementation is too “fat” for wireless devices because low power consumption and a smaller memory footprint are required (Spiritsoft, 2002). However, JMS has become the “de facto” standard as an API for wireless middleware, and most wireless middleware products are based on it.


The JMS API allows applications to create, send, receive, and read messages which can arrive asynchronously, which means that the client does not have to specifically request messages in order to receive them. In addition, the programmer can specify different levels of reliability, depending on the type of message that is transmitted. Unlike traditional low level network remote procedure call mechanisms, JMS is loosely coupled, which means that the sending and receiving applications do not both have to be available at the same time in order to enable communication (Java, 2002).

The JMS API Architecture

The following components are present in a JMS implementation:
• JMS Provider - Provides administrative and control features. It is the system that implements JMS interfaces.
• JMS Clients - Components or programs, written in Java, that are the producers and consumers of messages, clients, and servers. In the wireless domain, clients may include cellular phones and PDAs.
• Messages - The objects that are transmitted between JMS clients.
• Administered Objects - These are configured by the administrator and include destinations and connection factories. Together, the administered objects form the Java Naming and Directory Interface (JNDI) API namespace. For one client to establish a logical connection with another through the JMS Provider, it needs to perform a lookup of administered objects, using a standard directory service.
Further details on the JMS communication API can be found on the Java tutorial.
JMS supports the two more common approaches to messaging; namely, point-to-point and publish-subscribe, which permit messages to be transmitted directly between a client and a server, or for a client to subscribe to specific messages (e.g., sports scores) and servers to broadcast these messages to the specific clients that request them.


Contemporary middleware products, whether message oriented or otherwise, have not been designed for mobile devices (Maffeis, 2002). This inappropriateness stems partly from the use of communication protocols that were designed for wired networks. The dominant wired network is the Internet, which has the Transmission Control Protocol (TCP) as its transport protocol. Regular TCP, which is TCP designed for wired networks, could be used in the JMS Connection object; however, this may lead to intolerable inefficiencies. Wireless links do not provide the degree of reliability that hosts expect. The lack of reliability stems from high error rates of wireless links when compared to wired links. Additionally, certain wireless links, such as cellular networks, are subject to intermittent connectivity problems due to handoffs that involve calls being transferred between base transceiver stations in adjacent cells. The root of the problem is that congestion avoidance in the wired TCP algorithms is based on the assumption that most packet losses are due to congestion. As a result, the TCP sender spends excessive amounts of time waiting for acknowledgements that do not arrive.
As a result, most wireless middleware products and JMS implementations use either different transport mechanisms, such as a reliable data protocol similar to that described in RFC 908 (Velten et al., 1984), or a significantly lightweight versions of the standard TCP protocol.


As wireless devices become increasingly powerful and more accepted, wireless middleware will have to play an increasing role in ensuring that applications run efficiently in this environment. Currently, the versions of wireless middleware being used are, at best, second-generation versions; however, work is being undertaken in a number of areas.

Network Protocols

Alternative network protocols suitable for wireless communication are being analysed (Farooq & Tassiulas, 2003). This will lead to faster communications between the wired and wireless devices.

Application Communication Paradigms

As wireless technology becomes more available, developers of distributed applications are becoming more interested in how that technology affects the performance of their systems. Thus, the efficiency of different paradigms of communication, such as publish/subscribe, is being investigated (Caporuscio & Carzaniga, 2002); Farooq et al., 2004).

Efficiency of Wired Protocols

As most distributed applications on the Internet are using protocols such as SOAP and XML, work is being undertaken to optimize these protocols for wireless communications (Hanslo, 2004).

Alternative Middleware Products

Currently, Java (JMS, in particular) is effectively the only platform suitable for mobile communications. As the market for wireless applications becomes larger and more profitable, there will be more middleware products vying for a share. Thus, there will be greater competition and more choice for the applications developer. Some of these middleware products could permit applications for wireless ad hoc networks such as peer-to-peer computing, which could easily be developed (Kortuem, 2002).
As a result of this work, wireless applications will be developed, integrated into the enterprise, and executed with the efficiency and reliability that is expected from wired applications.


Wireless middleware has evolved from the traditional middleware background to a product field in its own right. The early attempts of stating that standard wired middleware products are “suitable for wireless” have passed and the wireless middleware products in commercial use today have different requirements, use different transport protocols, and have a different concept of robustness of connection from traditional products. In the future, more advanced products that are specifically catered to the wireless domain will be produced. These products will enable more advanced applications to be implemented and will further increase the usefulness of the mobile devices and PDAs. Finally, with the use of wireless middleware, ubiquitous computing will become a reality.


Application Synchronization: A specific type of wireless application whereby the data on the wireless device is synchronized with that on the main server.
Handover: In a cellular network, the radio and fixed voice connections are not permanently allocated for the duration of a call. Handover, or handoff as it is called in North America, means switching an ongoing call to a different channel or cell. This often results in loss of connection.
M-Commerce: A wireless application that involves the change of money. This could be through the use of a mobile device to pay for services.
Network Bandwidth: The data capacity through a network.
Network Latency: The time for a message to travel over the network from the sender to the receiver. In cellular networks, this includes the time from the device over the network to the base station, over a landline to the service provider, and out to the application. It could possibly include satellite transmission time from the earth station to the satellite and down to another earth station.
Point to Point: The communication from a single client to a single server.
Publish Subscribe: A method of communication by which clients register to be notified when some event occurs. When the event happens, the server checks though the list of subscribed clients and broadcasts to them the event data. This is often used in wireless applications for information on stock price changes, sports results, and so forth.
Wireless Application: An application running on a wireless device that transmits and receives data over a wireless network.

Next post:

Previous post: