The JMS Solution

We have outlined the core issues facing developers of mobile applications, and we have established requirements for mobile middleware in order to address those issues. In this section we will argue that a JMS implementation targeted at mobile devices fulfils these requirements and is thus a very appealing platform for advanced mobile solutions.

Motivation

For three decades now, message-oriented middleware (MOM) has been used for the reliable transmission of important information from one system to another. Messaging middleware allows for loose coupling of software components and thus for greater flexibility. Nowadays, JMS is the MOM standard for Java. It allows you to develop distributed applications more quickly, and in a platform-independent "Write Once, Run Anywhere" manner. JMS will prove even more valuable for developing sophisticated mobile applications because of the reasons given below.

Since JMS embodies a message-oriented rather than a connection-oriented model, it is ideally suited for applications that are resilient to intermittent network connectivity and able to operate while disconnected from the server. This is achieved by providing persistent message queues on both the mobile device and the server.

iBus//Mobile

The JMS abstractions can be implemented in a very lightweight manner. The iBus//Mobile product, an implementation of JMS for mobile devices, has shown that the JMS features (notably PTP and pub/Sub) can be implemented in a Java library of only 70k. At run time, an iBus//Mobile application can live with as little as 50k Java heap space.

The message-oriented paradigm maps nicely into the packet-oriented communication model of SMS, GPRS, EDGE, and UMTS. Furthermore, messaging can also be performed efficiently on both connection-oriented bearers such as GSM, and connection-oriented protocols such as TCP and HTTP. Hence, a JMS implementation can be designed in such way that arbitrary protocols and bearers can be plugged-in.

Another fact proven by iBus//Mobile is that mobile JMS middleware, if designed appropriately, can support multiple mobile OS platforms.

Security needs to be supported at different levels. First, a system administrator can control access to JMS topics and queues for individual mobile devices. Mobile devices (or more exactly, the applications running on them) are identified using userID/password combinations or security certificates. Furthermore, the messages are to be encrypted before transmission via a bearer. In any case you might want to check that your JMS vendor provides flexible access control and data encryption.

Regarding security, iBus//Mobile provides access control to JMS topics and queues, using a userID/password combination. Furthermore, iBus//Mobile will encrypt the traffic between a mobile application and the iBus//Mobile gateway. For that, various third-party encryption libraries can be used, such as Certicom (http://www.certicom.com). iBus//Mobile provides an open API allowing system integrators to extend the product to support other third-party security libraries and key management systems.

Architecture

One possible JMS solution for mobile devices consists of three components: the JMS provider, the mobile JMS gateway, and the lightweight JMS client library. Note that this is the architecture of the iBus mobile messaging middleware. This architecture is particularly suited for wireless portals and wireless ASP solutions:

The JMS Provider

This is a JMS message server product running in a data center. It can be either a standalone JMS server, such as Softwired's iBus//MessageServer, or a JMS-enabled application server, such as BEA Weblogic.

The JMS Gateway

This can be seen as the home base to which mobile devices connect through wireless bearers. From the JMS provider's point of view, the gateway is a regular JMS client. From the mobile device's point of view, the gateway is a communications hub and message format translator. Optionally, the gateway can be incorporated into the JMS provider.

The Lightweight JMS Client Library

Applications such as chat rooms, games, financial tickers and m-commerce transaction tools typically require a customized application to be available on the mobile device. We have so far assumed that a JMS enabled Java application is deployed onto mobile devices. For this type of application, a lightweight JMS client library is provided with the iBus//Mobile package. However, our proposed architecture is more general in that it can also support non-programmable devices such as WAP phones, SMS phones, and pagers. Therefore we will consider the deployment of the lightweight library as optional.

The client-to-gateway protocol is proprietary and optimized for low overhead. All information is transmitted in binary form. A JMS publish operation typically results in an overhead of less than 20 bytes. This makes the iBus//Mobile lightweight JMS library appealing not only for mobile devices but also for Java applets.

JMS Message Flows

This section explains the JMS message flows occurring between backend applications and mobile devices. At this point we assume that all messages (even device-to-device interactions) pass through the gateway. This is to guarantee the delivery of messages, in case a receiving device is temporarily disconnected or turned off.

We will look at four different interaction scenarios:

• A backend application sends an asynchronous notification to a native device

• A native device sends a request to a backend application

• A backend application sends a JMS message to a programmable device

• A programmable device sends a JMS message to a backend application

Backend to Native Device

Assume a backend JMS application running on the application server machine in the above scenario diagram. The application would like to transmit a stock alert via SMS, to a group of users interested in particular stock. The application encodes the stock alert into XML, creates a JMS text message and writes the XML into the text message body. Now assume the message is put into a JMS queue called stock-alerts. This is all that needs to be done by the developer of the backend application. The following tasks are performed transparently by the mobile JMS infrastructure.

We further assume the gateway is configured to receive messages put into the queue stock-alerts. The text message is received by the gateway and the XML information is parsed. Embedded in the XML information, there is the name of a SMS distribution list (for example stock-alerts-list) for the alert. The distribution list contains the SMS addresses to which the alert is to be sent. This information is administered by the gateway, to relieve the backend applications from maintaining their own distribution lists.

Now the XML is converted to an SMS text string by the gateway and is sent to all the SMS addresses located in the distribution file.

This also works for other wireless messaging standards besides SMS. For example, WAP push and paging. WAP-push is part of the WAP 1.2 specification. It provides asynchronous notifications from the WAP gateway to a mobile WAP device.

Native Device to Backend

Imagine a user of an SMS-enabled phone querying their flight departure time. The user creates an SMS message containing the information LAX SR118 and sends it to a service telephone number. The gateway is configured for receiving the SMS messages sent to that number, either through a GSM modem or through a direct link to an SMS control center.

The SMS is received by the gateway and is parsed. The first token LAX denotes a channel that is defined in the gateway configuration database. By looking up the channel in the configuration database, the gateway obtains the name of a JMS queue to which the message should be forwarded.

Next, the SMS (the string LAX SR118) is converted to XML and put into a JMS text message. Finally, the JMS message is forwarded to the queue we obtained from the gateway configuration database.

Now a backend JMS application can read the text message, look up the departure time of flight SR118, and send back a response to the user, also via SMS.

Backend to Programmable Device

The message flow occurs slightly differently when the lightweight JMS library is deployed on the mobile device. Assume a Palm PDA or a Symbian communicator running a stock ticker Java application. The ticker uses the JMS Pub/Sub model to subscribe to the topic quotes. A backend application receives stock quotes from a financial data feed such as Reuters or Bloomberg, and publishes them on topic quotes. The mobile JMS infrastructure performs the necessary steps for transmitting quotes from the backend to one or many mobile devices, in a reliable, efficient, and secure manner. Now let us look at the message flow.

First, the mobile ticker application is started. It creates a JMS topic subscriber on the topic quotes. The JMS client library will inform the gateway that it is interested in messages published on quotes.

When the backend application publishes a JMS message using a JMS topic publisher, the message is first received by the gateway. Next, the gateway puts the message into a database in case the device has lost network coverage. Then, the gateway transmits the message to the mobile device(s) using a wireless bearer such as GPRS. The client dispatches and acknowledges the message. Finally, the gateway removes the acknowledged message from its database.

Programmable Device to Backend

Imagine an m-commerce application allowing the user to send purchase requests to a backend application. For that we will use a queue entitled purchases.

The mobile application creates a queue sender for queue purchases. Next, a JMS message detailing a purchase is created and sent to the queue. This results in the JMS message being stored in an embedded database on the device, to ensure the message is not lost if the device loses network coverage. The JMS client library transmits the message from the local database to the gateway. The message is deleted from the on-device storage; only when the JMS library knows for sure that the message has arrived at the gateway.

Once the gateway has received the message, it puts it into the queue purchases of the JMS provider. The message is now accessible to backend applications.

Configurations

In the simple cases we have looked at, a deployment consists of one JMS provider, one gateway and several mobile devices. For e-business applications, portals, groupware and so on, we envisage a deployment containing at least one message server and one gateway. For certain embedded distributed systems, however, such as an elevator control system, a configuration without message servers might be more appropriate.

The reason for this is that a JMS message server typically requires a server platform based on the Windows or Unix operating system. Such a server component might be just too expensive for an embedded system, especially if only a small number of JMS clients are involved. Rather, the boards could exchange (non-persistent) JMS messages directly among themselves using point-to-point TCP/IP connections or multicast channels. Note, however, that such a configuration typically does not allow for JMS messages to be stored persistently. For that a message server is required.

The figures below depict peer-to-peer and device-to-gateway configurations:

The figure above shows peer-to-peer configuration using Point-to-Point (PTP) communication (left) and multicast communication (right). Below we see a possible device-to-gateway configuration:

For real scalability, we should consider a configuration with several gateways (below), where each gateway supports hundreds or thousands of mobile devices:

Note that we assume that the JMS provider implements load sharing and fault-tolerance, which is the case in the high-end JMS solutions available on the market today (see Chapter 8 on JMS clustering).

Going further, a business-to-business configuration might then consist of two servers interconnected by SSL or HTTP. For example, the architecture of a highly scalable wireless portal might foresee a data center in each country (or state), and route certain JMS messages from one data center to another using HTTP as a bearer: