Is EJB 3.0 a clone of Hibernate?

Abstract Sun's EJB 3.0 specification is in its final "sprint" stage, and many companies are busy following this specification. The latest version of this EJB specification provides outstanding database functions among many advantages. However, some developers feel that this specification is only a "clone" version of The Hibernate persistent storage engine. Really? This article is intended to discuss this issue.

Practices have proved that Hibernate is one of the best persistent storage engines created for Java. So far, I still clearly remember the first time I used Hibernate. At that time, we had a ready-made persistent storage engine, but it would consume a lot of system resources and never really worked properly. Surprisingly, Hibernate "instantly" solved our persistent storage problem! This is really a "godsend thing ". Without knowing it, the time has been quickly pushed forward to today. EJB 3.0 has surfaced again, and we will soon plan to upgrade our current EJB 2.x server to this later version. However, some people may be surprised to carefully analyze the persistent storage changes made in EJB 3.0-Isn't this a "clone" product from Hibernate? Does Sun really mean "Stealing" From Hibernate's design? My answer is that the situation is much more complicated than that.

I. ejbs 3.0

One of the important goals that EJB 3.0 must achieve is to make it a more useful and easy-to-use development tool. Sun's Linda DeMichiel recognizes that to achieve this goal successfully, EJB 3.0 must be based on the existing library that developers are using today; otherwise, it will lead to a difficult upgrade operation and may not attract enough attention. Therefore, members from Oracle, JBoss, Apache, BEA, Novell, Google, and other experts are invited to participate in the formulation of this specification. The goal of this group is to produce a specification that makes EJB easier to develop and creates a persistent storage standard that allows developers to easily upgrade.

When the Group began developing the EJB 3.0 specification, they quickly realized that many of these features should be functionally consistent with all major vendors and libraries. We will discuss these features in the following sections.

(1) EntityManager

The EntityManager is responsible for processing a transaction. In JDO, it is called the persistent storage manager, and in Hibernate it is called a session. In the GlassFish project, EntityManager is described as follows:

In fact, an EntityManager instance is associated with a persistent storage context. A persistent storage context is a group of entity instances, and any of them is a unique entity instance. In this persistent storage context, the object instance and its lifecycle can be managed. This interface defines the methods used to interact with the persistent storage context. The EntityManager API is used to create and delete persistent entity instances. You can use its primary key to search for and query entities.

This entity set managed by a given EntityManager instance is defined through a persistent storage unit. A persistent Storage Unit defines a set of all classes that are associated or grouped by applications and must coexist in the ing of a single database.

(2) name query

A name query is a predefined query that is assigned a name so that it can be accessed later. In database terms, named queries are called stored procedures. When combined with local queries (see the next section), database queries should be very easy.

(3) Local Query

Instead of using many restrictive entity query languages, local queries allow full use of the SQL language directly from ejbs. Now, we may directly call count (), max (), and other functions on the database without having to make other twists and turns.

(4) callback listener

A callback listener is an event listener or a trigger in database terms. They support code calls when an event occurs.

(5) detach/re-attach objects

It is unable to achieve this by leaving the control scope of an EntityManager and returning it again, resulting in continuous storage. In the past, to achieve this goal, we had to copy the value from an object to a POJO (common Java object), and then copy it back.

Before EJB 3.0, I always use a value-object and copy the value from EJB to a POJO. Then, I use this object on the front end. If a value in the POJO is changed, it will have to be "pushed back" to the EJB; then, the value is copied back. This "Chaotic" status no longer exists. An object can even be completely removed from the JVM and returned in a later period and re-attached. The efficiency of such changes cannot be underestimated.

(6) O/R ing type

It is difficult to map a field in an EJB to a column in a database before EJB 3.0. This feature has never been so satisfactory, and many third-party development tools have repeatedly postponed support for this feature. One feature of my favorite xDoclet is that it can define which SQL type corresponds to each persistent field in my EJB. With EJB 3.0 and annotation technology, we no longer need a third-party tool.

Ii. EJB 3.0 objects

It is worth noting that Enterprise Java Bean is now called POJO. With the emergence of annotation technology, java Beans no longer need interfaces, home and descriptor support files. This feature alone won the favor of a large number of development teams for EJB 3.0.

Now, since enterprise objects are no longer locked into the application server, we no longer need to copy and replicate them out of POJO, in this way, developers can easily display and edit data stored in ejbs without having to make the backend and front-end of the application server so strictly different. We will soon see the interesting effects of these changes on xDoclet.

Iii. Conclusion

Although there is no doubt that EJB 3.0 is based on Hibernate, it is actually based on all the top-level object/link Ing tools. It seems that this tool is not simply "modified", but is actually another outstanding "movie" created by Sun ". Developers do not have to learn a new tool with the same functions. Developers only need to spend some time upgrading to the new version of EJB 3.0, because EJB 3.0 is created based on the tools they already know and like