EJB 2 Message-Driven Beans

by Dion Almaer
05/22/2001

Working with the new Message Driven Beans and JMS

This article discusses the new EJB 2.0 Message Driven Beans. I walk through an example of using this new bean, along with the corresponding JMS infrastructure that surrounds it.

All of the code from this article should work with any EJB server that has support for Message Driven Beans (EJB 2.0 container); and you will need a messaging server that supports JMS to hold the queues. This article assumes that you know about Enterprise JavaBeans and their fundamentals.

The system that we will build in this article will be an email queuing system. The parts of the system are

• JMS Server: A JMS server will hold the message queue for our email system
• JMS Queue: A Queue will hold the JMS messages from the client. The messages on this queue will be MapMessages that will allow us to store name/value pair information about the email to be sent out
• Email Message Client: A client will create a JMS message, and put it on the JMS Queue. This message will hold the information for the email message to be sent out
• Email Message Driven Bean: A message driven bean will be responsible for taking in the JMS MapMessage and for mailing it out.

JMS Architecture

Before we can talk about Message Driven Beans, we need to talk about JMS, the Java Messaging Service. There are lots of messaging systems, each with its own API. Messaging systems provide a way to exchange events and data asynchronously. As a programmer, I can send some information to the messaging service and continue processing, without waiting for a response from the system. The JMS API describes a standard way to access any messaging system, just like JDBC allows me to talk to Oracle, Sybase, and SQL Server using the same API. As well as being able to call services asynchronously, we also have the added benefit of having a loose coupling between the code that originates the request, and the code that services the request. Different clients put messages onto a certain destination; and, separately, receivers take messages off the destination and deal with them.

Let's quickly go through some of the basics of the JMS APIs:

• Messaging Domains
• JMS Messages

Messaging Domains

Message systems have several models of operation. The JMS API provides separate domains that correspond to the different models. A JMS provider may implement one or more of the domains. The two most common domains are Point-to-Point and Publish/Subscribe. Both of the domains have the following concepts.

• Destination: the object a client uses to specify the target of messages it sends/receives
• Producer: a client that sends a message to a destination
• Consumer: a client that receives messages from a destination

Point-to-Point (PTP)

A point-to-point application has the following characteristics:

• A PTP producer is a sender
• A PTP consumer is a receiver
• A PTP destination is a queue
• A message can only be consumed by one receiver

For example, a call center application may use a PTP domain. A phone call enters the queue, and an operator takes care of that call. The phone call doesn't go to all of the operators, only one.

Publish/Subscribe (pub/sub)

A pub/sub application has the following characteristics:

A pub/sub producer is publisher

A pub/sub consumer is a subscriber

A pub/sub destination is a topic

A message may have multiple subscribers

For example, an email newsletter application may use a publish/subscribe model. Everyone who is interested in the newsletter becomes a subscriber, and when a new message is published (say the head of HR sends out new info), that message is sent to all subscribers.

Pages: 1, 2, 3

Next Page