1 Understanding EJBs

This chapter describes the new features and programming model of the EJB specification supported by WebLogic Server and also provides a basic overview EJB components, anatomy, and features.

This chapter includes the following sections:

• New Features and Changes in EJB
  
• Understanding EJB Components
  
• EJB Anatomy and Environment
  
• EJB Clients and Communications
  
• Securing EJBs
  

New Features and Changes in EJB

WebLogic Server 15.1.1.0.0 supports the Jakarta Enterprise Beans 4.0 specification.

Note:

In EJB 4.0, the package namespace changed from javax.* to jakarta.*.

For a complete list of changes and comparisons to previous EJB specifications, see What is New in This Release in the Jakarta Enterprise Beans 4.0 Specification.

Understanding EJB Components

Jakarta Enterprise Beans (EJB) technology is the server-side component architecture for Jakarta EE. EJB technology enables rapid and simplified development of distributed, transactional, secure and portable applications based on Java technology.

• Session EJBs Implement Business Logic
  
• Message-Driven Beans Implement Loosely Coupled Business Logic
  

Session EJBs Implement Business Logic

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 Jakarta EE Tutorial.

• Stateful Session Beans
  
• Stateless Session Beans
  
• Singleton Session Beans
  

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 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.

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: 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.

Message-Driven Beans Implement Loosely Coupled Business Logic

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 Developing 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.

EJB Anatomy and Environment

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.

• EJB Components
  
• The EJB Container
  
• EJB Metadata Annotations
  
• Optional EJB Deployment Descriptors
  

EJB Components

Every bean type requires a bean class. Table 1-1 defines the supported client views that make up each type of EJB, and defines any additional required classes.

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 4.0; however, the EJB 2.1 Remote and Local client view is not supported for singleton session beans.

See Create EJB Classes and Interfaces in Developing Jakarta Enterprise Beans Using Deployment Descriptors.

Table 1-1 Supported Client Views in EJB 3.2

Client Views	Session Bean Types	Additional Required Classes
Remote Client	Stateful, Stateless, and Singleton session beans	Remote business interface that defines the bean's business and lifecycle methods.
Local Client	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 service endpoint using the JAX-WS client view APIs.

The EJB Container

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

• Code generation

• Security

• Transaction management

• Locking and concurrency control

EJB Metadata Annotations

The WebLogic Server EJB programming model uses the Jakarta EE metadata annotations feature in which you create an annotated EJB 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.

See Programming the Annotated EJB Class.

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 Jakarta Enterprise Beans Using Deployment Descriptors.

The WebLogic Server EJB container supports three deployment descriptors:

• ejb-jar.xml—The standard Jakarta 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 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 deployment descriptors, refer to Deployment Descriptor Schema and Document Type Definitions Reference in Developing Jakarta Enterprise Beans Using Deployment Descriptors.

EJB 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 remote home and remote business interfaces, which can function remotely.

• Accessing EJBs
  
• EJB Communications
  

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 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 (JNDI) syntax to find the enterprise bean instance.

Dependency injection is the simplest way of obtaining an enterprise bean reference. Clients that run within a Jakarta EE server-managed environment, Jakarta Server Faces web applications, JAX-RS web services, other enterprise beans, or Jakarta EE application clients, support dependency injection using the jakarta.ejb.EJB annotation.

Applications that run outside a Jakarta EE server-managed environment, such as Java SE applications, must perform an explicit lookup. JNDI supports a global syntax for identifying Jakarta 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 Beans" in the Enterprise Beans chapter of the Jakarta EE 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. 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 Jakarta Enterprise Beans Using Deployment Descriptors.

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 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.

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 Jakarta Enterprise Beans (EJBs) in Developing Applications with the WebLogic Security Service provides instructions for configuring authentication and authorization for EJBs.