Table of Contents
Many applications use the Java Message Service for asynchronous messaging. Geronimo includes a JMS server, and application components can access JMS resources including connection factories, topics, and queues from the JMS server. When mapped as application resources, these JMS objects can be accessed from:
EJBs
Web Applications
Client Applications
JMS resource groups may be configured at the server level, at the application level, or a part of a single application client module. The default visibility can be summarized like this:
Table 7.1. JMS Resource Groups: Default Visibility
Resource Group Type | Multiple Applications | Multiple Modules in Same Application | Client Module Only |
---|---|---|---|
Server-Wide | yes | yes | no |
Application-Scoped | no | yes | no |
Client-Scoped | no | no | yes |
This chapter covers configuring JMS resource groups in each of these ways. We'll also look at customizing the embedded ActiveMQ JMS server, though that's not normally necessary.
Note | |
---|---|
Client-scoped and application-scoped resource are started and stopped with the owning application or module, and the default reference mapping strategies ignore resources deployed in other applications. However, this is not a security feature; it's always possible to manually construct a reference to any resource running in the server (no matter what its default visibility is). |
There are two aspects to JMS in Geronimo: the JMS Server itself (also known as the Message Broker), and the connection factories, topics, and queues through which individual application components communicate with the message broker. The ActiveMQ message broker is started by default in Geronimo, and usually does not need to be changed. JMS connection factories and destinations are bundled into JMS Resource Groups which can be individually deployed into Geronimo. Under the covers, JMS resource groups are configured as J2EE Connectors, and the default JMS resource groups connect to the embedded ActiveMQ server, so the J2EE Connector used to deploy JMS connection factories and destinations is known as the ActiveMQ RAR.
Tip | |
---|---|
If you deploy JMS Resource Groups through the Geronimo console, you won't have to worry about the details of the RAR file and deployment plan. The console can only deploy server-wide resource groups, though you can use it to write a plan for an application-scoped or client-scoped resource group. |
With that in mind, there are several steps to deploying JMS resources:
Ensure an ActiveMQ message broker is running in the server (the default configuration for it is geronimo/activemq-broker/1.0/car).
Write the RAR deployment plan for the JMS resources
Deploy JMS resources using the ActiveMQ RAR
Configure application components to refer to those JMS resources
Write code that accesses JMS resources in JNDI and configures properties such as persistence and transactions before sending or receiving messages.
When you deploy a server-wide resource group, you'll give the customized deployment descriptor and the ActiveMQ RAR to the deploy tool, and it will deploy the new resource group as it would any other standalone J2EE Connector. When you deploy an application-scoped JMS resource group, you'll include the TranQL RAR in the application EAR like any other application module, and add the customized deployment descriptor to the EAR as well. When you deploy a client-scoped resource group, you'll use a shortcut in the client module's Geronimo-specific deployment descriptor that allows you to configure a J2EE Connector right there, for that module alone. In any of those cases the ActiveMQ RAR is the same and the configuration file format is the same; it's just the method of deployment that's different.