Previous    Next

Portability Issues

Java's fundamental premise of Write Once, Run Anywhere (WORA) ensures that J2EE apps are far more portable than apps written using any comparable platform. We can be sure that Java objects will behave consistently in different environments, while the Sun J2EE Compatibility program helps guarantee that different J2EE servers fulfill the requirements of the J2EE specifications. As J2EE servers tend to be written in Java, servers themselves are usually supported on multiple operating systems. Unfortunately, the CTS doesn't present the complete picture. It's good that an app written within the bounds of the J2EE specifications can be ported between servers. However, what if a real-world app needs to go beyond the scope of the specifications? Let's examine what portability actually means in a J2EE context.

What does Portability Mean?

There are several issues around the portability of J2EE apps:

• Portability of apps between app servers
  This is probably the first issue that comes to mind when we think about portability in a J2EE context. Portability of apps between app servers will usually depend on the following factors, most of which are under our control:

  • How faithfully does the target server implement the J2EE specifications?

  • How compliant is the app's code to the J2EE specifications? Unnoticed violations are a hindrance while porting apps, when the target server enforces a different subset of J2EE requirements.
  • How much does the app make use of proprietary features of the original server?

  The Sun CTS helps eliminate the first issue. The second can be avoided by a thorough understanding of J2EE, and discipline during app development. This leaves the third: a much harder problem (we should, of course, only use proprietary server features when they deliver real benefit). I'll discuss strategies for ensuring that access to proprietary extensions does not break portability below.

• Portability of apps between server operating systems
  J2EE scores very well here. Java as a language is extremely portable. Virtual machines on all server operating systems are reliable. Leading app servers are tested on multiple platforms, and so it's likely that an app can be ported (for example, from Windows 2000 to Solaris) without any development work being required. The J2EE specifications discourage server-specific implementation features, such as use of the file system in business objects.
• The ability to change important resources that J2EE apps rely on
  The obvious case here is switching database. In fact, this rarely happens after a system is deployed. There is a saying that "Data tends to stick where it lands". In practice, it's much more likely that the J2EE app will be radically altered than that a live database will be migrated. In this case there are two possible scenarios:

  • Change to a comparable, competing resource. Imagine that we need to migrate from a proof of concept with Cloudscape to a deployment on Oracle. JDBC provides a basic level of abstraction here, although it will usually be necessary to modify SQL statements.

  • Change of resource type. This involves a more radical shift: for example, from an RDBMS to an ODBMS. Achieving portability in this case will involve a higher level of abstraction, such as entity beans. However, the likelihood of such change is more remote, and abstraction at such a high level may degrade efficiency and complicate app code.

It's vital to distinguish between these issues. I feel that far too much emphasis is placed on database portability, in particular. This reflects an unrealistic J2EE-centric view of enterprise IT. Organizations invest a lot of money in databases. They don't jump ship often, and expect this investment to be leveraged. Thus, it's unwise to ignore the potential of proprietary database features in simplifying app code and improving performance. Portability between app servers, on the other hand, is more easily achievable and may deliver greater business value. It's important to remember that we can enjoy some benefit from J2EE's portability even if we never choose to migrate our apps to a different platform. Since J2EE supports such a wide variety of implementations, there is a large community of J2EE developers with experience on a variety of platforms. This makes for a valuable mix of skills in J2EE teams. I'm reminded of this whenever I work with a Microsoft-only organization.

In summary, the J2EE portability news is good, but complete portability is neither possible nor desirable. The limits of portability largely reflect performance imperatives and the limits of the J2EE specifications, and the resulting need to use platform-specific technologies. As we shall see, there are techniques we can use to work around these issues.

A Pragmatic Approach to Portability

As we've already discussed, refusing to use any vendor-specific functionality is dangerous. Architects and developers are employed to deliver working solutions for real organizations, not produce "pure" J2EE apps. However, this doesn't mean that it's impossible to design for portability. This can be achieved in three ways:

• Write code that complies with the J2EE specifications. Adopt organization-wide standards for writing J2EE-compliant code, and ensure that all developers understand and follow them. Use the J2EE Reference Implementation verifier tool regularly to check compliance.

• Know the capabilities of the standard J2EE infrastructure and avoid using platform-specific solutions when a satisfactory standard alternative exists. However, don't just reject proprietary solutions automatically.
• Use loose coupling to isolate the use of platform-specific features for ensuring that the app's design (if not all its code) remains portable.

Previous    Next