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.

Can the system scale to 1,000 clients? Two thousand clients? The answer to this question is invariably yes. The real question is: How will it perform when 1,000 clients come on line?

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.

Market Segments

In this Article
Introduction	Free and Open-Source JMS
JMS in J2EE