Summary

Clustering is a world of tradeoffs. Performance, capabilities, scalability, reliability, and complexity are just some of the factors that tend to work against each other. If this were not the case, then there would be one best cluster architecture and this chapter would be very short. In addition to the many possible cluster architectures, there are a variety of problems that can be solved by clustering. Any particular JMS-based distributed system may only face some of these problems; hence you need to define your need before shopping around for a JMS cluster. If this chapter has achieved its purpose, then you should be well prepared to do this.

Examples of JMS providers that support some of the clustering concepts described in this chapter are: FioranoMQ IBM MQSeries, Progress Sonic MQ SwiftMQ and the JMS provider included with BEA WebLogic. Softwired will also release a clustered version of iBus//MessageServer in the near future.

After reading this chapter you should be well equipped to ask the right questions and find out what you need to know about JMS clustering. It should also serve to provide a common set of terminology to help avoid misunderstanding.

In the next chapter, we'll look at one particular use of JMS in a clustered architecture, that of distributed logging.