Section 6.10. EJB 3.0

6.10. EJB 3.0

The 3.0 version of the EJB specification is currently in draft form and should be released in final form shortly after this book hits the shelves. Early versions of EJB 3.0 implementations have started to appear already. In anticipation of the eventual wide availability of EJB 3.0 containers, we provide a short introduction to the new programming model introduced in the 3.0 specification.

The biggest complaint by developers about the current EJB programming model (Version 2.1) is that it is just too complex. Several Java interfaces and classes have to be written for each EJB, and configuration details have to be supplied in the form of an XML deployment descriptor. And that's after you've figured out the various rules and contracts for implementing container callbacks, using container services, and so on. Some projects find the benefits of the EJB container services to be worth it, and their developers work through the EJB complexities to get these benefits. But many developers have found other, simpler solutions to get these services. The most notable "EJB competitor" has been Hibernate, discussed in Chapter 20. Hibernate presents a much simpler programming model for handling object/relational persistence in enterprise applications, and many developers have voted with their feet and gone down the path of least resistance.

It's not surprising, then, that the primary goal in writing the EJB 3.0 specification was simplification. The specification leads listened to the critics, borrowed design principles (and developers) from Hibernate and other projects, and put together a streamlined programming model in EJB 3.0. Some of the significant new features in the new model are:

• An EJB can be implemented with a single Java class. You aren't required to write home and client interfaces (though you still can if you really want to).

• Annotations (based on the J2SE annotations model discussed in Chapter 21) have been introduced. These annotations can be used to specify most if not all of the configuration details for the EJB, including deployment descriptor details, persistence mappings, web service methods, container callbacks, and the like.

• The bean doesn't have to follow the EnterpriseBean interface (or its subclasses). Annotations can be used to map your methods to the container callbacks, letting you write your beans the way you want to write them.

To demonstrate the new model, Example 6-9 shows our stateful ProfileBean implemented under the EJB 3.0 programming model. This one, smaller class replaces all the code in the home, client, and implementation classes we had earlier. The EJB container implementation will generate the client and home interfaces based on the annotations we've placed in the code, such as the @Remote indicator on the class and the @BusinessMethod tag on our getName( ) method. In addition, we may be able to eliminate writing an EJB deployment descriptor since we've included the specification of dependent resources with an @Resource annotation and the other information we specified in our deployment descriptor can be inferred by other features and annotations in the code, like the @Stateful tag.

Example 6-9. EJB 3.0 version of Profile bean

 // Indicate this is a stateful session bean @Stateful(name="ProfileEJB3") // Request a remote client interface for this bean @Remote // Specify deployed resources this bean depends on @Resource(name="ProfileDB",           resourceType="javax.sql.DataSource",           jndiName="jdbc/ProfileDB") // Note: No need to extend the SessionBean interface public class ProfileBeanEJB3 {     // Name of the person owning the profile     private String mName = "";     // Entries in the profile (name/value pairs)     private Properties mEntries = new Properties();       // No activate, passivate methods - we don't need them,     // no need to write them.       // Tag this as a business method, so it appears in the generated     // client interface(s)     @BusinessMethod     // Also tag this as a web method, so it will be callable from     // the SOAP interface. Note that this annotation is actually     // defined in the new JAX-RPC 2.0 spec, not in the EJB 3.0 spec.     @WebMethod     public String getName() {         return mName;     } }

Note that the example we show here may not be directly applicable to the final EJB 3.0 specification when it is released. This example is based on the latest draft version of the specification available at this time.

If you have invested development time and resources into EJB 2.1 (or earlier) components, don't fret. There are backward-compatibility measures built into the EJB 3.0 specification. But given the cleaner, more flexible, and simpler model provided in EJB 3.0, you likely won't want to run your "legacy" EJBs for very long before converting them to this approach.