Advertisment

Coding made simple with EJB 3.0

author-image
CIOL Bureau
Updated On
New Update

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.

































Direct

Hit!
Applies to: Java

EE developers
USP: Explore the

new ways to develop enterprise applications with Java EE using EJB

3.0
Links: href="http://java.sun.com/products/ejb/docs.html">http://java.sun.com/products/ejb/docs.html 
Google keywords:

ejb 3.0


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.



border=0>





EJB 3.0

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 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.

Source: PCQuest

tech-news