Java Tutorial - Java Scipt :
When Is JMS the Right Solution?
As with any tool, there are times when it makes sense to use JMS and there are times when it doesn’t.
You would use JMS in situations where loosely coupled communication is beneficial. Queues and topics are fairly independent of the producers and consumers that use them. This buys flexibility in connecting enterprise components at the expense of increased cognitive complexity. You can fall into a tangle of asynchronous communications if messaging is overused without careful planning. It is far more difficult to trace asynchronous communication than it is to trace synchronous communication. On the flip side, messages can lead to reduced complexity by simplifying the enterprise architecture. You can publish events and forget about them. You can trim away polling and other synchronous hacks in favor of true asynchronous programming. In situations where components get overloaded by harsh spikes in processing, you can use messaging to distribute and normalize the load. The trade-off is that designing an application around messaging requires a different mindset
than a traditional method-driven approach. Another drawback to JMS is that messaging requires greater resources than a comparable method call. That is to say, in a one-to-one comparison, a message costs more than a method call. Overall, though, the scales may turn in favor of messaging. For example, in a system that sees large spikes in activity, you might be able to allocate fewer resources to handle the same load There is no single solution. JMS is a great tool and should be used when it makes sense. Hopefully, knowing what the trade-offs are will aid you in building your enterprise applications.
