Portability Verification of Applications for the J2EE Platform

Print-friendly Version

The Java 2 Enterprise Edition (J2EE) is a specification for an enterprise framework that has been widely adopted for its multi-platform, Internet-ready, thin-client architecture. J2EE provides a comprehensive specification for enterprise-wide Java technologies, as well as server-side and client-side support for developing multi-tier enterprise applications.

Application portability -- a key feature of the J2EE platform -- means that a J2EE application should run on any J2EE-compatible application server, with zero-cost modifications (that is, no change to the code is necessary, only changes to the deployment descriptors), or no modifications at all. Although J2EE is the most portable, vendor-neutral enterprise framework, some implementers may neglect certain key issues, leading to applications that aren't completely portable across J2EE-compliant application servers.

In this article, I'll introduce portability, and address some of the key portability issues. In addition, the article covers the following topics:

• Compatibility of different J2EE application servers
• Techniques for portability
• Java BluePrints program
• Java Verification Program
• Java Application Verification Kit (Java AVK)

J2EE and Portability

One of the most important benefits offered by the J2EE platform is application portability. A couple of the benefits of portability include:

• Development can start early: The development of an enterprise application can start before a J2EE implementation has been chosen. The code should be portable to any J2EE application server, at zero-cost.
• Freedom of choice: If you decide to switch to a different J2EE application server after several months into production, all existing code should run on the new J2EE application server, again at zero-cost.

The J2EE specification defines how the various J2EE technologies -- such as Servlets, JavaServer Pages (JSPs), Enterprise JavaBeans (EJBs), and others -- must behave. In theory, if this behavior is implemented correctly by different vendors, an application developed to the specification will run on any J2EE application server without modifications. In reality, however, it is not that simple. Think of the J2EE specification as a contract between the implementers of the specification and developers. Both parties must understand their responsibilities in order to have portable applications.

J2EE Implementation Compatibility

The J2EE Reference Implementation (RI) gives developers a sample implementation that can be used for learning the J2EE platform. In addition, it demonstrates how the J2EE platform specification can be implemented, and allows software vendors to test and verify the correctness of their implementations.

J2EE application servers are available from different vendors, including IBM (WebSphere Application Server), BEA (WebLogic Application Server), IONA (Orbix E2A Application Server), Oracle (9i Application Server), Sun (Sun ONE Application Server), and many others. To make sure that such implementations are compatible with the J2EE platform specification, Sun provides the J2EE Compatibility Test Suite (CTS), which is a standard set of over 15,000 test cases derived from the J2EE specification, used to test conformance to the J2EE specification. J2EE implementations that pass the CTS are considered J2EE-compatible. Click here for a list of J2EE-compatible products.

Write Once, Run Anywhere: Portable applications will run on all J2EE-compatible servers.

Vendor-Specific Extensions

Many J2EE implementations provide and support vendor-specific extensions to the J2EE. Such extensions are not inherently bad, because they drive innovation, but you need to understand that you must choose from among three options:

1. Limit yourself to the standard set of APIs defined in the J2EE platform specification, to maximize chances that your applications will run as is on other J2EE application servers.
2. Design your application in such a way that, if it is deployed on a server that doesn't support the vendor-specific server extensions your application uses, it can still default to the standard set of APIs. Catching exceptions is a valid way to implement this approach.
3. Make the calculated decision to develop different versions of the same application for different J2EE application servers. For obvious reasons, you should avoid this option.

It's worth noting that portability matters most to developers who want to sell their products to different customers, running different J2EE application servers. For in-house business applications that run on one platform that will never change, however, portability is obviously less important.

J2EE Best Practices

As demonstrated in two earlier articles by Liz Blair -- Build to Spec!, Part I and Build to Spec!, Part II -- even if you follow the specifications, you have to be meticulous in order for your applications to be portable. As a simple example, you must ensure that all of a bean's instance fields are serializable, so that the state of the bean can be preserved when the bean is passivated. Fields of primitive types like int and double are serializable, but fields that reference a class instance are serializable only if the reference's class implements java.io.Serializable, as demonstrated in the following snippet of code:

public class EmployeeEJB implements EntityBean {
   private int age;
   private double income;
   private EmployeePublications

   // rest of class
}

public class EmployeePublications implements Serializable {
   private String article;
   private int year;

   // rest of class
}

Now, since the EmployeePublications class is serializable, EmployeeEJB fields are also serializable.

To address such technical requirements, Sun's J2EE BluePrints provide developers with guidelines, patterns, and sample applications, such as the Adventure Builder and Pet Store sample applications. Overall, the J2EE BluePrints provide best practices and a set of design patterns, which are proven solutions to recurring problems in building portable, robust, and scalable J2EE applications.

Note: There are a number of key areas in the J2EE which have portability limitations, including deployment descriptors and security permissions. You can get rid of deployment descriptors incompliance using XDoclet. Security isn't portable, but J2EE 1.3 requires a specific authentication mechanism, such as Java Authentication and Authorization Service (JAAS). You might like to try the OSUser, which is a set of interfaces and providers (EJB, JDBC, LDAP, and so forth).

Java Verification Program

As I mentioned earlier, some J2EE application server vendors have released versions of their software with special extensions to differentiate their offerings from the rest of the pack. This has the obvious implication that an application designed specifically for BEA's WebLogic Application Server won't necessarily run on IBM's WebSphere Application Server. Customers, however, want an added level of assurance that applications are portable, and that they will work in a mixed J2EE application server environment. The Java Verification Program enables developers to continue to differentiate their offerings, while providing customers with a way to compare applications built on different J2EE application servers.

Sun Microsystems has started a certification program for all developers to help ensure that their application will run on a J2EE application server before deploying it on a customer's system. The Java Verification Program checks enterprise applications to make sure they are compatible with various J2EE-compatible application servers. It also tests the portability of applications from one application server to another. The Java Verification Program leverages the Java Application Verification Kit (Java AVK) for the Enterprise. (With the Java AVK, you test your own J2EE applications to ensure portability between various J2EE platforms.)

If your products have successfully completed the Java AVK for the Enterprise testing process, you can apply for the Java Verification Program and trademark license. If approved, you receive the right to use the Java Verified brand logo and trademark for the tested application, and you can participate in co-marketing opportunities. This comes at a cost, but it's well worth it: The license for the Java AVK costs $2,000 per tester seat; a company pays this money to verify their application for internal quality purposes. But if a company wishes to use the Java Verified logo (shown in Figure 1) with a J2EE product, it would cost them $15,000 to verify an application -- per year!

Figure 1: Java Verified logo

An enterprise application that is branded "Java Verified" tells customers that the developer of this application is actively seeking to provide support for multiple J2EE-compatible application servers. Note that you have do have the option of using the Java AVK to test your applications, and you don't have to apply for the Java Verified brand logo. But of course, you then cannot label your products with that logo, nor can you say you've used the Java AVK to test your applications.

Benefits of the Program

The Java Verification program benefits developers as well as customers. For developers, it provides market differentiation and increased business opportunities; when a product carries the Java Verified brand logo, it has a competitive edge, delivering instant cross-platform credibility and customer trust. Also, you can reduce sales cycles and investment costs, since the Java AVK lets developers build and test their applications across multiple platforms -- without the need for multiple application servers. This leads to a simplified sales process and reduction in migration cost and customer risk.

For customers (or enterprise solution buyers), the Java Verified brand logo informs them that the applications are compatible with all J2EE application servers, and have met the Write Once, Run Anywhere standard they're looking for when selecting solutions.

How Does the Java AVK Work?

The Java AVK helps analyze J2EE applications, to identify platform-specific code, as well as violations of the J2EE specification. The report tool generates detailed logs that pinpoint these problem areas.

Before I talk about the tools provided by the Java AVK, let's first look at the criteria it uses to identify an application as portable.

Application Portability Criteria

An application is considered portable when the following conditions are met:

1. The same application runs on at least one commercial J2EE-compatible application server.
2. The application doesn't depend on any vendor-specific server extensions.
3. The application has the same set of features across all servers.
4. The application passes all related verifier tests.
5. The application satisfies all runtime requirements.

Applications that use vendor-specific server extension APIs are still portable -- as long as code branching is used, so that the application can revert to portable code when run outside the specific application server.

In addition, native code in a J2EE application is acceptable if:

1. The native code is invoked through a standard connection method (such as the Interface Definition Language, or IDL).
2. The user interface is implemented in Java.

Java AVK Tools

The Java AVK provides the following tools for verifying applications at different levels: static checker (static verifier), dynamic checker (runtime), and report tool (generates all final reports).

Static Checking

During the static checking procedure, checks are performed on all J2EE platform .ear files. In addition, the static verifier validates the application deployment descriptors as defined by the J2EE specification, and validates the package of .ear files.

Dynamic Checking

The dynamic checking verification consists of two steps:

1. Introspection: Generate the list of public APIs in the J2EE application, including the EJB component public APIs, and JSP and Servlet components that are part of the application.
2. Instrumentation: Log EJB component public API and system exceptions, as well as JSP components, Server components, and web exceptions.

Report Tool

The report tool performs the following functions:

1. Compares instrumentation list against introspection list
2. Calculates average numbers for EJB component's methods and web components
3. Produces static reports from static checking results
4. Produces dynamic reports from dynamic checking coverage results

Sample Log File

The Java Pet Store enterprise application has been verified using the Java AVK tool. To give you an idea of the sort of output you would see if you tried to verify your applications, here are some screenshots. Figure 2 shows the suite summary:

Figure 2: Suite summary for the Java Pet Store

As you can see from Figure 2, all EAR files passed 100%, except PetStoreEAR, which passed 97% of the methods called. Figure 3 shows the EJB coverage for the PetStoreEAR file.

Figure 3: EJB method coverage for the PetStore EAR file

Note in Figure 4 that the one method of the EJBCardBean wasn't called; part of the verifier summary is shown in Figure 4.

Figure 4: Methods not successfully called (Click to Enlarge)

Download Information

A trial version of the Java AVK will be released sometime in February. There will be links to the trial version from http://java.sun.com/j2ee/verified.

Conclusion

There are a number of key areas in the J2EE which have portability limitations. To develop portable applications that will run on any J2EE application server with zero-cost modifications, be sure to read the specifications carefully. Vendor value-added APIs are specific to vendors, and as such, broker portability issues. This article provided an overview of portability in J2EE and discussed why portability is important. The article then presented the Java Verification Program and the Java Application Verification Kit (Java AVK) for the Enterprise, which is a tool intended to help developers test and verify their applications for correct use of the J2EE APIs and portability across J2EE-compatible application servers.

For more information

• J2EE
• Java BluePrints
• Java Verification Program
• Java Application Verification Kit (Java AVK)
• Sample J2EE applications verified with Java AVK
• Java Verification Program Application Process
• Order the Java AVK for the Enterprise
• J2EE Application Verification Kit (Presentation at JavaOne 2002)
• Developing Portable Applications for the J2EE Platform (Presentation at JavaOne 2002)

Acknowledgments

Special thanks to Larry Freeman and Carolyn Boyle of Sun Microsystems, whose feedback helped me improve the article.

About the author

Qusay H. Mahmoud provides Java consulting and training services. He has published dozens of articles on Java, and is the author of Distributed Programming with Java (Manning Publications, 1999) and Learning Wireless Java (O'Reilly, 2002).