ava Messaging Service (JMS) is an excellent message-queuing specification and also a pretty good publish-subscribe solution. To determine the best JMS implementation for messaging at your site, you will have to undertake the same effort as when selecting any other enterprise technology?namely, listing your current needs and projecting what they are likely to be in the future.

What kind of messaging do you need? And what is a prioritized list of criteria? I suggest that the top criteria should be reliability and scalability. Only then should you consider other factors, such as performance, ease of use, and administration. And only then, examine lesser issues, such as price.

Reliability is important because dropped messages are a nightmare to debug. All you know is the application did not work correctly or a transaction balked for unknown reasons. You will never suspect the middleware, and if you do, you will never be able to both reproduce the dropped packet and debug the product. So start by asking a vendor for references. The references you want to see are sales to financial services companies and defense contractors. Then call the reference accounts. You don’t want to find the middleware was shelved, for example.

For more information on the overall Java market, see our special report, “Judging Java.”/I>

Most people don’t recognize that scalability is a function of performance. They see the two issues as separate?they’re not. Can the system scale to 1,000 clients? Two thousand clients? But the answer to this question is invariably yes. The real question is: How will it perform when 1,000 clients come on line? Can the performance scale? Again, talk to references.

Pure performance, taken outside of the context of scalability, is less important. Most of the packages described here will be plenty fast enough for all projects with thresholds below real time. If you need real-time performance, look at the packages I discuss in “Extreme Performance.” Test the JMS candidates in your developer lab. Performance benchmarks are notoriously unreliable because they don’t reflect your site, so you will need to devise your own tests. Make sure they reflect your intended application; use messages that will be the same size as your production data items. Test the system under burst traffic and continuous flow. Have multiple clients send messages simultaneously at high volumes. Since your code will be mostly portable, you can run your benchmarks on all the final candidates you’re considering.

Price is the least important option. Because there are so many vendors in this market, prices are remarkably low. Before looking at cash outlay, examine the other secondary features, such as security options, administrative tools, and the like.

Your first decision, however, is likely to be whether you need a standalone JMS solution or one that is part of J2EE. If you’re expecting to use other J2EE technologies, especially enterprise Java Beans (EJBs) or Java Server Pages (JSPs), then a J2EE product might well be your best bet. If you just want a pure-play messaging middleware solution, then a standalone JMS will be less expensive and probably easier to tailor to your exact requirements.

JMS in J2EE
Choosing the right J2EE for your site is a complex task because J2EE is such a sprawl of technologies. Presuming, however, that your J2EE choice is predicated primarily on your choice of JMS, there are several top contenders. The first, without any doubt, is BEA Systems’ WebLogic, the market leader. Its JMS is fast and designed in-house. The J2EE implementation is superb; it’s universally recognized as the single best version of J2EE available. It has numerous features, excellent performance, scalability, and reliability.

The other heavyweight package is Totally E-Commerce from Hewlett-Packard Co.’s Bluestone Middleware division. The J2EE is also high-performance and scalable, and the JMS is provided by Sonic Software, a market leader in independent JMS versions.

IBM’s WebSphere is frequently associated with these products. However, WebSphere 3.5.x is not J2EE compliant. IBM has said it will be shipping J2EE-certifiedWebSphere 4.0 by fall 2001. The quality of WebSphere 4.0 cannot be ascertained, however, until customers have used the product for a while.

The problem with the BEA, IBM, and HP solutions is that they’re expensive and oriented toward large-scale server needs.

The problem with the BEA, IBM, and HP solutions is that they’re expensive and oriented toward large-scale server needs. If you have more modest needs or are looking for just a departmental solution, Macromedia’s JRun is the best solution; it is easy to install, run, and administer and entirely sufficient for smaller-than-enterprise needs.

Standalone JMSM
If you’re buying JMS primarily because you need messaging middleware, you have many choices. The market leaders among standalone JMS vendors are Sonic Software and Fiorano. The implementations are roughly equal in quality. Sonic is part of Progress Software, a publicly traded company that has for many years sold databases to mid-sized companies as well as a development environment for its database. As a result, Progress has somewhat more corporate muscle behind it, whereas Fiorano is a pure JMS company. This observation goes to questions of long-term presence and support, not to quality of implementation.

If you currently have messaging middleware installed and simply want JMS interfaces to it, the first place to check is your current middleware vendor. Almost all vendors are shipping JMS wrappers to their middleware layer or have announced them. If not, then consider SpiritSoft’s solution. Its JMS runs over middleware from IBM, Talarian, and Tibco. And if you have none of these installed, SpiritSoft can provide its own transport layer.

There are numerous other independent JMS vendors, some of whom appear in specialized contexts below, but these three players are the main independents and should be on your short list for pure play JMS messaging.

Extreme Performance
Messaging companies that target financial-services firms have offerings that specialize in two aspects: extreme speed and unfailing reliability. The two big names in this space are Tibco and Talarian. Tibco has announced JMS but has not shipped and probably won’t for a while. If you have Tibco middleware and need JMS, go to SpiritSoft for your solution.

Meanwhile Talarian has begun shipping two JMS products. The entry-level product, Workbench for JMS, is currently shipping. It’s more of an introductory product. Priced inexpensively, it uses a subset of Talarian’s SmartSockets technology?enough to fill JMS requirements. The big banana, though, is the Enterprise Workbench for JMS, which is a complete release of SmartSockets with JMS wrappers. This product is a superset of JMS and should be available later this year. And if it’s true to SmartSockets’ heritage, it will be the fastest JMS you can buy.

SpiritSoft supplies similar technology to financial markets in Europe. There it maintains several contracts in which it incurs legal liability should a client lose a single message. This is extreme reliability.

Free and Open-Source JMS
SwiftMQ is a free, commercial version of JMS from Germany. The company makes its living selling support and source code for its product.

Two open-source versions exist: One is OpenJMS from ExoLab.com, and the other is part of a open-source version of J2EE at Jboss. That JMS is set at version 0.8, which makes me a bit concerned, although the JBoss folks state it’s complete and being deployed.

Unless you’re an open-source evangelist, I do not recommend you use open source for JMS. JMS does not enjoy the same advantages of GNU tools and Linux?namely a large community of users ready to support each other, answer questions, and supply fixes. Rather, it has a very small community, so support is much sketchier and fixes slower. Moreover, commercial versions are inexpensive, so the dollar savings of open source is slight. Finally, since the commercial versions have been deployed at more sites and on larger nets, they will be better tested than open-source versions.

Developer Versions
Almost all vendors provide free developer versions for you to use. Since code written for JMS is pretty much portable between implementations, you can take any leading version and work with it to develop and test your code. Most versions limit the number of connections you can make to the JMS server. This is the case with Sonic Software, Fiorano, and BEA Systems.

If you need to test your code on systems with more connections, then try SwiftSoft or Talarian’s free download, which are complete?but time-locked?implementations. Alas, the time locks are both an excessively short 15 days, so don’t download them until you’re ready to go. Alternatively, you can always use SwiftMQ’s version for an indefinite period, should you want to do more testing.

Take your time, choose carefully, and enjoy the fact that if you chose the wrong JMS, you will for the first time in computing history be able to change middleware providers without rewriting your applications. Hooray!