Lesson 1

This module introduces entity beans and discusses their architecture and will look at how entity beans differ from session beans. Entity Beans and Session Beans are both part of the Enterprise JavaBeans (EJB) architecture in earlier versions of Java EE (now Jakarta EE), but they serve different purposes and have key differences in how they manage state, persistence, and transactions.

1. Purpose and Role
   • Entity Beans:
     • Represent persistent data stored in a database. Each instance of an Entity Bean corresponds to a row in a database table.
     • Focus on persistence management, allowing automatic mapping of Java objects to database tables (using Container-Managed Persistence (CMP) or Bean-Managed Persistence (BMP)).
     • Entity Beans were typically used to model business entities like "Customer", "Order", etc.
     • In modern Jakarta EE, Entity Beans have been replaced by JPA entities.
   • Session Beans:
     • Represent business logic. They encapsulate the business operations or workflows that an application performs, such as "processOrder()", "login()", etc.
     • Do not directly represent persistent data, although they can interact with a database through JPA or other persistence mechanisms.
     • Types of session beans:
       • Stateless: No client-specific state is maintained between method calls.
       • Stateful: Maintain client-specific state across method calls (useful for workflows).
       • Singleton: One instance per application (useful for shared resources).
2. State Management
   • Entity Beans:
     • Are inherently stateful because they represent database rows. Each instance of an Entity Bean is tied to specific data (e.g., a specific customer or order).
     • The state is automatically synchronized with the underlying database, either through the container (CMP) or by the bean itself (BMP).
   • Session Beans:
     • Stateless Session Beans: Do not maintain any client-specific state between method calls. Every call is independent.
     • Stateful Session Beans: Maintain conversational state for a particular client. The state is maintained across multiple method calls as part of a transaction or workflow.
     • Singleton Session Beans: Have a single instance for the entire application and are primarily used for shared resources.
3. Persistence
   • Entity Beans:
     • Are persistent. Their lifecycle is closely tied to the underlying database. Once created, they persist beyond the application's execution.
     • Use either Container-Managed Persistence (CMP) or Bean-Managed Persistence (BMP). In CMP, the container handles the interaction with the database, while in BMP, the developer must manually implement the persistence logic.
   • Session Beans:
     • Are not persistent. They are temporary objects that serve clients and manage business processes, but their state is not automatically saved to a database.
     • They can interact with persistent data by using JPA, JDBC, or other persistence mechanisms, but they do not automatically map to database tables as Entity Beans do.
4. Transaction Management:
   • Entity Beans: Typically rely on the container to manage transactions, particularly with CMP. The transaction boundaries are managed by the EJB container, and the container ensures that database changes are consistent with the application's operations.
   • Session Beans:
     • Can participate in transactions using CMT (Container-Managed Transactions) or BMT (Bean-Managed Transactions).
     • Session beans typically coordinate business processes that involve multiple operations (and possibly multiple entity beans) within a single transaction.
5. Lifecycle:
   • Entity Beans: - Are persistent objects. They have a lifecycle that includes creation, loading, passivation (when idle), and removal. Their state is synchronized with the database during this lifecycle.
   • Session Beans: Are transient and have a simpler lifecycle. Stateless session beans are created and destroyed based on client requests. Stateful session beans maintain state between requests but are removed when no longer needed or after a timeout period.
6. Replacement in Modern Jakarta EE
   • Entity Beans: Replaced by JPA (Java Persistence API), which offers a more flexible and developer-friendly way to manage persistent entities with annotations, EntityManager, and the use of POJOs (Plain Old Java Objects).
   • Session Beans: Still widely used in modern Jakarta EE for handling business logic, though they can also be replaced or supplemented by CDI (Contexts and Dependency Injection) beans in some cases.

Aspect	Entity Beans	Session Beans
Role	Persistent data (database rows)	Business logic
State	Stateful (maps to database rows)	Stateless, Stateful, or Singleton
Persistence	Built-in persistence (CMP/BMP)	No built-in persistence, uses JPA or JDBC
Transactions	Managed by container, especially in CMP	Can use CMT or BMT for transaction management
Lifecycle	Persistent (long-lived, tied to database)	Transient (short-lived, tied to client requests)
Modern Replacement	JPA (Java Persistence API)	Still widely used in Jakarta EE

Entity Beans were deprecated in favor of JPA due to the complexity and limited flexibility of the original EJB persistence model. Session Beans, on the other hand, continue to be useful for managing business logic in enterprise applications.

Entity beans represent some persistent data that is stored somewhere on-line, locally, or remotely. As this data is unique and has a unique identity, entity beans use primary keys^[1] to identify them. You will learn to create and use these primary keys.

• Bean-managed and Container-managed Persistence With entity beans, there are two kinds of persistence. When the programmer writes code that stores and retrieves the data within the bean, it is called bean-managed persistence^[2]. If this responsibility is delegated to the container, which then reads and writes the data automatically on behalf of the bean, it is known as container-managed persistence^[3].

You will be introduced to the lifecycle of the entity bean. It describes how the container manages the EJBObject, the instances, and their primary keys.
Starting with J2EE 1.3, the specification was developed by the Java Community Process (JCP) under the JSR 58. Support for entity beans was made mandatory, and EJBs introduced XML deployment descriptors to store metadata (which was serialized in a file in EJB 1.0). This version addressed the overhead of passing arguments by value with remote interfaces, by introducing local interfaces and passing arguments by reference. J2EE Connector Architecture (JCA) was introduced to connect Java EE to EIS.

Java EE was first released in 1999, and ever since, new specifications have been added at each release .
This became a problem in terms of size, implementation, and adoption. Some features were not well supported or not widely deployed because they were technologically outdated or other alternatives were made available in the meantime. So the expert group decided to propose the removal of some features through pruning. The pruning process (also known as marked for deletion) consists of proposing a list of features for possible removal in the following Java EE release. Note that none of the proposed removal items are actually removed from the current version but could be in the following one. Java EE 6 proposed the following specification and features to be pruned, and they indeed disappeared from Java EE 7:

1. EJB 2.x Entity Beans CMP (was part of JSR 318): The complex and heavyweight persistent component model of EJB 2.x entity beans has been replaced by JPA.
2. JAX-RPC (JSR 101): This was the first attempt to model SOAP web services as RPC calls. It has now been replaced by the much easier to use and robust JAX-WS
3. JAXR (JSR 93): JAXR is the API dedicated to communicating with UDDI registries. Because UDDI is not widely used, JAXR has left Java EE and evolves as a separate JSR.
4. Java EE Application Deployment (JSR 88): JSR 88 is a specification that tool developers can use for deployment across application servers. This API hasn’t gained much vendor support, so it leaves Java EE 7 to evolve as a separate JSR.

The next lesson introduces the architecture of entity beans.

[1] Primary key: Uniquely identifies a row in a database.

[2] bean-managed-persistence: The enterprise java bean itself is responsible for storing and restoring its state to and from the database.

[3] container-managed-persistence: The persistence of the data is managed by the ejb container.