Coming Back to POJOs

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