Chapter 7. Developing Session Beans
This chapter is for the Enterprise Bean provider; that is, the person in charge of developing the software components on the server side and, more specifically, the Session Beans.
 | Note |
|---|---|
In this documentation, the term "Bean" always means "Enterprise Bean." |
7.1. Introduction to Session Beans
A Session Bean is composed of the following parts, which are developed by the Enterprise Bean provider:
The Component Interface is the client view of the bean. It contains all the "business methods" of the bean.
The Home Interface contains all the methods for the bean life cycle (creation, suppression) used by the client application.
The bean implementation class implements the business methods and all the methods (described in the EJB specification), allowing the bean to be managed in the container.
The deployment descriptor contains the bean properties that can be edited at assembly or deployment time.
Note that, according to the EJB 2.0 specification, the couple "Component Interface and Home Interface" may be either local or remote. Local Interfaces (Home and Component) are to be used by a client running in the same JVM as the EJB component. Create and finder methods of a local or remote home interface return local or remote component interfaces respectively. An EJB component can have both remote and local interfaces, even if typically only one type of interface is provided.
The description of these elements is provided in the sections that follow.
A Session Bean object is a short-lived object that executes on behalf of a single client. There are stateless and stateful Session Beans. Stateless Beans do not maintain state across method calls. Any instance of stateless beans can be used by any client at any time. Stateful Session Beans maintain state within and between transactions. Each stateful session bean object is associated with a specific client. A stateful Session Bean with container-managed transaction demarcation can optionally implement the SessionSynchronization interface. In this case, the bean objects will be informed of transaction boundaries. A rollback could result in a Session Bean object's state being inconsistent; in this case, implementing the SessionSynchronization interface may enable the bean object to update its state according to the transaction completion status.