Thank you for your feedback!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" 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 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 javax.ejb.SessionBean or javax.ejb.MessageDrivenBean.
As a result of not having to implement 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.
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 @javax.ejb.Remote or @javax.ejb.Local annotations.)
The business interface is a plain old Java interface (or POJI); it should not extend javax.ejb.EJBObject or javax.ejb.EJBLocalObject.
The business interface methods may not throw 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 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.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.
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.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.
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.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 about EntityManager and the Oracle Kodo-provided KodoEntityManager.
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/samples/server/examples/src/examples/ejb/ejb30, where WL_HOME refers to the installation directory of WebLogic Server, such as /Oracle/Middleware/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.
Sign In