Bean Identity and Session Bean Handles

In this section we look at bean identities and bean handles^[1].

In Java EE 8, the relationship between a client and an EJB instance depends on the type of bean being used.

1. Stateless Session Beans:
   • Nature: Stateless session beans do not maintain any client-specific state between method calls. This means that any client request can be served by any available instance of the bean from the pool.
   • Client Relationship: There is no one-to-one relationship between the client and the bean instance. Instead, the container manages a pool of instances, and any instance from this pool can serve a client's request. The identity of the specific bean instance is irrelevant to the client, as the bean is stateless.
2. Stateful Session Beans:
   • Nature: Stateful session beans maintain state across method calls for a specific client. The state is unique to that client, which means that the same instance is used to serve multiple requests from that particular client.
   • Client Relationship: There is a one-to-one relationship between the client and the bean instance for the duration of the session. No other client interacts with this specific bean instance, and the identity of the bean instance is important because it maintains the state for that particular client.
3. Singleton Beans:
   • Nature: Singleton beans are shared across all clients within an application. There is only one instance of a singleton bean, and it is created once and exists for the lifetime of the application.
   • Client Relationship: There is no one-to-one relationship between the client and the bean instance. Instead, all clients interact with the same shared instance. The identity of the singleton bean instance is global to the application, and every client can access it.
4. Message-Driven Beans:
   • Nature: Message-driven beans (MDBs) process messages asynchronously from a queue or topic. They do not maintain a conversational state with any client.
   • Client Relationship: Like stateless session beans, there is no one-to-one relationship between the client and the MDB instance. The container can create multiple instances to process messages concurrently, and any available instance can handle a message.

Conclusion: In Java EE 8, only Stateful Session Beans maintain a one-to-one relationship between a client and a specific bean instance, ensuring that no other client or party needs to know about the identity of the bean instance. For other types of beans, such as 1) Stateless Session Beans, 2) Singleton Beans, and 3) Message-Driven Beans, this one-to-one relationship does not exist, and the identity of the specific instance is either shared across clients or irrelevant.

Session bean instances have no external identity. The one-to-one relationship between the client and the instance means that no other party needs to know about the identity of the bean instance. Within a client, you can compare two remote references to the same or different bean instances using the following method of the EJBObject:

if (beanA.isIdentical(beanB)) { 
.  .  .

Do not simply compare remote references using ==. It is not guaranteed to give correct results. For example (beanA == beanB) may not work correctly. Use isIdentical().

In Java EE 8, the concept of a handle does indeed relate to a specific `EJBObject`.
What is a Handle? A handle is a serializable object that acts as a stable, persistent reference to a specific `EJBObject`. The `EJBObject` represents the remote interface of an Enterprise JavaBean (EJB), which clients use to invoke methods on the EJB.
Relationship Between Handle and `EJBObject`:

• Specificity: A handle is tied to a specific `EJBObject`. When a handle is serialized and stored, it can be later deserialized and used to retrieve the exact same `EJBObject` instance, allowing the client to continue interacting with the EJB as if no interruption had occurred.
• Usage: Handles are particularly useful in scenarios where a client needs to maintain a reference to an EJB across different sessions or when the client is remote and may need to reestablish a connection to the same EJBObject at a later time.
• EJBObject: The `EJBObject` itself is the remote object through which the client interacts with the bean. It provides the remote methods defined in the bean's remote interface.

Example Use Case: If a client obtains a handle from an `EJBObject`, serializes it, and stores it somewhere (like in a database), that handle can later be deserialized to retrieve the exact `EJBObject` instance. This allows the client to continue its interaction with the same bean instance across different client sessions.

// Obtain a handle from an EJBObject
Handle handle = myEJBObject.getHandle();

// Serialize the handle to store it
ObjectOutputStream out = new ObjectOutputStream(new FileOutputStream("handle.ser"));
out.writeObject(handle);
out.close();

// Later, deserialize the handle to retrieve the EJBObject
ObjectInputStream in = new ObjectInputStream(new FileInputStream("handle.ser"));
Handle deserializedHandle = (Handle) in.readObject();
EJBObject ejbObject = deserializedHandle.getEJBObject();

Conclusion:In summary, a handle in Java EE 8 directly relates to a specific `EJBObject`. It provides a mechanism for maintaining a persistent reference to that `EJBObject` across different client interactions, even if those interactions are separated by time or occur in different sessions. This feature is particularly useful in distributed enterprise applications where maintaining continuity with specific EJB instances is important.

A handle relates to a specific EJBObject object. Thus, the handle can be used to "find" an already created bean instance. The handle is retrieved from the EJBObject as follows:

javax.ejb.Handle handle = bean.getHandle();
// serialize the handle and store
 . . .

Once the client has the handle to the EJBObject of a bean instance, it can be serialized and written to stable storage. Later, possibly in a different JVM, the handle can be de-serialized from stable storage and used to obtain a reference to the EJBObject as follows:

// load and de-serialize the handle
 .  .  .
// get the Remote object reference
bean = handle.getEJBObject();
String response = bean.sayHello();
 . . .

The handle will be valid as long as the bean instance has not been removed, or the container has not crashed and discarded the instance. Some containers will impose a timeout on an instance if it has not been accessed for a specific length of time, at which point the instance will be discarded.

Click the Quiz link below to test your understanding of session bean business methods and exceptions and session bean handles.
Business Methods - Quiz
In the next lesson, you will review what you've learned in this module.

[1]Bean handle: A universal reference to a bean instance, that is available from the EJBObject, that can be used to re-connect to a bean at a later time.