What is Wireless JMS Middleware?

By Dr. Silvano Maffeis, CTO, Softwired 02 Oct 2001 | SearchMiddleware

Digg This!     StumbleUpon     Del.icio.us

Micro Browsers Are Not Enough!

Wireless platforms based upon markup languages such as WML have not proven very successful yet. For example, WAP users often complain about a poor user experience due mostly to lack of interesting content, to an awkward interaction model, and to errors occurring when a device loses network coverage for a limited period of time. In my opinion, deploying WAP over a faster bearer, such as GPRS, will not solve the problem either. I believe the problem is more fundamental and relies in the fact that the interaction model that is used successfully on the wireline Web, was simply transferred to the wireless Web. This was done without taking into consideration that mobile devices are used in a completely different manner than PCs at home or at the office.

Wireless Middleware to the Rescue

User experience is further improved by installing customized applications on mobile devices, which allow the user to continue working with the mobile application even when disconnected from the network.

Those applications are best built using a "store-and-forward" communication paradigm, which is provided through appropriate messaging middleware (MOM) technology on the device.

I believe that for the development of mobile applications, messaging middleware offers a much more powerful and adequate paradigm than CORBA or RMI.

To develop this type of mobile application,the approach of my company Softwired is to use Java technology straight through from the mobile devices to the application servers. Our approach consists of deploying customized Java applications on the mobile device, and on the server computers.

Then, we use a packet-oriented wireless bearer such as SMS, GPRS, CDPD, or Mobitex to connect the mobile devices to the back-end servers in a flexible and scalable manner.

To make the interactions between the clients and the servers reliable and secure, we deploy standards-based Java messaging middleware technology on the mobile devices and on the servers. For that we rely on our iBus product family, industry's only end-to-end JMS (Java Message Service) middleware solution.

Application Areas

The application areas of such end-to-end, wireless enabled JMS middleware are manifold:

• Mobile workforce automation, and other Business-to-Employee (B2E) systems: These require customized client applications, offline and online operation, as well as high efficiency.
• M-Banking, M-Finance, M-Commerce, and other Business-to-Consumer (B2C) systems: Only wireless messaging middleware can guaranteed exactly-once delivery of transactions issued by a mobile user.
• Supply chain management, and other Business-to-Business (B2B) systems.
• Embedded systems, remote-administration of machines, manufacturing control, and other Machine-to-Machine (M2M) communication systems: Messaging middleware supports the immediate delivery of signals and other important data.
• Games, chat systems, and other Peer-to-Peer (P2P) applications: Messaging allows for highly interactive communication.

Wireless JMS Deployment

A Wireless JMS (WJMS) deployment consists of Java-enabled mobile devices (PDAs, Communicators, JavaPhones, etc.) with a WJMS client library installed. Optionally, the devices provide a persistent database in order to implement store-and-forward communication.

View Architectural Diagram.

The devices use a wireless network to communicate with a WJMS Gateway service. The Gateway is a software component able of receiving WJMS messages from a wireless network, and of relaying these messages to a server-side JMS provider. The JMS provider either is a stand-alone JMS messaging server such as iBus//MessageServer, or a full-fledged J2EE application server such as BEA WebLogic.

The server-side application logic of the mobile system is implemented in the form of stand-alone JMS applications, of EJB MessageDrivenBeans, or of both.

This results in a clean end-to-end solution, in which we use one powerful communication abstraction straight-through from the clients to the servers: JMS. No need for format transcoders in the form of transcoding engines, Servlets, or server pages.