EJB 3.0 in a nutshell

An overview and critical analysis of the latest EJB specification

By Anil Sharma, JavaWorld.com, 08/09/04

Despite several positives, the complexity of the Enterprise JavaBeans architecture is hindering the adoption of J2EE. The EJB architecture is probably the only J2EE component that has failed so miserably in delivering J2EE's promise of increased developer productivity thorough ease of development. EJB 3.0 makes another attempt at delivering that promise by reducing EJB's complexity for developers. EJB 3.0 decreases the number of programming artifacts for developers to provide, eliminates or minimizes callback methods required to be implemented, and reduces the complexity of the entity bean programming model and O/R mapping model.

In this article, I first cover the most significant changes in EJB 3.0. It's important to have the basics in place before diving into the EJB 3.0 pool. Next, I give a high-level view of the EJB 3.0 draft and then get into specifics of the proposed specification, paying attention to all changes one-by-one: impact on types of enterprise beans, O/R mapping model, entity-relationship model, EJB QL (EJB Query Language), etc.

Background

The two most significant changes in the proposed EJB 3.0 specification are the use of the program annotation facility introduced in Java 5 and the new O/R mapping model based on Hibernate.

Metadata facility in Java 5

Java 5 (previously called J2SE 1.5, or Tiger) has introduced a new program annotation facility to the language. With this facility, you can define custom annotations and then annotate fields, methods, classes, etc., with these annotations. Annotations do not directly affect program semantics, but tools (compile time or runtime) can inspect these annotations to generate additional constructs (like a deployment descriptor) or enforce desired runtime behavior (like an EJB component's stateful nature). Annotations can be inspected through source parsing (e.g., compilers or IDE tools) or by using the additional reflection APIs added in Java 5. Annotations can be defined to be available only at the source code level, at the compiled class level, or at runtime. All annotations proposed in the EJB 3.0 early draft have a RetentionPolicy of RUNTIME. This increases the class's memory footprint marginally, but makes the life of container provider and tool provider much easier.

Refer to Resources for further reading on this topic.

Hibernate

Hibernate is a popular, open source O/R mapping framework for Java environments, meant to shield developers from most common data-persistence-related programming tasks. It also has a specific Hibernate Query Language (HQL), imprints of which can be seen in the new EJB QL. Hibernate offers facilities for data retrieval and update, connection pooling, transaction management, declarative entity relationship management, and declarative and programmatic queries.

Bird's eye view

The changes in the proposed EJB 3.0 specification can be divided into two categories:

An annotation-based EJB programming model, in addition to the EJB 2.1 model of defining an application's behavior through deployment descriptors and several interfaces.
The new persistence model for entity beans. EJB QL has also changed significantly.

There are also several side effects to these proposals, like a new client-programming model, use of business interfaces, and an entity bean life cycle. Please note that the EJB 2.1 programming model (with deployment descriptors and home/remote interfaces) is still valid. The new simplified model does not entirely replace the EJB 2.1 model.

EJB annotations

One of the expert group's important goals is to reduce the number of artifacts a bean provider must provide, and the group has done a pretty neat job in reaching that goal. In the EJB 3.0 world, all kinds of enterprise beans are just plain old Java objects (POJO) with appropriate annotations. Annotations can be used to define the bean's business interface, O/R mapping information, resource references, and just about anything else that was defined through deployment descriptors or interfaces in EJB 2.1. Deployment descriptors are no longer required; the home interface is gone, and you don't necessarily have to implement a business interface (the container can generate it for you).

For example, you declare a stateless session bean by using the @Stateless annotation on the Java class. For stateful beans, the @Remove annotation is marked on a particular method to indicate that the bean instance should be removed after a call to the marked method completes.

To reduce the amount of information you must specify for a component, the expert group has adopted a configuration-by-exception approach, meaning you provide intuitive defaults for all annotations so that most of the common information can be inferred.

The new persistence model

The new entity beans are also just POJOs with a few annotations and are not persistent entities by birth. An entity instance becomes persistent once it is associated with an EntityManager and becomes part of a persistence context. A persistence context is loosely synonymous with a transaction context; in strict words, it implicitly coexists with a transaction's scope.

The entity relationships are also defined through annotations. In addition, O/R mapping is also done through annotations, and support for several database-specific operations is provided. With EJB 2.1, developers used their own design patterns or employed nonportable techniques (for example, auto key generation strategies).

Digging deep

It's now time to get into the specifics of proposals made in the EJB 3.0 early draft. Let's start with all four types of enterprise beans and then move on to the proposals generic to the whole of the EJB programming model.

Stateless session beans:

A stateless session bean (SLSB), written the EJB 3.0 way, is just a plain Java file with a class-level annotation of @Stateless. The bean class can implement the javax.ejb.SessionBean interface, but is not required to (and typically will not).

An SLSB doesn't have a home interface anymore—in fact, no EJB type requires it. The bean class may or may not implement a business interface. If it does not implement any business interfaces, a business interface will be generated using all the public methods. If only certain methods should be exposed in the business interface, all of those methods can be marked with the @BusinessMethod annotation. By default, all generated interfaces are local, but the @Remote annotation can be used to indicate that a remote interface should be generated.

1 | 2 | 3 | Next >

Discuss

Start a new discussion or jump into one of the threads below:

Subject	Replies	Last post
location of generated deployment descriptors By Nandakishore	0	11/30/06 12:45 AM by Nandakishore
isInverse=true By Anonymous	0	10/05/06 08:59 AM by Anonymous
EJB 3.0 new Path Finder By Jai Kumar	3	10/05/06 08:57 AM by Anonymous
prediction on where this will end up By tom-murphy	3	10/05/06 07:50 AM by SachinK
JDO ! By Tibo	3	10/05/06 07:50 AM by Anonymous
Ejb not needed in our life By gamol	7	10/05/06 07:49 AM by Anonymous
Entity Beans By Anonymous	2	10/05/06 04:27 AM by Anonymous
EJB 3.0 is the right direction. By Mohit Keswani	1	10/05/06 02:59 AM by Anonymous
Native SQL? Why? By mitko.p	3	10/04/06 08:05 AM by Anonymous
EJB Complexity By Anonymous	4	10/04/06 06:30 AM by Anonymous
Annotations OK, but depl.descr. still needed! By Hoffe	3	10/03/06 02:18 PM by Anonymous
Annotations vs XDoclet By Anonymous	12	03/01/06 08:38 PM by Anonymous