I have always used JMS as a transport/distribution/organization protocol. Several publishers send data on different topics, several subscribers subscribe to data on those topics--publishers and subscribers don't know each other. It works well.
However, now I am responsible for larger and more complex systems. For example, a transaction engine receives transactions and sends them on to the subscribers. If a new subscriber joins, it needs 'sync' the subscriber (which may include keeping history or some sort of 'snapshot' data) and continue to provide it with updates. In order to have a resilient system, I likely need to run at least two transaction engines (in case one fails), they need to be synced, they need to recover correctly. Subscribers should continue to work without errors--as much as possible. Parts of the system can ignore data (such as fast market data), parts of the system need to guarantee data is _never_ lost in a crash (orders, trades, etc.) At least some of this is apparently already provided. A large, concentrated and informed, effort such as qpid is bound to be better tested and better designed than efforts of a few people responsible for all kinds of irrelevant things. Unfortunately, JMS doesn't get more than a few pages of basic description in most J2EE books (and all the other stuff is irrelevant to my work). I'm sure AMQ has its own features, beyond JMS. I've started looking at clustering solutions, such as GridGain, but I'm not sure they are designed for low latency requirements. Can someone recommend the best way to maximize messaging software? Books, articles, docs, etc.? Thanks
