Why You Can't Ignore the JMS

A fateful Sun decision suddenly makes Java Messaging Service
an even more important factor in corporate development

by Andrew Binstock

Nov 10, 2003

Page 1 of 3

un Microsystems' Java Message Service (JMS) is about to have a huge impact on the messaging middleware business. This venerable industry, which provides the plumbing for transaction processing and data movement at many large IT sites, has been hobbled by proprietary vendor APIs to the middleware layer.

Specifically, when a shop chose one vendor's middleware solutionlet us say IBM's MQseries, the 800-pound gorilla in this spaceit would rewrite all its applications to communicate via MQseries' APIs. Since these APIs work only with MQseries, the site could not switch to another middleware provider without rewriting all its applications. The cost of this was so prohibitive that once a site chose a middleware package, it was effectively saddled with its choice forever.

Over the years, users pressured middleware vendors to come up with a standard set of APIs, and several initiatives did indeed establish standard messaging API sets. But vendors were slow to implement them; ultimately, no standard was widely accepted.

For more information on the overall Java market, see our special report, "Judging Java."

This all changed when Java introduced JMS in 1998. This new specification defined a comprehensive set of APIs for message queuing (the one-to-one model) and publish-subscribe (the one-to-many model) messaging. To get around the problem of vendor adoption, Sun made a fateful decision: It mandated that certified J2EE implementations had to include a JMS server. The effects of this were immediate.

All of a sudden, IT had its long-awaited standardized APIs and, equally important, it enjoyed the arrival of a whole new crop of middleware vendors. These newcomers, untrained in the strong-arm methods of their predecessors, forced the game such that today all major middleware vendors have shipped or announced JMS-compliant APIs. As a result, prices have started to tumble. Users have finally been emancipated, and the messaging middleware market will never be the same.

The inner workings of JMS were previously presented on DevX in an excellent article by Brian Maso, which gives a thorough presentation of how the messaging operates and what issues developers will face. The rest of my discussion focuses on the JMS market. Because there are so many players, the market has become segmented. This enables IT departments to choose a tailor-made JMS implementation that exactly fits their needs.