Calcey is currently engaged in the challenging task of overhauling the persistence layer of the software platform for a leading multi-player gaming company based in Silicon Valley. The client’s Java-based software infrastructure is a complex blend of different technologies such as Spring Framework, JSP, Tapestry, HiveMind, Hibernate, Oracle, MySQL and PostgreSQL. The versions of some of these frameworks used are deprecated and have been targeted for gradual replacement by the client. Discussions took place on how to maintain the platform tiers independent and flexible for different technologies. There was particular concern about the persistence layer of this platform, which had been wired using outdated Hibernate 3.1 technology.
The Hibernate framework is used for mapping object-oriented entities with a relational database. Being open-source software, Hibernate has its advantages and disadvantages. The main disadvantages of Hibernate are:
- It is an open-source solution framework and often goes through model revamps. Upgrading from an older version of Hibernate to a newer one can prove to be very difficult owing to the frequent changes in hibernate-specific APIs.
- Switching from the Hibernate persistence framework to another alternative is time-consuming, due to its proprietary query language and annotations.
- The custom implementations of certain Hibernate features like caching introspection are not mature and are possibly earmarked for deprecation.
- It is the industry standard today for the ORM layer to be unbounded by a specific technology.
After all, keeping one’s application layers simple, independent and swappable is an architectural principle that an organization would aspire to have. So a goal was set for Calcey to migrate the existing JPA incompatible ORM layer to meet the JPA 2.1 standard. The migration would ensure that the ORM layer was independent of Hibernate-specific class libraries, thus enabling easy configuration of different ORM technologies such as Eclipse Link or MyBATIS.
Migrating from one ORM to another can be a simple task once JPA is implemented, as is demonstrated below:
The Calcey team did a preliminary assessment of the interfacing points in the code base (with the ORM layer) and decided to initially migrate from Hibernate 3.1 to Hibernate 3.5 (Hibernate 3.1 which does not meet the complete JPA standards and is buggy). Thereafter, the team stepped into refactoring the code in earnest – a time-consuming task due to the many data calling points within the other architectural layers of the system, often occurring from different frameworks such as Tapistry and HiveMind.
A team of two developers and a tester are dedicated to this project, which happens to be my first project management assignment at Calcey. We have scoped out the requisite changes over a somewhat longer period of time, to manage the regular feature implementation requests in parallel to this important refactoring exercise. Calcey hopes to complete this refactor in the coming three months.