JMS is about having Enterprise Java Applications communicate with the outside world.
Does not sound too impressing, but often is a challenge to get right. Messaging is an EAI Pattern, who, at times, do really help with integrating software systems.
The drawback about messaging is some added complexity in configuration, and the extra messaging model to deal with, but thinking it through, if you had to handle all the if’s and when’s of communicating to an external system, you may as well go with what is proven.
Enumerating the plus-points of JMS would take more than one paragraph, which is why I will not try. Details here. Using JMS will get your integrated (JEE) Applications improved transactional behaviour, better testability and improved configurability, for free.
Scenario: integrating external REST API. In your database you have configured some external system’s URL, whereupon you call some REST API to retrieve objects, to be processed inside your JEE Application.
- start a second instance of your JEE Application over the production database, or a backup thereof, and watch two systems fight over the external systems resources.
- in case of an error (application, database, networking, dns, …) the external system may not give you the same object again for processing, because you already had it. Same may happen when sending your response to the external system, where your database transaction got rolled back. You try again, but will get an error that this particular response has already been received, since external system never knew about your rolled-back database transaction in the first place.
Better with JMS?
To the point: queues can be transactional and persistent, meaning if there’s an error saving the message to your database you can get the message again from the queue, until it has been processed correctly. This works as well when sending your processed response - if something is committed to the queue, there will be re-attempts to deliver the message, even if the server crashes, the network or the external system is down.
Testability: messages need not come from an external integrated system. When your architecture includes queues, you can always, and very easy, feed your test messages into your queues. Never again start an entire systems zoo, just to test (or develop on) one component of your architecture.
Getting started: an impediment to get the dev-guys started with queues
can be the setup. In JBoss you may use
-jms.xml files to
create the queues. Makes it simple to roll out queues for
development. The JMS Spec is part of JEE, adhering to the concept of
managed resources, thereby leading to better configurability and,
perhaps most importantly, improved flexibility of your JEE
Examples and More
JEE Tutorial MDB Example: here.
JBoss Seam MDB Example: here.
Check out Creating Robust JMS Applications for message acknowledge modes (transactional queues).