Introduction to POJO (Plain Old Java Object) Programming Model
One of the new features of added by Sun Microsystems in EJB 3.0 is POJO (Plain Old Java Object). It is a Java object that doesn't extend or implement some specialized classes and interfaces respectively require by the EJB framework. Therefore, all normal Java objects are POJOís only. The following classes are not POJO classes shown as:
In POJO model, it is recommended that, interfaces should be explicitly implemented whenever you want to pick and choose the methods of the interface. The interfaces are optional for entity beans but required for session beans and message-driven beans. In this model, both the interface and the bean class do not have to throw unnecessary exceptions such as RemoteException.
The interface class in POJO model is a Plain Old Java Interface (POJI).
The Benefits of POJOs:
Decoupling: It decouples the application components
from the infrastructure of the EJB framework that lets you construct an
application from loosely coupled components. There are no longer need to write
the tedious JNDI framework-specific lookup code. You can design and implement
the business logic. Once that's working, and then you can deal with persistence
Easier testing: You can test or run your business
logic outside of the application server in a few seconds.
The POJO technology can be used with any type of
Enterprise Java Beans(e.g Session Bean, Message Driven Bean or Entity Bean).
The POJO technology can be used with any type of Enterprise Java Beans(e.g Session Bean, Message Driven Bean or Entity Bean).
Letís understand the POJO with Message Driven Bean:
Message Driven POJOs:
Message-driven POJOs offer the functionality like MDB to make a simple JavaBeans for the developers. Similar to a MDB in EJB, it acts as a receiver for JMS messages.
Writing a message-driven POJO is not much different than writing a
message-driven EJB. The major difference between both is that, an message-driven
POJO (MDP) must
implement the javax.jms.MessageListener interface. Like an MDB, you don't have to implement
javax.ejb.MessageDrivenBean and the EJB lifecycle methods defined by the interface.
In EJB 3.0ís container application server, there is an easier way to implement message driven RPCs. You can use POJOs as message end-points (message driven POJO). The RPC caller retrieves an automatically generated stub of the POJO and makes regular calls against the POJO methods. The message driven POJO works much like a session bean of EJB3, except that all calls are tunneled via a message queue.
Letís see the structure of Message Driven POJO given below:
see how message driven POJO is used in EJB3 taking an example.
In our sample
application, the class MessagePojoClient.java asynchronously invokes the onMessage
method to display a simple ďHello...Ē message on a message driven POJO over
a message queue. After the message driven POJO finishes the display task, it
saves the result in a server wide cache manager.
The POJO business interface:
In our example, we are using the javax.jms.MessageListener
interface, so we donít need to define it again. You can also define new
interface using @producer annotation to implement specific methods.
The message driven POJO implementation:
The implementation of the message driven POJO is tagged with the @Consumer annotation. You can specify the message queue property in the annotation attribute. If a message queue is un-defined, the EJB container will create one for you at server start-up.
The code for MDP is given below:
Note that, here we didnít use @MessageDriven annotation to map the JNDI name.
use the message driven POJO on the client side, client looks up a stub object of
interface from the JNDI. The auto-generated stub-object not only implements the
@Producer interface but also a component interface named ProducerObject. Using the
method, you can get a ProducerManager object, which is used to make JMS connections. After a JMS connection is
established, you can call any method in the
Description of Code:
When the EJB3 container deploys the @Consumer, it looks
for all of its implemented interfaces and registers each one of them in JNDI
under. The client code above looks up the MessageListener interface in
JNDI. Each producer implements the ProducerObject. The client typecasts
the MessageListener to the ProducerObject. It then gets a ProducerManager
that manages the JMS connection for this proxy. To start being able to send
messages to the Queue, the client calls Connect( ) method on the manager.
It then can successfully call methods on the "msglst" object.
This method called onMessage( ) is
converted into a JMS message and published to the Queue of the Consumer. The
consumer will receive the message and invoke its onMessage method.
There are a variety of ways to send a JMS message such as using JmsTemplate or Spring. Letís see the configuration of the message listener containers that ships with Spring.
Deploy and Run the MDP Application: