Adoption of the Java Persistence Framework: selection, timing, and pros and cons?

For the development of new software systems, object-oriented programming is undoubtedly the most widely used programming mode today. Because of the persistence demand of business data, relational database management system (RDBMS) has been widely used. An RDBMS uses a relational model, which differs from the domain object model in a software system. When developing software systems using object-oriented programming languages and using RDBMS to persist data, the data persistence framework becomes a very critical and important component in the application architecture, which hides the underlying complexity of application data persistence.

Over the past few years, some of the persistence frameworks have been well developed to help you manage object-relational mapping and data persistence requirements. However, it is not a simple task to choose a suitable framework as needed, as multiple factors can affect the decision. In this article, I'll discuss how to make choices in some of the more widely used Java persistence frameworks based on three basic criteria: selection, timing, and pros and cons. In the "Select" section, I'll talk about how to choose the framework; in the "Timing" section, I'll discuss scenarios where you should consider application frameworks and scenarios where you should look for alternatives; and finally, in the "Pros and cons" part, I'll discuss when you decide to adopt a framework, All the advantages and disadvantages of the framework. The first thing to discuss here is the most famous framework in the Java persistence domain.

Entity Enterprise Java Bean

Java Persistence API

Hibernate

TopLink

Let's discuss these frameworks in more detail.

Entity Enterprise Java Bean

Enterprise JavaBean (EJB) technology is a hosted server-side component architecture for the Java platform Enterprise Edition (Java EE). In this definition, "managed" and "server side" are key terms. In the EJB schema, the application server manages the lifecycle of one or more deployed EJBS and provides common runtime services through the EJB container. The services provided by the container include security, concurrency control, transaction, and persistence management.

The EJB specification defines three types of Enterprise beans: Session, Entity, and message driven. Each type has some unique characteristics that are used for different purposes. Since this article is about the Java persistence framework, we'll talk a little bit about the persistence aspect of the EJB architecture, which involves managing the persistence requirements of your Enterprise Java application using Entity EJB.

When designing an application with an EJB, the EJB represents an entity in the business Domain model. For example, imagine a commercial bank application's account entity. The account Entity Bean will be deployed to the Java EE Application Server, which will provide some run-time services to this Entity bean through the EJB container. This service is automatically persisted and I will discuss it in more detail.

Depending on how the persistence is implemented, the Entity EJB can be further divided into two kinds: bean-managed persistence (BMP) and container-managed persistence (CMP). Use the Bmp,bean instance to take responsibility for the persistence of its state through the JDBC code. Using the Container-managed PERSISTENCE,EJB container provides the ability to automate the persistence of Entity beans: When needed, save the state to the underlying database or load the state from the underlying database.

Now let's discuss some scenarios where you might want to apply an EJB framework in these scenarios, and in particular, you might use CMP for data persistence.

When to consider EJB as the persistence framework

The first thing you need to consider is the services that are required for the container. If your application requires services that are provided by containers other than persistent management, such as transformation management, security, and concurrency control, it is best to use the EJB framework.

Resource requirements also need to be considered. The EJB Framework provides the perfect scalability for demand applications. However, there are also costs: intensive resource requirements, especially when using remote interface patterns. Consider applying the Entity EJB only when there is no resource constraint to achieve the required level of performance.

Another related factor is the de facto framework. If you are working on a Java platform based EE deployment, chances are that the EJB container has become part of your application server. "Why not use what is already available?" "may be the first question to ask in your architectural decision making process." I think of this as a "political" advantage over other frameworks, as it is already available.

When to consider an EJB alternative as a persistence framework

The functional requirements of the persistence layer may be the first factor that prompts you for an alternative scenario. If your application does not require each feature provided by the EJB framework, this means that you should seek an alternative.

Resource availability exceeds performance requirements may be another scenario where you want to look for other alternatives. Although the EJB framework provides the perfect performance and scalability, the resource consumption of the EJB framework is staggering. The bottom line question is: do we really need this? In many cases, a well written data access object or Hibernate framework provides the perfect alternative.

Although rare, data sources, rather than relational databases, may prevent you from using container-managed persistence frameworks.

If you have used or planned to use EJBS as your persistence framework, here are some of the advantages and disadvantages you can expect.