Coming Back to POJOs

The new EJB 3.0 specification has a lot of changes that range from doing away with old complicated EJB architecture to annotations that make life simpler for Java EE developers

Wednesday, June 07, 2006

Print

Comment

Email

Digg

Del.icio.us

Reddit

Twitter

EJB 2.1 has been in wide use mainly because of the performance and scalability it provides. However, the fact is that it is very cumbersome and complex to write applications using it. For example, when writing a Web component or Web service, we had to line up repeated lines of code for binding the naming and similar procedures. Also, when creating beans, we had to implement a sea of interfaces. These issues lead to the gradual adoption of POJOs (Plain Old Java Objects) when coding beans in enterprise applications.

The EJB 3.0 Specification (or the JSR 220) introduces a simpler architecture for enterprise beans. The new specification, not surprisingly, makes use of POJOs and annotations to do away with implementing remote, local and home interfaces. Another big change from the previous specification is the omission of having to write deployment descriptors that were an integral part of an EJB 2.1 based bean. The new architecture allows developers to simply write source code using annotations and compiling it produces XML documents, the Local/Home/Remote interfaces and other classes. In this article we take a sneak-peak into the new architecture.

The basics
In contrast to earlier EJB specifications, enterprise beans in 3.0 are simple Java objects. This change translates into two major differences as we said earlier-the EJB 2.1 way of using deployment descriptors for defining an application with respect to behavioral aspects can be replaced with annotations. This does not mean that deployment descriptors no longer exist, but that annotations can be put to use in place of these descriptors. Or if required, you can go ahead with descriptors (you will need to figure out why you would do that) like old times.

The second difference is that implementations of remote/local and home/local interfaces are not required. The Entity Bean in the new specification is a non-abstract class containing implementations of the getter/setter methods in comparison to the abstract 'Entity Bean' that was being used earlier. Note that although the EJB 3.0 'Entity Bean' does not require component interfaces, it may implement a business interface. The use of annotations proliferates to more than just doing away with deployment descriptors.

In EJB 3.0, annotations can also be provided for dependencies and JNDI lookups, thus, simplifying the context-lookup coding. Other than this, annotations have also made their way into object-relational mappings in the new specification.

The new architecture allows developers to represent all information in the form of annotations, which are then used to extract descriptors and interfaces by the Container or the Processing Tool

Annotations 
Annotations are an integral part of the beans definition in the new speci- fication. Firstly, we have annotations to define whether the bean is an Entity or a Session bean. These are the '@Entity' and '@Stateless' or '@Stateful' annotations respectively. For Entity beans, the table name, column name and primary key column properties are also specified as metadata annotations. The '@Table' annotation specifies the table used for the entity bean's persistence.

The name of table is taken to be that of the bean if no name is specified using the name element. The '@Column' annotation specifies a column in the table corresponding to a bean property. The primary key is specified by the '@Id' annotation, whereas '@Transient' defines a non-persistent bean property.  Similarly, there are other annotations for Session beans also, such as '@Resource' that specifies the resources to look up to (ie, obtain the EntityManager in runtime and the '@Remote' annotation that specifies the remote interface).

Similarly, the QL (Query Language) queries have also been changed to make use of annotations. They were specified using the '' tag element in the ejb-jar deployment descriptor in the earlier architecture.

In 3.0, they are specified using '@NamedQuery' and '@NamedQueries'. The former represents a single query where as the latter represents a group of queries. For Container-Managed Relationships that were specified using the tag element in ejb-jar deployment descriptors, the new architecture has introduced four different annotations '@OneToMany', '@OneToOne', '@ManyToOne' and '@ManyToMany' for the four relationships.

Sample beans
A sample Entity bean in EJB 3.0 can be coded as follows.

@javax.persistence.Entity
public class NewEntity {
    private Long id;
public NewEntity() {
}
@javax.persistence.Id
@javax.persistence.GeneratedValue(strategy =  
javax.persistence.GenerationType.AUTO)
    public Long getId() {return id;}
    public void setId(Long id) {this.id = id;}
...}

The '@GeneratedValue' annotation provides for auto-generation of a unique ID, which is of type 'long' in our case. }

In conclusion
The new specification has certainly made changes for the better as far as enterprise beans are concerned.

Even the persistence model has been changed from a persistence-schema based abstract model to a more light-weight OR mapping, again using annotations. With each of these not tagged as mandatory in the architecture, we have room for interoperability as well.

Whether or not these changes help in increasing EJB adoption to a greater extent than it's current state is something that would become calculable with time.

Anadi Misra

Page(s)   1