Testing EJB 3.0 simplifies API specification

Java™community Process (JCP) publishes the early second version of the Enterprise javabeans™ (EJB) 3.0 specification under JSR 220, which is divided into three files:

EJB 3.0 Simplified API: Defines a new simplified API for code Enterprise JavaBean components, especially session beans and message-driven beans.

Enterprise JavaBeans core Contracts and requirements: Defines the EJB contract between the Bean and the EJB container.

Persistence API: Defines a new entity Bean model for persistence.

In this column, I think I should highlight some of the features in the EJB 3.0 simplification API and comment on the areas where improvements can be made. Since I'm only proposing and discussing the simplified API, when it comes to EJB components, I'll involve session beans and message-driven beans, not entity beans, because it doesn't contain persistence under the simplified API.

The EJB specification has many goals, most of which I will not involve, but in short: The EJB 3.0 specification includes all the goals of the j2ee™5.0 specification to simplify the Java EE programming model. Because of this, this part of the specification is not so much a set of functional enhancement techniques as a modification of the original specification. However, there are still a lot of new programming models for developers to add to the spec, and I'll talk about them like I'm looking at a feature.

This article assumes that you have learned some knowledge about the current EJB specification.

POJO and annotations

"POJO" (traditional Java object) is a term that has recently ceased to be used in many areas. It involves code written as a normal Java class. Because EJB programming enables you to extend a specific class, provides several interfaces, and can write deployment descriptors, they are considered overloaded Java objects and no longer common classes. Instead, developers have to have Java-ee containers to run and test them. I admit that coding POJO without using tools makes development difficult. In the EJB 3.0 specification:

The EJB component no longer requires a local interface. In addition, there is no need for EJB components to provide different interfaces or to extend some explicit EJB-specific classes.

The J2SE 5.0 annotation is now a major proxy for implementing components. By detailing these special annotations, developers can create POJO classes of EJB components. The class will run through the annotation processor, and the potential container will provide the pipeline.

EJB 3.0 introduces the concept of a business interface. The following shows an instance:

public　interface　Stock
{
　 public　double　getQuote(String　symbol);
}

Your Bean class can implement the interface:

@Stateless　public　class　StockBean　implements　Stock
　 public　double　getQuote(String　symbol)
　 {
　 return　100.33;
　 }
}

The above @ stateless annotation means that this class is now a stateless session bean that will be invoked using the business interface. Early drafts allow for the possibility of generating business interfaces from Bean classes. Stateless session beans can be encoded without implementing specific interfaces and annotations. The following shows an instance:

@Stateless　public　class　StockBean
　 public　double　getQuote(String　symbol)
　 {
　 return　100.33;
　 }
}