About
A session bean encapsulates business logic that can be invoked programmatically by a client over local, remote, or web service client views. To access an application that is deployed on the server, the client invokes the session bean’s methods.
Session bean is not persistent. (That is, its data is not saved to a database.) A session bean represents a transient conversation with a client. When the client finishes executing, the session bean instance and its data are gone.
If you choose to have a session bean access the database, you have to use:
The state of an object consists of the values of its instance variables.
Articles Related
Types
Session beans are of three types:
Types | State Scope | Web Service Implementation | Concurrency invocation | Task Type |
---|---|---|---|---|
Stateful | Session | No | No | Presentation of a simplified view to the client or other components of the application |
Stateless | Method invocation | Yes | No | Generic task for all clients (mail, …) |
Singleton | Application | Yes | Yes | Tasks upon application startup and shutdown, multiple threads concurrently |
Stateful and stateless session beans serve one client at a time; whereas, singleton session beans can be invoked concurrently.
Stateful
The state is retained for the duration of the client/bean session. If the client removes the bean, the session ends and the state disappears. Because the client interacts (“talks”) with its bean, this state is often called the conversational state.
A session bean is not shared; it can have only one client, in the same way that an interactive session can have only one user. When the client terminates, its session bean appears to terminate and is no longer associated with the client.
Stateless
A stateless session bean does not maintain a conversational state with the client. When a client invokes the methods of a stateless bean, the bean’s instance variables may contain a state specific to that client but only for the duration of the invocation. When the method is finished, the client-specific state should not be retained.
Except during method invocation, all instances of a stateless bean are equivalent, allowing the EJB container to assign an instance to any client. Because they can support multiple clients, stateless session beans can offer better scalability for applications that require large numbers of clients. Typically, an application requires fewer stateless session beans than stateful session beans to support the same number of clients.
The @Stateless annotation decorating the enterprise bean class lets the container know that the Bean is a stateless session bean.
package com.gerardnico.ejb;
import javax.ejb.*;
@Stateless
public class myBean {
.....
}
Singleton
A singleton session bean is instantiated once per application and exists for the lifecycle of the application. Singleton session beans are designed for circumstances in which a single enterprise bean instance is shared across and concurrently accessed by clients.
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.
Applications that use a singleton session bean may specify that the singleton should be instantiated upon application startup, which allows the singleton to perform initialization tasks for the application. The singleton may perform cleanup tasks on application shutdown as well, because the singleton will operate throughout the lifecycle of the application.
Access Definition (Metadata)
Before the EJB specification 3.1, a client can access a session bean only through view implemented or not through Java Interface.
EJB 3.1
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.
The java 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.
By default, any user can invoke the public methods of an EJB.
View
Before the EJB specification 3.1, a client can access a session bean only through view implemented or not through Business Interface
Type of (Business|Java) Interface | Type of view | Through |
---|---|---|
no-interface (non-existent) | local | the public methods of an enterprise bean |
local | local | the methods define in a local business interface |
remote | remote | the methods define in a remote business interface |
where a business interface is a standard Java programming language interface that contains the business methods of the enterprise bean.
If you aren’t sure which type of access an enterprise bean should have, choose remote access.
Although it is uncommon, it is possible for an enterprise bean to allow both remote and local access. If this is the case, either the business interface of the bean must be explicitly designated as a business interface by being decorated with the @Remote or @Local annotations, or the bean class must explicitly designate the business interfaces by using the @Remote and @Local annotations. The same business interface cannot be both a local and a remote business interface.
If the bean’s business interface is not decorated with @Local or @Remote, and if the bean class does not specify the interface using @Local or @Remote, the business interface is by default a local interface.
Local
A local view can be either:
- a local business interface that defines the business and lifecycle methods that are specific to the bean.
To build an enterprise bean that allows only local access, you may, but are not required to, do one of the following:
- create an enterprise bean implementation class that does not implement a business interface, indicating that the bean exposes a no-interface view to clients. For example:
@Session
public class MyBean { ... }
- Annotate the business interface of the enterprise bean as a @Local interface. For example:
@Local
public interface InterfaceName { ... }
- Specify the interface by decorating the bean class with @Local and specify the interface
name. For example:
@Local(InterfaceName.class)
public class BeanName implements InterfaceName { ... }
Enterprise beans that use the no-interface view do not implement a business interface.
Remote
The remote interface defines the business and lifecycle methods that are specific to the bean.
To create an enterprise bean that allows remote access, you must either
- Decorate the business interface of the enterprise bean with the @Remote annotation:
@Remote
public interface InterfaceName { ... }
- Decorate the bean class with @Remote, specifying the business interface or interfaces:
@Remote(InterfaceName.class)
public class BeanName implements InterfaceName { ... }
An EJB with a remote interface is an RMI object. An EJB’s remote interface extends java.rmi.remote
Client
Type of client and view
The type of client access allowed by the enterprise beans:
Type of client | Type of view accessible |
---|---|
remote | remote business interface |
local | no-interface, local and local business interface |
where a local client has these characteristics.
- It must run in the same application as the enterprise bean it accesses.
- It can be a web component or another enterprise bean.
Client Access
Client access to an enterprise bean view is accomplished through either:
- dependency injection (the easiest way)
- or JNDI lookup.
Dependency injection
Dependency injection using Java programming language annotations is the easiest way.
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.
To obtain a reference to the view of an enterprise bean through dependency injection, use the javax.ejb.EJB annotation and specify:
- the enterprise bean’s implementation class for a access through the no-interface view
- the locale or remote business interface name
@EJB
ExampleBean exampleBean;
JNDI lookup
JNDI lookup use the JavaNaming and Directory Interface syntax to find the enterprise bean instance. JNDI supports a global syntax for identifying Java EE components to simplify this explicit lookup.
To obtain a reference to the views of an enterprise bean through JNDI lookup, use the javax.naming.InitialContext interface’s lookup method:
- No-interface (Clients do not use the new operator to obtain a new instance of an enterprise bean that uses a no-interface view)
ExampleBean exampleBean = (ExampleBean)
InitialContext.lookup("java:module/ExampleBean");
- Local Business Interface
ExampleLocal example = (ExampleLocal)
InitialContext.lookup("java:module/ExampleLocal");
- Remote Business Interface
ExampleRemote example = (ExampleRemote)
InitialContext.lookup("java:global/myApp/ExampleRemote");