Portability and the AVK: An Interview with Bill Shannon

Print-friendly Version

Bill Shannon is a distinguished engineer at Sun Microsystems, where he is one of the architects of the Java 2 Platform, Enterprise Edition. He has been with Sun since 1982 and previously worked on the JavaMail API, the HotJava Views product, the Common Desktop Environment, the Solaris operating system, and all versions of SunOS. He graduated from Case Western Reserve University with an MS in Computer Engineering.

Does "Write Once, Run Anywhere" (WORA) really exist?

Absolutely. You can write applications that will run on any J2EE-compatible application server. Although a few cases are very difficult, in many cases more can be done than you may realize. Java BluePrints is the proof point here. Each year, we run the Deployathon, which demonstrates a significant J2EE application running on multiple J2EE-compatible application servers.

What is the difference between portability and WORA?

WORA is much stronger than portability. Portability is a matter of degree. You can be, for example, 90 to 95% portable. But WORA is about 100% portability. That's the soul of the Java platform.

With the J2EE 1.4 platform, web services are part of the platform. How do web services and interoperability change the portability story? Is portability still as important?

Interoperability and portability are two very different things. Portability is about being able to move an application from one vendor's platform to another vendor's platform. Interoperability is about applications from two different vendors being able to talk to each other. Both are important, but they are entirely different. Interoperability doesn't change the portability story.

Does the J2EE 1.4 platform make it easier to write portable J2EE applications?

The J2EE specification adds new facilities to the platform that were previously only available in vendor-specific ways. Many vendors had supported web services in their products, but it is only with J2EE 1.4 that web services can be implemented in a standard way. This makes the investment in web services applications more valuable, because it can be used in more ways on multiple implementations. In addition, there are now also management and deployment APIs (JSR 77 and 88). These APIs make it easier to write portable management applications and portable deployment tools.

Is using a J2EE-compatible application server enough to ensure portability?

Not really. The J2EE specification describes the standard elements of a J2EE-compatible application server; it provides the basis for portability. But an application server will always include proprietary extensions that provide a value-add for them, but may result in vendor lock-in for the developer. If developers are using a single application server for testing, there is a real danger that they may be using proprietary APIs or using J2EE APIs in a nonstandard way. For this reason, it is important to test applications with a second application server -- and this is where the Java Application Verification Kit (AVK) for the Enterprise provides its value.

How exactly does the AVK work?

The AVK has both static and dynamic verification. Static verification validates the packaging of the WAR files, checks method signatures, and reports any inconsistencies. The dynamic verification validates correct execution of web components and EJB public APIs through introspection and instrumentation. In the 1.4 version of the AVK, there is also source-code flagging of proprietary APIs.

But developers use platform-specific extensions to optimize performance and to take advantage of platform-specific features. Does writing multi-platform applications automatically mean that applications must pay a performance penalty and cannot take advantage of platform-specific features?

Platform-specific features cause problems only when they are embedded in the logic of the application. The recommended approach is to use platform-specific deployment descriptors to take advantage of platform-specific features. Therefore, portability does not require a sacrifice in performance -- this is a myth. The functional behavior of the application will be portable, but the performance characteristics of the application may not be portable.

What types of portability questions do you typically hear?

People tend not to think about portability upfront. They write a program that runs on the product that they initially bought, and then they change products or buy additional products. It's important to use a verification product like the AVK from the beginning of development. Design an application carefully; be careful when you use vendor-specific features.

Different vendors distribute application clients differently. How do I design an application client to function in different scenarios?

Packaging an application client is a bit more of a challenge. You should use the application client container, although many people often write applications without using the application client container. For such situations, consider using web services, since that enables you to write the client and server on a broad variety of hardware and software platforms.

What is the best way to package an application and group files?

There are several recommended packaging formats. In addition to standard JAR files, there are Web Application Archive (WAR) files, Enterprise Application Archive (EAR) files, and Resource Adapter Archive (RAR) formats. You use an EAR file to package a J2EE application containing many different types of components. The J2EE Blueprints contain advice on how to organize files within an EAR or WAR file.

Can you share common code across applications?

Before the J2EE 1.4 platform, you would package common code with each application or provide it as a service (for example, an Enterprise JavaBean component) that would be used by other components. In the J2EE 1.4 platform, we added the ability to install class libraries that can be shared by all applications in the application server.

What is your recommendation for the best way to handle native code? Can an application that uses native code still be portable?

As I said, portability is a relative thing. You could write a C program that has highly portable source code. Factor in Windows and Solaris, and portable code is still possible. Remember that the goal of the Java platform is to achieve 100% portability for applications (Write Once, Run Anywhere), so use of native code should rarely be necessary. The standard approach when non-portable code is required is to isolate the less portable parts of the application so that they can more easily be changed. It is also recommended that you refer to Java BluePrints for guidelines for interfacing with native code.

How do you share session context across related application components?

The common ways of doing this are storing it on the client (using cookies, URL rewriting, or hidden form fields), using HttpSession, using an EJB Stateful session bean, and storing it in the database using JDBC directly or using EJB entity beans. It makes sense to store it on the client if you want your server-side application to maintain as little state as possible. You should use the HttpSession for web-centric applications, and Stateful session bean for EJB-centric applications. If the state needs to be persisted for the long term, store it in the database.

How can SQL programming be made more portable?

Most vendors support a level of the SQL specification, and often the language used by one vendor's database does not work on another vendor's database. You can alleviate this problem by using Entity Beans and EJB Query Language, since they provide an abstract SQL-like model that all J2EE vendors must support. If you need to use JDBC directly, you can use the Data Access Object (DAO) design pattern to isolate SQL code.

How do EJB design choices (BMP & CMP) impact portability?

Using Bean Managed Persistence means that you need to rely on SQL code. In this case, the DAO pattern will help. But Container Managed Persistence is more portable. CMP maps an abstract schema to the real schema capabilities of the specific platform. This means that CMP schema can be optimized by the platform vendor. Many application server vendors also provide tools to efficiently map existing database schemas to a network of related CMP entity beans.

Do you have any tips on addressing J2EE security in a portable way?

The basic security strategy is to express the application's security policy in terms of roles, and access policies based on these roles. At deployment time, this abstract security policy will be mapped to the security facilities available in the deployment environment. Embedding knowledge of particular security mechanisms in the application will make it less portable.

Sun just released the AVK 1.4 beta. Can I use it with a J2EE 1.2-based application or a J2EE 1.3-based application?

Yes. The AVK 1.4 beta can be used with J2EE 1.2, J2EE 1.3, and J2EE 1.4-based applications. It works with any application that can be run on the J2EE 1.4 SDK.

What is the difference between the free verifier and the Java AVK?

The free verifier is a subset of the Java AVK. It is intended for developers who wish to do a static test only and who do not need the full set of verification tests that Sun offers. The Java AVK is intended for developers who wish to do a more complete static verification test and who plan to do the deployment and dynamic verification tests. The Java AVK is also available for ISVs who want to go after the Java Verified brand. Developers should start with the J2EE 1.4 SDK and download the Beta version of the Java AVK.

Can I use the AVK if I am not using EJBs or web services?

Yes, the AVK works with enterprise applications that use any combination of EJBs, JSP pages, or Servlets -- or that use EJBs alone, JSP pages alone, or Servlets alone. Web services support is available in the upcoming AVK 1.4 release.

See Also

Beta version of the Java AVK
Technical article: Java AVK for the Enterprise
Download J2EE v1.4 SDK
Java BluePrints