JBoss Messaging Providers
JBossMQ (JBoss 4.x, JMS 1.0 compatible) ->
JBoss Messaging (JBoss EAP 5.x, JMS 1.0 and 1.1 compatible) ->
HornetQ (JBoss EAP 6.x, JMS 1.1 compatible) ->
Apache ActiveMQ (JBoss EAP 7.x, JMS 2.0 compatible)
Reference to the latest document
JBoss EAP 7.0 JMS (and other) Examples
Download JBoss quickstarts/helloworld examples
JBoss EAP 7.0 JMS to ActiveMQ mapping
The core ActiveMQ Artemis is JMS-agnostic and provides a non-JMS API, which is referred to as the core API.
ActiveMQ Artemis also provides a JMS client API which uses a facade layer to implement the JMS semantics on top of the core API.
JBoss EAP 7.0 Apache ActiveMQ Artemis Core API and JMS Destinations
Let’s quickly discuss how JMS destinations are mapped to Apache ActiveMQ Artemis addresses.
Apache ActiveMQ Artemis core is JMS-agnostic. It does not have any concept of a JMS topic. A JMS topic is implemented in core as an address (the topic name) with zero or more queues bound to it. Each queue bound to that address represents a topic subscription. Likewise, a JMS queue is implemented as an address (the JMS queue name) with one single queue bound to it which represents the JMS queue.
By convention, all JMS queues map to core queues where the core queue name has the string "jms.queue." prepended to it. E.g. the JMS queue with the name "orders.europe" would map to the core queue with the name "jms.queue.orders.europe". The address at which the core queue is bound is also given by the core queue name.
For JMS topics the address at which the queues that represent the subscriptions are bound is given by prepending the string "jms.topic." to the name of the JMS topic. E.g. the JMS topic with name "news.europe" would map to the core address "jms.topic.news.europe"
In other words if you send a JMS message to a JMS queue with name "orders.europe" it will get routed on the server to any core queues bound to the address "jms.queue.orders.europe". If you send a JMS message to a JMS topic with name "news.europe" it will get routed on the server to any core queues bound to the address "jms.topic.news.europe".
If you want to configure settings for a JMS Queue with the name "orders.europe", you need to configure the corresponding core queue "jms.queue.orders.europe".
JBoss EAP 5.x Messaging
The ServerPeer is the heart of the JBoss Messaging JMS facade. You can configure its behavior by altering $JBOSS_HOME/server/$PROFILE/deploy/messaging/messaging-service.xml.
All JBoss Messaging services are based in the ServerPeer.
JMS uses the database defined in jboss-as/server/$PROFILE/deploy/messaging/<DATABASE_TYPE>-persistence-service.xml as a persistence storage. The default persistence storage type is Hypersonic (HSQLDB) defined in hsqldb-persistence-service.xml. Note that the configuration is defined for a clustered environment (<attribute name="Clustered">true</attribute>).
Persistence Manager, Post Office and JMS User Manager
The Persistence Manager, Post Office and JMS User Manager all interact with persistent storage. All configuration for these managed beans is handled in the <your database type>-persistence-service.xml file.
JBoss Messaging ships with a JDBC Persistence Manager, which handles message data persistence in a relational database accessed via JDBC. The Persistence Manager can be plugged into the Messaging server, which allows additional implementations to persist message data in non-relational stores, and file stores.
Persistent service configuration details are grouped in <database type>-persistence-service.xml. JBoss Messaging ships with the hsqldb-persistence-service.xml file by default, which configures the Messaging server to use the Hypersonic database instance included by default with any JBoss Enterprise Application Server instance.
JBoss Messaging also ships with Persistence Manager configurations for MySQL, Oracle, PostgreSQL, Sybase, Microsoft SQL Server, and DB2. The example configuration files (such as mysql-persistence-service.xml and ndb-persistence-service.xml) are available from the jboss-as/docs/examples/jms directory of the release bundle.
The JDBC Persistence Manager uses standard SQL as its Data Manipulation Language (DML), so writing a Persistence Manager configuration for another database type is a matter of changing the configuration's Data Definition Language (DDL), which usually differs on a per-database basis.
JBoss Messaging also ships with a Null Persistence Manager configuration option, which can be used when persistence is not required.
The Post Office handles binding related persistence. The post office routes messages to their destination or destinations. It maintains the mappings between the addresses to which a message can be sent, and the final queue. For example, when sending a message with an address that represents a JMS queue, the post office routes the message to that JMS queue. When sending a message with an address that represents a JMS topic, the post office routes the message to a set of queues — one for each JMS subscription.
The post office also handles the persistence for address mapping.
JBoss Messaging post offices are cluster-aware. In a cluster, they automatically route (push) and pull messages between nodes in order to provide fully-distributed JMS queues and topics.
JMS User Manager
The JMS User Manager handles user-related persistence.
The JMS User Manager maps pre-configured client IDs to users. It also manages user and role tables, depending on the configured login module.
JBoss Messaging ships with a default set of preconfigured destinations that are deployed at server start-up. The configuration information for these destinations can be found in the following section of jboss-as/server/$PROFILE/deploy/messaging/destinations-service.xml:
To create a new destination (queue or topic, here using queue as an example), edit /jboss-as/server/$PROFILE/deploy/messaging/destinations-service.xml and add the following within the <server> element:
Configuring Connection Factories
JBoss Messaging is configured by default to bind two connection factories in JNDI upon start up.
The first connection factory is the default, non-clustered connection factory. This connection factory is provided to maintain compatibility with applications originally written against JBossMQ, which does not include automatic failover or load balancing. If you do not require client-side automatic failover or load balancing, then you should use this first connection factory.
The first connection factory is bound into the following JNDI contexts:
The second connection factory is the default clustered connection factory, which is bound into the following JNDI contexts:
If you want to provide a default client ID for a connection factory, or bind a connection factory to a different JNDI locationConsider, then configure and deploy additional connection factories. To deploy a new connection factory, configure a new ConnectionFactory managed bean in connection-factories-service.xml.
You can also create a new service deployment descriptor, <name>-service.xml, and deploy it in $JBOSS_HOME/server/messaging/deploy.
Configuring Remoting Connector
JBoss Messaging uses JBoss Remoting for all communication between the client and the server.
For more information about JBoss Remoting configuration and capabilities, refer to the Remoting chapter in the Administration and Configuration Guide.
The default configuration includes one remoting connector, which is used by the single default connection factory. Each connection factory can be configured to use a different connector.
The default connector is configured to use the remoting bisocket transport, a TCP socket-based transport that listens and accepts connections only on the server side. That is, connections are always initiated from the client side. This connector is ideal for typical firewall scenarios, where only inbound connections are allowed on the server, or where only outbound connections are allowed from the client.
The bisocket transport can be configured to use SSL when a higher level of security is required.
The other supported transport is the HTTP transport, which uses the Hypertext Transfer Protocol to communicate between client and server. The client periodically polls the server for messages to receive data. This transport is ideal when a firewall between server and client allows only incoming HTTP traffic on the server. Because of its polling behavior and the limitations of HTTP, this transport does not perform as well as the bisocket transport. It is not designed to handle high-load situations.
No other remoting transports are currently supported by JBoss Messaging.
Remoting configuration details can be seen in $JBOSS_HOME/server/$SERVER/deploy/messaging/remoting-bisocket-service.xml.
The default bisocket transport port is 4457:
<!-- There should be no reason to change these parameters - warning!
Changing them may stop JBoss Messaging working correctly -->
<attribute name="marshaller" isParam="true">org.jboss.jms.wireformat.JMSWireFormat</attribute>
<attribute name="unmarshaller" isParam="true">org.jboss.jms.wireformat.JMSWireFormat</attribute>
<attribute name="dataType" isParam="true">jms</attribute>
<attribute name="socket.check_connection" isParam="true">false</attribute>
<attribute name="clientSocketClass" isParam="true">org.jboss.jms.client.remoting.ClientSocketWrapper</attribute>
The default JNDI port is 1099 (1099+100=1199 if you specify -Djboss.service.binding.set=ports-01 when starting jboss):
<td>Port:</td><td><input type="text" name="port" value="1099" size="40"></td>
Here is usually how a JMS client should be configured to connect to JBoss Messaging as JMS server:
# The URL of the JNDI provider
# The Java naming package
# The Java naming factory class
# The JNDI name of the connection factory
# The JNDI name of the JMS queue