1. Understanding Oracle WebLogic Server
  2. Enterprise JavaBeans (EJBs)

12 Enterprise JavaBeans (EJBs)

Enterprise JavaBeans (EJBs) are Java EE components that implement EJB technology. EJBs run in the EJB container, a runtime environment within Oracle WebLogic Server. Although transparent to the application developer, the EJB container provides system-level services, such as transactions and security, to the EJBs deployed in it. These services enable you to quickly build and deploy EJBs, which form the core of transactional Java EE applications.

This chapter includes the following topics:

Understanding EJBs

EJB 3.2 technology is the server-side component architecture for the development and deployment of component-based business applications. EJB technology enables rapid and simplified development of distributed, transactional, secure, and portable applications based on Java EE technology.

The EJB 3.2 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 modules directly inside of web applications, removing the need to produce archives to store the web and EJB components and combine them together in an EAR file.

This topic contains the following sections:

EJB Documentation in WebLogic Server

See the following documents to know about using EJBs with WebLogic Server:

Additional EJB Information

To learn more about EJB concepts, such as the benefits of enterprise beans, the types of enterprise beans, and their life cycles, then visit the following web sites:

Session EJBs Implement Business Logic

Session beans implement business logic. A session bean instance serves one client at a time. There are three types of session beans: stateful, stateless, and singleton.

For detailed information about the types of session beans and when to use them, see What Is a Session Bean in the Java EE 8 Tutorial.

Stateful Session Beans

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 invoke another EJB that validates the login data.

  • Send confirmation of authorization to the JSP.

  • Call a bean that accesses profile information for the authorized user.

Stateless Session Beans

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

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: An Internet application that provides a central counter service. A stateless singleton bean can be called from a Java client, with the count being consistently incremented by 1 as the client is invoked multiple times.

Message-Driven Beans Implement Loosely Coupled Business Logic

A message-driven bean (MDB) 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.

See Developing Message-Driven Beans for Oracle WebLogic Server.

Example: In an online 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.

EJB Anatomy and Environment

To develop an EJB, you must provide files for the EJB class, the business interfaces, and the helper classes. The environment for the EJB includes an EJB container and, optionally, one or more deployment descriptor files.

The following sections briefly describe classes required for each bean type, the EJB runtime environment, and the deployment descriptor files that govern a bean's runtime behavior:

EJB Components

The composition of a bean varies by bean type. Table 12-1 defines the classes that make up each type of EJB, and defines the purpose of the class type.

Note:

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 Developing Enterprise JavaBeans, Version 2.1, for Oracle WebLogic Server.

Table 12-1 Components of EJB 3.1

EJB Component Description Stateless Session Stateful Session Singleton Session MDB

Remote business interface

The remote business interface exposes business logic to remote clients—clients running in a separate application from the EJB. It defines the business methods a remote client can call.

Yes

Yes

Yes

No

Local business interface

The local business interface exposes business logic to local clients—those running in the same application as the EJB. It defines the business methods a local client can call.

Yes

Yes

Yes

No

Local No- interface

The no-interface view is a variation of the Local view that exposes the public methods of the bean class without the use of a separate business interface.

Yes

Yes

Yes

Yes

Bean class

The bean class implements business logic.

Yes

Yes

Yes

Yes

The EJB Container

An EJB container is a runtime 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 runtime services such as:

  • Life cycle management

  • Code generation

  • Security

  • Transaction management

  • Locking and concurrency control

Embeddable EJB Container

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 (for example, batch jobs), and the use of the EJB programming model in desktop applications.

Most of the services present in the enterprise bean container in a Java EE server are available in the embedded enterprise bean container, including injection, container-managed transactions, and security. Enterprise bean components execute similarly in both embedded and Java EE environments, and therefore the same enterprise bean can be easily reused in both standalone and networked applications.

For more information about the Embedded Enterprise Bean Container, see Using an Embedded EJB Container in Oracle WebLogic Server in Developing Enterprise JavaBeans for Oracle WebLogic Server.

EJB Metadata Annotations

The WebLogic Server EJB 3.2 programming model uses the metadata annotations feature in which you create an annotated EJB 3.2 bean file, and then use the WebLogic compile tool weblogic.appc (or its Ant equivalent wlappc) to compile the bean file into a Java class file and generate the associated EJB artifacts, such as the required EJB interfaces and optional deployment descriptors.

See Programming the Annotated EJB Class in Developing Enterprise JavaBeans for Oracle WebLogic Server.

Optional EJB Deployment Descriptors

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 Developing Enterprise JavaBeans, Version 2.1, for Oracle WebLogic Server.

WebLogic Server EJB 2.x has three deployment descriptors:

  • ejb-jar.xml—The standard Java EE deployment descriptor. All beans must be specified in an ejb-jar.xml. 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. Similar to ejb-jar.xml, 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 weblogic-cmp-jar.xml file.

For descriptions of the WebLogic Server EJB 2.x deployment descriptors, refer to Deployment Descriptor Schema and Document Type Definitions Reference in Developing Enterprise JavaBeans, Version 2.1, for Oracle WebLogic Server.

EJBs Clients and Communications

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 home and business interfaces that can function remotely, unless the bean has only a local interface.

This topic includes the following sections:

Accessing EJBs

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 superclasses 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 javax.ejb.EJB annotation.

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, Programming Access to EJB Clients in Developing Enterprise JavaBeans for Oracle WebLogic Server.

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 Beans in the Java EE 8 Tutorial.

EJB Communications

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. An EJB's remote interface extends java.rmi.remote. For more information on WebLogic RMI, see Developing RMI Applications 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. See Configuring EJBs to Send Requests to an URL in Developing 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. See Configuring Network Resources in Administering Server Environments for Oracle WebLogic Server.

Securing EJBs

By default, any user defined in the security realm can invoke the public methods of an EJB. Therefore, if you want to restrict access to EJBs, you can create security policies for them, or use security-related annotations, to specify the roles that are allowed to invoke all, or a subset, of its methods. For information about restricting access to EJBs using annotations within the EJBs themselves, see Securing Access to the EJB in Developing Enterprise JavaBeans for Oracle WebLogic Server.

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 Oracle WebLogic Server Administration Console Online Help.

For more information about security and EJBs:

Roadmap for EJBs in WebLogic Server

The WebLogic Server documentation set includes several introductory, procedural, and reference topics, including examples, that help you understand how to develop, deploy, and secure EJBs in the WebLogic Server environment.

Table 12-2 Roadmap for EJBs in WebLogic Server

Major Task Subtasks and Additional Information

Understanding EJBs

Simple EJB examples

Iterative EJB developing

Programming the annotated EJB class

Deployment guidelines for EJBs

Using an embedded EJB container in Oracle WebLogic Server

Configuring the Persistence Provider in Oracle WebLogic Server

Reference

Information about EJB 2.x