These sections describe the new features and programming model of EJB 3.0.
It is assumed the reader is familiar with Java programming, Java Platform, Enterprise Edition (Java EE) Version 5, and EJB 2.x concepts and features.
Enterprise JavaBeans (EJB) is a Java Platform, Enterprise Edition (Java EE) Version 5 technology for the development and deployment of component-based business applications. Although EJB is a powerful and useful technology, the programming model in version 2.X and previous was complex and confusing, requiring the creation of multiple Java files and deployment descriptors for even the simplest of EJB. This complexity hindered the wide adoption of EJBs.
As a consequence, one of the central goals of Version 3.0 of the EJB specification is to make it much easier to program an EJB, in particular by reducing the number of required programming artifacts and introducing a set of EJB-specific metadata annotations that make programming the bean file easier and more intuitive.
Another goal of the EJB 3.0 specification was to standardize the persistence framework and reduce the complexity of the entity bean programming model and object-relational (O/R) mapping model.
The remainder of this section describes, at a high-level, how the programming model and requirements changed in EJB 3.0, as compared to version 2.X, and lists a brief description of the new features of EJB 3.0.
The following summarizes the changes in the EJB programming model and requirements between EJB 2.X and 3.0:
You are no longer required to create the EJB deployment descriptor files (such as
ejb-jar.xml). You can now use metadata annotations in the bean file itself to configure metadata. You are still allowed, however, to use XML deployment descriptors if you want; in the case of conflicts, the deployment descriptor value overrides the annotation value.
The bean file can be a plain old Java object (or POJO); it is no longer required to implement
As a result of not having to implement
javax.ejb.MessageDrivenBean, the bean file no longer has to implement the lifecycle callback methods, such as
ejbPassivate, and so on. If, however, you want to implement these callback methods, you can name them anything you want and then annotate them with the appropriate annotation, such as
The bean file is required to use a business interface. The bean file can either explicitly implement the business interface or it can specify it using the
The business interface is a plain old Java interface (or POJI); it should not extend
The business interface methods may not throw
java.rmi.RemoteException unless the business interface extends
Because the EJB 3.0 programming model is so simple, Oracle no longer supports using the EJBGen tags and code-generating tool on EJB 3.0 beans. Rather, you can use this tool only on 2.X beans. For information, see the "EJBGen Reference" in Programming WebLogic Enterprise JavaBeans for Oracle WebLogic Server.
Bean files can now use metadata annotations to configure metadata, thus eliminating the need for deployment descriptors.
The only required metadata annotation in your bean file is the one that specifies the type of EJB you are writing (
@javax.persistence.Entity). The default value for all other annotations reflect typical and standard use of EJBs. This reduces the amount of code in your bean file in the case where you are programming a typical EJB; you only need to use additional annotations if the default values do not suit your needs.
Bean files supports dependency injection. Dependency injection is when the EJB container automatically supplies (or injects) a variable or setter method in the bean file with a reference to another EJB or resource or another environment entry in the bean's context.
Bean files support interceptors, which is a standard way of using aspect-oriented programming with EJB.
You can configure two types of interceptor methods: those that intercept business methods and those that intercept lifecycle callbacks.
You can configure multiple interceptor methods that execute in a chain in a particular order.
You can configure default interceptor methods that execute for all EJBs contained in a JAR file.
The following features are not part of the Enterprise JavaBeans 3.0 specification, but rather, are value-added features to further simplify the EJB 3.0 programming model:
Automatic persistence unit deployment based on variable name.
If you want to query and update an entity in your session bean, you annotate a variable with either the
@javax.persistence.PersistenceUnit annotation; the variable is then injected with persistence unit information. You can specify the
unitName attribute to reference a particular persistence unit in the
persistence.xml file of the EJB JAR file; in this case, the EJB container automatically deploys the persistence unit and sets its JNDI name to the persistence unit name, as listed in the
persistence.xml file. You can also simply name the injected variable exactly the same as the persistence unit you want injected into the variable; in this case, you no longer need to specify the
unitName attribute, but the EJB container still deploys the persistence unit and sets its JNDI name to the persistence unit name.
Support for vendor-specific subinterfaces when injecting an
EntityManager from a particular persistence provider.
When you inject a persistence context into a variable using either
@javax.persistence.PersistenceUnit, the standard data type of the injected variable is
EntityManager. If your persistence provider provides a subinterface of the
EntityManager (such as
KodoEntityManager in the case of Oracle Kodo) then as a convenience you can simply set the data type of the injected variable to that subinterface, rather than use the more complicated lookup mechanisms as described in the EJB 3.0 specification. For example:
@PersistenceContext private KodoEntityManager em;
See Chapter 3, "Simple Enterprise JavaBeans 3.0 Examples," for simple examples of stateless and stateful session beans, interceptor classes, and how to invoke an entity. The sections in this guide reference these examples extensively. These examples are meant to simply show how to use the new EJB 3.0 metadata annotations and programming model, rather than how to program the business code of your EJB.
For a more complex example that includes actual business code, see samples directory of the WebLogic Server installation, in particular
WL_HOME refers to the installation directory of WebLogic Server, such as
This guide describes how to program 3.0 session and message-driven EJBs, and how to invoke 3.0 entities from a session EJB. It does not describe how to actually program and configure a 3.0 entity. For details instructions on that topic, see "Java Persistence API" in the Oracle Kodo documentation.