--Ads--

Message Driven Beans

Message driven beans are the light weight components used for communication. In message driven beans the messaging service is in asynchronous mode because the user is not intended to get the instant result. To understand the concept of message driven beans more clearly first we should go through the various concepts illustrated given below:

Techniques to implement messaging, message-oriented-middleware (MOM) and the asynchronous behavior.
Utilization of JMS, message-oriented-middleware to implement JMS based message-driven-beans.
Features and comparison of message-driven-beans with entity and session beans.
Techniques to develop message driven beans, including advanced topics like gotchas and possible actions.

Motivations for messaging: EJB components are used to develop the applications for the distributed computing network. Distributed computing network uses the RMI-IIOP protocol to communicate with each other. This protocol is used to call the EJB components. RMI-IIOP accepts challenges in several areas like:

Asynchrony: A typical RMI-IIOP client has to wait until the server completes its processing and returns the result to the client. After that the server enables to the client to continue its processing.
Decoupling: An RMI-IIOP server must have the knowledge about the server that it want to use. The client can address them directly through object references. It is not possible to remove a server from the server without directly impacting the clients because the client and server are closely coupled with each other.
Reliability: Data may be lost or the client can't perform any operation if the server or the network crashes.
Support for multiple senders and receivers: You can use messaging server instead of remote method invocation (RMI) but the messaging service uses the middleman between the client and the server. This middleman simply receives the messages from one or more senders and sends these messages to one or more consumers. It is not required to get the response instantly from the receiver. The receiver may sends back response back to the sender after completing all the processing. This is known as asynchronous programming.

There are four previous concerns that the messaging addresses with RMI-IIOP as follows:

Non blocking request processing: There is no need to block the messaging request while executing another request. For example suppose you are purchasing a book from Amazon.com having a single click functionality. you are enable to continue browsing the site without waiting to check the authorization of your credit card. Until and unless there is something wrong Amazon.com sends you a confirmation email. These types of systems are developed by using the messaging technique.

Decoupling: In case of message-oriented-middleware, it is not necessary for the sender to have the knowledge about the message receiver. It only interacts with the messaging system while sending messages. Thus the message senders are decoupled from consumers.

Reliability: Your message-oriented-middleware guarantees to send a message to its destination if the receiver is not temporarily available, simply by sending the message to the message-oriented-middleware which sends the message to the receiver when he is available. While it is not possible with RMI-IIOP protocol because there is no middleman in this case. If you send a message using the RMI-IIOP protocol and if server is down then it throws the exception.

Support for multiple senders and receivers: Most of the message-oriented-middleware supports this features i.e. receiving messages from multiple senders and can also broadcast them to many receivers.

Message-oriented-middleware is the term that can be given to any system that supports the messaging system. There are a number of products based on MOM architecture. BEA Tuxedo/Q, Sun Java System Messaging Server, IBM WebSphere MQ, Tibco Rendezevous, Microsoft MSMQ, FioranoMQ and Sonic Software SonicMQ are the examples of MOM based architecture.

Java Message Services (JMS): JMS API is an enterprise tool developed by Sun Microsystems used to develop the enterprise applications. JMS API supports to a framework that allows the development of portable and message based applications. JMS communicates in synchronous or in asynchronous mode by using point-to-point and the publish-subscribe models respectively. JMS has become vendor specific and many vendors such as IBM, Oracle, Hewlett-Packard, BEA Systems and Macromedia are providing the JMS implementation.

JMS API: JMS APIs play an important role as comparing the RMI-IIOP protocol. You need to aware with different interfaces, low level topology issues like structure, messaging format, networking protocol and server location.

Locate the JMS provider's ConnectionFactory instance: First establish the connection by using a ConnectionFactory instance to get access the JMS provider of the MOM product you are using. An administrator typically creates and configures the ConnectionFactory for the JMS client's use.
Create a JMS connection: A JMS connection manages the low level network communications similar to JDBC connection. Use ConnectionFactory to get a connection. For large deployment this connection may be load balance across a group of machines.
Create a JMS session: A JMS session object is used to send and receive the messages and works as the ConnectionFactory for message producers and message consumers. It also allows the encapsulation of messages in transactions. We use Connection to get the session object.
Locate the JMS Destination: A JMS destination is an object to which we are sending or from which we are receiving the messages. Locating the right destination is similar to tuning the channel in the right direction to get the clear picture while watching the television or answering the correct phone to get the desired message.
Create a JMS producer or a JMS consumer: If you are interested to send a message then you need an object to pass your message. This object is known as the JMS producer. If you want to receive a message you need to call a JMS object. This object is known as the Consumer object. To get hold an object Session and Destination are used.
Send or Receive a message: There may be different types of messages like text, streams, maps, bytes, objects and so on. To send a messages first instantiate it and then send it by using the Producer object. If you are intended to receive a message then first receive the message with the help of Consumer object and then crack it to see what it contains.

All the points described above are applicable to both point-to-point as well as publish/subscribe.

Here we are going to discuss JMS by taking the queuing system. Queuing system includes the following parts:

JMS Server: The JMS server maintains the message queue to receive emails.
JMS Queue: In case of point-to-point messaging system, a queue is used to hold the messages from clients. Messages holding this queue are of MapMessages type that stores the information about the email as name/value pair.
Email Message Client: A client of this messaging system creates the JMS message to put it on the JMS Queue. This message contains the information about the message to be sent out.
Email Message Driven Bean: It is the message driven bean that is responsible to take the JMS MapMessage to mail it out.

JMS Architecture: Talk first about JMS while talking about the message driven beans. There are a lot of messaging systems exist in the market. Messaging systems provide a mechanism to exchange data and events asynchronously. JMS API defines a standard way to access any messaging system such as JDBC that enables the user to talk to SQL Server, Oracle and Sybase simply by using the same API. The additional benefits of JMS API are loose coupling between the generated request and the code that services the request.

Here are some of the basics of the messaging server that one should know to more clearly understand the concept of JMS APIs:

Messaging Domains
JMS Messages

Messaging Domains: A messaging system includes several models of operation. JMS API provides separate domains corresponding to different models. JMS provider is free to implement one or more domains. Point-to-Point and Publish/Subscribe are the two most commonly used domains. These two domains concludes the following concepts.

Producer: The client, responsible for sending the message to the destination is known as the producer.
Consumer: The client, responsible for receiving the message is known as the consumer.
Destination: Destination is the object used by the client to specify the target that uses it to send the message to or to receive the message from.

Point-to-Point (PTP): An application that uses the point-to-point technique for messaging has the following characteristics.

A PTP producer is the sender.
A PTP consumer is the receiver.
PTP uses a queue as the destination.
A receiver can consume only a single message.

A call center application is the example of a PTP domain, where a phone call enters in the queue therefore only one operator takes care of this call rather than all of the operators.

Publish/Subscribe (pub/sub): An application that uses the pub/sub technique must include the following characteristics.

A pub/sub producer is the publisher
A pub/sub consumer is the subscriber
pub/sub uses the topic as the destination.
A message can have the multiple consumer.

An email newsletter application may use the pub/sub model, where an interested candidate may become the subscriber to receive a new published message.

Integrating JMS with EJB: Integration of JMS with EJB is the excellent idea because of it the EJB components gets benefit from the value proposed by messaging like multinary communications and non blocking clients. The idea behind the introduction of new type of bean is to consume messages in an EJB application.

Use a Java Object that receives the JMS messages to call an EJB client: Instead of developing the whole new bean the java community proposed an idea of object to receive a message and to call the appropriate EJB component such as the session bean or the entity bean. But the problems that come with this approach are:

You have to implement the multithreading concept just to increase the message consumption so that you can listen the messages in multiple threads. However developing the multithreaded application is not a tuff task for the developer.
Register yourself as a listener by writing the special code for JMS messages.
Hard code the JMS destination name in your java object that access the destination information required for extra effort to access the destination information from the dish like property files.
JMS message listener receives services from the EJB container just like a plain java object such as clustering, pooling, transaction, automatic life cycle management and many more. You need to hard code this yourself that is a tuff task and error prone.
Your java object is wrapped by other EJB components therefore it requires some way to start up. If the class is running inside the container then you are required to use a server specific startup class for the activation of the java object when the EJB server starts. This is not portable as the EJB container does not define an standard way to activate the given logic.

Reuse an existing type of EJB component somehow to receive JMS messages: Session beans or entity beans may receive messages but the problem with this approach is:

Life-cycle-management: The container doesn't know the way of creating a bean when a JMS message arrives.
Threading: EJB does not allow multithreading when a message arrives to the bean that is processing other request. If a bean is processing a request it does not take the new message arrive to the bean.

Message driven bean: Message driven beans are the special type of components that can receive the JMS as well as other type of messages. Message driven bean can also be used to receive the messages other than JMS. When a message is reached at the destination then the EJB container invokes the message driven bean. A message driven bean is decoupled with the client that sends the message. A client is not allowed to access the message driven bean through a business interface. The client can interact with the message driven bean only through the messaging system. To interact with the message driven bean use the message provider specific API such as JMS.

Message Driven Beans

Message Driven Beans

Message Driven Beans

Tutorials