The first five recipes are point-to-point applications. They represent a simple type of point-to-point application as there is only one producer of information, a servlet, and only a single consumer, the MDB. In this recipe, we will further develop this type of application by reusing the ObjectMessageApplication developed in the previous recipe.
Make sure you are familiar with the ObjectMessageApplication. We will add a minimal amount of code to illustrate variations of the point-to-point application architecture. This type of application is sometimes referred to as a producer-consumer application. One or more producers will generate messages which are placed in a queue. One or more consumers will retrieve and process the messages.
In the figure that follows, one or more producers will create items such as a purchase order and place them in a queue. At a later time, one or more consumers may pull an item off of the queue and process it. This decouples the production and consumption of items and can result in performance enhancements.
The ObjectMessageApplication creates an order that is placed in a queue. More than one servlet, or other types of client, can generate an order. A single MDB will handle only a single request at a time. However, with multiple MDBs available in the container, multiple messages can be consumed concurrently.
A variation of this architecture is where an MDB consumes and sends messages to the queue. For example, the OrderBean may receive an order and based on factors, such as the customer's purchase history, decide to provide an additional "bonus" order as thanks for their patronage. The MDB may then place an additional order as a bonus and add this new order to the queue.
The following is a modified version of the OrderBean. The @Resource annotations have been added as instance variables to permit the MDB to send messages to the queue. The onMessage method has been modified to send a message to the queue under certain circumstances.
@MessageDriven(mappedName = "jms/OrderQueue", activationConfig = {
@ActivationConfigProperty(propertyName = "acknowledgeMode", propertyValue = "Auto-acknowledge"),
@ActivationConfigProperty(propertyName = "destinationType", propertyValue = "javax.jms.Queue")
})
public class OrderBean implements MessageListener {
// These declarations are used to send out a thank you order
@Resource(mappedName="jms/OrderFactoryPool")
private QueueConnectionFactory queueConnectionFactory;
@Resource(mappedName="jms/OrderQueue")
private Queue queue;
public OrderBean() {
}
@Override
public void onMessage(Message message) {
try {
ObjectMessage objectMessage = (ObjectMessage) message;
Order order = (Order)objectMessage.getObject();
System.out.println("Part Number: " + order.getPartNumber());
System.out.println("Weight: " + order.getWeight());
System.out.println("Quantity: " + order.getQuantity());
System.out.println("Order Received");
// Send out a thank you order
if(order.getQuantity() > 40) {
Connection connection;
try {
Message-Driven Bean (MDB)using, in point-to-point applicationconnection = queueConnectionFactory.createConnection();
Session session = connection.createSession(false, Session.AUTO_ACKNOWLEDGE);
MessageProducer messageProducer = (MessageProducer) session.createProducer(queue);
objectMessage = session.createObjectMessage();
objectMessage.setObject(new Order(54321,5.5f,1));
messageProducer.send(objectMessage);
System.out.println("---> Thank you order sent ");
} catch (JMSException ex) {
Logger.getLogger(OrderBean.class.getName()). log(Level.SEVERE, null, ex);
}
}
} catch (JMSException ex) {
Logger.getLogger(OrderBean.class.getName()).log(Level.SEVERE, null, ex);
}
}
}
Execute the application and observe that the order has been placed from the MDB.
INFO: ---> Thank you order sent
INFO: Part Number: 54321
INFO: Weight: 5.5
INFO: Quantity: 1
To send a message from an MDB we use essentially the same code as that found in the servlet. The @Resource annotations have been added to allow us to send a message.
A test was made in the onMessage method to determine if the bonus order should be placed. This was accomplished by determining if the order's quantity was greater than 40. If this was the case, then a new connection and message was created and sent to the queue.
Another version of the architecture uses more than one queue. In some situations the consumer of the message may need to validate or otherwise process the order. Once the validation is complete, then it is sent to a second queue. Messages from the second queue are consumed by another MDB that may actually place the order. The figure below illustrates this process.
The advantage of this approach is that the number of MDBs required to perform the validation versus the order placement can be controlled and administered separately. The time it takes to validate an order can be more or less than it takes to place the order. Splitting the work across multiple queues and MDBs provides more flexibility in administrating the overall application.