RSS Feed
Download our iPhone app
Browse DevX
Sign up for e-mail newsletters from DevX


Migrate Your J2EE Apps from EJB to Hibernate

You've decided to switch from EJB to Hibernate for persistence in your J2EE applications, but you don't know what to do with your existing EJB tier. Learn how a few decisions upfront, some simple ground rules, and design patterns can smooth the transition.

ccording to its Web site, Hibernate is a "powerful, ultra-high performance object/relational persistence and query service for Java." And they're not just blowing smoke. Hibernate is a key player in the movement towards more lightweight designs and is quickly becoming the Java persistence tool of choice. The decision to use Hibernate for new projects is a no-brainer, but for mature applications the choice is not as clear-cut.

If you have a large J2EE project—possibly in production—is migrating your existing homegrown or entity-bean-based solution worth it? Perhaps, it all depends on whether your existing persistence layer is deficient or unable to scale to meet your long-term goals. In some cases, the risk may be high and the costs outweigh the benefits. But if you've decided to go with Hibernate, you can minimize the impact of the change and make the transition—if not painless—at least well structured and predictable with a bit of upfront design.

Hibernate itself is a deceptively simple component to integrate. You can be up and running within a few hours. But once you've mastered the basics, you need to consider Hibernate in the context of your existing architecture. This includes:

  • Your migration strategy
  • Logical design
  • Packaging and configuration
  • Session handling strategy
  • EJB interactions: transactions, caching strategy, and primary key generation

Migration Strategy
You can use one of two basic integration approaches:

  1. Big bang — Migrate your persistence tier wholesale all at one time.
  2. Staged — Port it gradually, object by object or by functional or component grouping.

The advantage of a big-bang approach is that it makes a clean break with your old architecture and ensures a consistent platform going forward. Your code will be more uniform and easier to maintain and you don't have to worry about entity/Hibernate wiring. However, doing it all at one time carries a high risk and may not fit in with your other work streams. The reality is that project teams seldom have the time, resources, or inclination to rewrite and test an entire application tier.

Adopting a staged approach is less risky, but it isn't as clean in terms of logical design. Hibernate is container friendly. It will happily co-exist with your entity beans and participate in container-managed transactions. So you can migrate gradually, mixing entities with Hibernate. The disadvantage of this approach is the added complexity and maintenance. Developers will have to maintain at least two distinct flavors of persistence logic and understand which one to use in any given use-case.

Applicability of Hibernate
Be wary of using a one-size-fits-all approach to adopt Hibernate. A common mistake is to use Hibernate exclusively for all data-access functions. Hibernate is not applicable for all types of data access; it is suited for object-centric access. So if you're performing reporting queries or batch processing, you may want to keep those parts of your existing infrastructure as is. Hibernate is appropriate for persisting and querying for objects, typically elements of your domain model.

Testing Is Essential
Obviously, regression testing is essential to any migration effort. Think of testing as your migration safely net. It's only with testing that you can validate your migration strategy, whether your code works, whether it is consistent with expected behavior, and that you haven't broken anything else. If you don't have a regression test suite already in place then create one. If it seems like unnecessary overhead, consider that fixing bugs now is a lot cheaper than fixing them later on in the migration cycle. You can add test cases gradually as you convert each object to Hibernate. Without regression testing, you simply won't know whether your code works until a user calls with a problem.

Close Icon
Thanks for your registration, follow us on our social networks to keep up-to-date