iTechNote

I will be writing a series of articles related to EJB 3.0 in preparation for my SCBCD exam. The main objective is to keep updating the site while studying intensively for one month. The notes are prepared by reading through Enterprise JavaBeans 3.0, Fifth Edition by Bill Burke and Richard Monson-Haefel.

Entity Bean

In EJB 3.0, persistence has been spun off from EJB to its own specification called Java Persistence API. The API defines a way to map plain old Java objects (POJOs) to a database. These plain old Java objects are called entity beans.

The Java Persistence API also defines EJB QL that is tailored to work with Java objects rather than a raw relational schema. Entity beans are different from EJB session beans in that they are POJOs. They do not have a remote or local interface and can be accessed only as POJOs.

In order to “make” a POJO class as an entity bean class, you need to tag the class with @javax.persistence.Entity annotation and have at least one field or getter method that is designated as the primary key using @javax.persistence.Id annotation. All access to an entity goes through EntityManager persistence service that provides query API and life cycle methods.

Other annotations include:

• @javax.persistence.Table(name="table_name") - Specify the database table to which the entity will be mapped.
• @javax.persistence.Column(name="column_name) - getter methods of the persistent properties of the entity bean.
• @javax.persistence.GeneratedValue - Specify the container/database will generate the ID automatically

Entity beans are grouped into persistence unit which is stored in persistence.xml. Persistence unit is associated to a particular database so that persistence provider knows how to interact with it. It also has a EntityManager service so that it can be referenced in the application code.

Session Bean

The session bean is much more complicated than entity bean. It has a few interfaces listed as follow:

• @javax.ejb.Remote - Remote Interface, business methods that are accessible outside the EJB container via RMI-IIOP or any other distributed object protocol.
• @javax.ejb.Local - Local Interface, business methods that are accessible inside the EJB container.
• @javax.jws.WebService - Endpoint Interface, business methods that are accessible outside the EJB container via SOAP.

A session bean can have any combination of local, remote and endpoint interfaces. When a client interacts with these interfaces, the EJB container creates a proxy stub to monitor the interactions, apply security and engage in transactions as appropriate.

The EJB container handles these services based on defaults, annotations and/or XML deployment descriptors. For example, the default transaction type is REQUIRED and the default security semantics are UNCHECKED. Annotations can be used to change the default when it is not enough. For per deployment runtime configuration, the XML deployment descriptors is the way to go.

A session bean can be stateful (@javax.ejb.Stateful) or stateless (@javax.ejb.Stateless). The difference lies in whether the session bean maintains a conversational state. It is analogous to the difference between instance method and static method in POJOs.

Message-driven Bean

Message-driven bean is annotated with @javax.ejb.MessageDriven. Any EJB container must support JMS based message-driven beans which implement javax.jms.MessageListener interface. The onMessage() method is mandatory to implement as it is responsible handling asynchronous messages.

Message-drive beans do not implement remote, local or endpoint interfaces. The activity of message-driven bean is transient that is the same as session bean. They differ in how they are accessed.

Both session beans and message-driven beans have interface to their EJB container called bean-container contract. The contract provides callback methods, the EJBContext and JNDI environment naming context.