第三章 更新 WebSphere Application Server 企业应用程序时保持持续可用性.pdfVIP

页码，1/ 18 更新 WebSphere Application Server 企业应用程序时保持持续可用性 简介： 文描述了在希望保持应用程持续可用性的产品环境中，推出企业应用程序的新版本的方法。并讨论了基于浏 览器的客户端及基于 Java 的客户端的应用程序。 标记本文！ 发布日期：2004 年 12 月 01 日 级别：初级 引言 本文详细描述了在 IBM WebSphere®Application Server Network Deployment Version 5.x 单元中将 J2EE 企业应 用程序的新版本迁移到产品中，同时保持站点的持续可用性。并介绍了使用两种不同方式执行应用程序更新的步骤， 其中一个是使用多 WebSphere 单元，另一个是使用单 WebSphere 单元。每个方法都有其优缺点，在产品设置中经 常结合使用 两种方法，所以理解 两个方法是有益处的。某些 WebSphere 运行时体系结构和 HTTP 插件配置文 件结构的背景信息将为迁移过程创造条件。 本文假设您已经熟悉 IBM WebSphere Application Server V5.x 及 J2EE 企业应用程序。 对基于浏览器的客户端，过程利用了通过修改 plugin-cfg.xml 文件来操作 HTTP 服务器插件程序路由表的能 力。插件程序的会话亲缘性特征帮助将现有用户路由到当前版本的应用程序服务器，同时新用户被路由到运行应用程 序新版本的应用程序服务器。随着新版本的开始使用，使用 plugin-cfg.xml 文件服务器元素的 LoadBalanceWeight 属性可以平稳地“排除”离线服务器。 当考虑将应用程序从一个版本迁移到另一个版本时，取决于版 之间更改的多少，可能会引发几个问题。需要特别注 意的是： l 数据库模式的兼 性 l 正在进行的迁移 l 用户体验的考虑 l EJB 版本的兼 性。 这些方面的考虑对版本迁移计划和执行产生的影响，也许会大于推出应用程序到产品服务器的机制产生的影响。这些 方面不在本文的范围之内， 里假设这些问题已经通过向后兼容或通过独立于应用程序推出的步骤得以适当的解决。 简单起见，我们将假设应用程序服务器只运行待移植的应用程序。实际上，应用程序服务器通常运行不只一个应用程 序。假设服务器集群运行应用程序 A ，B，C。推荐的方法是每次只移植一个应用程序，如应用程序 A 。当然，开发 的测试阶段包括一套的测试来保证应用程序 A 的新版 （及其支持的所有的库）与应用程序 B 和 C （及他们支持的 库）是兼 的。如果在实际上是不可能的，那么 个移植将需要另外的应用程序服务器集群来运行应用程序 A 的新 版本。这通常需要附加硬件设备。 如果产品环境被配置用来使用持续的 HTTP 会话状态，那么就会有出现错误的情形（希望可能性会小些）：运行应用 程序版 N 的应用程序服务器可能访问应用程序 N+1 版本的 HTTP 会话状态，反之亦然。假设运行应用程序版 N 的服务器有出现错误，而随后的请求恰巧被传递到运行应用程序版 N+1 的应用程序服务器上。如果对象类定义 阻止 HTTP 会话状态从应用程序的一个版 改变到另一个版本，那么当会话状态被反串行化时将会抛出 java.io.InvalidClassException。当抛出此异常时应用程序应当适当的做些什么。在 种情况下需要做的最好 的事情可能是要求用户重新登录或将用户重定向到起始页， 样就会创建新的会话， 样也会使用户回到运行应用程 序新版本的服务器上或其他什么地方。另一方面，如果在迁移过程中有问题发生，那么立即回滚应用程序版 N+1， 页码，2/ 18 并恢复站点到所有应用程序版 为 N 的服务器上。 我们将假设应用程序回滚只会花费相对较短的时间，如最多两个小时。如果回滚周期很长 （换句话说，就是推出的时 间长到同一用户访问站点并建立了一个以上新的会话），那么很有可能的是对移植所考虑的 “用户体验”其中一项是 在推出期间需要确保已经看到应用程序新版本的用户在其后来访问的站点上也看到新版本。如果用户已经使用了应用 程序的新版本，您可能也不希望用户重新使用老版 。在扩展的过渡时期可能发生上述情 ，因为服务器将会运行应 用程序的 N 和 N