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.

Market Segments
J2EE Vendors
While all J2EE vendors must provide a JMS server, almost none have written their own. BEA Systems, the market leader in J2EE sales, is one of the few exceptions; its JMS was developed entirely in-house. The old-guard middleware vendors who now sell J2EE platforms have provided JMS wrappers to their middleware piping. IBM did this, for example, wrapping JMS around MQseries. Likewise, Talarian Corp. wrapped JMS around its SmartSockets middleware.

Several J2EE vendors chose the third path, which was to OEM their JMS from independent third-party vendors. Hewlett-Packard’s Bluestone J2EE server, for example, uses a JMS layer from Sonic Software (a division of Progress Software).

These OEM’d versions come from a variety of independents that are contentiously vying with each other and squabbling over benchmarks.

The Independents
The most visible is Sonic Software. It is by far the best marketed of all JMS implementations and is viewed in many quarters as one of the best implementations as well. Its most impressive credential is that HP Bluestone’s use of SonicMQ JMS in its J2EE was instrumental in winning HP the contract of American Airlines’ massive Sabre reservations project. The project needed fast and scalable messaging, and the Sonic JMS provided this.

Sonic and Fiorano have waged a war of words about whose implementation is faster. And you can go to their respective Web sites to find the latest charges about whose benchmarks you should believe.

Sonic’s strongest direct competition comes from Fiorano Software, a company that developed one of the very earliest JMS implementations. It was also one of the first to offer SSL and a variety of other security features. And Fiorano is leading the way in other innovations such as content-based routing of XML messages. Sonic and Fiorano have waged a war of words about whose implementation is faster. And you can go to their respective Web sites to find the latest charges about whose benchmarks you should believe.

However, if you’re looking for real-time messaging, neither Fiorano nor Sonic are likely to be your best option. For pure blinding speed, look at the next page, Extreme Vendors.

The third important independent is SpiritSoft, an English firm that recently set up offices in the U.S. SpiritSoft has much to recommend it. It is probably the first vendor to deliver a JMS implementation, having done so in early 1998. It also has chosen a unique implementation: its JMS will ride over other vendors’ transports. So if you have Talarian, Tibco, or IBM’s MQseries middleware in your shop or any combination of these, SpiritSoft’s JMS will ride seamlessly over these transports. It also works over Microsoft’s MSMQ?a unique trait. If you have none of these message layers, SpiritSoft provides its own transport. The company has its roots in the financial-services sector, so its particular strength is reliability. Fittingly, it OEMs its JMS to Persistence Software, whose PowerTier J2EE implementation is targeted at the financial market.

Sonic Software and Fiorano allow developers to download and use a free copy of their product, which is limited by the number of connections it will support. SpiritSoft offers a complete implementation for free to developers on a 60-day time-locked trial basis.

For a completely free unrestricted version, consider SwiftMQ’s JMS, a full commercial implementation from Germany. Also, an open-source version is available from exolab.org under the name OpenJMS.

Talarian Corp. and Tibco are the two marquee names in real-time messaging. Both companies’ products are used primarily in publish-subscribe (one-to-many) mode in high-performance contexts such as financial sector and the defense industries. Typically, they are found on trading floors of stock exchanges providing brokers with data feeds of share prices, trades, and the like.

In these contexts, both companies specialize in velocity and dependability. Talarian leads the way in JMS implementations, having announced two JMS products, one of which is already shipping. This product, Workbench for JMS, uses a subset of Talarian’s middleware and is designed to compete with the low end of the JMS market. The Enterprise version of Workbench for JMS is shipping this summer and runs on the full Talarian messaging transport. This gives it the benefit of access from languages other than Java, plus multicast, and a number of administrative tools. A developer version with a 15-day time lock is available from Talarian’s website.

Talarian’s primary competitor in extreme performance is Tibco. That is, in all areas but JMS. Tibco has announced that it will ship a version of JMS some time this year. As yet, though, no product is available.

Next month, I will discuss how to choose a JMS implementation and how to assess the vendors discussed here.