Configuring the JMS Invokers

We didn't use messaging in the ToDo application, but messaging is an important part of many enterprise applications. JBoss supports JMS, the Java Message Service, and provides a fully spec-compliant JMS implementation, complete with invokers for accessing JMS destinations outside of the application server.

Fortunately, setting up JMS for production use is quite easy. You need to know only two things: whether your applications uses JMS, and whether external applications use your JMS. With those two pieces of information, you can configure the JMS invokers.

How do I do that?

All of the JMS services are configured under the deploy/jmsdirectory. If you aren't using JMS at all, all you need to do is delete the entire jmsdirectory. That will remove not only the JMS invokers, but also the entire JMS subsystem. If you aren't writing a messaging application, there's no need to take up valuable memory and processor time tending to those services.

JMS is common enough that we can't just leave it at that. If you do need to keep messaging around, you'll need to decide which JMS invokers to keep around.

The JMS invokers are the services in the jmsdirectory. The first is jvm-il-service.xml. This invocation layer is used only inside the application servers. It doesn't provide any access to the outside world, so don't worry about leaving it around.

Next is jbossmq-httpil.sar. This is the HTTP invoker for JMS. If you need external clients that tunnel over HTTP, this invoker will save your life. But you likely won't need it, so just remove this service and don't worry about it.

The last invoker is uil2-service.xml. If you are curious, that stands for unified invocation layer, version 2. This gives access to JBoss messaging queues. If you have no external clients accessing your destinations, you can safely remove the service. Otherwise, you'll have to leave it and make sure your destinations are properly secured.

Destinations are configured in jbossmq-destinations.xml in deploy/jms. Here's the configuration for a topic:

     <mbean code="org.jboss.mq.server.jmx.Topic"              name="jboss.mq.destination:service=Topic,name=testTopic">         <depends optional-attribute-name="DestinationManager">             jboss.mq:service=DestinationManager         </depends>         <depends optional-attribute-name="SecurityManager">             jboss.mq:service=SecurityManager         </depends>         <attribute name="SecurityConf">             <security>                 <role name="guest"    read="true" write="true"/>                 <role name="publisher"    read="true" write="true"                                            create="false"/>                 <role name="durpublisher" read="true" write="true"                                            create="true"/>             </security>         </attribute>       </mbean> 

The SecurityConf attribute defines the permissions for each logical role you are interested in. The read and write permissions correspond to the ability to read messages from and send messages to a destination. The create permission is the ability to create a durable subscription to a destination.

The SecurityManager attribute links to the security interceptor defined in jbossmq-service:

     <mbean code="org.jboss.mq.security.SecurityManager"            name="jboss.mq:service=SecurityManager">         <attribute name="DefaultSecurityConfig">             <security>                 <role name="guest" read="true" write="true" create="true"/>             </security>         </attribute>         <attribute name="SecurityDomain">java:/jaas/jbossmq</attribute>         <depends optional-attribute-name="NextInterceptor">             jboss.mq:service=DestinationManager         </depends>     </mbean> 

The security manager defines both the default security configuration, if one isn't defined on the destination in jbossmq-destinations.xml, and the security domain to be used to verify JMS permissions. java:/jaas/jbossmq is already defined in login-config.xml:

     <application-policy name="jbossmq">         <authentication>             <login-module                 code="org.jboss.security.auth.spi.DatabaseServerLoginModule"                flag="required">                 <module-option name="unauthenticatedIdentity">                    guest                 </module-option>                 <module-option name="dsJndiName">java:/DefaultDS</module-option>                 <module-option name="principalsQuery">                     SELECT PASSWD FROM JMS_USERS WHERE USERID=?                 </module-option>                 <module-option name="rolesQuery">                     SELECT ROLEID, 'Roles' FROM JMS_ROLES WHERE USERID=?                 </module-option>             </login-module>         </authentication>     </application-policy> 

This is a standard DatabaseServerLoginModule. You saw how to configure it in Chapter 5. What's interesting about this configuration is the use of the unauthenticatedIdentity option. This says to assign unauthenticated users the guest role. When it's combined with the DefaultSecurityConf of the JMS security manager, anyone can access your JMS destinations. You'll want to remove the permissions for the guest role if you have remote access into JMS.

What just happened?

You saw the necessary steps to configure JMS in a production system. If you weren't using a service, you removed it completely. Otherwise, you had to choose which of the three invokers you needed. To allow remote JMS clients, you had to keep the UIL2 service, which required you to pay careful attention to the security configuration.