Entity Beans   «Prev  Next»

Lesson 5Finding an entity bean using the primary key
ObjectiveWrite the code to lookup a bean using its primary key.

Locating Enity Bean

In Jakarta EE 10, Entity Beans from J2EE (EJB 2.x) have been fully replaced by Java Persistence API (JPA), which offers a more flexible, modern, and POJO-based approach to persistence. The concept of locating an entity bean using a primary key has been modernized using JPA's `EntityManager` and its method:
<T> T find(Class<T> entityClass, Object primaryKey);

✅ How Primary Key-Based Lookup is Replicated in Jakarta EE 10 (Using JPA)
Instead of using JNDI lookups or `home.findByPrimaryKey()` as in J2EE Entity Beans, in Jakarta EE 10 you do the following:
✅ Step-by-Step Comparison
J2EE (Entity Beans) Jakarta EE 10 (JPA)
Requires remote/local interface POJOs annotated with @Entity
home.findByPrimaryKey(primaryKey) entityManager.find(Entity.class, primaryKey)
Container-managed persistence and lifecycle You manage persistence with EntityManager
EJB deployment descriptors (XML) Uses annotations like @Entity, @Id, @GeneratedValue

✅ Example in Jakarta EE 10 (JPA-based):
Entity Class:
import jakarta.persistence.*;

@Entity
public class Customer {
    @Id
    private Long id;

    private String name;

    // getters and setters
}


Stateless Bean or CDI Bean:
import jakarta.persistence.*;
import jakarta.ejb.Stateless;

@Stateless
public class CustomerService {

    @PersistenceContext
    private EntityManager entityManager;

    public Customer findCustomer(Long id) {
        return entityManager.find(Customer.class, id);
    }
}

✅ Key Benefits Over J2EE Style
  • No need for home interfaces
  • No JNDI lookups
  • Entity lifecycle managed via `EntityManager`
  • Annotations make entity configuration simpler and type-safe
  • Cleaner exception handling (e.g., `NoResultException`, `EntityNotFoundException`)


✅ Optional Enhancements
You can also use:
  • entityManager.getReference() – lazy fetch proxy
  • JPQL queries for more flexible lookups
  • CriteriaBuilder for type-safe dynamic queries

Summary: The primary key lookup of entity beans in J2EE is now cleanly replicated and improved in Jakarta EE 10 through JPA's `EntityManager.find()`. This is more maintainable, testable, and integrates seamlessly with the CDI and EJB architecture.

The diagram titled
The diagram titled "EntityManager.find() Process" outlines the steps for retrieving an entity from a database using JPA in Jakarta EE 10.
Here's the detailed breakdown of each step:
  1. @Entity class
    • Define a plain Java class and annotate it with `@Entity`.
    • This marks the class as a JPA-managed entity that maps to a table in the database.
    • Example:
      @Entity
      public class Customer {
          @Id
          private Long id;
          private String name;
      }
              
  2. Inject EntityManager
    • Use the `@PersistenceContext` annotation to inject an instance of `EntityManager` into a managed bean (like a `@Stateless` EJB or CDI bean).
    • This `EntityManager` is used to interact with the persistence context.
    • @PersistenceContext
      private EntityManager entityManager;
              

  3. Call `find(entityClass, primaryKey)`
    • Invoke the `find()` method on the `EntityManager` to retrieve the entity by its primary key.
    • This is the equivalent of `findByPrimaryKey()` from J2EE EJBs, but much simpler.
    • Customer customer = entityManager.find(Customer.class, 1L);
              
  4. Return entity
    • The `find()` method returns the entity object if found, or `null` if no matching row exists in the database.
    • The returned object is managed by the current persistence context.
Summary: This process replaces complex EJB Entity Bean lookup with a clean, annotation-driven, POJO-based approach using `EntityManager.find()` in Jakarta EE 10 with JPA. It simplifies database interaction while adhering to modern standards.



JPA entities are simple POJOs

In Jakarta EE 10, the term "entity bean" (from the old EJB 2.x model) is deprecated and no longer used.
Instead, we use JPA entities, which are simple POJOs (Plain Old Java Objects) annotated with `@Entity`.
🔄 Terminology Shift
Legacy Term (J2EE) Modern Jakarta EE 10 Term
Entity Bean JPA Entity
Home Interface EntityManager.find()
Deployment Descriptor Annotations (@Entity, @Id, etc.)
Container-managed Fields POJO fields with annotations

✅ JPA Entities ≈ ERD Entities
JPA entities are aligned with ERD (Entity-Relationship Diagram) concepts:
  • In ER modeling, an entity maps to a table.
  • In JPA, an `@Entity` maps to a table.
  • Each field in the entity corresponds to a column.
  • The `@Id` field maps to the primary key.
🧠 Example Mapping
ERD Table: `Customer(id, name, email)`
JPA Entity:
@Entity
public class Customer {

    @Id
    private Long id;

    private String name;
    private String email;

    // getters/setters
}

In Jakarta EE 10, you are still modeling *entities", just with a more lightweight, modern, and decoupled architecture compared to the old EJB-based system.
For J2EE which was used during the dotcom era, the server side application would use a primary key to locate an entity bean? Has the use of entity beans in Jakarta EE 10 been deprecated. Describe the server side Java technology which is used to locate the primary key of a MySQL database table.

Finding the data

If the client knows the primary key of the persistent data that it needs, it can use that primary key to look up the bean.
The home object has a method findByPrimaryKey(PrimaryKey) that is used to create an instance of the bean and initialize it with the persistent data. The mechanism is described in the following series of images.

How do you find an entity bean using the primary key?
1) The client invokes the findByPrimaryKey() method of the home object passing it the primaryKey object
1) The client invokes the findByPrimaryKey() method of the home object passing it the primaryKey object.

2) The container creates an instance of the bean and asks it to look up the data.
2) The container creates an instance of the bean and asks it to look up the data.

3) The instance looks up the data and, if the key matches some data, the data is read into the bean instance.
3) The instance looks up the data and, if the key matches some data, the data is read into the bean instance.

4) The bean instance returns control to the container
4) The bean instance returns control to the container.

5) The container creates an EJBObject for the primary keys
5) The container creates an EJBObject for the primary keys.

6) The home object returns the EJBObject remote reference to the client. The client can then access the bean instance for that primary key.
6) The home object returns the EJBObject remote reference to the client. The client can then access the bean instance for that primary key.


Transition from Legacy J2EE to Jakarta EE

The `EJBObject` interface was part of the EJB 2.x remote invocation model, which required:
  • A remote interface that extended javax.ejb.EJBObject
  • Explicit use of RMI/IIOP
  • Use of JNDI lookups to obtain the stub object

Example (legacy J2EE):
public interface CustomerRemote extends EJBObject {
    public String getName() throws RemoteException;
}

❌ Deprecated and Removed
  • As of EJB 3.x, and continuing into Jakarta EE 10, this model has been completely replaced by a simpler POJO-based, annotation-driven model.
  • `javax.ejb.EJBObject` is not used or required for any modern enterprise bean.
  • Instead, remote and local interfaces are defined as plain interfaces using `@Remote` or `@Local`.

✅ Modern Jakarta EE 10 Alternative
@Remote
public interface CustomerService {
    String getName();
}

@Stateless
public class CustomerServiceBean implements CustomerService {
    public String getName() {
        return "Alice";
    }
}

  • No need for EJBObject, EJBHome, or RMI stubs.
  • Clients invoke methods via dependency injection or portable JNDI names.

✅ Jakarta EE 10 API Confirmation
The Jakarta EE 10 API (jakarta.ejb) does not include `EJBObject`. The Jakarta platform has officially removed legacy EJB interfaces and deployment models tied to CORBA and heavy container contracts. You can verify this directly via the Jakarta EE 10 API documentation:
jakarta.ejb package
`EJBObject` is not listed.
✅ Summary
  • EJBObject was required in EJB 2.x (J2EE)
  • ❌ It is not present in Jakarta EE 10
  • ✅ Modern beans use annotations (`@Stateless`, `@Stateful`) and plain interfaces
  • ✅ Clients interact directly with beans or through lightweight dependency injection / JNDI

Subsequent client access

The bean instance for that data now exists. If any client subsequently invokes the findByPrimaryKey() method on the home object, passing it the existing primary key, then the container simply returns the remote reference to the EJBObject. There is no lookup in the database or creation of a new instance or EJBObject. It is very efficient. The following diagram illustrates what happens:

Subsequent client access Client and EJB Objects
The diagram you provided illustrates the legacy architecture of EJB 2.x Entity Beans (used during the J2EE era). Here’s a detailed breakdown of each component shown in the image:
🔸 Clients (Client-A and Client-B)
  • These are remote or local application clients attempting to interact with enterprise business logic and persistent data.
  • They rely on JNDI lookups to access remote interfaces and invoke business methods on entity beans.
🔸 Home Object
  • This is an instance of the Home Interface, which is responsible for:
    • Creating, finding, and removing entity beans.
    • Returning a reference to an `EJBObject` stub.
  • Example (J2EE):
  CustomerHome home = (CustomerHome) ctx.lookup("CustomerHome");
  Customer customer = home.findByPrimaryKey(id);
  
🔸 EJBObject
  1. Acts as the remote interface proxy, through which the client interacts with the actual entity bean instance inside the container.
  2. Every method on the remote interface is implemented by the EJBObject.
  3. Ensures RMI-style remote communication between the client and server.

🔸 Entity Bean
  • A server-side component that:
    • Represents persistent data in a DBMS.
    • Is managed by the EJB container.
    • Follows container-managed persistence (CMP) or bean-managed persistence (BMP).
  • One entity bean corresponds to one row in a relational database table.

🔸 Container
* The EJB container is responsible for:
  • Managing the life cycle of entity beans.
  • Providing services like transactions, security, and persistence.
  • Instantiating and pooling entity beans.
  • Handling method invocations from EJBObject to the actual bean.

🔸 DBMS (Database Management System)
  • The underlying relational database that stores the actual entity data.
  • The entity bean performs CRUD operations on the DBMS either directly or via container-managed mechanisms.
🔄 Summary of the Flow
  1. Client-A performs a JNDI lookup to get the Home Object.
  2. The Home Object provides a reference to an EJBObject via a finder or create method.
  3. The EJBObject serves as the client’s handle to the entity bean.
  4. The entity bean interacts with the DBMS to retrieve or update data.

❌ Deprecated Architecture
  • EJBObject, HomeObject, and Entity Beans in this form are obsolete as of EJB 3.0 and fully removed in Jakarta EE 10.
  • They have been replaced by:
    • POJO-based JPA entities for persistence
    • Stateless CDI or EJB beans for business logic
    • No requirement for remote interfaces or RMI

Jakarta EE 10 Architecture

Finding Entity Bean - Quiz

Take a moment to test your knowledge on finding an entity bean using the primary key by clicking the Quiz link below.
Finding Entity Bean - Quiz
The next lesson introduces Bean-Managed Persistence (BMP).

SEMrush Software