J2EE application migration: From EJB to OccamJ with JDO

Author: Tim Stapleton, Beyond Browsing Inc
Tim is responsible for the enterprise software development business at Beyond Browsing Inc. His career in enterprise software projects has spanned 15 years and numerous commercial domains. He can be reached at (firstname DoT lastname at beyondbrowsing DoT com)

Technology keys: Java, J2EE, JDO, POJO, EJB

Abstract

This case-study documents a real-life migration of an enterprise J2EE application from EJB with CMP to OccamJ pure-Java object server with Open Access JDO. This solution both serves and persists ‘Plain Old Java Objects” dubbed a “POJO-POJO” approach. The subject is a software application that supports the production management of feature-length animated movies at a major Hollywood studio. This system is central to the management of the production process and supports approx. 300 interactive users and inter-process updates from a 1000 CPU render-farm.

The application had reached a size that was hampering ongoing development and maintenance. Compile and deploy times were approaching 10 minutes even on the fastest available hardware. It was also hoped to achieve in-production performance gains by using JDO and to simplify the production environment by running a single Java VM server with multi-CPU support rather than clustering multiple VMs.

The migration which took about 6 weeks to complete was deemed very successful: Compile/deploy times were reduced to less than 20 seconds. Initial production performance was approx 15% faster and JDO flexibility allowed optimization of critical components of the application to yield much greater performance.

1. Environment

Animated movie production is a complex operation involving hundreds of artists and production staff and thousands of computers with a typical duration of two to four years. These are highly complex operating environments employing various software tools for compositing, rendering and editing together with custom process tools typically written in perl, python or c-shell. The production management system tracks and routes the progress of each CGI (Computer Generated Imagery) artifact as it goes through the production pipeline. Updates are triggered by user-input and by inter-process input from the rendering and production tool systems. There may be five or more movies in various stages of production each of which can involve a million individual tasks.

The existing system architecture was an EJB implemented server with approx. 80 first-order entity beans using container-managed persistence (CMP). Server code was layered using stateful session beans as facades and stateless session beans for business processes and communication services (email, LDAP etc). Application clients included thin-client Java applications, JSP web pages and production tools written in script or C++. These inter-process services were hosted as web-services (SOAP).

The application was hosted on two 4-way SMP servers (primary and backup) fronting replicated Database Servers.