HIBERNATE- BASICS
(R.S.Ramaswamy)- ( in 3 parts)
(part-1)
( CMP-EJB vs. HIBERNATE)
(published in DeveloperIQ-July-2005)
The J2EE field is agog with excitement about a very popular open-source technology , Hibernate , being elevated to the status of JCP standard. Feedback from J2EE programmers in industry says that knowledge of Hibernate is mandatory for all J2EE aspirants.In this short tutorial , the author attempts to trace the reasons for this new trend & to alert us , to the imminent and dramatic changes in the J2EE landscape.
HIBERNATE is an ORM ( Object-Relational-Mapping)
technology. It is an Open-Source and free technology , developed in SourceForge.net.
There have been a number of such ORM technologies,in recent past.. TopLink
is one such tool , subsequently adopted by Oracle and so proprietary. Hibernate
from SourceForge and OJB(Object-Relational-Bridge) from Apache are two
well known ORM tools, open-source and free. JDO, also falls within the
same category.
Gavin King is the lead for Hibernate and Craig Russell & David
Jordan, the lead authors for SUN-sponsored JDO effort. Due to some technical
problems, it appears that the majority in JCP favours Hibernate today instead of
JDO.At first reading though, the difference is not, all that apparent. The
syntax and the approach appear to be almost same, but Hibernate syntax is easier
to learn.
It is interesting to note that Craig Russell works for SUN and Gavin King is now
with JBoss. It shows that JCP is a democratic community and SUN is not dictating
terms except to protect the language and its enterprise-level users.
EJB-3, is the latest version and it is heavily influenced by Hibernate.
Some readers equate EJB-3 with Hibernate. Some even equate EJB-3 with JBOSS!
Oracle supports EJB-3 proposals and as it is the main Database company in j2ee
world, EJB-3 has bright future. J2EE( Java Enterprise Edition) by its very name
is an Enterprise level technolgy, and as EJB is the essence of such Enterprise
applications,because of the built-in container services offered, the
significance of the surging interest in Hibernate can be really appreciated only
in association with EJB and hence a detour into EJB is inevitable.
EJB has three types. One type is the SESSION BEAN,residing in ENTERPRISE
container, which can be thought of as a function-bean, invoked in RMI-IIOP
style.(this is a rough definition). Such session-bean , may be either stateless
or stateful. This type of EJB has stood the test of time during the last six
years and has even gained wide approval,even for data-access, especially since
it fits very well with the emerging XML WebService technology, and is very easy
to learn and implement.( The earlier tutorial on EJB as webservice in Feb-2005,
in DeveloperIQ illustrates this feature). The stateless bean working in
Enterprise container has an exact counter-part in Microsoft COM+(MTS). but the
other types are said to be available in MS platform only through third-party
extensions.
ORM tools have been sometimes used along with Session
beans. The only problem till recently was that they were proprietory and rather
costly. But nowadays, very reliable open-source ORM tools are available, and
even Richard Monson Haefel ( an acknowledged authority and author on
EJB)approves this method as a safe and productive alternative to Entity beans.(
page-467..EJB by Haefel-OReilly).
The other branch, the ENTITY BEAN has been less lucky. EJB-1.1,EJB-2.0 and then
EJB-2.1 , have meant a number of changes in the specification relating to Entity
Beans.
We can say that an Entity bean is an 'Attribute bean' or 'property-bean', with
setter and getter methods, invoked in RMI-IIOP style and persisted in Enterprise
container. The pattern of defining a typical Javabean is a recurring theme in
Java. The same style occurs in BDK,EJB-Entity beans, Struts,JSF and now in
Hibernate too. So, it is very important and elegant.
The third branch is Messaging paradigm and MDB. A recent article in the web
dubbed the 'RPC' style, on which the previous two types of EJB are based, as
stone-age technologies! An Enterprise by its very name implies huge number of
customers and concurrent transactions, RPC style being like telephone call,
could result in 'line-engaged!' problem.If the call involves the called person
referring to some records before replying, it leads to line- blocking.But,
messaging style, as in email, atleast ensures that the message has been sent.It
is evident that dubbing RPC( read 'telephone') as unsuitable , is over-statement.Sometimes,
we desire immediate response,too. By the same token, even XML webservice , if it
is really serious, should adopt messaging style and it does.MDB (Message-Driven
bean) has weathered the storm and is in fact gaining more and more acceptance.
So, why is it that Entity beans alone were found wanting and the specification
keeps on changing?
Entity beans are of two types. CMP & BMP.
CMP stands for Container-Managed Persistence and BMP stands for Bean-managed
persistence. Theoretically, the EJB specification does not say anything about
the method to be adopted in persisting objects for permanent storage and
retrieval. It could be simple object serialization. The database may be
object-database or Object-relational database or XML.In practice , however, a
database has always meant a Relational Database and its SQL.
In a very complex Enterprise application, we begin with Modelling. Instead of
dealing with tables and their complex inter-relations, it is more intuitive to
deal with classes and objects. Thus we design our system , 'thinking in objects'
and not in tables. So long, as we are dealing with objects in memory or with
objects persisted in hard-disk simply as objects, there is no problem, except
that object-serialization , especially of complex objects is a slow process. On
the other-hand, Relational Database technology is fast, time-tested, well-known
and famous. So, the problem is to work with objects in memory but persist the
objects in hard disk as relational database.
This is what is known as ORM ( Object-Relational Mapping).If we opt to
deal directly with tables only and either read data or manipulate data by
session beans, we skip the entire ORM problem.But how practical is it for really
complex projects?That is the rationale for the development of Entity Beans in
EJB.
In CMP, the coder deals with objects, only in memory. He creates new
objects, modifies them, deletes them and views them , all in memory. The task of
saving these objects in memory ,to the relational database table is done by the
container, automatically. The coder does not write any sql-related code
for this.
In BMP, the coder has to write the sql to persist the object in memory to the
relational database.
CMP in EJB1.1 was suitable for simple tables, without complex relationships to
other tables.CMP avoids all references to the underlying database. So, it is
more portable. There is no vendor-lock-in.CMP can persist data to Object-
databases also, besides Relational databases.
But, CMP is not always suitable. If the database is some legacy type, which
cannot be used with SQL, the database company gives a proprietory code for
persistence and such code has to be used in our program to persist data. The
facilities given in CMP originally were found to be too elementary and there
were complaints.
But, what matters is that CMP makes use of ORM concepts, though the
implementation left much to be desired. It did not expose how the EJB vendor
implements it.Weblogic,Oracle,IBM WebSphere, SUN ,JBoss , each may implement CMP
in any way that they deem fit.Except in special circumstances, it will be better
to use CMP, not merely because, it makes the code more portable & is easy to
write. Much more important reason is that the EJB container can optimize the
performace dramatically, if we adopt CMP.So the developer community wanted to
adopt CMP but found it unsuitable for really complex jobs.
And a sizable section of developers found the XML Deployment Descriptors for CMP
,
especially for complex jobs, a bit troublesome and tedious.It can be said that any
design which makes us dependent on wizards, is a bad design. Unlike the
Deployment Descriptors for Session beans, which can be hand-coded in a jiffy, by
just find/replace method in a text editor, the DD for CMP required three XML
files, two of them very special to the container used.
In order to improve things, EJB 2.0 proposed a few changes, mainly in the matter
of writing CMP. It provided for Relationships. It proposed a simple query
language known as 'EJB-QL'. Since, calling an Entity bean through a session bean
(Facade pattern) is more efficient , from the viewpoint of minimizing network
traffic, the very concept of remote interface for entity beans was questioned
and so local interface also was provided for Entity beans.( In a total
reversal, there is no local interface in EJB-3! and instead of EJB-QL
, Hybernate Query Langauge is taking over in EJB-3).
Even with all these improvements, CMP was found to be less than the ultimate
solution. There was no possibility for Inheritance.
Though the container services provided by the EJB
container are indispensable in a truly large enterprise application, the J2EE
camp is almost vertically split into WebTier & EJB-Tier votaries. The
WebTier supporters claim that EJB with its steep learning curve and error prone
development environment for developers is not really necessary for most
applications. And they would like to have an ORM tool , built into the J2EE
specification. For afterall, ORM task is not specific to EJB alone. Even
Servlets and JSP could use them. In fact , they have been using them, though the
J2EE specification was silent about it. ORM tools like OJB, JDO and Hibernate
can be used not only in EJB containers but in webcontainer and even in
standalone containers. Gavin King makes it a special point in favour of
Hibernate.Making such a tool , a J2EE standard, would make development tasks far
easier ,to develop either web-tier application or ejb-tier application. saving
us from the medley of classpath to required jars.
In a scathing attack on the complexity and questionable performance of EJB Entity
beans (though, unjustifiably on EJB itself), Rod Johnson, prophesies
, that in a few years' time, J2EE will cease to include EJB.Whether , we agree
or not, it is worth looking into the criticisms against EJB Entity beans ,raised
by him.( 'J2EE Development without EJB'-Wrox/Wiley/DreamTech-2004).For, he is
proposing the Spring Framework as an alternative to EJB container and the idea
is gaining ground.J2EE developers and students may have to re-orient themselves
rather abruptly, to remain relevant to industry.
In the next part of this introductory tutorial, we will acquaint ourselves with
the basic features of Hibernate.