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.
src='/IMG/758/15758/outputfilejune2k6.jpg' width=350 border=0> |
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.
takeaways
The new architecture extends
Enterprise JavaBeans to also include the following new functionality and
simplifications to the earlier EJB APIs.
Developers no longer need to
specify common and expected behaviors or requirements when designing EJB
containers. You only need to specify what's uncommon
The requirements when using checked
exceptions are reduced
There is no need to implement
call-back interfaces
There is no need for Home
interfaces for Session beans
Entity bean persistence is now
simplified with support for lightweight domain-modeling, inheritance and
polymorphism
Session and message driven beans
can use interceptors
All required interfaces for
persistent entities have been eliminated
EJB QL has been enhanced to provide
more functionality-projection, explicit inner and outer joins, bulk updates and
deletes, sub-queries and 'group by'. You can also create dynamic queries as well
as use native SQL
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
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.
Source: PCQuest