摘自 IBM WebSphere 开发者技术期刊。

引言

与以前版本相比，IBM WebSphere Application Server V6 包含很多系统管理功能方面的重要增强。本系列文章探索该产品在这一领域的发展，其中的每篇文章都着重讨论一项特定功能的详细信息。本系列文章包括：

• 第 1 部分：增强系统管理概述
• 第 2 部分：增量单元升级
• 第 3 部分：使用概要文件简化管理系统
• 第 4 部分：使用最新的 AdminTask 命令帮助管理员轻松实现任务自动化
• 第 5 部分：更新已部署应用程序的灵活选项

回页首

应用程序更新：应用程序生命周期的一部分

作为 J2EE™ 应用程序服务器，WebSphere Application Server 主要用于协助 J2EE 应用程序的部署和管理。典型的应用程序管理操作包括以下任务：

• 部署 J2EE 企业应用程序归档（enterprise application archive，EAR）文件。
• 启动和停止应用程序。
• 编辑应用程序配置。
• 将更新应用到应用程序文件。
• 从服务器删除应用程序等。

一旦应用程序部署，并随后在企业环境中启动后，就可以为其客户机提供服务，且可能长时间保持运行状态。

不过，如果认为将应用程序 EAR 文件的第一个版本部署到应用程序服务器就可以满足应用程序的整个生命周期内的所有客户需求，未免有些天真。事实上，大部分应用程序都会由于各种原因而需要进行周期性的业务逻辑更新。要求对已部署应用程序进行更新的常见场景包括：

• 小错误修改：产品用户所报告的问题或正在运行的应用程序测试中出现的问题通常需要对应用程序逻辑进行小的修改。这些修复会对一小部分应用程序文件进行更新，而通常不会更改应用程序行为或接口。此类更新的频率可能为每天数次，也可能为周期性地应用一组累积修复。

• 小内容修改：与错误修复类似，这些通常作为小的功能增强处理，源自用户反馈或业务逻辑的新需求。此类更新包括对公司徽标、版权声明的更改，抑或对提供反馈的 JSP 页面的更改。

• 新修订的部署：通常，这些是对应用程序逻辑的较大更新，可能包括添加代码或删除代码，或对业务逻辑的其他大修改。此类更新不会被频繁的执行，而仅是在广泛的应用程序测试和负载测试完成后进行，而且通常计划在非高峰期（夜间或周末）进行。这些更新还可以与 J2EE 元素外的其他解决方案支持组件一起使用，如数据库更新、操作系统更新，等等。

• 应用程序自我修改：特殊类型的应用程序会在应用程序执行期间动态地生成自己的内容。例如，Web 应用程序可能决定为每个注册并创建自己个人信息的用户生成新的 JSP。

评估应用程序是否能够满足其客户机请求的一个重要考虑事项就是其可用性需求。虽然应用程序的预期持续可用性可能会根据应用的更新类型而不同，但在很多环境下，都不希望出现服务中断的情况，特别对于关键任务的应用程序更是如此。例如，只是替换一个 GIF 图像的更新通常可以在应用程序正常运行期间完成。而另一方面，部署应用程序的新修订涉及的方面更多，可能需要在计划维护停止期间执行。

WebSphere Application Server V6 包括一系列管理功能，可以在各种场景中帮助更新已部署的应用程序，可以使用任何提供的系统管理工具（如管理控制台、wsadmin 脚本工具和编程 Java™ API 集）来访问这些功能。在本文中，我们将重点讨论如何通过 Java API 集和 wsadmin 脚本工具使用 WebSphere Application Server V6 中的新应用程序更新功能。

回页首

V5 中受限制的更新功能

在了解 WebSphere Application Server V6 中的应用程序功能之前，让我们首先看一下 WebSphere Application Server V5 中的应用程序更新支持，以便与 V6 进行比较。WebSphere Application Server V5 的系统管理: 第六部分：应用程序管理 说明了如何在 WebSphere 平台部署和管理 J2EE 应用程序。图 1 中的简单摘要显示了在 WebSphere Application Server Network Deployment（以下称为 Network Deployment）V5 和 V6 环境中部署应用程序时的端到端流。

1. 在 Network Deployment 环境中，应用程序 EAR 文件是通过连接到部署管理器进行安装的。
2. 安装进程会将 EAR 文件和应用程序相关配置保存在 WebSphere Application Server 主存储库中。
3. 部署进程还将收集关于部署目标的信息，如希望在其中运行应用程序的服务器和集群。
4. 当主存储配置与节点同步后，应用程序配置将复制到节点级别的存储库中，并提取到应用程序安装目的地中。
5. 每个在节点上运行的应用程序服务器都使用在配置同步操作期间提取的应用程序的单个副本。

V5 中提供的唯一应用程序更新就是 Full Application Update，这种更新方式需要用于替代已部署的应用程序 EAR 的 EAR 文件。更新进程将直接卸载已部署的 EAR 文件，然后安装新的 EAR 文件。当与目标节点同步已更新的 EAR 文件时，应用程序将停止（如果应用程序正在该节点的应用程序服务器上运行），之后进行替换，然后重新启动。

V5 中的应用程序更新功能具有某些局限：

• 由于更新支持仅接受 EAR 文件，因此即使对于简单的更改，也必须对整个 EAR 文件进行打包。
• 如果在运行期间更新应用程序，则在替换应用程序文件时，会在目标节点上回收整个应用程序（停止并重新启动）。
• 由于应用程序更新将执行应用程序卸载，然后再执行安装，因此在更新期间，将丢失部署后所执行的任何应用程序配置（如共享库配置）。

回页首

V6 中的细粒度更新

WebSphere Application Server V6 引入了一项细粒度更新功能，能解决 V5 中的上述局限，允许部署人员仅更新应用程序的特定子组件。此外，对正在运行的应用程序应用更新时，并不会对整个应用程序进行回收。不过，如果需要进行回收，则仅回收适用的部分，具体取决于更新的内容和 WebSphere Application Server 处理动态应用程序更新的能力。

AppManagement MBean 可帮助在应用程序服务器上部署和管理应用程序，其中包含一个新 updateApplication 功能，用以支持这些细粒度更新。此功能是通过各种管理客户机公开的，如管理控制台、wsadmin 脚本工具和编程 MBean Java API。以下是细粒度应用程序更新功能的两个主要方面：

• 细粒度内容更新
• 更新时的回收行为。

细粒度内容更新

1. 单个应用程序文件

   可以通过更新功能对应用程序 EAR 中任何范围的单个文件进行添加、删除或更新操作。此类文件可以驻留在应用程序范围中（即不位于任何模块中）、特定的模块中或甚至模块的 JAR 内。

2. 模块文件

   还可以在已部署的应用程序中对单个模块文件进行添加、删除或更新操作。提供了一个部署向导（与第一次部署应用程序时出现的向导相似），用于通过管理控制台或 wsadmin 工具进行模块添加或更新操作。在进行模块添加操作时，部署人员可以指定绑定信息（如 EJB 的 JNDI 名称、Web 模块的虚拟主机、用户/组映射的安全角色，等等）。在模块更新操作期间，缺省情况下，会将现有（已部署）模块的绑定与更新模块中的绑定合并。因此，部署人员只需为更新模块中的新构件提供绑定即可。

3. 部分应用程序

   部分应用程序不是有效的 J2EE 归档文件，而是一个 zip 文件，其中包含应用程序组件的子集和要在已部署的应用程序中添加或更新的各个应用程序文件。部分应用程序 zip 文件中的条目的文件路径必须与已部署应用程序中的文件相对于已部署 EAR 的根的位置匹配。例如，如果要通过部分应用程序更新已部署 EAR 内的 HelloWorld.jar 中的文件 com/acme/hello.class，则该部分应用程序必须包含一个路径为 HelloWorld.jar/com/acme/hello.class 的条目。

   部分应用程序更新是通过简单的文件替换逻辑实现的。如果部分应用程序中的文件不存在于已部署的应用程序 EAR 中，则更新操作会将其添加到已部署的 EAR 文件。类似地，如果部分应用程序中的某个文件存在于已部署的应用程序 EAR 中，则更新操作会在已部署的 EAR 中更新此文件。单个文件内容不会合并到部分应用程序更新中，不管部分应用程序中的条目是否表示单个文件或归档。因此，除非需要插入归档的完全替换内容，否则不要在部分应用程序包中包含其他归档（如 JAR、WAR 等等）。类似地，若要执行模块文件更新操作（即模块添加、删除或更新），则应该使用模块文件输入类型，而不是将整个模块打包到部分应用程序中。以下例演示如何使用部分应用程序更新对文件进行添加/更新。

   下面的应用程序 MyApplication 的归档视图包括三个模块，每个模块具有两个文件：

   • MyApplication
     • MyBusinessLogic.jar
       • a/b/file1.class
       • c/d/file2.class
     • MyWeb.war
       • e/f/file1.jsp
       • g/h/file2.jsp
     • MyModule3.jar
       • i/j/file4.class
       • k/l/file5.class

   部分应用程序 zip 包视图：

   • MyPartialUpdate.zip
     • /MyBusinessLogic.jar/a/b/file1.class
     • /MyWeb.war/m/n/file3.jsp
     • /MyModule3.jar

   此更新将产生以下结果：

   • 替换 MyBusinessLogic.jar 下的 a/b/file1.class 文件。
   • 在 MyWeb.war 下添加新文件 /m/n/file3.jsp。
   • 使用部分应用程序 zip 中提供的对应内容完全替换 MyModule3.jar。

   您将看到，到目前为止，尚不能使用上述部分 zip 包从已部署的 EAR 文件中删除文件。通过在部分应用程序 zip 中提供一个特殊的元数据文件 META-INF/ibm-partialapp-delete.props，可以在部分应用程序更新场景中完成应用程序文件删除。此文件可以存在于应用程序范围中，也可以存在于任何嵌入归档范围中（包括模块）。

   例如，若要在应用程序级别中（在所有模块外）删除文件，则请在部分应用程序 zip 文件中添加一个 /META-INF/ ibm-partialapp-delete.props 文件。类似地，若要从模块（如 MyWeb.war）删除文件，则请在部分应用程序 zip 文件中添加一个 /MyWeb.war/META-INF/ ibm-partialapp-delete.props 文件。若要从 MyWeb.war 文件内的 util.jar 删除文件，则请添加一个 /MyWeb.war/util.jar/META-INF/ ibm-partialapp-delete.props 文件。

   META-INF/ ibm-partialapp-delete.props 文件必须为 ASCII 文件，对于每个要从该范围删除的文件，此文件中应当包含表示其文件名称模式的行。例如，如果部分应用程序 zip 具有一个包含以下内容的 MyWeb.war/META-INF/ibm-partialapp-delete.props 文件：

   com/acme/abc\.class images/old/.*\.gif .*\.back

   
   

   则更新操作将删除 com/acme/abc.class 文件、images/old 中扩展名为 .gif 的所有文件和 MyWeb.war 模块中扩展名为 .back 的所有文件。

4. 完整应用程序更新

   可以通过传递整个应用程序的新修订，而对整个已部署的应用程序 EAR 进行更新。此场景与 V5 中的应用程序更新场景相似。不过，V6 包含了一个重要的增强，以保留部署之后执行的应用程序配置。例如，与应用程序关联的共享库引用、启动权重、应用程序的会话管理设置等等，现在都可以在完整应用程序更新期间得以保留。

当使用任何输入内容类型向已部署的应用程序应用细粒度更新时，更新内容将与 WebSphere 主存储库中的 EAR 文件合并。另外，还会在存储库中为每个更新创建一个基于 XML 的 Delta 文件，其中将列出受更新操作（添加、删除或更新）影响的各个应用程序文件 URI。当在存储库中保存了已更新的 EAR 文件和生成的 Delta 文件后（对于 WebSphere Application Server Base 配置）或通过配置同步操作与应用程序目标节点进行了同步后（在 Network Deployment 配置中），将读取 Delta 文件中记录的数据，以了解要在安装目的地中提取或删除已更新的 EAR 中的哪些文件。因此，除非执行完整应用程序更新，否则不会在安装目的地重新提取整个已更新的 EAR 文件。

回页首

细粒度回收行为

细粒度应用程序更新的另一个重要方面就是对在运行时更新的应用程序应用细粒度回收（或重新启动）行为。在 WebSphere Application Server V5（以及 V6 中），当在配置存储库中更新正在运行的整个应用程序时，会进行以下操作：

1. 首先会在目标应用程序服务器上停止正在运行的此应用程序。
2. 从安装目的地目录删除所有的旧应用程序文件。
3. 在安装目的地目录提取所有新应用程序 EAR。
4. 如果更新操作过程中停止了应用程序，则将启动该应用程序。

不过，如果通过单个文件、单个模块或部分应用程序 zip 包对正在运行的应用程序应用了细粒度更新，则应用程序更新逻辑将仅采取操作来停止和重新启动所有受更新操作影响的应用程序部分。务必注意，应用程序构件之间存在运行时依赖项（如缓存的类接口引用）。因此，并非始终可以回收应用程序的更新部分并维护应用程序的运行时完整性。在特定情况下，应用程序服务器运行时可能无法处理应用程序的离散部分的动态重新启动。在此情况下，应用程序更新逻辑的唯一选择就是重新启动整个应用程序。下表总结了几个细粒度更新场景和对应的回收行为。

对于上述情况，有一些例外，此时无论所更新的是什么，都会重新启动整个应用程序：

• 应用程序类加载器策略为 SINGLE：如果应用程序类加载器策略设置为 SINGLE（表示应用程序中的所有模块共享单个类加载器），则将回收整个应用程序。缺省设置为 MULTIPLE，表示每个 Web 模块都位于其自身的类加载器中。

• 安全角色定义更改：如果模块级别操作导致应用程序安全角色定义更改，则会因为任何模块级别的更改而导致整个应用程序重新启动。是否决定回收整个应用程序，取决于安全运行时处理正在运行的应用程序的动态角色更新的能力。WebSphere Application Server 的本机安全运行时不处理对应用程序安全角色的动态更新，因此，如果启用了本机安全配置，则任何影响安全角色定义的更新都会导致对整个应用程序进行回收。另一方面，作为 WebSphere 插件的 IBM Tivoli Access Manager 安全性可以处理对应用程序角色定义的动态更新，因此在这种情况下的回收行为与上表中列出的更新模块的行为相同。

可以在与目标节点同步已更新的 EAR 文件之前向 WebSphere 存储库中的应用程序 EAR 应用多个细粒度更新。在这种情况下，最终的回收行为会对所有更新产生累积效果。例如，如果其中一个更新需要重新启动整个应用程序，则不管其他更新如何，都将重新启动应用程序。

内行的部署人员还可以强制执行特定的回收行为（全部回收、不回收、回收特定的 WAR 模块），而忽略系统的缺省设置。不过，这样做时必须格外小心，因为如果处理不当可能会导致意外的应用程序行为。

回页首

应用程序更新示例

这一部分提供了一个细粒度应用程序更新的简单编程示例。本文附带的下载文件中包含了一个更为详细的示例。

updateApplication API 在用于部署和管理应用程序的 AppManagement MBean 中定义。以编程方式更新应用程序需要获得对 AppManagement MBean 的访问权限，然后恰当地传递以下参数，以对应用程序调用 updateApplication 方法：

• contentURI：要更新的文件的 URI。执行部分或完整应用程序更新时，将忽略此参数。

• pathToContents：要更新的内容在文件系统中的路径（位于 AppManagement Mbean 的本地）。对于删除操作，将忽略此参数。如果路径指向运行客户机的计算机的本地，则会在 properties 参数中传递其他信息，从而要求将更新内容上传到 WebSphere Application Server 计算机。

• Operation：可以为下列情况之一：

  • AppConstants.APPUPDATE_ADD
  • AppConstants.APPUPDATE_UPDATE
  • AppConstants.APPUPDATE_ADDUPDATE
  • APPConstants.APPUPDATE_DELETE

• Properties：操作所要求的其他属性，包括（但不限于）：

  • AppConstants.APPDEPL_LOCALE = 客户机区域设置
  • AppConstants.APPUPDTAE_CONTENTTYPE = 输入内容的类型；可以为以下类型之一：
    • AppConstants.APPUPDATE_CONTENT_FILE
    • AppConstants.APPUPDATE_CONTENT_MODULEFILE
    • AppConstants.APPUPDATE_CONTENT_PARTIALAPP
    • AppConstants.APPUPDATE_CONTENT_APP

• sessionID：如果在配置会话中执行更新操作，则为会话标识符；否则为 Null。

有关更多详细信息，请参阅 javadoc for com.ibm.websphere.management.application.AppManagement interface。

以下示例步骤演示了如何通过添加单个文件以编程方式更新已部署的应用程序：

				
//create AdminClient using host / port to application server
AdminClient adminClient = AdminClientFactory.createAdminClient .. 
// get hold of app management MBean proxy
AppManagement appMgmt = AppManagementProxy.getJMXProxyForClient (adminClient);

				
String appName = "MyApp";
String fileURI = "test.war/com/acme/abc.jsp";
String fileContents = "C:/temp/abc.jsp";
Hashtable options = new Hashtable();
options.put (AppConstants.APPDEPL_LOCALE, Locale.getDefault());
options.put (AppConstants.APPUPDATE_CONTENTTYPE, 
                AppConstants.APPUPDATE_CONTENT_FILE);

				
// Update the application
  appMgmt.updateApplication (
                 appName,
                 fileURI,
                 fileContents,
                 AppConstants.APPUPDATE_ADD,
                 options,
                 null);

updateApplication API 和大多数应用程序管理 API 一样，都是异步 API；即此类 API 会立即返回，而在单独的线程中执行更新操作。更新操作的进度和结果是通过 JMX 事件传达的。有必要向 AppManagement MBean 添加一个 JMX 事件，以了解更新操作是否完成。有关编程帮助，请参见下载文件中包含的编程示例。

以下示例 wsadmin 脚本可以用于细粒度应用程序更新。

				
// To add a single file
$AdminApp update MyApp file {-contenturi test.war/com/ibm/addMe.jsp 
  -contents C:/temp/addMe.jsp -operation add}
// To delete a single file
$AdminApp update MyApp file {-contenturi test.war/deleteMe.jsp -operation delete}
// To add a module
$AdminApp update MyApp modulefile {
  -operation add -contents c:/apps/app1/Increment.jar 
    -contenturi Increment.jar 
     -nodeployejb -BindJndiForEJBNonMessageBinding 
       {{"Increment Enterprise Java Bean" Increment 
     Increment.jar,META-INF/ejb-jar.xml Inc}}}
// To remove a module
$AdminApp update MyApp modulefile {-contenturi test.war -operation delete}
// Partial app update
$AdminApp update MyApp partialapp {-contents C:/temp/MyApp/myAppPartial.zip}
// Full app update
$AdminApp update MyApp app {-operation update 
  -contents c:/apps/app1/newApp1.ear -usedefaultbindings -nodeployejb}

				
// To add a single file
AdminApp.update('MyApp', 'file', '[-contenturi test.war/com/ibm/addMe.jsp 
  -contents C:/temp/addMe.jsp 
     -operation add]')
// To delete a single file
AdminApp.update('MyApp', 'file', '[-contenturi test.war/com/ibm/deleteMe.jsp 
  -operation delete]')
// To add a module
AdminApp.update('MyApp', 'modulefile', '[-operation add 
  -contents c:/apps/app1/Increment.jar -contenturi 
     Increment.jar -nodeployejb 
     -BindJndiForEJBNonMessageBinding [["Increment Enterprise Java 
     Bean" Increment Increment.jar,META-INF/ejb-jar.xml Inc]]]')
// To delete a module
AdminApp.update('MyApp', 'modulefile', 
  '[-contenturi test.war -operation delete]')
// Partial app update
AdminApp.update('MyApp', 'partialapp', 
  '[-contents c:/temp/MyApp/myAppPartial.zip]')
// Full app update
AdminApp.update('MyApp', 'app', 
  '[-operation update -contents c:/apps/app1/newApp1.ear 
  -usedefaultbindings 

回页首

应用程序更新期间的持续可用性

在进行应用程序更新期间的应用程序可用性通常非常重要。应用程序的持续可用性是一个广泛的话题，涉及到与 WebSphere 管理领域之外的其他构件的协调，此类构件包括数据库、支持软件、客户机更新，等等。因此，对于持续可用性而言，应用程序更新 Rollout 的可接受做法根据业务环境和可用资源的不同，有很大变化。本文其余部分将主要讨论如何对在 WebSphere 平台上部署和管理的应用程序构件进行无干扰更新。

尽管应用程序更新过程与应用程序环境密切相关，但从较为抽象的角度来看，似乎存在无干扰应用程序更新的通用模式。此模式包括的步骤如下所示：

1. 创建冗余应用程序目标，以进行工作负载管理和保证持续可用性。
2. 从某些目标容量子集将请求路由到别处。
3. 当所有工作已从该目标子集转移后，更新部署在其上的应用程序。
4. 使已更新的目标子集重新联机（使用一些测试负载进行了完美测试后）。
5. 将工作路由回已更新的子集。
6. 对于剩余的应用程序目标重复以上步骤。

若要进一步细化，可以采用很多方式设置冗余应用程序目标。Network Deployment 配置提供了用于此用途的集群支持。其他选择包括设置多个部署了相同应用程序的 WebSphere Application Server Base 或 Network Deployment 单元，或者设置使用硬件级别的集群技术。通过使用 Network Deployment 集群配置设置了冗余目标后，就可以利用特定于 WebSphere 的方法将来自目标子集的请求路由到别处（例如，修改集群成员权重或更新特定于 WebSphere 的 plugin-cfg.xml 文件，以进行 Http 请求路由）。通常，在 WebSphere 单元或硬件集群上建立了冗余目标后，还可以使用外部 IP 喷射装置来路由请求。

为了从应用程序目标子集转移请求，需要确保完成现有的正在处理的请求，并修改路由器组件，以避免向这些目标路由任何新请求。根据经验，通常需要等待与 Http 会话超时相等的时间，以确定特定应用程序目标的工作已全部转移。

一种常见的部署做法是让一个 WebSphere Application Server 仅承载来自一个业务应用程序的构件。这些构件不需要使用相同的 J2EE EAR 文件或作为同一个应用程序的部分进行部署，与 WebSphere 配置中的定义一样。不过，在运行时这些构件通常会彼此进行交互，因此需要同时部署或更新。此类配置当然是管理员的首选配置，而不是 WebSphere 要求必须采用的配置。此配置的一个优势在于，可以根据您的运行时和配置目的将不同应用程序彼此隔离。此类配置的源程序更新通常需要在更新期间停止和重新启动整个应用程序服务器。嵌入本机 C 或 C++ 代码库或与之进行交互的应用程序就常用此类配置。此类本机库的更新需要进行操作系统级别的进程重新启动。可能会因为其他业务的特定原因而选择此类配置进行应用程序部署和更新。

应用程序更新的另一个方面就是现有（已部署）应用程序和应用程序的新修订之间的客户机兼容性。应该同时考虑语法级别（应用程序公开的公共接口、用于访问 Web 层的 URL 等等）和语义级别（为给定客户机请求返回一致结果的应用程序业务逻辑）的兼容性。本文所述的应用程序更新注意事项和过程均主要侧重于兼容应用程序更新。

回页首

updateAppOnCluster 命令

WebSphere Application Server V6 中的新命令框架提供了 updateAppOnCluster 命令，其通过协调配置同步和集群成员重新启动以方便在 WebSphere 集群中进行应用程序 Rollout。此命令可满足无干扰应用程序更新的常见配置场景，在此场景中：

• 应用程序部署于 WebSphere 集群上。
• 集群采用水平配置；即集群成员分布在多个 WebSphere 节点。
• 作为更新 Rollout 步骤的一部分，需要重新启动整个集群成员（而不仅是其应用程序得到更新的成员）。
• 只要考虑了客户机连接性，就能保证更新后的兼容性；即在进行更新过程中，可以将客户机请求路由到应用程序的两个修订版本之一。

在 WebSphere 主存储库中进行了应用程序更新（由部署管理器控制）后，将会调用此命令。该命令将执行多个配置和操作动作，以一次性地将已更新应用程序部署到一个目标节点。将为集群中每个节点完成以下步骤：

1. 临时禁用节点上的自动配置同步选项，以确保在执行该命令时不会意外地对配置进行同步。

2. 停止该节点上运行相应的应用程序的集群成员。由于应用程序部署在集群上，因此，一旦集群（工作负载管理）逻辑检测到集群成员停止后，该集群成员就不会收到任何新请求。

3. 在主存储库与节点存储库间执行配置同步，以将已更新的应用程序部署到该节点。在同步操作最后，会将已更新的应用程序提取到节点的安装目的地。

4. 重新启动已停止的集群成员，以使其准备好接收请求。

使用 wsadmin 脚本调用此命令：

				
$AdminTask updateAppOnCluster { -ApplicationNames app1 -timeout 600}

				
$AdminTask.updateAppOnCluster ('[-ApplicationNames app1 -timeout 600 ]')

该命令接受要部署的应用程序列表作为参数。这些命令的适用于将多个相关 WebSphere 应用程序部署在集群上且一起更新的场景。timeout 参数是可选的，用于指定在应用程序 Rollout 期间等待服务器停止或启动的时间。（除非应用了 APAR PK10512，否则在 V6 中会忽略 timeout 参数。）

务必注意，命令执行时间可能会很长，具体取决于参与应用程序 Rollout 的节点数。用于调用该命令的管理客户机可能在发回命令结果之前超时，但可以更改管理客户机连接超时值，以避免发生这种情况。

回页首

结束语

应用程序更新是应用程序生命周期中非常重要的部分，而且可能是应用程序管理工作中最常执行的操作之一。IBM WebSphere Application Server V6 提供了大量有用的方法，以帮助进行应用程序更新和 Rollout，从而提供了处理这些重要而必需的任务的灵活性，并能加以控制。

回页首

下载

名字	大小	下载方法
05_apte_download.zip	7 KB	FTP|HTTP

关于下载方法的信息

参考资料

• 您可以参阅本文在 developerWorks 全球站点上的 英文原文
  
  
• WebSphere Application Server V6 信息中心
  
  
• WebSphere Application Server API doc
  
  

作者简介

为本文评分

评论

回页首

内容

• 引言
• 应用程序更新：应用程序生命周期的一部分
• V5 中受限制的更新功能
• V6 中的细粒度更新
• 细粒度回收行为
• 应用程序更新示例
• 应用程序更新期间的持续可用性
• updateAppOnCluster 命令
• 结束语
• 下载
• 参考资料
• 作者简介
• 建议