Programming message services in Java

Asynchronous interactions seem to be the way of the future

Deployment and execution

To deploy to JBoss, the ear file can be copied to the ${JBoss.home}/server/default/deploy directory and the JBoss server started. As JBoss starts up, it will discover the new jar file and deploy it automatically (which makes deploying to JBoss very easy). As the JBoss server is being started up, you should see messages telling you that it is deploying the new ear file and linking the MDB to the queue.

After the JBoss server has fully started up, you can start the client application. I ran the NewsClient form within the Eclipse IDE, specifying the j2ee.jar file of my Enterprise Java installation for the JMS classes and including a command line string to send to the MDB. In my case, this string was the message “Hello”.

The end result is that the string “Hello” is printed out in the JBoss console window, as illustrated below:

20:03:45,656 INFO  [Server] JBoss (MX MicroKernel) [4.2.1.GA (build: 
SVNTag=JBoss_4_2_1_GA date=200707131605)] Started in 52s:235ms 
20:04:43,468 INFO  [STDOUT] In the onMessage method(Hello)

There you have it; you’ve now stepped through and run a simple JMS based asynchronous application.

EJB3 versus old MDBs

It is interesting to compare this with what I would have had to define prior to EJB3. With older message driven beans I would have had to implement the javax.ejb.MessageDrivenBean interface as well as the MessageListener interface. It would also have been necessary to define any application server specific files used to define the destination type and destination of the queue.

For example, as well as the default ejb-jar.xml JAR file; with JBoss I would also have had to define a JBoss.xml file. The first file, the JAR file, would have been used to specify that this was a MDB and that it should be bound to a queue. The JBoss specific file would then have been used to bind the MDB to the appropriate queue (the queue/testQueue). The two files, as would be defined for EJB 2.0 are presented below.

The ejb-jar.xml file:

<ejb-jar>
    <enterprise-beans>
        <!-- Some descriptors omitted -->
        <message-driven>
            <ejb-name>DebugMonitor</ejb-name>
            <ejb-class>util.DebugMonitorBean</ejb-class>
            <message-selector>JMSType = ‘DEBUG’</message-selector>
            <transaction-type>Container</transaction-type>
            <acknowledge-mode>Auto-acknowledge</acknowledge-mode>
            <message-driven-destination>
               <destination-type>javax.jms.Queue</destination-type>
            </message-driven-destination>
         </message-driven>
    </enterprise-beans>
    <!-- Some descriptors omitted -->
</ejb-jar>

The JBoss.xml file

<?xml version="1.0"?>
<JBoss>
   <enterprise-beans>
       <!-- Some descriptors omitted -->
       <message-driven>
           <ejb-name>TestMonitor</ejb-name>
           <configuration-name>
              Standard Message Driven Bean
           </configuration-name>
           <destination-jndi-name>queue/queueTest</destination-jndi-name>
           <container-pool-conf>
              <MaximumSize>1</MaximumSize>
              <MinimumSize>1</MinimumSize>
           </container-pool-conf>
       </message-driven>
    </enterprise-beans>
</JBoss>

Conclusion

In this column, we’ve looked at how asynchronous applications can be defined using the JMS API. The example, although very simple, is essentially the same as used by any asynchronous JMS based applications. As you can see the actual implementation is very straight forward and particularly with EJB3, simple to implement. ®