Upgrading Open Source Frameworks – Part I

Just recently, I created a series of proof of concepts for a client that concentrated on making components of a system available across the enterprise. The route chosen for these proof of concepts was Web Services, and the SOAP stack used was Apache CXF v2.1.3. In addition to the introduction of Web Services, upgrades of several open source frameworks were also performed, most notably Spring Framework v1.2 to Spring Framework v2.5.6, and Hibernate v3.0.5 to Hibernate v3.3.1. In addition, a migration from XDoclet v1.2.3 to XDoclet v2.0.6 (Codehaus) was also performed.

Such upgrades can involve varying levels of effort, depending on the situation. It must be first understood that conducting upgrades to software frameworks, with little exception, are not trivial matters because third-party frameworks help form the architecture of the associated systems. While the term “architecture” can denote various meanings, what can be generally agreed upon is that decisions of an architecture nature, associated with properties that have an affect upon the architectural and business qualities of a system, are typically best applied early in a software development effort since there are typically more implications to architecture changes in later life stages of a system.

The decision to investigate the upgrades sited was associated with the following architectural and business qualities:

• time-to-market
• maintainability
• system lifetime
• framework lifetime

Let’s take a look at each of these qualities one at a time.

Of the qualities being discussed here, time-to-market is perhaps the most self-explanatory. Essentially, a system in possession of this quality indicates that the associated software can be completed with greater efficiency, leading to a more timely release date. While the decision to use Apache CXF is a discussion in itself, the use of annotations that enable Web Services, including functionality provided by JAX-WS v2.1.2 in this case, can lead to a less complex setup time, as anyone experienced with annotations in general can attest, as long as the implications of using such powerful mechanisms are understood by the implementor.

Closely tied to time-to-market, a business quality, is maintainability, an architectural quality. Maintainability describes the degree to which a system can be easily supported, and modifiability and extensibility are two additional qualities which indicate how easily changes may be made (and with what level of disruption) to the associated software. Maintainability is somewhat akin to usability, except usability is typically viewed from an end-user point of view rather than the vantage point of a software developer who needs to use the source code that provides the end-user experience.

It is often said that 80% of the lifetime of a system resides in a phase generally known as maintenance mode, a time during which any given system is supported following its release into production. While the degree of maintainability will effect the course of the initial development effort, the lifetime of the system also needs to be considered. Most software systems have a greater lifespan than originally anticipated, and the commercial (COTS) and open source frameworks utilized within systems need to be chosen with this consideration in mind, and should optimally be assessed periodically to determine viability.

Back in late January, for example, I reported on some early rumblings of Spring Framework v3.0, the stable release of which is expected later this month. At that time, an interview with Rod Johnson (the originator of the Spring Framework) had just been made available, as well as a presentation by Jürgen Höller, also from SpringSource, which stated that although Spring Framework v3.0 will provide “100% backward compatibility” to the Spring Framework v2.5.x programming model and “95% backward compatibility” to Spring Framework v2.5.x extension points, he also noted that “all previously deprecated portions of the API will be removed for Spring Framework v3.0″.

Deprecation of course is not new with the Spring Framework. At any given time the API provided by the Java language itself includes various deprecated classes and methods marked for eventual removal. For example, I completed a Six Sigma project for a recent client that was essentially a cycle time performance initiative (with the achieved goal of providing considerable cost savings), and part of that effort was to upgrade Java 1.3.1 to Java 5; source code modifications to the custom software built for that client needed to be performed because of the deprecations involved with the associated Java upgrade.

To set the stage for an extended system lifetime, as well as enable the support offered by Spring Framework for Apache CXF, an upgrade to Spring Framework 2.5.6 was recommended to the client. Not only was the lifetime of the system itself under consideration, the lifetime of the frameworks utilized by the system also needed to be considered. In Part II of this discussion, we’ll discuss some of the implementation details of the open source framework upgrades introduced here.