Enterprise JavaBean (EJB) 3.0 new Experience

The long-awaited EJB3.0 specification had recently released its first draft. A brief overview of the new specification is presented in this article, including new metadata support, EJBQL modifications, the entity Bean Model's access to the bean context and the run-time environment, and so on. The author also discusses the future adjustment of EJB and the relationship between EJB3.0 and other development specifications.

Begin

In any case, because of the complexity of EJB, the performance in the Java EE architecture has not been very good. EJB is probably the only organization in the Java EE architecture that has not honoured its ability to simply develop and increase productivity. The EJB3.0 specification is trying to make efforts in this area to mitigate the complexity of its development. EJB3.0 eases the developer's effort to lower the underlying development, eliminating or minimizing the implementation of a number of callback methods that previously had to be implemented, and reducing the complexity of the entity bean and the O/R mapping model.

In this article, I will first introduce some of the major changes in EJB3.0. It is very important for further insight into EJB3.0. Later, I will describe the details that have been submitted to the EJB3.0 specification from a higher level and explain the changes in the new specification: Entity BEAN,O/R mapping Model, Entity Relational model and EJB QL (EJB Query Language), and so on.

Background

Two important changes in EJB3.0 are: Using the program annotation tool in Java5 and the O/R mapping model based on hibernate.

Meta-data tools in JAVA5

A new program annotation tool has been added to Java5 (formerly known as j2se1.5 or Tiger). With this tool you can customize the annotation tags to annotate fields, methods, classes, and so on by using these custom tags. These annotations do not affect the semantics of the program, but they can be interpreted using tools (compile-time or runtime) to produce additional content (such as a deployment profile), or to force certain run-time behaviors (such as the state attributes of an EJB component). Annotations can be parsed through source file parsing (such as compilers or the IDE tool) or by using the APIs reflection mechanism in JAVA5. Annotations can only be defined at the source code level. Because all annotation tokens submitted to the EJB3.0 draft have a run-time retentionpolicy, they increase the amount of storage space occupied by the class file, which is convenient for container manufacturers and tool manufacturers.

Hibernate

Currently hibernate is very popular, it is the development of the source code Java O/R mapping framework, the purpose is to get developers from tedious data persistence programming free. It also has a standard HQL (Hibernate query Language) language, and you can see its shadow in the new EJB QL. Hibernate is very simple in processing such as data query, update, connection pooling, transaction processing, Entity relationship processing and so on.

Overview
　　
There are two major changes in the EJB3.0 specification that have been submitted:

1. A set of annotated EJB programming models coupled with application behavior defined by the deployment descriptor and several interfaces defined in EJB2.1.

2. The new entity bean Persistence model, EJBQL also has a number of important changes.

There are also some suggestions for the above, such as a new client-side programming model, the use of business interfaces, and the lifecycle of entity beans. Note that the EJB2.1 programming model, including deployment descriptors and Home/remote interfaces, is still valid. The new simplified model does not completely replace the EJB2.1 model.

EJB annotations

An important goal of the EJB specification organization is to reduce the number of original code, and they provide a perfect and concise approach to this. In EJB3.0, any type of enterprise bean is simply a simple Java object (POJO) with the appropriate annotations. Annotations can be used to define a bean's business interface, O/R mapping information, resource reference information, and the effect is the same as defining a deployment descriptor and interface in EJB2.1. Deploying descriptors in EJB3.0 is no longer necessary; The home interface is gone and you don't have to implement a business interface (the container can do that for you).

For example, you can use the @stateless annotation tag class to declare a Java class as a stateless reply bean. For stateful-reply beans, @Remove Annotations can be used to mark a particular method, which indicates that an instance of the bean is purged after the method is invoked.

To reduce the descriptive information for the description component, the specification organization also incorporates the means by which the exception is configured (configuration-by-exception), meaning that you can provide a clear default value for all annotations, so that most conventional information can be inferred.

The new persistence model

The new entity Bean is also an annotated simple Java object (POJO). Once it is accessed by Entitymanager it becomes a persistent object and becomes part of the persistence context. A persistence context is loosely coupled with a transaction context; Strictly speaking, it implicitly coexists with a transaction session.

Entity relationships are also defined by annotations, and the O/R mapping also provides several different database specification operations, which are accomplished through the developer's own design pattern or other technology (for example, the EJB2.1 primary key policy).

In-depth study

Now is the time to learn more about the EJB3.0 draft. Let's start with four enterprise-class beans in all ejbs and see what they look like in the new specification.

Stateless reply bean

In the EJB3.0 specification, writing a stateless reply bean (SLSB) requires just a simple Java file and adding @stateless annotations to the class layer. This bean can extend the Javax.ejb.SessionBean interface, but these are not required.

A slsb no longer needs a home interface, and no EJB needs it anymore. A bean class can implement a business interface or do not implement it. If no business interface is implemented, the business interface is generated by any public method. If only a few business methods are exposed to the business interface, these methods can use @businessmethod annotations. By default, all generated interfaces are local (native) interfaces, and you can use @remote annotations to declare this interface to be remote (remote).

The following lines of code can be defined as a helloworldbean. In EJB2.1, the same bean requires at least two interfaces, one implementation class and several empty implementations, plus a deployment descriptor.

Import javax.ejb.*;

/**
* A stateless session beans requesting that a remote business
* Interface be generated for it.
*/
@Stateless
@Remote
public class Helloworldbean {
Public String SayHello () {
Return to "Hello world!!!";
}
}