The most common way to set up a JMS queue is to use an XML configuration file. This part of the exercise shows you how to write a JMX MBean definition for a new JMS queue. You can find the JMX configuration file in ex12_2/src/resources/services.

<server>
  <mbean code="org.jboss.mq.server.jmx.Queue"
         name="jboss.mq.destination:service=Queue,
               name=titan-ReservationQueue">
    <depends optional-attribute-name="DestinationManager"
     >jboss.mq:service=DestinationManager</depends>
  </mbean>
  
                     
                          <mbean code="org.jboss.mq.server.jmx.Queue"
         name="jboss.mq.destination:service=Queue,
               name=titan-TicketQueue">
    <depends optional-attribute-name="DestinationManager"
     >jboss.mq:service=DestinationManager</depends>
  </mbean>
</server>

Recall that each set of MBeans must be defined within a <server> tag and each MBean declared in an <mbean> tag. Because this exercise requires two different queues, we’ve defined two MBeans. The MBean class that represents a JMS queue is org.jboss.mq.server.jmx.Queue. Its name property specifies the name of the JMS queue to be created, such as titan-ReservationQueue and titan-TicketQueue.

Remember also that the application server must deploy the DestinationManager MBean before any queue or topic is deployed. This dependency is declared within the <depends> tag in jbossmq-titanqueues-service.xml. JBoss will take care of satisfying this dependency and make sure the titan-ReservationQueue and titan-TicketQueue will not be started until the DestinationManager MBean has finished initializing and is ready to provide services to new queues and topics. Copying this file into the JBoss deploy directory will hot-deploy these JMS queues and make them ready for use.

To deploy jbossmq-titanqueues-service.xml, run the make-queues Ant target:

C:workbookex12_2>ant make-queues
Buildfile: build.xml

make-queues:
     [copy] Copying 1 file to C:jboss-4.0serverdefaultdeploy

On the server side, the following lines are displayed:

[titan-ReservationQueue] Bound to JNDI name: queue/titan-ReservationQueue
[titan-TicketQueue] Bound to JNDI name: queue/titan-TicketQueue

Add each of the new JMS queues through the JMX HTTP connector the same way you added the JMS topic in the preceding exercise, with one obvious difference: instead of using the createTopic( ) operation of the JBossMQ server, use the createQueue( ) operation.

Remember that queues and topics created in the JMX HTTP Connector live only until the application server is shut down.

<message-driven>
  <ejb-name>ReservationProcessorEJB</ejb-name>
  <ejb-class
   >com.titan.reservationprocessor.ReservationProcessorBean<
  /ejb-class>
  <transaction-type>Container</transaction-type>
  <message-selector>MessageFormat = 'Version 3.4'</message-selector>
  <acknowledge-mode>auto-acknowledge</acknowledge-mode>       
  <message-driven-destination>
    <destination-type>javax.jms.Queue</destination-type>
  </message-driven-destination>

The MDB descriptor specifies container-managed transactions and automatic acknowledgement of messages, and that messages will be received from a queue rather than a topic. The descriptor also contains a <message-selector> tag that allows the MDB to receive only those messages that conform to a specified format. Then a set of <ejb-ref> entries identifies all the beans that ReservationProcessor beans will use during their execution:

  <ejb-ref>
    <ejb-ref-name>ejb/ProcessPaymentHomeRemote</ejb-ref-name>
    <ejb-ref-type>Session</ejb-ref-type>
    <home>
      com.titan.processpayment.ProcessPaymentHomeRemote
    </home>
    <remote>
      com.titan.processpayment.ProcessPaymentRemote
    </remote>
    <ejb-link>ProcessPaymentEJB</ejb-link>
  </ejb-ref>
  <ejb-ref>
    <ejb-ref-name>ejb/CustomerHomeRemote</ejb-ref-name>
    <ejb-ref-type>Entity</ejb-ref-type>
    <home>
        com.titan.customer.CustomerHomeRemote
    </home>
    <remote>com.titan.customer.CustomerRemote</remote>
    <ejb-link>CustomerEJB</ejb-link>
  </ejb-ref>
  <ejb-local-ref>
    <ejb-ref-name>ejb/CruiseHomeLocal</ejb-ref-name>
    <ejb-ref-type>Entity</ejb-ref-type>
    <local-home>
        com.titan.cruise.CruiseHomeLocal
    </local-home>
    <local>com.titan.cruise.CruiseLocal</local>
    <ejb-link>CruiseEJB</ejb-link>
  </ejb-local-ref>
  <ejb-local-ref>
    <ejb-ref-name>ejb/CabinHomeLocal</ejb-ref-name>
    <ejb-ref-type>Entity</ejb-ref-type>
    <local-home>
        com.titan.cabin.CabinHomeLocal
    </local-home>
    <local>com.titan.cabin.CabinLocal</local>
    <ejb-link>CabinEJB</ejb-link>
  </ejb-local-ref>
  <ejb-local-ref>
    <ejb-ref-name>ejb/ReservationHomeLocal</ejb-ref-name>
    <ejb-ref-type>Entity</ejb-ref-type>
    <local-home>
        com.titan.reservation.ReservationHomeLocal
    </local-home>
    <local>com.titan.reservation.ReservationLocal</local>
    <ejb-link>ReservationEJB</ejb-link>
  </ejb-local-ref>
  <security-identity>
    <run-as><role-name>everyone</role-name></run-as>
  </security-identity>

Because the MDB will send a confirmation message to a queue once the booking has been successful, it needs a reference to a javax.jms.QueueConnectionFactory, specified in the <resource-ref> at the end of the MDB descriptor:

  <resource-ref>
    <res-ref-name>jms/QueueFactory</res-ref-name>
    <res-type>javax.jms.QueueConnectionFactory</res-type>
    <res-auth>Container</res-auth>
  </resource-ref>
</message-driven>

Note this difference from the preceding exercise: while this bean does send messages to a queue, its descriptor does not contain a <resource-env-ref> entry that refers to the destination queue. Why not? In Exercise 12.1, the destination was fixed at deployment time, but in this exercise the destination is not fixed and not even known by the MDB. It is the client application that knows the destination, and transmits it to the MDB by serializing the JMS queue object as part of the JMS message.

<message-driven>
  <ejb-name>ReservationProcessorEJB</ejb-name>
  <destination-jndi-name
    >queue/titan-ReservationQueue<
    /destination-jndi-name>
  <resource-ref>
    <res-ref-name>jms/QueueFactory</res-ref-name>
    <jndi-name>java:/JmsXA</jndi-name>
  </resource-ref>
</message-driven>

The <destination-jndi-name> tag maps the MDB to an existing JMS destination in the deployment environment. You should recognize the name of one of the two JMS queues you just created: titan-ReservationQueue.

The <resource-ref> tag maps the ConnectionFactory name used by the ReservationProcessor EJB to an actual factory in the deployment environment. This mapping is identical to the one in the exercise for the TravelAgent EJB.

public static void main (String [] args) throws Exception
{
   if (args.length != 2)
      throw new Exception
   ("Usage: java JmsClient_ReservationProducer <CruiseID> <count>");
   
   Integer cruiseID = new Integer (args[0]);
   int count = new Integer (args[1]).intValue ( );

The producer then looks up a QueueConnectionFactory and two JMS queues from the JBoss naming service. The first queue is the one bound to the ReservationProcessor MDB, to which passage booking messages will be sent. The second is not used directly, as you’ll see later.

QueueConnectionFactory factory = (QueueConnectionFactory)
  jndiContext.lookup ("ConnectionFactory");
Queue reservationQueue = (Queue)
  jndiContext.lookup ("queue/titan-ReservationQueue");
Queue ticketQueue = (Queue)
  jndiContext.lookup ("queue/titan-TicketQueue");
QueueConnection connect = factory.createQueueConnection ( ); 
QueueSession session = connect.createQueueSession 
  (false,Session.AUTO_ACKNOWLEDGE);
QueueSender sender = session.createSender (reservationQueue);

The client application is now ready to send count booking messages in batch. Among other chores, it has looked up the ticket queue, the JMS queue that the ReservationProcessor MDB will use to send confirmation messages.

For each booking, it then creates a JMS MapMessage, assigns the ticket queue into the message’s JMSReplyTo property, and sets the booking data: Cruise ID, Customer ID, Cabin ID, price, credit card number, and expiration date, and so on. Note that only basic data types such as String and int can be stored in a MapMessage:

   for (int i = 0; i < count; i++)
   {
      MapMessage message = session.createMapMessage ( );
      
      // Used in ReservationProcessor to send Tickets back out
      message.setJMSReplyTo (ticketQueue);
      
      message.setStringProperty ("MessageFormat", "Version 3.4");
          
      message.setInt ("CruiseID", cruiseID.intValue ( ));
      // either Customer 1 or 2, all we've got in database
      message.setInt ("CustomerID", i%2 + 1);  
      // cabins 100-109 only
      message.setInt ("CabinID", i%10 + 100); 
      message.setDouble ("Price", (double)1000 + i);
      
      // the card expires in about 30 days
      Date expDate = new Date (System.currentTimeMillis ( ) + 
                              30*24*60*60*1000L);
      
      message.setString ("CreditCardNum", "5549861006051975");
      message.setLong ("CreditCardExpDate", expDate.getTime ( ));
      message.setString ("CreditCardType", 
                         CreditCardDO.MASTER_CARD);
      
      System.out.println ("Sending reservation message #" + i);
      sender.send (message);
   }
   
   connect.close ( );
}

One interesting property that’s set in the JMS message header is MessageFormat. Recall that the <message-selector> tag in the MDB deployment descriptor used this property to specify a constraint on the messages the MDB is to receive.

Once all messages are sent, the application closes the connection and terminates. Because messages are sent asynchronously, the application may terminate before the ReservationProcessor EJB has processed all of the messages in the batch.

The consumer application is very similar to the client application in Exercise 12.1. This time, though, it will subscribe not to a topic but to a queue.

To receive JMS messages, the client application class implements the javax.jms.MessageListener interface, which defines the onMessage( ) method. The main method simply creates an instance of the class and uses a trick to make the main thread wait indefinitely:

public class JmsClient_TicketConsumer
   implements javax.jms.MessageListener
{
   
   public static void main (String [] args) throws Exception
   {      
      new JmsClient_TicketConsumer ( );
      
      while(true) { Thread.sleep (10000); }
   }

The constructor is very simple JMS code that subscribes the client application to the JMS queue and waits for incoming messages:

 public JmsClient_TicketConsumer ( ) throws Exception
 {      
    Context jndiContext = getInitialContext ( );
      
    QueueConnectionFactory factory = (QueueConnectionFactory)
       jndiContext.lookup ("ConnectionFactory");
    Queue ticketQueue = (Queue)
       jndiContext.lookup ("queue/titan-TicketQueue");
    QueueConnection connect = factory.createQueueConnection ( );
    QueueSession session =
      connect.createQueueSession (false,Session.AUTO_ACKNOWLEDGE);
    QueueReceiver receiver = session.createReceiver (ticketQueue);
    receiver.setMessageListener (this);
      
    System.out.println ("Listening for messages on titan-
                         TicketQueue...");
    connect.start ( );
   }

When a message arrives in the queue, the consumer’s onMessage( ) method is called. The method simply displays the content of the ticket:

 public void onMessage (Message message)
 {      
    try
    {         
       ObjectMessage objMsg = (ObjectMessage)message;
       TicketDO ticket = (TicketDO)objMsg.getObject ( );
       System.out.println ("********************************");
       System.out.println (ticket);
       System.out.println ("********************************");
         
    }
    catch (JMSException displayed)
    {
       displayed.printStackTrace ( );
    }
 }