|Oracle® Fusion Middleware Programming Enterprise JavaBeans for Oracle WebLogic Server
12c Release 1 (12.1.1)
Part Number E24972-02
|PDF · Mobi · ePub|
These sections describe the new features and programming model of EJB 3.1 and also provide a basic overview EJB components, anatomy, and features.
These sections summarize the changes in the EJB programming model and requirements between EJB 3.0 and 3.1, as well between EJB 2.x and 3.0.
The EJB 3.1 specification provides simplified programming and packaging model changes. The mandatory use of Java interfaces from previous versions has been removed, allowing plain old Java objects to be annotated and used as EJB components. The simplification is further enhanced through the ability to place EJB components directly inside of Web applications, removing the need to produce separate archives to store the Web and EJB components and combine them together in an EAR file.
For a comprehensive listing of the new features in EJB 3.1 features introduced in this release of WebLogic Server, see "Enterprise Java Beans (EJBs)" in What's New in Oracle WebLogic Server.
Singleton Session Bean – singleton session beans provide a formal programming construct that guarantees a session bean will be instantiated once per application in a particular Java Virtual Machine (JVM), and that it will exist for the life cycle of the application. With singletons, you can easily share state between multiple instances of an enterprise bean component or between multiple enterprise bean components in the application.
Simplified No Interface Client View – The No-interface local client view type simplifies EJB development by providing local session bean access without requiring a separate local business interface, allowing components to have EJB bean class instances directly injected.
Packaging and Deploying EJBs Directly in a WAR File – EJB 3.1 provides the ability to place EJB components directly inside of Web application archive (WAR) files, removing the need to produce archives to store the Web and EJB components and combine them together in an enterprise application archive (EAR) file.
Portable Global JNDI Names – The Portable Global JNDI naming option in EJB 3.1 provides a number of common, well-known namespaces in which EJB components can be registered and looked up from using the pattern
java:global[/<app-name>]/<module-name>/<bean-name>. This standardizes how and where EJB components are registered in JNDI, and how they can be looked up and used by applications.
Asynchronous Session Bean Invocations – An EJB 3.1 session bean can expose methods with asynchronous client invocation semantics. Using the
@Asynchronous annotation in an EJB class or specific method will direct the EJB container to return control immediately to the client when the method is invoked. The method may return a future object to allow the client to check on the status of the method invocation, and retrieve result values that are asynchronously produced.
EJB Timer Enhancements – The EJB 3.1 Timer Service supports calendar-based EJB Timer expressions. The scheduling functionality takes the form of CRON-styled schedule definitions that can be placed on EJB methods, in order to have the methods be automatically invoked according to the defined schedule. EJB 3.1 also supports the automatic creation of a timer based on metadata in the bean class or deployment descriptor, which allows the bean developer to schedule a timer without relying on a bean invocation to programmatically invoke one of the Timer Service timer creation methods. Automatically created timers are created by the container as a result of application deployment.
Embeddable EJB Container – EJB 3.1 supports an embeddable API for executing EJB components within a Java SE environment. Unlike traditional Java EE server-based execution, embeddable usage allows client code and its corresponding enterprise beans to run within the same virtual machine and class loader. This provides better support for testing, offline processing (e.g., batch jobs), and the use of the EJB programming model in desktop applications.
JPA 2.0 Support – Oracle EclipseLink is the default JPA 2.0 persistence provider that is shipped with Oracle WebLogic Server. Oracle Kodo was deprecated in Oracle Fusion Middleware 11gR1 (220.127.116.11.0) (Oracle WebLogic Server 10.3.1). WebLogic Server runs with the JPA 2.0 JAR in the server
classpath. Although JPA 2.0 is upwardly compatible with JPA 1.0, JPA 2.0 introduced some methods to existing JPA interfaces that conflict with existing signatures in OpenJPA interfaces.
As a result, applications that continue to use Kodo/JPA as the persistence provider with WebLogic Server 12.1.1 must be recompiled. For more information, see "Updating Applications to Overcome Conflicts" in Programming Enterprise JavaBeans for Oracle WebLogic Server
JPA 2.0 Support Using the Default TopLink Persistence Provider – Oracle TopLink, a JPA 2.0 persistence provider, is now the default JPA provider, replacing Kodo, which was the default provider in previous releases. Any application that does not specify a JPA provider in
persistence.xml will now use TopLink by default. Applications can continue to use Kodo (a JPA 1.0 provider) by explicitly specifying Kodo/OpenJPA as their persistence provider in
persistence.xml. In addition, a Weblogic Server domain can be configured to use Kodo by default, if desired.
For more information, see Chapter 8, "Configuring the Persistence Provider in Oracle WebLogic Server."
Applications That Use Kodo as the Persistence Provider – This release of WebLogic Server runs with the JPA 2.0 JAR in the server's classpath. Although JPA 2.0 is upwardly compatible with JPA 1.0, JPA 2.0 introduced some methods to existing JPA interfaces that conflict with existing signatures in OpenJPA interfaces. As a result, applications that continue to use Kodo/JPA as the persistence provider with WebLogic Server 12.1.1 must be recompiled. For more information, see Updating Applications to Overcome Conflicts with JPA 2.0.
The following summarizes the new functionality and simplifications made in EJB 3.0 to the earlier EJB APIs:
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 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.
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
Session beans may expose client views via business interfaces. Session beans may either explicitly implement the business interface or they 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
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.
Because the EJB 3.x programming model is so simple, Oracle no longer supports using the EJBGen tags and code-generating tool on EJB 3.x beans. Rather, you can use this tool only on 2.x beans. For information, see the "EJBGen Reference" in Programming Enterprise JavaBeans, Version 2.1, for Oracle WebLogic Server.
Enterprise JavaBeans (EJB) 3.1 technology is the server-side component architecture for Java EE 6. EJB 3.1 technology enables rapid and simplified development of distributed, transactional, secure and portable applications based on Java technology.
Session beans implement business logic. There are three types of session beans: stateful, stateless, and singleton. Stateful and stateless session beans serve one client at a time; whereas, singleton session beans can be invoked concurrently.
For detailed information about the types of session beans and when to use them, see "What Is a Session Bean" in the "Enterprise Beans" chapter of the Java EE 6 Tutorial at
Stateful session beans maintain state information that reflects the interaction between the bean and a particular client across methods and transactions. A stateful session bean can manage interactions between a client and other enterprise beans, or manage a workflow.
Example: A company Web site that allows employees to view and update personal profile information could use a stateful session bean to call a variety of other beans to provide the services required by a user, after the user clicks "View my Data" on a page:
Accept the login data from a JSP, and call another EJB whose job it is to validate the login data.
Send confirmation of authorization to the JSP.
Call a bean that accesses profile information for the authorized user.
A stateless session bean does not store session or client state information between invocations—the only state it might contain is not specific to a client, for instance, a cached database connection or a reference to another EJB. At most, a stateless session bean may store state for the duration of a method invocation. When a method completes, state information is not retained.
Any instance of a stateless session bean can serve any client—any instance is equivalent. Stateless session beans can provide better performance than stateful session beans, because each stateless session bean instance can support multiple clients, albeit one at a time. The client of a stateless session bean can be a web service endpoint.
Example: An Internet application that allows visitors to click a "Contact Us" link and send an email could use a stateless session bean to generate the email, based on the "to" and "from" information gathered from the user by a JSP.
Singleton session beans provide a formal programming construct that guarantees a session bean will be instantiated once per application in a particular Java Virtual Machine (JVM), and that it will exist for the life cycle of the application. With singletons, you can easily share state between multiple instances of an enterprise bean component or between multiple enterprise bean components in the application.
Singleton session beans offer similar functionality to stateless session beans but differ from them in that there is only one singleton session bean per application, as opposed to a pool of stateless session beans, any of which may respond to a client request. Like stateless session beans, singleton session beans can implement Web service endpoints. Singleton session beans maintain their state between client invocations but are not required to maintain their state across server crashes or shutdowns.
Example: The Apache Web site provides a "Simple Singleton: ComponentRegistry" example that demonstrates how a singleton bean uses Container-Managed Concurrency to utilize the Read
(@Lock(READ)) functionality, to allow multi-threaded access to the bean, and the Write
(@Lock(WRITE)) functionality, to enforce single-threaded access to the bean.
A message-driven bean implements loosely coupled or asynchronous business logic in which the response to a request need not be immediate. A message-driven bean receives messages from a JMS Queue or Topic, and performs business logic based on the message contents. It is an asynchronous interface between EJBs and JMS.
Throughout its life cycle, an MDB instance can process messages from multiple clients, although not simultaneously. It does not retain state for a specific client. All instances of a message-driven bean are equivalent—the EJB container can assign a message to any MDB instance. The container can pool these instances to allow streams of messages to be processed concurrently.
The EJB container interacts directly with a message-driven bean—creating bean instances and passing JMS messages to those instances as necessary. The container creates bean instances at deployment time, adding and removing instances during operation based on message traffic.
For detailed information, see Programming Message-Driven Beans for Oracle WebLogic Server.
Example: In an on-line shopping application, where the process of taking an order from a customer results in a process that issues a purchase order to a supplier, the supplier ordering process could be implemented by a message-driven bean. While taking the customer order always results in placing a supplier order, the steps are loosely coupled because it is not necessary to generate the supplier order before confirming the customer order. It is acceptable or beneficial for customer orders to "stack up" before the associated supplier orders are issued.
These sections briefly describe classes required for each bean type, the EJB run-time environment, and the deployment descriptor files that govern a bean's run-time behavior.
Every bean type requires a bean class. Table 2-1 defines the supported client views that make up each type of EJB, and defines any additional required classes.
The EJB 2.1 and earlier API required that Local and Remote clients access the stateful or stateless session bean by means of the session bean's local or remote home and the local or remote component interfaces. These interfaces remain available for use with EJB 3.x; however, the EJB 2.1 Remote and Local client view is not supported for singleton session beans.
For more information see "Create EJB Classes and Interfaces" in Programming Enterprise JavaBeans, Version 2.1, for Oracle WebLogic Server.
Table 2-1 Supported Client Views in EJB 3.1
|Client Views||Session Bean Types||Additional Required Classes|
Stateful, Stateless, and Singleton session beans
Remote business interface that defines the bean's business and lifecycle methods.
Stateful, Stateless, and Singleton session beans
Local business interface that defines the bean's business and lifecycle methods.
Local No- interface
Stateful, Stateless, and Singleton session beans
Only requires the bean class.
Web Service Clients
Stateless and Singleton session beans
A Web service endpoint that is accessed as a JAX-WS or JAX-RPC service endpoint using the JAX-WS or JAX-RPC client view APIs.
An EJB container is a run-time container for beans that are deployed to an application server. The container is automatically created when the application server starts up, and serves as an interface between a bean and run-time services such as:
Life cycle management
Locking and concurrency control
The WebLogic Server EJB 3.1 programming model uses the Java EE 6 metadata annotations feature in which you create an annotated EJB 3.1 bean file, and then compile the class with standard Java compiler, which can then be packaged into a target module for deployment. At runtime, WebLogic Server parses the annotations and applies the required behavioral aspects to the bean file.
For more information, see Programming the Annotated EJB Class.
As of EJB 3.0, you are no longer required to create the EJB deployment descriptor files (such as
ejb-jar.xml). However, you can still use XML deployment descriptors if you want. In the case of conflicts, the deployment descriptor value overrides the annotation value.
If you are continuing to use deployment descriptors in your EJB implementation, refer to "EJB Deployment Descriptors" in Programming Enterprise JavaBeans, Version 2.1, for Oracle WebLogic Server.
The WebLogic Server EJB container supports three deployment descriptors:
ejb-jar.xml—The standard Java EE deployment descriptor. The
ejb-jar.xml may be used to define EJBs and to specify standard configuration settings for the EJBs. An
ejb-jar.xml can specify multiple beans that will be deployed together.
weblogic-ejb-jar.xml—WebLogic Server-specific deployment descriptor that contains elements related to WebLogic Server features such as clustering, caching, and transactions. This file is required if your beans take advantage of WebLogic Server-specific features. Like
weblogic-ejb-jar.xml can specify multiple beans that will be deployed together.
weblogic-cmp-jar.xml—WebLogic Server-specific deployment descriptor that contains elements related to container-managed persistence for entity beans. Entity beans that use container-managed persistence must be specified in a
For descriptions of the WebLogic Server EJB deployment descriptors, refer to "Deployment Descriptor Schema and Document Type Definitions Reference" in Programming Enterprise JavaBeans, Version 2.1, for Oracle WebLogic Server.
An EJB can be accessed by server-side or client-side objects such as servlets, Java client applications, other EJBs, web services, and non-Java clients. Any client of an EJB, whether in the same or a different application, accesses it in a similar fashion. WebLogic Server automatically creates implementations of an EJB's remote home and remote business interfaces, which can function remotely.
Clients access enterprise beans either through a no-interface view or through a business interface. A no-interface view of an enterprise bean exposes the public methods of the enterprise bean implementation class to clients. Clients using the no-interface view of an enterprise bean may invoke any public methods in the enterprise bean implementation class or any super-classes of the implementation class. A business interface is a standard Java programming language interface that contains the business methods of the enterprise bean.
The client of an enterprise bean obtains a reference to an instance of an enterprise bean through either dependency injection, using Java programming language annotations, or JNDI lookup, using the Java Naming and Directory Interface syntax to find the enterprise bean instance.
Dependency injection is the simplest way of obtaining an enterprise bean reference. Clients that run within a Java EE server-managed environment, JavaServer Faces web applications, JAX-RS web services, other enterprise beans, or Java EE application clients, support dependency injection using the
Applications that run outside a Java EE server-managed environment, such as Java SE applications, must perform an explicit lookup. JNDI supports a global syntax for identifying Java EE components to simplify this explicit lookup. For more information see, Using the JNDI Portable Syntax.
Because of network overhead, it is more efficient to access beans from a client on the same machine than from a remote client, and even more efficient if the client is in the same application.
For information on programming client access to an EJB, see "Accessing Enterprise Bean" in the "Enterprise Beans" chapter of the Java EE 6 Tutorial at
WebLogic Server EJBs use:
T3—To communicate with remote objects. T3 is a WebLogic-proprietary remote network protocol that implements the Remote Method Invocation (RMI) protocol.
RMI—To communicate with remote objects. RMI enables an application to obtain a reference to an object located elsewhere in the network, and to invoke methods on that object as though it were co-located with the client on the same JVM locally in the client's virtual machine. An EJB with a remote interface is an RMI object. For more information on WebLogic RMI, see Programming RMI for Oracle WebLogic Server.
HTTP—An EJB can obtain an HTTP connection to a Web server external to the WebLogic Server environment by using the
java.net.URL resource connection factory. For more information, see "Configuring EJBs to Send Requests to an URL" in Programming Enterprise JavaBeans, Version 2.1, for Oracle WebLogic Server.
You can specify the attributes of the network connection an EJB uses by binding the EJB to a WebLogic Server custom network channel. For more information, see "Configuring Network Resources" in Configuring Server Environments for Oracle WebLogic Server.
By default, any user can invoke the public methods of an EJB. Therefore, if you want to restrict access to the EJB, you can use security-related annotations to specify the roles that are allowed to invoke all, or a subset, of the methods, which is explained in Securing Access to the EJB.
In addition, you create security roles and map users to roles using the WebLogic Server Administration Console to update your security realm. For details, see "Manage Security Roles" in the Oracle WebLogic Server Administration Console Help.
For additional information about security and EJBs, see:
"Security Fundamentals" in Understanding Security for Oracle WebLogic Server has introductory information about authentication, authorization and other security topics.
"Securing Enterprise JavaBeans (EJBs)" in Programming Security for Oracle WebLogic Server provides instructions for configuring authentication and authorization for EJBs.
Securing Resources Using Roles and Policies for Oracle WebLogic Server contains instructions for on configuring authentication and authorization for your EJBs using the Administration Console.