JMS in Commercial Wireless Middleware Products

SpiritSoft—The SpiritArchitecture

At the heart of the SpiritArchitecture are two complementary message products—SpiritWave and SpiritLite. These operate with each other (SpiritWave can stand alone) to provide messaging transport across and beyond the enterprise. SpiritWave was the first commercially available JMS implementation…SpiritLite, with its small footprint, low power consumption and minimal load times, runs on any platform and is specifically designed for use by applets (within browsers) and by mobile devices. (Spiritsoft, 2002)

SpiritLite makes use of SpiritSoft's Java LightWeight Message Service (JLWMS), a stripped-down version of JMS. An application running SpiritLite sends a message to the SpiritWave message server. The SpiritWave server then decides whether the message should be forwarded to another SpiritLite client or transformed to the JMS format for JMS clients. This means that SpiritLite and JMS clients can interoperate seamlessly.

JLWMS is based on the JMS specification but is smaller and less demanding on resources. As an example, JLWMS requires only a single thread to consume messages and makes use of a lightweight wrapper around a JLWMS message payload. JMS messages, on the other hand, impose an overhead of 300 bytes per message even when empty. JLWMS supports point-to-point and publish/subscribe messaging and numerous message types from the JMS specification, including ObjectMessage, TextMessage, MapMessage, and BytesMessage.

Other features of SpiritLite include TCP/IP or HTTP firewall tunneling, serverless messaging between SpiritLite clients, UDP transport instead of TCP when reliability is not an issue, and an open plug-in API that allows new features to be added easily. For example, communication drivers and security tools can be added when required. SpiritLite enables secure, persistent sessions on the Internet with the aid of Secure Socket Layers (SSL).

Softwired—iBus//Mobile

iBus//Mobile from SoftWired, a Swiss-based company, was first shipped commercially in December 2000 (http://www.softwired-inc.com). The product makes use of wireless JMS (WJMS), a lightweight implementation of JMS. WJMS is capable of implementing both point-to-point and publish/subscribe in a Java library of only 70k, and at run-time, an iBus//Mobile application requires as little as 50k heap space (Maffeis2, 2002).

The iBus//Mobile architecture is depicted in Figure 5.

Figure 5: The iBus/Mobile Architecture

The components of this architecture are a JMS provider, a mobile JMS gateway, and the WJMS client library. The JMS gateway sits in between the clients and JMS provider. To the JMS provider, the gateway appears to be a regular JMS client. From the clients' point of view, however, the gateway acts as a communications hub and message format translator. The gateway guarantees delivery of messages to the receiving party. The WJMS client library is intended for deployment on programmable wireless devices, but as shown above, the iBus//Mobile architecture also caters for nonprogrammable devices, such as pagers and cellular phones. Therefore, it could be said that the client library is optional and depends on the nature of the client device.

Scalability is addressed by having several gateways, each supporting hundreds or thousands of mobile devices. The JMS provider would implement load sharing and fault tolerance to cope with the increased demand for resources. Furthermore, two or more JMS providers in a wide area network can be connected using HTTP or SSL. This configuration may appear where a company implements data centers in different regions of a country or even in different countries.