Network Deployment (Distributed operating systems), v8.0 > Applications > EJB applications

Enterprise beans

An enterprise bean is a Java component that can be combined with other resources to create Java applications. There are three types of enterprise beans, entity beans, session beans, and message-driven beans.

All beans reside in EJB containers, which provide an interface between the beans and the application server on which they reside.

EJB 2.1 and earlier versions of the specification define entity beans as a means to store permanent data, so they require connections to a form of persistent storage. This storage might be a database, an existing legacy application, a file, or another type of persistent storage.

The EJB 3.0 specification deprecates EJB 1.1-style entity beans. The Java Persistence API (JPA) specification is intended to replace the deprecated enterprise beans. While the JPA replacement is called an entity class, it should not be confused with entity enterprise beans. A JPA entity is not an enterprise bean and is not required to run in an EJB container.

Session beans typically contain the high-level and mid-level business logic for an application. Each method on a session bean performs a particular high-level operation. For example, submitting an order or transferring money between accounts. Session beans often invoke methods on entity beans in the course of their business logic.

Session beans can be either stateful, stateless, or singleton. A stateful bean instance is intended for use by a single client during its lifetime, where the client performs a series of method calls that are related to each other in time for that client. One example is a shopping cart where the client adds items to the cart over the course of an online shopping session. In contrast, a stateless bean instance is typically used by many clients during its lifetime, so stateless beans are appropriate for business logic operations that can be completed in the span of a single method invocation. Stateful beans should be used only where absolutely necessary. Using stateless beans improves the ability to debug, maintain, and scale the application.

The EJB 3.1 specification introduces singleton session beans. The EJB container initializes only one instance of a singleton session bean, and that instance is shared by all clients. Because a single instance is shared by all clients, singleton session beans have special life cycle and concurrency semantics. Singleton session beans can have business local, business remote, and web service client views; they cannot have EJB 2.1 local or remote client views.

The EJB 3.x specifications support stateless and stateful session beans. They follow a simple pattern such as:

• Define the business interface.
• Define the class that implements it.

• Add metadata with annotations or with XML deployment descriptors.

The result of a simple EJB 3.x stateful session bean looks like the following:

package ejb3demo;

@Stateful
public class Cart3Bean implements ShoppingCart {
    private ArrayList contents = new ArrayList();

public void addToCart (Object o) {
  contents.add(o);
    }

public Collection getContents() {
    return contents;

    }
}

EJB components can use annotations such as @EJB and other injectable @Resource references if the module is an EJB 3.x module.

Web application clients and application clients can use deployment descriptor-defined EJB references. If the reference is for an EJB 3.x session bean without a home interface, the reference should be defined with a null <home> or <local-home> setting in the deployment descriptor.

Web application clients and application clients can also use @EJB injections for references to EJB session beans within the same enterprise archive (EAR) file, but the binding must either use the AutoLink support within the container or the annotation must use the name of the reference that is defined by the deployment descriptor and bound when the application is installed. For more information about AutoLink, see the topic, "EJB 3.x application bindings support."

Message-driven beans enable asynchronous message servicing.

• The EJB container and a Java Message Service (JMS) provider work together to process messages. When a message arrives from another application component through JMS, the EJB container forwards it through an onMessage method call to a message-driven bean instance, which then processes the message. In other respects, message-driven beans are similar to stateless session beans.
• The EJB container and a Java Connector Architecture (JCA) resource adapter work together to process messages from an enterprise information system (EIS). When a message arrives from an EIS, the resource adapter receives the message and forwards it to a message-driven bean, which then processes the message. The message-driven bean is provided services such as transaction support by the EJB container in the same way that other enterprise beans are provided service.

Beans that require data access use data sources, which are administrative resources that define pools of connections to persistent storage mechanisms.
EJB 3.0 and EJB 3.1 application bindings overview
Data sources
Message-driven beans - JCA components
Message-driven beans - listener port components
Task overview: Using enterprise beans in applications
Develop singleton session beans

Related

Options for the AdminApp object install, installInteractive, edit, editInteractive, update, and updateInteractive commands using wsadmin.sh Concept topic

+

Search Tips   |   Advanced Search