在多集群 WebSphere Process Server 单元中配置高效的消息传递

Matt Roberts, 高级 IT 专家, IBM Hursley

引言

随着客户开始使用 IBM® WebSphere® Process Server（以下称为 Process Server）来管理越来越多的业务流程或实现其自动化，将所有必要的模块都包含在单个黄金部署拓扑中的做法经常变得不再可行。为了处理这个问题，可以创建一组新的黄金集群，并在两个目标之间分配模块，但此方法需要仔细考虑 SCA 运行时和应用程序模块使用 WebSphere Service Integration Bus（以下称为 SIBus）消息传递组件的方式。本文将提供一系列以高效且可维护的方式配置 SIBus 的最佳实践指南，从而帮助您成功进行实现。

黄金拓扑

本文将提供黄金拓扑的概述，介绍多黄金拓扑中的 SIBus 消息传递，并说明如何在多黄金拓扑环境中配置高效的消息传递连接。

概述

虽然有着各种不同的称法，包括黄金拓扑、白银拓扑、全面支持或远程消息传递，不过大部分 IBM® WebSphere® Process Server 和 WebSphere Enterprise Service Bus 客户都在使用这样的生产配置，其中的服务集成总线消息传递引擎配置为独立的 WebSphere 集群的一部分，Process Server 或 WebSphere ESB 模块承载于此集群中，如图 1 中所示。

图 1. 黄金拓扑

什么是黄金拓扑？ 有关黄金拓扑、白银拓扑、全面支持或远程消息传递的含义的完整细节，请参见在下面参考资料部分提供的链接。

对于此文档中描述的功能，黄金和白银拓扑彼此相当，都具有独立的消息传递集群。此文档全文中均使用黄金拓扑，但是本文中的观察结果也同样适用于白银拓扑。白银拓扑和黄金拓扑的区别在于其中的 CEI 功能部署到应用程序集群，而并没有自己的独立集群。

在此拓扑中，应用程序模块部署到应用程序集群，消息传递集群中只有单个活动消息传递引擎，如 MEServer1 中所示，它在 MEServer2 中有一个被动对等项，在 MEServer1 出现故障时备用。

图中所示的集群链接集提供了独立调配和管理环境的各个组件的能力，例如，提供应用程序集群中的服务器数量，以满足所安装的各个应用程序模块的可伸缩性或吞吐量需求。

模块可伸缩性问题

虽然环境拓扑提供了出色的可伸缩性，但是随着为了满足业务需求而开发的 SCA 模块不断增多，越来越多的客户感到单个集群链接集已不足以满足这些模块的需求。

在有些大型生产方案中，SCA 模块的数量达到一百或两百的情况并不少见。这可能是由于采用了过度细粒度的方法处理模块或服务定义造成的，或者是由于客户反对对代码开发或管理进行划分来与现有团队结构相匹配的做法造成的。

在包括大量 SCA 模块的客户方案中，经常会出现黄金拓扑环境非常勉强地努力满足项目的非功能需求，例如：

• 应用程序集群中的服务器启动时间长到不能接受，从而使得在生产或开发环境中进行维护之类的管理任务极为费时。
• 部署在应用程序集群中的应用程序的数量太多，导致可用的 Java™ 堆大小中没有足够的空间运行应用程序。
• 服务集成总线消息传递引擎启动或故障转移的时间长，导致出现不能接受的长时间停机或 ME 不可用的时间内服务不可用。

这些问题是由于每个模块的初始化开销及消息传递引擎（Messaging Engine，ME）上的负载造成的，这两个因素都可能随着应用程序数量的增加而成为阻碍因素。

每个 SCA 应用程序都会导致在消息传递引擎上创建一系列目的地，增加 ME 的启动逻辑的负载。创建的目的地的数量取决于模块的复杂性和其中使用的操作的类型，经常会导致每个模块创建六个或更多目的地。ME 使用 WebSphere 平台中的其他服务意味着启动消息传递引擎的时间长度将以 n² 为系数变化，其中“n”是消息传递引擎本地的目的地的数量。因此，随着所安装的 SCA 应用程序的数量的增加，ME 启动或故障转移所花的时间也会增加，但是后者增加速度会更快一些。

对于小型到中型规模的目的地数量（上限为约 300 个），消息传递引擎启动时间的增加通常是可接受的。不过，如果定义的目的地超过了 300 个，或者包括的 SCA 模块超过了 50-60 个，则 n² 增加所带来的效果将非常明显，导致 ME 故障转移时间从以秒计算增加到以分钟进行计算。

使用多黄金拓扑模式解决可伸缩性问题

解决部署如此众多的 SCA 应用程序导致的问题的最简单方法是将应用程序集划分为两个或更多独立的黄金拓扑集群集（每个应用程序仅部署到一个应用程序集群），并对每个应用程序集群采用独立的 ME 集群，如下图中所示。

图 2. 将应用程序划分到两个或更多黄金拓扑副本中

通过将应用程序拆分到多个应用程序集群，任何给定服务器上都有必须启动的应用程序，从而缩短了服务器启动的时间，与此类似，由于每个消息引擎上的本地目的地数量为之前的一半，因此 ME 的启动和故障转移时间都应该减少到可以接受的范围内。

上述设计可以采用两种方式进行实现：

1. 每个黄金拓扑一个单元
2. 单个单元中配置多个黄金拓扑集群集

方法 A（多个单元，各自包含一个黄金拓扑的副本）能保证模块彼此独立运行，不过需要以安装、配置和维护新单元基础结构的额外管理开销为代价。另外，如果在安装于不同的单元中的模块之间有通信需求，则不能轻易使用此拓扑，因为需要进行手动配置才能允许此行为。

方法 B（单个单元/多个集群）避免了额外的配置开销，但是必须谨慎实施，以确保每个集群的 Process Server 功能不会彼此干扰；例如，务必注意以下要点：

1. 应用程序集群必须将“remote SCA destination”位置属性设置为相关的消息传递引擎集群，以便在安装 SCA 模块时正确地将目的地本地化。
2. 每个 ME 集群中的消息传递引擎应该成为相同 SCA.APPLICATION 和 SCA.SYSTEM 总线的成员。对于系统总线，这将允许一个集群中的模块调用另一个集群中的模块；而在应用程序总线中，可以节约为每个黄金拓扑副本创建独立总线的管理成本。

即使假定上述配置能正确实现，上面的关系图中所示的连接模式通常不会完全按照您的预期实现。有关连接过程的描述，请参见下面的如何实际建立 SIBus 连接部分。

多黄金拓扑中的 SIBus 消息传递

如何实际建立 SIBus 连接

图 2 中所示的所需连接模式的简化形式如下：

图 3. 所需连接模式的简化视图

从 SCA 模块到 SCA.SYSTEM 或 SCA.APPLICATION 总线的每个连接都由 JMS ConnectionFactory、JMS Activation Specification（对于 JMS 消息驱动的 Bean）或 J2C Resource Adapter Activation Specification（对于内部 SCA 消息驱动的 Bean）控制。

缺省情况下，这些管理项目包含一组属性，用于告知系统将应用程序连接到指定总线上的任意消息传递引擎（系统或应用程序）。对于单元中单个黄金拓扑的情况，这是可以接受的，因为只有一个消息传递引擎供选择。不过，如果总线中有多个 ME，如相同单元中存在多个黄金拓扑的副本的情况，则连接将需要在可用的消息传递引擎之间进行工作负载平衡。

多个消息传递引擎之间的工作负载平衡意味着 Module1 将有 50% 的时间连接到 ME2，以发送/接收本地化到 ME1 的消息，如下所示：

图 4. 交叉连接模式

图 4 中所示的交叉连接模式会导致在消息传递引擎中创建远程队列点（Remote queue points，RQP）。RQP 是运行时构件，对于应用程序发送到的目的地不由所连接的消息传递引擎承载的情况，由 RQP 对这些消息进行存储和管理。在图 4 中所示的模式中，将创建一个 RQP，用于 ME1 承载的 Module1 的消息所传输到的目的地。

交叉连接模式的缺点

性能

由于使用了在两个消息传递引擎之间传输消息的可靠协议，而这在应用程序和所需的目的地之间造成了额外的通信延迟，因此交叉连接模式效率较低。

对于这个交叉连接模式造成的性能降低，很难进行理论预测，不过我们可以很容易地发现，从应用程序所连接的 ME（上面图 4 中的 ME2）以可靠方式将消息传递到消息所发送到的目的地所在的 ME (ME1) 需要额外的跳转，这样所带来的开销是非常大的。

因此，出于性能考虑，有必要对环境进行配置，以避免交叉连接模式。

可管理性/服务能力

用于连接到消息传递引擎的工作负载管理算法要求，如果未指定目标属性，则系统实际上会基于请求的运行时顺序对连接进行轮询。这意味着，很难或不可能预测在什么地方建立连接，因为连接的目标取决于给定服务器中所有连接请求的准确顺序。

这增加了系统管理的复杂性，因为服务器之间要创建的连接组并不固定；例如，无法使用 netstat 进行查看。

这个行为还会导致服务能力问题，因为特定方案的两次执行可能使用完全不同的连接模式，而导致在考察应用程序是直接连接到其与之通信的目的地所在的消息传递引擎，还是通过中间消息传递引擎从该目的地获得消息时，可能会观察到不同的运行时行为。

当一个应用程序发送的消息未达到队列供第二个应用程序使用时，就出现了这方面的问题。从外部来看，消息似乎丢失了；事实上，此消息安全地存储在第一个应用程序连接到的消息传递引擎上的远程队列点上，在等待传输到目的地所在的消息传递引擎。如果不知道第一个应用程序连接到哪个 ME，则确认消息等待的位置并解决问题将非常费时。

出于一致性的原因，非常需要按照如下所示建立防止交叉连接模式的目标连接需求，从而形成强制的连接路径。

次要代码路径

与直接连接到承载目的地的消息引擎的应用程序相比，交叉连接 到其他消息传递引擎的应用程序使用了不同（且更为复杂）的代码路径。

在 Process Server 和 WebSphere ESB 的早期版本中，有些客户在由于疏忽而使用了交叉连接模式（会影响应用程序内的消息流）时遇到了功能问题。在第一代故障数据捕获记录（Failure Data Capture Records，FFDC）中，这种问题经常包含类或方法名称，涉及远程使用者、远程队列点 或保证交付 之类的文字。

IBM 已经修复了这些问题，因此务必确保向单元（隶属一个或多个总线）中所有服务器应用最新的服务修补程序。这些修补程序在下面的步骤 1 中描述，强烈建议将其应用到环境中的所有节点。

在多黄金拓扑环境中配置高效的消息传递连接

应用程序交叉连接时用于解决问题的简单方法是，配置 ConnectionFactory 或 ActivationSpecification 对象的必要属性，以告知系统连接到相应的消息传递引擎。

此过程包含三个步骤：

步骤 1：应用相关修补程序包

除了本文提供的脚本执行的配置更改外，还必须按照如下所述应用一系列服务更新，这些更新处理 Process Server 基础结构其他领域的同类交叉连接模式。

• 对于 Process Server v6.0.2，强烈建议使用包括 WebSphere Application Server 的 v6.0.2.27 或更高版本（Process Server v6.0.2.4 或更高版本）的修补程序包，因为其中包括一系列用于此方案的关键修补程序，是下面描述的 iFixe 之一的先决条件。
• JR29484 及其相应的先决条件：SCA 目标重要性
• JR30198：失败的事件管理器目标重要性
• PK71156：SIBus 恢复修补程序

请注意，在应用 JR29484 之后，按照 JR29484 的文档中所述，必须在各个 Process Server 应用程序集群的集群范围内定义一个 WebSphere 变量，其名称为 SCA_TARGET_SIGNIFICANCE，值为 Required 或 Preferred。

有关这些修补程序的进一步信息，请参见参考资料部分提供的链接。

步骤 2：创建属性定义（仅限于 Process Server v6.0.2）

重要说明：在进行任何配置更改前，应该创建 Process Server 配置的备份！

在 WebSphere Application Server V6.1（及关联的堆栈产品）中，配置此连接行为所需的属性已经进行了预定义，可供管理员进行配置。如果使用 v6.1 产品，则直接进入步骤 3。

如果配置文件是使用 v6.0.2.4 之前的 Process Server（具体来说，使用 v6.0.2.25 之前的 Application Server 版本）创建的，则属性定义不会自动生成。如果配置文件是使用 Process Server v6.0.2.3 或更早版本创建的（即使后来已经升级到了 Process Server v6.0.2.4 或更高版本），则必须遵循这些说明来定义属性。

设置属性定义所需的配置步骤在 PK54128 下描述，在下面的参考资料部分提供了相应的链接。此网页介绍如何使用管理控制台定义必要的属性定义，不过使用 Service 团队提供的 JACL 脚本“SIBUpdateResourceAdapter.jacl”和“SIBInternalUpdateResourceAdapter.jacl”更为简单，且不容易出错，能实现相同的配置。

此网页还说明了，有必要在创建配置文件前配置属性，不过这里所给的脚本并没有这个限制，可以在无需重新创建任何定义的情况下应用到现有配置文件。下载部分也提供了用于下载这些 JACL 脚本的链接。

对于希望定义属性的单元，必须使用以下命令运行一次这些脚本（有关完整细节，请参见“参考资料”部分提供的链接所指向的文档）。

清单 1. 运行脚本来创建目标属性定义

wsadmin ¨Cf SIBUpdateResourceAdapter.jacl wsadmin ¨Cf SIBInternalUpdateResourceAdapter.jacl

步骤 3：配置目标属性

现在已经定义了属性，接下来必须使用相对于您的环境的必要环境特定变量对其进行配置。这包括对两个（或更多）应用程序集群的集群范围内定义的每个 JMS ConnectionFactory、QueueConnectionFactory、TopicConnectionFactory、ActivationSpecification 和 J2C ActivationSpecification 进行以下更改：

• 将 TargetType 设置为 BusMember：我们希望连接到相关 Process Server ME 集群中的消息传递引擎。
• 将 Target 设置为 ME 集群的名称。
• 将 Significance for Connection Factories 设置为“Preferred”或“Required”，具体取决于您的应用程序环境（有关选择这两个选项的帮助，请参见后面的内容）。对于 ActivationSpecifications，其重要性应始终设置为“Required”。

现在这个活动可能会非常耗时，因此本文在下载部分提供了名为“configure_MultipleGold_Messaging.jacl”的脚本，用于帮助您自动执行此工作。

此外，为了避免必须每次安装新应用程序或进行配置后必须重新进行此活动，脚本将更新指定对象的 admin 对象模板，从而使创建的任意新对象都会自动选取合适的缺省值。因此，安装新应用程序时，除非开发人员或管理员专门进行了另行配置，否则在相应范围内（例如，群集上）创建的任何 ActivationSpecification 对象都将自动选取关联的消息传递引擎作为其目标。

 

Preferred 和 Required 的区别何在？

目标重要性属性提供的基本行为如下：

• Required：连接到其他目标属性（例如，总线成员）中指定的目标。如果此目标不可用，则连接失败。
• Preferred：尝试连接到其他目标属性中指定的目标。如果该目标不可用，则尝试连接到相同总线中运行的任意消息传递引擎。

请注意，如果管理员设置了“Preferred”，而指定的目标在创建连接时不可用，则将创建到其他 ME 的连接。如果稍后原始（首选）目标再次可用，不会自动丢弃连接并进行重新建立；应用程序将保持连接到非首选 ME，直到该连接由于任何原因断开为止。对于长期存在的连接，或使用连接池技术时，这个行为可能不尽人意，这种情形应该使用“Required”目标重要性。

 

选择使用 Preferred 还是 Required

可以在两种类型的对象上设置目标属性：连接工厂和激活规范。

激活规范
激活规范为消息驱动的 Bean（Message Driven Bean，MDB）提供必要的配置细节，并包括关于在何处连接以及从哪个目的地使用消息的信息。激活规范可以由开发人员/管理员创建，也可以由 SCA 基础结构作为 SCA 模块定义的一部分创建。

无论 Activation Specification 如何创建，目的地的位置都是在配置时固定的，因此我们可以准确地知道 MDB 应该连接到哪个总线成员。连接到任何其他总线成员将导致上面所述的交叉连接模式，因为将尝试通过已连接到的总线成员从消息传递引擎检索消息。

如果承载目的地的消息传递引擎没有运行，即使连接到其他消息传递引擎，MDB 也无法使用消息，因为该 ME 仍然需要联系这个不可用的 ME 来检索消息。因此，对于 ActivationSpecifications，我们应始终将重要性设置为“Required”，以获得最佳的性能。（请注意，无论指定的参数如何，configured_MultipleGold_Messaging.jacl 脚本会始终将激活规范重要性设置为“Required”，而此选项仅适用于连接工厂对象。）

连接工厂
连接工厂用于发送或接收消息，将使用的目的地在配置时未知。

如果管理员知道特定的连接工厂将仅用于使用消息，则可以应用与上面激活规范相同的逻辑，应该为目的地所在的总线成员设置“Required”目标。

如果连接工厂将仅用于发送消息，则通常最好将重要性设置为“Preferred”，以获得更好的容错能力（消息将在总线中有任意消息传递引擎可用的情况下发送）。对此，有下面两个例外，这两种情况下需要使用“Required”设置：

1. 前一部分所述的关于这些主体的可管理性/服务能力。
2. 消息顺序或事件序列。如果使用了“Preferred”设置，则应用程序在出现故障的情况下可能会通过其他路径发送消息，从而无法保证消息到达目的地的顺序。如果需要考虑消息顺序，则应该始终使用“Required”。

 

如何运行目标属性配置脚本

重要说明：在进行任何配置更改前，应该创建 Process Server 配置的备份！

下面的清单中提供了如何执行随本文提供的配置脚本的简单示例，用于自动进行上述必要的配置更改。

清单 2. 运行脚本来配置目标属性定义

wsadmin -f configure_MultipleGold_Messaging.jacl CORRECT AppCluster1 Required

... 其中，AppCluster1 是之前配置的 Process Server 应用程序集群的名称。

接下来同步各个必要的节点，然后重新启动应用程序集群中的每个服务器。如果不想重启消息传递集群服务器，可以不重启。

配置更改生效后，任何现有（或新的）应用程序都只会连接到在关联消息传递集群中的消息传递引擎，这样更为高效，而且避免了上面所述的缺点。

 

运行脚本的场合

对于系统中的每个 Process Server 应用程序，都必须运行一次此脚本。因此，如果您的环境有两个黄金拓扑实例，则将需要运行此脚本两次，并分别提供相应的集群名称参数。

如果在单元中有 Process Server 集群之外的其他服务器，而这些服务器包括连接工厂或激活规范对象的定义，则还应该遵循清单 6 中提供的针对非集群化服务器的说明，按照与上面所述类似的方式配置这些对象的目标属性。

在开始功能或性能测试之前，必须将脚本作为标准配置流程的一部分运行，以确保环境与将在生产环境中使用的环境匹配。

运行脚本一次之后，所有现有应用程序都得到了正确配置，并会为安装到 Process Server 应用程序集群的任何新应用程序创建相应的缺省设置并在此范围内创建其资源。

在大多数情况下，缺省设置对所部署的新应用程序都将是正确的。不过，为了确保设置了正确的配置，应该考虑在每批新应用程序安装之后重新运行一次脚本，以检查缺省设置是否真正得到了正确应用。

执行脚本时，会输出所找到的配置的摘要，以及进行了哪些更改或建议进行哪些更改。下面示例控制台输出部分提供了此摘要的示例。

 

资源范围需求

为了使脚本正确工作，必须能够自动地确定哪些连接工厂和激活规范资源与应用程序/消息传递引擎集群关联。为了完成此工作，要假设在应用程序集群中的集群范围定义了所有必要的资源，SCA 模块自动创建的资源通常是这样。

如果有在其他范围配置的资源（例如，在单元范围），而这些资源将由 Process Server 应用程序集群中的应用程序使用，则强烈建议在运行脚本之前在相应的应用程序集群范围重新定义这些资源。

重要说明：此脚本包括了用于手动指定资源定义的范围的选项（请参见脚本顶部的注释）。不过，这在处理单元范围内的资源时非常不足，因为不非常谨慎，就可能在为第二个集群执行此脚本时重写新属性值。由于这个原因，本文并不对这个选项进行深入讨论，并假定所有资源都在相应的集群范围定义。

 

使用配置脚本

此脚本使用以下命令执行：

清单 3. 运行脚本来配置目标属性定义

wsadmin.sh -f configure_MultipleGold_Messaging.jacl

请注意，这里并不会详细讨论可选的 scopeOverride 参数，因为其使用并不代表最佳实践，请参见前一部分的说明。

参数文档

下面将详细讨论每个参数。

表 1. mode 参数的说明

mode

值	描述
VALIDATE	检查当前配置选项中指定的值，并判断这些值的适合性，但并不进行任何配置更改。
COMPLETE	更新尚未设置的任何配置选项的值，但并不修改已经配置的项的值。 此选项用于解决所有资源都在单元范围定义的问题（有多个应用程序集群）；不过在这里将不对此进行讨论，因为在单元范围定义资源并不是这种情况下的最佳实践。
CORRECT	将所有值更新为与脚本（并参考用户输入的其他参数）确定的最优选择匹配。这是在大多数情况下使用的选项。

表 2. appClusterName 参数的说明

appClusterName

值	描述
Name of application cluster	插入您的特定环境的 Process Server 应用程序集群的名称。 此信息用于查找相应的资源范围，也用于计算关联的消息传递引擎集群的名称。

表 3. significance 参数的说明

significance

值	描述
Required	如上所述，将找到的任何连接工厂对象的目标重要性设置为 Required。
Preferred	如上所述，将找到的任何连接工厂对象的目标重要性设置为 Preferred。

脚本执行示例

在下面的示例中，假定部署管理器在与执行脚本的会话相同的主机的缺省端口运行。如果您的环境中不是这样，则必须提供 -host 和 -port 参数，以便管理客户端连接到部署管理器。

清单 4. 将配置更新为 Required

wsadmin -f configure_MultipleGold_Messaging.jacl CORRECT env.AppTarget Required

更新集群“env.AppTarget”中定义的所有消息传递资源定义，将目标重要性设置为 Required，覆盖任何现有数据。这是脚本的最常见执行模式。

清单 5. 验证连接工厂的配置是否使用 Preferred 重要性

wsadmin -f configure_MultipleGold_Messaging.jacl VALIDATE env.AppTarget Preferred

检查“env.AppTarget”集群中消息传递资源适配器的配置，将结果打印到控制台。未进行/保存配置更改。

将检查激活规范，以确定是否与相关目的地的计算主位置匹配，且具有 Required 目标（请参见选择使用 Preferred 还是 Required）。 将检查 JMS Connection Factory 对象，确定是否使用应用程序集群的关联 ME 集群的总线成员的名称将其设置为 BusMember/Preferred。

重要说明：请注意，当使用 Validate 选项运行脚本时，将在脚本退出时看到一个或多个以下警告消息：

-------------------------------------------------------- No changes have been saved to the configuration. --------------------------------------------------------

WASX7309W: No "save" was performed before the script. "configure_MultipleGold_M essaging.jacl" exited; configuration changes will not be saved.

这些消息确认没有对配置进行更改，完全可以将其忽略。

清单 6. 更新非集群化服务器的配置（全部在一行上）

wsadmin -f configure_MultipleGold_Messaging.jacl CORRECT server1 Required /Node:myNode01/Server:server1/

除了标准 Process Server 应用程序集群外，有些用户还可能在单元中有一个或多个非集群化服务器；例如，用于承载不能在集群化环境中运行的适配器。

这些非集群化服务器还可能在其服务器范围内定义消息传递资源，并且必须采用与应用程序集群类似的方式配置，这可以通过使用上面所示示例实现。

在此服务器范围定义的活动规范将自动获得承载正确计算的目的地的总线成员的名称。

要为在此服务器范围定义的 JMS ConnectionFactory 对象定义目标总线成员，管理员必须在服务器范围手动配置一个 WebSphere 变量，将其名称设置为“JMSCF_TARGET_BUS_MEMBER”，值为目标总线成员名称。例如，要指向同一个非集群化服务器上的所有 JMS CF 对象，必须使用“node.server”语法：例如，在上面所示的脚本调用中使用“myNode01.server1”指示服务器。如果目标总线成员是集群，则将使用集群名称作为此变量的值。

如果未设置 JMSCF_TARGET_BUS_MEMBER 变量，则连接工厂对象将保留空目标字段，以便在运行时可用的消息传递引擎集中进行工作负载平衡。

 

已知的约束和限制

• ConnectionFactory 和 ActivationSpecification 名称（显示名称，而不是 JNDI 名称）包含空格，使得很难或不可能对项目列表进行解析。推荐的解决方法是删除空格。
• 如果资源在单元范围定义，则脚本可以确定哪些资源应该与哪个集群关联。最佳实践是在相应集群范围内定义资源

 

脚本使用示例

管理控制台示例

在执行本文描述的步骤之前，缺省情况下，激活规范或连接工厂将不会设置目标，如管理面板中的 JMS Activation Specification 的屏幕截图中所示。

图 5. 管理控制台中目标属性的缺省（未配置）值

请注意，Target 字段为空，而 Target Type 和 Target Significance 字段使用缺省值“Bus member name”和“Preferred”。除非在 Target 字段中输入名称，否则不会考虑 Target Type 和 Target Significance 的值。

现在，请对相应的应用程序集群运行配置脚本（可以在上面的截图中看到）。

wsadmin -f configure_MultipleGold_Messaging.jacl CORRECT mattEnv.AppTarget Required

如果从控制台注销，然后再次登录（以强制新配置更改生效），并再次查看相同的对象，您将会发现值已经通过执行脚本更新了，如下所示：

图 6. 由脚本进行配置之后的目标属性

控制台输出示例

以下显示了运行脚本的控制台输出示例。

WASX7209I: Connected to process "dmgr" on node KADGINCellManager01 using SOAP connector; The type of process is: DeploymentManager WASX7303I: The following options are passed to the scripting environment and are available as arguments that are stored in the argv variable: "[CORRECT, mattEnv.AppTarget, Required]" Precondition validation: - Found application cluster OK - Found associated ME cluster name: mattEnv.Messaging -------------------------------------------------------- Found Platform. Messaging Component SPI Resource Adapter -------------------------------------------------------- * Found activation spec: sca/SOACoreIVT/ActivationSpec busName: SCA.SYSTEM.KADGINCell01.Bus destination: sca/SOACoreIVT target: mattEnv.Messaging (current config) targetType: BusMember (current config) targetSignif: Required (current config) BusMember: mattEnv.Messaging (calculated) * Found activation spec: jms/act/adapterServerAS busName: SCA.APPLICATION.KADGINCell01.Bus destination: myQueue target: KADGINNode01.server1 (current config) targetType: BusMember (current config) targetSignif: Required (current config) BusMember: KADGINNode01.server1 (calculated) * Found activation spec: corespi/topicTest busName: SCA.APPLICATION.KADGINCell01.Bus destination: Default.Topic.Space target: mattEnv.Messaging (current config) targetType: BusMember (current config) targetSignif: Required (current config) durability: NonDurable * Found an activation spec TEMPLATE on the RA - Setting value of targetType to BusMember - Setting value of target to mattEnv.Messaging - Setting value of targetSignificance to Required -------------------------------------------------------- Found SIB JMS Resource Adapter -------------------------------------------------------- * Found activation spec: jms/cei/QueueActivationSpec jndiDest: jms/cei/EventQueue busName: CommonEventInfrastructure_Bus destination: mattEnv.Messaging.CommonEventInfrastructureQueueDestination target: mattEnv.Messaging (current config) targetType: BusMember (current config) targetSignif: Preferred (current config) BusMember: mattEnv.Messaging (calculated) - WARNING: Target significance is not optimal in current config - FIXED: Target significance updated to Required * Found activation spec: actspec/MattTest jndiDest: jms/fred busName: SCA.APPLICATION.KADGINCell01.Bus destination: adapterQueue target: anIncorrectTarget (current config) targetType: ME (current config) targetSignif: Preferred (current config) BusMember: KADGINNode01.server1 (calculated) - WARNING: Target name is not optimal in current config - FIXED: Target name updated to KADGINNode01.server1 - WARNING: Target type is not optimal in current config - FIXED: Target type updated to BusMember - WARNING: Target significance is not optimal in current config - FIXED: Target significance updated to Required * Found activation spec: jms/act/TopicAS jndiDest: jms/myTopic busName: SCA.APPLICATION.KADGINCell01.Bus destination: Default.Topic.Space target: mattEnv.Messaging (current config) targetType: BusMember (current config) targetSignif: Required (current config) durability: NonDurable * Found a JMS CF: jms/sampleCF target: (current config) - WARNING: Target name is not optimal in current config - FIXED: Target name updated to mattEnv.Messaging targetSignif: Preferred (current config) - WARNING: Target significance is incorrect - FIXED: Target significance updated to Required targetType: BusMember (current config) * Found an activation spec TEMPLATE on the RA - Setting value of target to mattEnv.Messaging - Setting value of targetSignificance to Required - Setting value of targetType to BusMember * Found a JMS TEMPLATE on the RA - Setting value of Target to mattEnv.Messaging - Setting value of TargetSignificance to Required - Setting value of TargetType to BusMember * Found a JMS TEMPLATE on the RA - Setting value of Target to mattEnv.Messaging - Setting value of TargetSignificance to Required - Setting value of TargetType to BusMember * Found a JMS TEMPLATE on the RA - Setting value of Target to mattEnv.Messaging - Setting value of TargetSignificance to Required - Setting value of TargetType to BusMember -------------------------------------------------------- Save any configuration changes that were made. --------------------------------------------------------

结束语

本文介绍了一系列步骤，用于确保单个 WebSphere 单元具有多个黄金部署拓扑时大型 WebSphere Process Server 环境遵循相关的最佳实践。我们讨论了在这种环境中使用 Service Integration Bus 消息传递时潜在的缺陷，并提供了一个脚本，可用于自动配置消息传递资源，使其遵循最佳实践。

通过遵循本文中所述的步骤，您可以利用我们通过与实现了这种类型的拓扑的领先客户协作时获得的经验教训，帮助确保您的部署成功。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/14789789/viewspace-610856/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/14789789/viewspace-610856/