简介： 本系列文章的第 2 部分将介绍如何确定哪种部署选项最适合您的特定应用程序。
在上一期文章 第 1 部分：迁移概述 中，您看到了 IBM® PureApplication® System 如何支持虚拟应用程序和虚拟系统。简而言之，两者之间的差异就是控制水平与自动化水平之间的权衡。在本文中，我们将探讨如何确定哪种部署选项最适合您的特定应用程序。
虚拟应用程序 是部署 JEE 应用程序的一种方法，这种方法利用一组策略决策来确定应用程序应如何扩展并使用 Java™ 虚拟机 (JVM) 的资源。将应用程序作为虚拟应用程序部署时，您还要利用一组内置的共享服务，处理一些细节问题，例如负载平衡和 HttpSession 管理。
然而，这些自动化的优势是有代价的。应用程序的拓扑结构（例如，一次运行多少台应用服务器，哪台服务器处理哪些类型的请求等等）将由 PureApplication System 主动管理。这也就意味着，您可能无法将应用程序隔离到运行 servlet 的 Web 层中，以及运行远程 EJB 的 EJB 层中。对于许多应用程序而言，这或许并不是什么问题，但对于依靠多层打包或者特定应用程序拓扑结构的特性的旧式应用程序来说，这会是一个严重的问题。另外一方面的代价是导致仅支持某些编程模型。如果应用程序需要更高的灵活性，PureApplication System 也支持虚拟系统。
虚拟系统这种机制将创建通过虚拟镜像构建的完整拓扑结构的模板或模式。在构建虚拟系统时，可以利用 IBM 提供的 Hypervisor Edition 镜像，也可以利用基本的 RHEL 镜像，使用 IBM Tivoli® ICON 工具构建您自己的镜像。
另外，也可以利用 PureApplication System 的 “捕获和扩展” 特性，它允许您从一个虚拟镜像入手，并在打包之前为该镜像添加额外的软件，以便稍后使用。构建虚拟系统时的另外一个关键考虑事项就是可以在虚拟系统中添加您自己的脚本。如果希望将应用程序部署到已经创建的某个拓扑结构模式中，您需要编写部署脚本，使之能够在将虚拟系统实例部署到 PureApplication System 硬件的实例化过程中执行。
在大多数情况下，将应用程序迁移到 PureApplication System 并不复杂。然而，迁移过程的关键在于了解您是否需要合理选择正确的方法来迁移应用程序。PureApplication System 支持多种部署应用程序的方法。选择一种能通过最小的工作量带来最佳成效的方法，这是迁移过程中需要制定的最重要的决策。在迁移众多现有 ISV 应用程序的过程中，我们发现最简单的方法就是提出一系列的问题：
- 您是否正在构建新应用程序？
先解答这个问题的原因非常简单：您需要利用最简单、最便捷的部署机制。如前所述，PureApplication System 提供的最简单的部署模型就是虚拟应用程序。如果您正在构建新应用程序，并且有机会影响与应用程序相关的技术和设计选择的决策制定，那么请选择那些使应用程序兼容虚拟应用程序的选项。
但在大多数情况下，您每天处理的应用程序并非未经开发的全新应用程序。您往往需要处理已经构建完成的、在现有环境中运行的现有应用程序。随后您必须考虑下一个问题。
- 这是否是一个 Web 应用程序？
这是一个看似简单实际上暗藏玄机的问题。这个问题的真正含义是 “这个应用程序是否仅获取入站 HTTP 或者 HTTPs 的请求？” 这种定义整合了应用程序开发内多种不同的模式。其含义可能如下：
- 一个应用程序向使用 JavaScript 和 AJAX 技术编写的用户界面提供 RESTful 服务。
- 一个为互联网中的外部客户端实现 SOAP 服务的 Web 服务提供程序。
- 一个使用 servlet 和 JSP 构建的传统 Web 应用程序。
然而，这种定义不包括某些应用程序类型，例如，利用这种定义时，就不会将那些通过 RMI 或者 RMI/IIOP 连接到后端 EJB 的 Java 富客户端的 Java 客户端-服务器应用程序定义为 Web 应用程序，这样的考虑也为我们引出了下一个问题。
- 您是否使用远程 EJB？
几乎从问世起，EJB 就一直是 JEE 编程模型中非常有用的一部分。但在获得远程 EJB 优势的同时，您要付出的是应用程序拓扑结构复杂性的代价。应用服务器必须同时处理发送到您的 servlet、JSP 和 Web 服务的 HTTP 传入流量，以及来自 EJB 客户端的 RMI/IIOP 传入流量。通常情况下，这是通过构建两层应用服务器实现的；一层专门处理 HTTP 流量，另外一层专门处理 RMI 流量。为了利用虚拟应用程序简化流程，您必须放弃其中某些拓扑结构选项。因此，就像我们之前所讨论的那样，如果需要使用远程 EJB，那么只要可以使用虚拟系统，就应该使用这些拓扑结构选项。
- 您的应用程序是否通过标准的方式打包？
同样，这是一个看似简单实际上暗藏玄机的问题。“通过标准的方式” 代表的含义是：是否打包为 EAR 文件、WAR 文件、ZIP 存档或者 EBA (OSGi Enterprise Bundle Archive)？尽管 JEE 标准将应用程序打包为 EAR 或者 WAR 文件，而 OSGi 标准又引入了 EBA 存档，但许多应用程序仍然不是通过这种方式打包的，而是作为 “分散式” 目录结构提供。这种做法可能适用于 Tomcat 这样的简单服务器，但采用非标准化的方法会使您在迁移到新的 JEE 服务器（例如支持虚拟应用程序的服务器）时遭遇阻力。因此，如果您对这个问题的回答是 “否”，则应该通过上述一种标准格式重新打包应用程序。类似地，WebSphere® Application Server 中也有其他许多打包战略可供您使用，例如，与服务器有关的共享库。同样，为了简化模型，虚拟应用程序中不会使用这些选项。如果无法避免使用这些方法，那么就应该考虑使用虚拟系统。
- 您的应用程序是否使用了标准 JEE 编程模型？
人们常说 “标准最大的优点之一就是有许多标准可以选择”。遗憾的是，在编程模型方面，这种说法非常地恰当。随着新 API 的迅速推出，Java 社区充斥着大量从未得到批准、从未得到广泛认可、因此无法成为 JEE 标准正式组成部分的 JSR。问题在于，使用虚拟应用程序时，我们希望能够简化一切操作。因此，您必须将受支持的 API 限制为可以管理的一组 API。如果您的应用程序仅使用 JEE5、J2EE1.4、1.3 或 1.2、OSGI、JPA、JAX-RPC、JAX-WS 和 JAX-RS 提供的标准 API，则完全不必担心这个问题。
另一方面，如果您正在为较新的 JEE 版本（例如 JEE 6）编程，或者正在使用深埋于 JCP 中的某种过时 API，那么或许无法将您的应用程序用作虚拟应用程序。鉴于上述问题，IBM 的做法是通过 Feature Pack 为较新的 API 提供支持。因此，如果您正计划采用较新版本的 API，那么有可能需要考虑使用 WebSphere Application Server V8 构建虚拟系统，并在支持这种 API 的 Feature Pack 发布时整合 Feature Pack。
- 该应用程序目前是在 WebSphere Application Server Version 7 上运行还是在 Version 8 上运行？
这是一个很温和的问题，但也非常重要。这个问题有一些需要考虑的答案。即便您对这个问题的回答为 “是”，但出现了前面的关于编程模型、打包或远程 EJB 使用的问题之一，那么您的决定已经无法改变，也就是说，您的应用程序无法作为虚拟应用程序。然而，如果您的回答是 “否”，那么仍然有可能将您的应用程序作为虚拟应用程序运行。如果您的应用程序符合上面的编程模型问题和打包问题，那么一切就不存在问题。但如果您的应用程序是在更早版本的 WebSphere Application Server 或者另外一种应用服务器上运行，那么有可能就需要先完成一些迁移工作，然后才能将其转为虚拟应用程序或者虚拟系统。
- 您的应用程序是否需要任何 WebSphere 系列产品（例如 WebSphere Portal Server 或者 WebSphere Process Server）？
如前所述，虚拟应用程序方法是以构建 Web 应用程序为目标的方法。如果您的应用程序类型（也可以说是 “工作负载”）不属于 Web 应用程序，那么当前虚拟应用程序方法就不适合您。请注意，这是一个具有时态的陈述。IBM Workload Deployer 和 PureApplication System 将逐步添加新的工作负载类型。因此，在未来的某些时候，即便您拥有业务流程管理应用程序，也可以利用当今虚拟应用程序为 Web 应用程序提供的较高自动化水平。然而，就目前而言，如果您需要这些产品，就需要构建虚拟系统，整合作为 PureApplication System 或 IBM Workload Deployer 的在线目录的一部分已发布的 IBM Hypervisor Edition 产品。
- 您的应用程序是否已经准备好利用 WebSphere Extreme Scale 进行会话管理？
与之前的许多问题一样，这个问题有着丰富的内涵。实际上，您首先必须考虑 HttpSession API 的使用情况。许多应用程序都是以完全无状态的方式编写的，完全没有利用 HttpSession API，也就是说，这些应用程序最适合作为虚拟应用程序。另一方面，如果您的应用程序中目前使用了 HttpSessions，则必须略微思考一下如何利用它们。
首先，HttpSession 的所有内容是否都声明为 java.io.Serializable？如果不是，那么您就遇到了一个问题。虚拟应用程序的扩展策略采用的模型是可以根据需要动态创建和销毁的应用服务器实例，可处理应用程序在任意时刻承担的负载量。如果您假设服务器将长期存在，其内存是会话信息的 “安全” 存储库，那么在实现虚拟应用程序时就会遇到意外的挑战。
同样，如果您的会话非常庞大（数百 MB），那么从 WebSphere Extreme Scale 网格通过网络加载会话所需的时间也可能让您感到意外。另一方面，如果您拥有的是较小、完全串行化的会话，并且它们符合 HttpSession 最佳实践，则可以使用虚拟应用程序。
- 您的应用程序使用的是外部安全性产品，还是 Trust Authentication Interceptors (TAI) 或 JAAS 插件等特殊安全性 API？
最后要考虑的一个问题就是应用程序的安全要求。如果您的应用程序不存在安全要求，或者只是简单地使用 WebSphere 安全性，而且使用一种受支持的用户注册库（TDS、Microsoft® Active Directory），那么您就可以将系统实现为虚拟应用程序。另一方面，如果您使用单独的安全性产品，例如 Tivoli Authentication Manager 或者竞争对手的类似产品，或者 JAAS 或 TAI 等特殊 WebSphere 安全特性，则需要计划构建虚拟系统。
需要考虑的一个重要方面就是应用程序具有生命周期，单独一种部署模型并不适用于应用程序的整个生命周期。例如，在开发和测试环境中，您可能希望将应用程序部署为虚拟应用程序，以便获得最简单的模型，确保正确捕获这些环境内的配置参数（例如 JVM 策略）。然而，在生产环境中，您可能需要将其部署为虚拟系统，以便为该应用程序设置最优环境。同样，您的一个现有应用程序目前可能必须部署为虚拟系统，但在该应用程序后续的版本中，您可能会更改其代码，使之适合作为虚拟应用程序部署。
在规划过程中，最重要的就是判断应用程序是否已经为虚拟应用程序做好了准备，是否只需要花时间规划流程即可。幸运的是，IBM 可以帮助您完成这个流程。PureExperience 流程拥有多个步骤，涵盖了我们上面提出的问题，并在各个领域中提出了更多问题。通过这种问答过程，IBM 客户技术专业人员可以帮助您了解哪种部署模型最适合您的特定应用程序。同样，IBM Software Services for WebSphere 可提供应用程序迁移服务和其他服务，帮助您采用 PureApplication System。请联系您的 IBM 销售代表，获得更多的帮助，立即开始工作！
本系列的第 2 部分探讨了在为 IBM PureApplication System 做准备时，哪种部署选项最适合您的特定应用程序。您了解了如何区分虚拟应用程序和虚拟系统方法。此外，本文还提供了一组问题，帮助您确定哪种方法最适合您。
