Migrating a J2EE application from EJB to JDO
My enterprise line-of-business experience has presented some specific challenges that no doubt have shaped my outlook on software development.
Here are a few points on enterprise builds:
1. They are long-living applications. Typically 10 years. This makes technology choice tricky as it’s very easy to become hostage to a technology that is constantly evolving and requiring continual ‘ports’ to the latest releases. There will always be technology upgrades needed but this can be quite expensive in nascent technologies.
2. They are complex with far more entities and ui screens than typical BtoC applications. They tend to test the scalability of the development tools. It’s an uncomfortable situation when your project is larger than anything that the tools vendor has previously dealt with.
3. Developer productivity is usually an issue. These projects typically involve replacing existing systems written in an older technology (AS400, Mainframe, 4GL etc). While these older technologies deliver applications that are much less rich than a modern Java or Java/Web application, they are very efficient from a developer perspective.
4. They usually involve training of an existing developer workforce to work with the new technologies. It’s often not practical or desirable to replace the development team when implementing new technology. There is a large amount of business and domain knowledge vested in the existing developers.
In my experience EVERY company underestimates the time and effort needed to make this transistion. It’s not just Java anymore; It’s Java and J2EE and Web and Web services and a new IDE and the specifics of a particular application server. And in addition there’s the transistion to the distributed environment. This can be quite a leap.
These experiences have drawn me towards solutions that are as simple and as effective as I can find; as can be seen in the following case study.
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 â
Annotations are not good for ‘config’ data. As a means of describing common patterns to be applied to code so that boiler-plating can be generated it is the best.
Using Hibernate with XDoclet is an example of what annotations want to address.
Imaging writing a POJO and adding @WebService in front of the class.
Deployment descriptors are a problem because they try combine different kinds of configuration information. The are wiring that should not be change because the system will break. Then there is a need for configuration options that should be easy to change and defined in a standard way. This is still abscent from most specifications I have seen.
Corneil du Plessis