Object-relational mapping EJB and Hibernate

Size: px

Start display at page:

Download "Object-relational mapping EJB and Hibernate"

Earl Potter
5 years ago
Views:

1 T A R T U Ü L I K O O L MATEMAATIKA-INFORMAATIKATEADUSKOND Arvutiteaduse instituut Infotehnoloogia eriala Aleksandr Tkatšenko Object-relational mapping EJB and Hibernate Referaat aines Tarkvaratehnika Juhendaja: Ivo Mägi TARTU 2005

2 Contents Overview... 3 Persistence... 3 ORM... 4 EJB... 4 Types of EJB... 4 EJB 2.1 and EJB Hibernate... 6 Description... 6 Pros and cons... 6 Conclusion... 7 Used material... 8

3 Overview In object-oriented languages of our times programming objects represent real-world objects. This approach enables programmers to use the benefits of programming concepts such as polymorphism and inheritance to handle the most complicated tasks. But the problem arises as it comes to persistence, which becomes one of the most common requirements to modern applications. Object persistence means that individual objects can outlive the application process; they can be saved to a data store and be re-created later. Although there are several ways to store persistent data, relational database technology is the most spread one due to its flexibility and robustness in data management. However, tabular representation of data in a relational system is fundamentally different than the graphs of objects used in object-oriented Java applications. It means that programmers are required to allow their software to function in two different worlds processing of data would be done in object-oriented form, but the same data would have to be stored in SQL form. This semantic gap has led to so-called object/relational paradigm mismatch. Several solutions are available now to manage it. Object-relational mapping (ORM) solution seems to be the most suitable for many scenarios at the moment. Here we will concentrate basically on such persistence implementations as Hibernate and EJB CMP. Persistence As have already been mentioned, persistence layer is a tricky point in an application structure. It should be considered especially carefully due to the following reasons: Almost all projects have to face the persistence issue, Persistence comprises considerable amount of the project budget, Persistence can significantly affect the performance of application, Programmers spend a lot of time doing the same thing over and over. In Java programming language there have been a range of solutions addressing the same problem. Let s take a look at some of them. Serialization It is a build-in Java persistence mechanism, providing ability to write objects to the persistent storage. The main limitation of this method it that only the entire graph of objects can be serialized, and such operations as search and update are not available unless the whole graph is retrieved. Writing JDBC by hand It is the best solution in case of applications with intensive data transfer. Although this method isn t preferred at it significantly lowers the readability and maintainability of the code. Object-oriented databases Object-oriented database management systems allow storing data in its object representation. Application and data store are tightly coupled together and no intermediate means is used for interaction between them. One of their main limitations is that switching from an SQL DBMS to a purely object-oriented DBMS means you lose the capability to create SQL queries. This technology hasn t been widely adopted by now and relational model is still a preferred way to store data. As we can see, these techniques have their cons and pros. They can be perfectly applicable in certain tasks while imposing severe limitations in others. Next, we will discuss ORM.

4 ORM Object/relational mapping (ORM) is a solution of the object/relational paradigm mismatch gaining an increasing acceptance at the moment. It can be defined as the automated persistence of objects in a Java application to the tables in a relational database, using metadata that describes the mapping between the objects and the database ( Hibernate in action ). ORM technique bridges between object and relational models of data. It means that each class represents a certain database entity, and each record will be a class object. The major advantage of ORM is that it releases programmers from the tedious work of writing SQL by hand, which saves time and makes the code more readable and, hence, maintainable. Applications using ORM middleware, can be expected to be cheaper, more performant, less vendorspecific, and more adaptable to the changes in internal objects or SQL schemas. There is a range of tools (mappers) implementing ORM technology. The full-featured mappers are expected to support different databases, provide certain optimization techniques, define mapping metadata, persistent class appearance and lifecycle of persistent objects, address concurrency, inheritance, polymorphism, transaction and cache management problems and implement other functionality which is difficult to hand-code in real terms. Hibernate is an open-source ORM implementation providing core and additional functionality of a full-featured mapper. It s free and not so complex (to get started), which makes it widely acceptable as a decent persistence solution. In EJB, persistence is implemented by Entity beans. Until recently this technology (EJB 2.1) has been less successful, basically, because of the excessive complexity and questionable performance of EJB Entity beans. At the moment the specification of EJB 3.0 is available which aims at simplicity, standardization and extension of functionality. EJB An Enterprise JavaBeans is a part of J2EE technology. Its components, or enterprise beans, can be defined as a body of code encapsulating the business logic of enterprise application on the J2EE server. To simplify the development of large, distributed applications, Enterprise beans make use of EJB container, which undertakes for such system-level services as transaction management and security. Enterprise beans are also said to be portable components, able to run on any J2EE server in case they use standard functionality. Types of EJB There are three types of enterprise beans: Session bean represents a single client inside the Application Server. To access an application that is deployed on the server, the client invokes the session bean's methods. The session bean performs work for its client, shielding the client from complexity by executing business tasks inside the server. Entity beans represent a business object in a persistent storage mechanism (usually RDB). They allow shared access, have primary keys, and can participate in relationships with other entity beans. There are two types of persistence for entity beans: bean-managed (BMP) and container-managed (CMP). With bean-managed persistence, the entity bean code contains the calls that access the database. If a bean has container-managed persistence, the EJB container automatically generates the necessary database access calls. Message-Driven beans allow J2EE applications to process messages asynchronously. It normally acts similarly to the event listener except that it receives JMS messages instead of events. The messages can be sent by any J2EE component - an application client, another enterprise bean, or a web component - or by a JMS application or system that does not use J2EE technology. Messagedriven beans can process either JMS messages or other kinds of messages.

5 These components reside in EJB container and can interact with each other in order to implement common functionality of the application. As we are mostly interested in the way, how persistence is managed in EJB, next we ll emphasize the implementation of CMP Entity beans. EJB 2.1 and EJB 3.0 As it has already been mentioned, EJB 2.1 was not the best solution in practice. It is complex, first, because of the number of artifacts the application requires to work properly. Programmer has to define classes of implementation and primary key, home and bean interfaces, deployment descriptor (ejb-jar.xml) file, containing mapping metadata and also other vendor-specific descriptor(s). Second, EJB 2.1 uses a lot of infrastructure: Value objects, BusinessDelegates, Session Stubs, which also have their own intricacies. Definitely, such complexity takes lots of time to learn and distracts from business logic. CMP, proposed by EJB 2.1 specification as persistence implementation, doesn t fully solve the object/relational mismatch due to the following reasons: CMP entity beans precisely correspond to the database tables, what brings limitations in using java s reach typing. It also means that these entity beans are more sensitive to the changes in schema. Entity beans don t support inheritance and polymorphic associations and queries. It is a significant obstacle as we are dealing with object-oriented design. Entity beans aren t serializable. EJB require unnatural Java style what makes it difficult to reuse the code outside the specific container. Choosing EJB solution we also sacrifice performance, especially in case of large, resourceconsuming data sets. It makes this approach poorly usable in applications with intensive data transfer. Such excessive complexity and a set of limitations often cause the developers to escape to either writing JDBC/SQL by hand or using other persistence solutions. On the contrary, the EJB 3.0 release considers the experience and deficiencies of its predecessor and counterparts focusing on simplification of API, reduction of the number of artifacts and sensible default settings ( configuration by exception ). Not surprisingly, the major change in EJB 3.0 underwent Entity beans. The ORM facilities have been enhanced by support of polymorphic queries and associations, multitable mappings, join-table support and extensions of EJBQL. As EJB 3.0 takes advantage of JDK 1.5 annotations, the deployment descriptors can be either ditched or used to override annotation types and provide more complex configuration. It s recommended to use annotations if applying metadata changes the design of the class or the design of code interacting with the class. Purely logical entity bean annotations @Basic, fall under these rules. Vendor-specific annotations can, however, affect the portability of the code (and hence should be avoided as much as possible). This rule refers, for instance, to table and column annotations. It s also suggested to map primary key generators in XML files, as some databases don t support sequences and Identity generation. Another change to entity beans is that now they are pure POJO. They can be created in a standard way using new() operation and interaction between persistent storage and objects in memory is managed by EntityManager service. Precisely, EntityManager is responsible for creating, removing, finding persistent entities and querying over them. It manages the lifecycle of the entity beans. EJBQL has been significantly perfected. In EJB 3.0 it supports all the SQL functionality: group by, having, inner and outer join, subqueries, bulk update and delete operations have been added.

6 As we can see, these changes significantly improve the situation over CMP Entity beans in comparison with the previous release. Although it s not the final release of the specification, EJB 3.0 technology offers full-featured persistence engine to deal with object-relational problem in appropriate way. By this time some vendors provide early-access downloads of the new technology and it is expected to gain popularity in the nearest future as the final release of specification is available. Hibernate Description Hibernate is a proprietary persistence framework. It is free/open-source project, providing full functionality to manage the persistence layer of applications. Hibernate does not require any Application server and can be used in standalone applications. It is relatively simple and also welldocumented, what makes it so popular at the moment. Hibernate technology is used to manage persistence on JBoss Application server. Hibernate implements persistence in the way similar to EBJ: a class represents a database entity, and each record in the database is a class object. Queries return either a single object or a Java Collection of multiple records (Map, Set, List, SortedMap, SortedSet, arrays, Collection are supported). The instances can be either in transient, detached or persistent state. The transient state corresponds precisely to the EJB 3.0 new state and means that an instance isn t and has never been associated with persistent context. Hibernate s persistent state is similar to EJB s managed state what means that instance is currently associated with persistent content and has an identity (primary key). Instances become detached after the closure of persistence context. As we can see the EJB s removed state isn t implemented in Hibernate. Hibernate has a much simpler infrastructure than EJB. Generally it contains connection management, transaction management and ORM component. It can be run in either light or full cream mode. The light mode assumes that a minimum subset of Hibernate API is used and application manages transactions and JDBC connections on its own. In case of full cream architecture Hibernate take care of the details. These two types of architecture can be considered as analogues of BMP and CMP in EJB respectively. As for the artifacts, it is necessary to provide only Hibernate configuration file, mapping file(s) and POJO Bean(s). The distinctive feature of Hibernate is its flexible ORM syntaxes. It supports inheritance and polymorphism, bidirectional associations, hand-written SQL, stored procedures, multiple key generation strategies and composite keys. Some of these solutions were successfully adopted in EJB 3.0 specification. The mapping metadata can be either written by hand or using such tools as XDoclet or Middlegen to generate deployment descriptors out of annotations provided in POJO Bean classes or out of database schema respectively. Hibernate annotations which satisfying the EJB 3.0 specification can be used with Hibernate 3.1. Hibernate uses HQL to manage data. This query language fully covers the specification of EJBQL 3.0 and additionally provides several enhancements such as query by criteria" and "query by example" API. Pros and cons The main benefit of Hibernate is its simplicity without loss of functionality. It s basically provided by efficient query language it uses, flexible ORM and existence of tools which help to manage mapping. The next advantage is that it doesn t require an Application server and its APIs are pluggable in any container. On the other hand, Hibernate as any other proprietary framework has its own particularity. What works with Hibernate may not work with other frameworks. Hibernate also provides no means to

7 manage security and so it is left on database level only. And, finally, large data sets are still a threat to memory. Conclusion Surfing the net, I found a number of opinions that Hibernate is equals to EJB 3.0. And it s difficult to disagree with it, especially considering the fact that that EJB 3.0 specification was heavily affected by Hibernate and other successful solutions of our days. These two technologies have their common features: they use 1.5 JDK Annotations and EntityManager (optional for Hibernate) and have similar O/R mappings, query languages and object lifecycle. But in spite of these similarities in appearance, I think, that the fields of implementation of these technologies may vary. EJB is indispensable, basically, in large enterprise applications which require security, cashing and clustering. Hibernate, though, may perfectly suit as a fast and effective solution in case of small and middle-sized standalone applications. Hence, I think, that they are not competitors, but good supplements to each other to address the object-relational paradigm mismatch and certainly have bright future.

8 Used material [1] Hibernate in action Christian Bauer, Gavin King [2] J2EE Tutorial [3] JSR-220, Enterprise JavaBeans 3.0 Specification [4] Hibernate Reference Documentation Version: 3.1rc1 [5] EJB 3.0 article [6] Wikipedia

Web Application Development Using JEE, Enterprise JavaBeans and JPA

Web Application Development Using JEE, Enterprise Java and JPA Duration: 35 hours Price: $750 Delivery Option: Attend training via an on-demand, self-paced platform paired with personal instructor facilitation.