![]() ![]() ![]() ![]() ![]() ![]() |
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.
Note: | This document does not discuss programming 3.0 entity beans; that information is provided in the Java Persistence API guide of the Oracle Kodo documentation set. |
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 the new features of EJB 3.0.
The following summarizes the changes between EJB 2.X and 3.0:
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. javax.ejb.SessionBean
or javax.ejb.MessageDrivenBean
.javax.ejb.SessionBean
or javax.ejb.MessageDrivenBean
, the bean file no longer has to implement the lifecycle callback methods, such as ejbCreate
, 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 @javax.ejb.PostActivate
.@javax.ejb.Remote
or @javax.ejb.Local
annotations.)javax.ejb.EJBObject
or javax.ejb.EJBLocalObject
.java.rmi.RemoteException
unless the business interface extends java.rmi.Remote
.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 EJBGen Reference.
@javax.ejb.Stateless
, @javax.ejb.Stateful
, @javax.ejb.MessageDriven
, or @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.
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:
If you want to query and update an entity in your session bean, you annotate a variable with either the @javax.persistence.PersistenceContext
or @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.
See Invoking a 3.0 Entity for general information about invoking an entity from a session bean and Annotations Used to Interact With Entity Beans for reference information about the annotations.
EntityManager
from a particular persistence provider.
When you inject a persistence context into a variable using either @javax.persisetence.PersistenceContext
or @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 Invoking a 3.0 Entity and KodoEntityManager for general information aboutEntityManager
and the Oracle Kodo-providedKodoEntityManager
.
See 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
/samples/server/examples/src/examples/ejb/ejb30
, where WL_HOME
refers to the installation directory of WebLogic Server, such as /bea/wlserver_10.3
.
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.
![]() ![]() ![]() |