Having bridged data from some other message system to Diffusion more than once, it was clearly time to build something so we might be able to avoid repeating work the next time.
As organisations grow, there’s an increasing chance that data somewhere within it is moving around over JMS. Getting this data out to a large number of users typically requires that Java clients are written and distributed to each of them. How do you go about exposing this data to web clients? Applets fell out of favour years ago, so you’re going to need another way.
We’ve tried to make this easy with Diffusion by creating a JMS adapter. In the trivial case, you modify a configuration file, add a jar file or two to your CLASSPATH and hey presto – messages are being pushed straight to your web page. In this example, you won’t have to write a single line of code.
Let’s take a quick look at how we can do this. First, I’ll assume you’ve got Diffusion 4.5 or later installed and a copy of Apache ActiveMQ. This will work just as well with other JMS providers but ActiveMQ is free and quick to set up. As I hinted at earlier, Diffusion needs jmsadapter.jar and the ActiveMQ libraries on its CLASSPATH. The simplest way to do this is to drop them into Diffusion’s ext directory where they’ll be automatically loaded when Diffusion starts, or you can modify the Diffusion startup script if you prefer. For ActiveMQ, you’ll need to locate a file such as activemq-all-5.7.0.jar and jmsadapter.jar can be found in Diffusion’s lib directory.
The adapter is implemented as a Diffusion publisher, so we need to enable it in etc/Publishers.xml. A clean Diffusion installation will already have a configuration defined but it’s commented out. We’ll remove the comments so it will be loaded when Diffusion is restarted.
<publisher name="JMSAdapter"> <class>com.pushtechnology.diffusion.adapters.jms.JMSAdapter</class> <enabled>true</enabled> <start>true</start> <property name="config.filename">../etc/JMSAdapter.xml</property> </publisher>
Next we have to edit etc/JMSAdapter.xml, but fortunately the values provided are mostly sane. If you haven’t configured ActiveMQ we can even remove the entries corresponding to security credentials but if we don’t, ActiveMQ won’t complain.
<?xml version="1.0" encoding="UTF-8" standalone="yes"?> <jms-config> <binding> <env> <property name="java.naming.factory.initial">org.apache.activemq.jndi.ActiveMQInitialContextFactory</property> <property name="java.naming.provider.url">tcp://localhost:61616</property> </env> <connection-factory name="ConnectionFactory"> <reconnect> <max-reconnections>10</max-reconnections> <interval>5000</interval> </reconnect> </connection-factory> <root-topic>jms/activemq</root-topic> <priority low="3" high="7" /> <queue-distribution-mode>SMALLEST_QUEUE</queue-distribution-mode> </binding> <mapping> <artefact-names jms=".$" diffusion="/~"/> </mapping> </jms-config>
And that’s pretty much all you need to do. If it’s not already running, start up ActiveMQ and Diffusion. All being well, you’ll see some lines in your Diffusion log file which look something like this:
2013-03-11 10:31:49.522 : INFO : Starting Publisher 'JMSAdapter' 2013-03-11 10:31:49.678 : INFO : Started Publisher 'JMSAdapter'
… and you’re ready to start exchanging messages with JMS!
What we’ve done here is set up a subscription to the JMS topic named MyTopic, but not much visibly happened as we haven’t sent a message into the JMS broker yet. Let’s do that now. In another browser window or tab, go to http://localhost:8161/admin/topics.jsp. In the list of topics, you should see MyTopic and a screen which looks similar to this:
Choose the “Send To” link, write something into the Message body and click “Send“.
Switch back to the Diffusion client and, all being well, the message should have been delivered:
What just happened?
Now the Diffusion topic exists, new clients subscribing to it will automatically receive an Initial Load message without having to go back to the JMS server. It follows from this that updates to the JMS topic automatically update the Diffusion topic and all subscribed clients receive delta messages from this point on.
We’ve now seen that without resorting to any coding, we’ve bridged messages from the world of JMS to a web-based client. In future posts, we’ll look at other examples; receiving from JMS queues, sending messages to JMS and more.