引言
J2EE 应用程序由多种不同类型的组件构成，例如 servlet、EJB 组件和 J2EE 客户端 ，这些组件可以封装在不同的模块中。随着 J2EE 应用程序的日趋成熟，也就有必要不断 使用新的应用程序功能。普遍的做法是通过小规模的增强或者对组件接口（或者其实现） 加以改进来获得新应用程序功能，而不是对整个企业应用程序进行大规模的改变。因此， 在许多情况下，对每个应用程序组件的不同版本加以支持（同时可以重用其他相关的组件 ，而这些相关的组件不受新版本变化的影响）是人们所期望的事情。
为了实现上述功能，有必要对需要升级的应用程序组件进行增量式，而不是使用一种 “大手笔”的方法对整个企业应用程序进行更换。要想实现这种增量式，就有 必要使同一个应用程序服务器能够支持企业应用程序组件的多个不同的版本。
本文论述和讲解为了支持在一个 WebSphere Application Server 实例中同时托管 J2EE 应用程序的多个版本所需要解决的关键问题。尽管其中的一些问题可以在部署阶段 解决，但是也有一些问题需要在应用程序设计和开发的阶段加以解决。我们在此使用一个 小型的 J2EE 应用程序（由 EJB 组件、servlet、JSP 以及 HTML 构成）对如何解决这些 关键问题进行了示范。
有不同的方法可以使企业应用程序从一个版本完全转换到另外一个版本，例如在同一 WebSphere 网络域中使用不同的单元。这些方法不在本文的讨论范围之内，本文只在 EJB 组件、servlet 或静态内容的层面上以较细的粒度论述应用程序的版本。
同时托管的冲突和问题
同时托管的 J2EE 应用程序的不同版本需要使用共同的应用程序服务器资源，如类加 载器、JNDI 名称空间、应用程序 URL 和其他的外部资源，这些因素会产生冲突。我们将 这些冲突列举如下（并且在本文的后面将其进行讨论）。
类加载冲突
不同版本的 J2EE 组件类需要加载到同一个应用程序服务器的 Java 虚拟机进程中。 通过在 WebSphere 应用程序服务器中使用多种类加载器，可以避免这些冲突。
servlet 路径冲突
不同版本的 Web 应用程序组件（例如 servlet、JSP 和 HTML 模块）会有冲突的 URL 。这些冲突可以通过对每个版本使用不同的上下文根来解决。
JNDI 名称空间冲突
J2EE 应用程序组件可能会引用远程和（或）本地的持久性对象，这可能包括 EJB 本 地接口。多个版本的 J2EE 应用程序组件不能在同一应用程序服务器域的同一个 JNDI 名 称空间注册相同的名称。解决名称空间冲突的方法是避免在应用程序代码中使用硬编码的 JNDI 名称空间，而依赖于 java:comp/env 名称空间中的应用程序环境项（正如 J2EE 1.2 规范中所定义的）。通过这种方式，在部署阶段可以为不同的版本指定实际的 JNDI 名称空间。
外部资源冲突
不同版本的 J2EE 应用程序可能会使用相同的外部资源的不同版本，例如数据库结构 。可以通过资源管理器（例如 JDBC 数据源）使不同版本的应用程序使用同一外部资源的 不同版本，并且通过应用程序的 java:comp/env 环境来访问资源管理器。通过这种方式 ，直到部署阶段才将外部资源和使用它的应用程序代码绑定起来，因而可以在部署阶段指 定外部资源的不同版本。
图 1 突出显示了在同时托管两个不同版本的 J2EE 应用程序时发生冲突的部分。
图 1. 在同一个应用程序服务器上同时托管的不同版本的 J2EE 应用程序之间的冲突 。
另外，除了以上的各种冲突，也要考虑下面的应用程序设计和开发问题：