Configuring the messaging system in JBoss

Message oriented middleware has been an integral part of the application server, since the first releases of the application server. Messaging systems allow you to loosely couple heterogeneous systems together, whilst typically providing reliability, transactions, and many other features.

Note

In the current release of the application server (7.0.2), the messaging subsystem is included in a separate configuration file named standalone-preview.xml. Starting from the release 7.1.0 of the application server, the messaging sub-system will be included in the configuration file named standalone-full.xml.

Messaging systems normally support two main styles of asynchronous messaging: Queue messaging (also known as point-to-point messaging ) and Publish-Subscribe messaging .

In the point-to-point model, a sender posts messages to a particular queue and a receiver reads messages from the queue. Here, the sender knows the destination of the message and posts the message directly to the receiver’s queue.

On the other hand, the publish/subscribe model supports publishing messages to a particular message topic. Subscribers may register interest in receiving messages on a particular message topic. In this model, neither the publisher nor the subscriber know about each other.

The following table shows the characteristics of the two different paradigms:

JBoss AS has used different JMS implementations across its releases. Since release 6.0, the default JMS provider is HornetQ (HTTP://WWW.JBOSS.ORG/HORNETQ), which provides a multi-protocol, embeddable, very high performance, clustered, asynchronous messaging system.

Note

At its core, HornetQ is designed simply as set of Plain Old Java Objects (POJOs), with few dependencies on external jars. In fact, the only one jar dependency is the Netty library which leverages the Java New Input-Output (NIO) API for building high-performance network applications.

Frequently asked Jboss Interview Questions

Because of its easily-adaptable architecture, HornetQ can be embedded in your own project, or instantiated in any dependency injection framework, such as JBoss Microcontainer, Spring, or Google Guice. In this book, we will cover the scenario where HornetQ is integrated into JBoss AS subsystem as a module. The following image shows how the HornetQ server fits in the overall picture:

As you can see, a key part of the HornetQ integration is the JCA Adaptor that handles the communication between the application server and the HornetQ Server.

Tip

Why we cannot simply connect your resources (say your EJB) to HornetQ server?

This is theoretically possible, however, it violates Java EE specifications and will cause the loss of many benefits. As a matter of fact, the application server’s JCA layer provides extra functionality, such as connection pooling and automatic transaction enlistment, which are desirable when using messaging, say, from inside an EJB. For a description of JCA Thread pooling configuration, refer to the section of this chapter named Bounded Thread pool.