级别： 中级 Sebastian Faulhaber, IT 专家, IBM, Software Group
Konstantin Luttenberger, IT 专家, IBM, Software Group
Anne Faulhaber , IT 专家, IBM
2009 年 6 月 01 日 本文是这个由两部组成的系列文章的最后一部分，将介绍 IBM WebSphere Process Server 的操作体系结构，并阐述其核心组件的工作原理。在本文中，您将了解构建 WebSphere Process Server 的运行时层的组件，以及这些组件在操作环境中如何一起工作。您将首先研究 SCA 运行时模块，然后探索功能层，以了解 WebSphere Business Process Choreographer 如何管理业务流程、CEI 的用途，以及有关支持服务的内容。
SCA 运行时简介
在本系列文章的 第 1 部分 中，服务组件体系结构（Service Component Architecture，SCA）规范是 IBM® Business Process Management (BPM) 堆栈中的主要构造块之一。换句话说，SCA 是 SOA 的体系结构风格的实现规范。本系列文章的第 1 部分介绍了操作参考体系结构（请参见图 1）。
图 1：WebSphere Process Server 的操作参考体系结构
本文将概述具体的运行时实现和相关构件，如 WebSphere® Process Server（以下称为 Process Server）上下文中的模块和组件。在此方面，将从操作角度重点介绍如何实现事务，以及哪些组件比较重要。由于 Process Server 依赖于 WebSphere Application Server（以下称为 Application Server）技术和功能，因此您将会看到许多 J2EE 组件，其中一些组件您可能已经熟悉。
SCA 模块
SCA 规范将引入称为模块的新概念类型来创建面向服务的业务应用程序。SCA 模块本身可描述为向外界公开服务进而实现某种业务逻辑的应用程序。从集成开发人员的角度而言，业务应用程序由一组在某个业务级别上彼此交互的不同模块组成。例如，称为 InvoiceHandling 的模块使用由 CustomerManagement 模块公开的服务。SCA 意在尝试提供这种以业务为中心的视图，它是具体的技术实现，可解决如何实现 CustomerManagement 模块的实际服务调用问题。这在许多情况中是隐藏的。不过，这使得管理人员和架构师的协作更为重要，只有这样才能了解 SCA 模块的各个操作方面，从而在 Process Server 基础结构中获得成功实现。
从更技术的角度看，SCA 模块基于 J2EE 技术，并使用了人们若干年来一直使用的各种概念：Enterprise Java™ Bean (EJB)、消息驱动的 Bean（Message Driven Bean，MDB）和 Java 2 Connector Architecture (J2C) 等。对于 J2EE 而言，SCA 模块的结构如下所述（请参见图 2）。
图 2：SCA 模块的操作视图
一个 SCA 模块将产生一个用于部署的企业存档 (EAR) 文件，该文件包含一组 J2EE 构件：
- 仅当 Web 服务或 REST 服务由模块 1..1 公开时才创建 0..1 Web 存档文件 (WAR)。
- 1..1 EJB 模块具有大量的 Bean：
- 1..1 无状态会话 Bean（Stateless Session Bean，SSB）负责同步 SCA 通信。
- 1..1 MDB 负责异步 SCA 通信。
- 0..n 取决于包含的 SCA 组件：即围绕组件的实现构建 Facade 的若干 EJB 和/或 MDB。
- 1..n 实用工具 JAR
- SCA 模块内容本身（除了核心服务组件定义语言（Service Component Definition Language，SCDL）文件以外，可能还包含用于某些 SCA 组件实现的配置文件）。
- 每个库一个（包含开发人员的接口和业务对象，实际上为 XSD 和 WSDL 文档）。
- 提供附加功能的大量 JAR 文件（用于实例 Log4J 或其他自定义开发的代码）。
SCA 组件
以前引入的 SCA 模块是其他 SCA 构件（如 SCA 组件）的容器。可以将这些模块看作构件。与 SCA 模块相比，这些构件可提供和使用更细粒度的业务服务。例如，前面提到的 CustomerManagement 模块可能包含一个负责创建新客户的组件 (CustomerCreation) 和另一个负责查询现有客户信息的组件 (CustomerQuery)。SCA 组件位于基础 SCA 模块的边界，并且仅向外界公开某些定义的服务。SCA 组装模型不指定组件的实际实现类型（请参见参考资料部分中的 SCA 组装模型）。但每个 SCA 运行时供应商可以提供一组不同的实现类型。对于 Process Server 而言，IBM 将在开发环境 (WebSphere Integration Developer) 中提供大量的 SCA 组件实现以供运行时使用。
常用的实现类型包括：
-
流程 (BPEL)。实现业务流程的执行。此实现涉及 BPC（请参见下一部分）和 Process Server 数据竖井的使用（请参见“参考资料”，了解本系列文章第 1 部分中的“数据库”部分）。
-
人工任务。实现与业务流程的人工交互。此实现涉及 BPC（请参见下一部分）和 Process Server 数据竖井的使用（请参见“参考资料”，了解本系列文章第 1 部分中的“数据库”部分）。
-
Java。允许集成开发人员在模块中写入自定义 Java 代码。
-
规则组。提供定义特定于某一业务的参数的能力（例如“Buying Approval Cap”），可以使用这些参数在运行时更改业务流程的行为。这涉及 Process Server 的数据竖井的使用（请参见本文的“参考资料”部分，了解本系列文章第 1 部分中的“数据库”部分）。接口映射。实现数据和接口转换。
图 3. SCA 组件的操作视图
从操作角度看，SCA 模块的实际组装模型在运行时几乎完全隐藏（请参见图 2）。因此，操作人员和管理人员对模型中包含的 SCA 组件都不能提供清晰的可视化表示形式。只有集成开发人员才能提供模块内容的可视化概要。因此，请务必注意，在各种情况下都需要关于包含的 SCA 组件及其实现类型的详细信息：例如，故障排除和性能分析。
建议：开发和操作团队广泛地共享信息非常重要。由于 SCA 解决方案与传统的 J2EE 项目相比更为复杂，因此这方面对 Process Server 基础结构的成功操作非常关键。
操作体系结构
正如本系列文章的第 1 部分中提到的，Process Server 可以提供 IBM 的 SCA 规范的实现。所谓的 SCA 运行时（如操作参考体系结构中所示）提供实际的功能，用于运行符合 SCA 编程模型的应用程序。SCA 运行时是 Process Server 环境的核心构造块之一。下图显示了运行时操作体系结构的概述：
图 4. SCA 运行时的操作体系结构
WebSphere Application Server 提供的 J2EE 功能为具体的 SCA 实现构建基础。SCA 运行时主要使用事务处理、工作负载平衡和数据库连接功能来访问 Process Server 基础结构层中的组件（数据库和服务集成总线）（请参见本文参考资料中本系列文章的第 1 部分）。此外，这意味着 SCA 运行时还向在其上运行的 SCA 模块公开基础 J2EE 容器的高质量服务。
- SCA 实现 JAR：
- Java 存档文件包含特定于 IBM 供应商的实现代码，如不同的 SCA 组件实现（业务流程、Java、适配器、状态机、人工任务、业务规则、接口映射和选择器）使用的 SPI（服务提供者接口）和业务应用程序使用的 API。
- 消息传递资源：
- 名为“SCA.SYSTEM.<busID>;.Bus”的服务集成总线（Service Integration Bus，SIB）主要用于模块和组件之间的异步 SCA 通信。它包含在部署时自动生成并与特定 SCA 模块关联的大量队列。可以将这些队列视为 SCA 环境中不同组件之间的通道，而 SCA 运行时负责路由各种消息。
此外，还存在一个名为“SCA.APPLICATION.<busID>.Bus”的总线。从操作角度而言，它没有 SYSTEM 总线重要，因为该总线主要包含与基础 SCA 通信不相关的某些场景的队列。例如，在 SCA 模块中使用 JMS 导入时，此总线可用于定义自定义队列。
- 对集成解决方案控制台（Integrated Solutions Console，ISC）的扩展：
- ISC 以前称为 WebSphere 管理控制台，它通过添加一些特定于 SCA 的视图进行了扩展。这些视图使操作人员和管理人员能够在开发的 SCA 模块上大致了解开发人员的透视图（另请参阅“支持服务”部分）。不过，这些功能不能代替开发人员和操作人员之间必要的知识共享。
SCA 运行时重要说明
SCA 运行时提供运行 SCA 模块的核心功能，因此它是 Process Server 的主要构造块之一。请务必注意，SCA 编程模型向开发人员隐藏了大部分模块的具体技术实现。这样可让开发人员将精力集中于应用程序的业务方面。不过，这在运行时可导致操作人员无法预见的复杂错误场景和难以解决的性能问题。
因此，在开发人员和管理人员之间进行积极广泛的知识共享对于 Process Server 操作的成功极为重要。
开发人员应与管理人员共享广泛的信息来解决以下问题：
- 组件是否作为流程和/或人工任务实现？
- 流程是长时间运行的流程还是微流程（请参见 Business Process Choreographer 部分）？
- 应用程序有多少个模块，它们是如何连接的？
- 模块向外界公开哪些接口？
- 模块是访问 BPC 还是 HTM API（请参见 WebSphere Business Process Choreographer 部分）？
WebSphere Business Process Choreographer
在本系列文章的第 1 部分中已经提到，WebSphere Business Process Choreographer 通常使用 Process Server 功能。许多项目使用业务流程和/或人工交互实现业务需求。Business Process Choreographer 由人工任务容器 (Human Task Container) 和业务流程容器 (Business Process Container) 组件构成。
操作体系结构
Business Process Choreographer 在 WebSphere Application Server 的 J2EE 运行时中运行，并使用不同的应用服务器组件，如服务集成总线 (Service Integration Bus) 和事务管理器 (Transaction Manager)。图 5 提供了 Business Process Choreographer 的体系结构概述。
图 5：Business Process Choreographer 的操作体系结构
该体系结构主要由两个企业应用程序：业务流程容器（称为 BPEContainer）和人工任务容器（称为 TaskContainer）构成。这些应用程序可以访问 BPE 数据库和位于 Business Process Choreographer Bus 上的某些特定于 Process Choreographer 的队列（请参见参考资料部分中的 WebSphere Process Server 操作体系结构：第 1 部分：基本体系结构和基础结构组件。
每个队列都有一种特殊功能。
当使用提供的向导或 wsadmin 脚本设置业务流程和人工任务容器时，将创建所有队列。还创建用于访问这些队列的连接工厂。这些连接工厂附带了一些缺省值（例如最大连接数），可能需要优化才能实现最佳性能（请参见参考资料部分中的 Websphere Business Process Management V6.1 – 性能优化）。
在设置 Business Process Choreographer 配置的过程中还创建了队列和连接工厂，Business Process Choreographer 数据库 (BPEDB) 的数据源是使用缺省值（即数据源连接池中的最大连接数）创建的。在进行此配置时可能也需要优化。
人工任务管理器和业务流管理器
正如前面提到的，Business Process Choreographer 用于管理业务流程和人工任务的生命周期。因此，引入了业务流管理器（Business Flow Manager，BFM）和人工任务管理器（Human Task Manager，HTM）。下图显示了如何访问这些管理器，以便使用其执行业务流程和人工任务的功能。
图 6：Business Process Choreographer - 接口和客户端
人工任务管理器和业务流管理器都提供可以通过不同接口访问的通用 API（请参见参考资料部分中的 WebSphere Process Server API 和 SPI 文档）。通过 Web 服务和 EJB 接口可以访问 HTM API，并且通过 JMS 接口还可以访问 BFM API。
请考虑访问这些 API 的几种不同的可能性：
- 您可以使用在客户端构建的 Process Server，如 BPC Explorer（请参见参考资料部分）。
- 可以使用 Process Server 的客户端生成框架 (Client Generation Framework) 生成客户端。
- 还可以编写自已的自定义客户端。
从操作角度看，要使用不同的接口，您需要监视和优化与资源相关并且用来访问这些接口的参数。
例如：
- SOAP/HTTP 请求的 Web 容器线程池大小
- 使用 JMS API 的查询大小
- 使用 Enterprise Java Bean API 和 Web 服务 API 操作的安全注意事项
- 针对某些 API 操作（如查询与业务流程和任务相关的对象）的数据库查询优化（使用物化视图或存储查询）（请参见参考资料部分）
对于管理而言，JMX MBean API 是管理 WebSphere Process Server 中与人工任务和业务流程相关方面的通用方法。JMX MBean API 可提供对各种 Mbean 的访问，例如人工任务管理器 (TaskManagement MBean)。
一些常见的 Process Server 操作任务有：
- 查询和重放 HTM 和 BFM 存放队列中的失败消息
- 刷新员工查询
- 删除未使用的员工查询
- 查询失败的事件（请参见“失败事件管理器”）
- 更改 HTM 或 BFM 配置
MBean 对自动化管理任务和监视流程服务器环境非常有用。
业务流程和业务流管理器
业务流管理器的主要任务是执行和管理使用业务流程执行语言（以下称为 BPEL）编写的业务流程。WebSphere Process Server 环境中的 BPEL 流程可以分为以下两种类型：微流程和长时间运行的流程。它们在处理方式上差异很大。微流程不能涉及人员交互（人工任务），并且自始至终都是自动执行的。而且，它们无法包含计时器操作（wait、onAlarm）或接收任何种类的异步消息（例如，事件处理程序）。它们在单个事务中运行，其状态仅保存在内存中，而不能持久性地保存到流程的服务器数据库中。
长时间运行的流程可以调用不能立即响应的服务，并且可以涉及人员交互。其状态是持久性的，并且可以长时间地运行。这就是当需要更新存放此类流程的模块时版本控制成为此类流程的重要因素的原因。
BFM 配置中的某些参数会影响运行时和性能：
-
重试限制。对失败调用的重试次数
-
保持队列消息限制。在业务流管理器处理切换到停顿模式之前，保持队列上允许的最大消息数
-
审核日志记录。（如果不需要，请考虑关闭）
-
CEI 日志记录。（如果不需要，请考虑关闭）
关闭审核日志和 CEI 意味着禁用执行审核和监视的预期方法。由于性能影响以及仅存在快照并且没有任何完整历史记录，因此，业务流程数据库不适于用作“审核存储”。因此，当关闭上述监视功能时，请注意这一点。
对于长时间运行的流程类型，流程中的事务行为以及与其他组件的交互类型在开发时确定。从操作角度而言，这一点非常重要，因为流程中的错误可能出现在不同位置，具体取决于事务边界和涉及的协议。只有开发人员可以影响错误出现的位置和方式。
同步交互方式：
异步交互方式：
- 失败事件
- BPC Explorer 中失败的流程
- BPC Explorer 中停止的活动
- 服务集成总线（SI 总线）异常目的地
- Business Process Choreographer 中的保留队列
您应该不断地监视错误可能发生的不同位置，以确保系统正常运行。可以使用工具和应用程序来帮助监视这些位置。对于队列监视（服务集成总线目的地和保留队列），可使用 Service Integration Bus Explorer（请参见参考资料部分），如果是失败事件，可使用失败事件管理器（请参见“失败事件管理器”部分）。
人工任务和人工任务管理器
人工任务管理器的主要任务是管理任务执行语言 (TEL) 中描述的人工任务。可以将人工交互定义为内联任务（作为业务流程的一部分实现）或独立任务（作为 SCA 组件实现）。开发人员负责任务分配（定义允许哪些用户执行与该任务关联的特定角色的工作）。
从操作角度而言，管理人员需要知道流程服务器的性能可能会显著降低，这具体取决于向人员或组分配的任务。例如，如果将一个组指派到某个任务的角色而不使用组工作项，那么会为该组中的每个用户创建一个工作项，这可能导致为一个任务实例创建数千个工作项。
建议：作为最佳实践，您应该在人工任务容器的设置中启用组工作项，并将“组”员工谓词用于人工任务中的任务分配。
HTM 分配中的特殊值会影响 WebSphere Process Server 的运行时，甚至开发的应用程序：
-
人员解析。刷新计划和超时会影响刷新员工查询的频率。如果您的组织变化很快，则可能需要比缺省值更频繁的刷新。
-
电子邮件服务。为升级邮件配置电子邮件设置。
- 影响 BFM 的性能和行为的自定义属性（请参见“参考资料”部分了解详细描述）。
-
审核日志记录。（如果不需要，请考虑关闭）
-
CEI 日志记录。（如果不需要，请考虑关闭）
Business Process Choreographer 重要说明
Business Process Choreographer 提供在 WebSphere Process Server 中运行 BPEL 流程和人工任务的所有功能。开发人员负责确定导致定义事务边界和使用不同交互风格的实现和限定符。因此，开发人员和操作人员之间的沟通对 Process Server 环境的成功至关重要。
为防止在生产中由于无法优化 Business Process Choreographer 而发生运行时和/或性能问题，应在预生产环境中执行以下任务：
公共事件基础结构
此部分介绍公共事件基础结构（Common Event Infrastructure，CEI）背后的一般概念，并描述如何在 Process Server V6.1 中使用它。CEI 是 IBM 用来发送、分发、保存和使用标准化事件的基础结构。CEI 使用的事件格式是定义公共基础事件（Common Base Event，CBE）的一般结构及其 XML 表示形式的 CBE 标准。
下图显示了组成 CEI 的构造块。
图 7：公共事件基础结构的构造块
事件服务
该基础结构中的中心组件是事件服务 (Event Service)。它负责处理 CBE，将其写入事件数据存储库 (Event Datastore) 中，并将其分发到 JMS 目的地 (JMS Destination)。可以为集群或服务器激活事件服务，这里还安装了相应的应用程序。
尽管每个 Process Server 单元中可能有多个事件服务，但是为简单起见，本部分只讨论缺省的事件服务。
使用 CEI，您可以将事件以同步方式或异步方式发送到事件服务。
事件服务消息驱动的 Bean
对于异步通信，将安装名为事件服务 MDB 的消息驱动的 Bean（Message Driven Bean，MDB），并使用 JMS 机制检索事件。
正如本系列文章的第 1 部分中描述的，服务集成总线（Service Integration Bus，SIB）是 Process Server 的缺省 (JMS) 消息传递提供者的实现。
当配置事件服务时，缺省消息传递提供者的事件服务 MDB 与所有资源一起安装，并以异步方式接收事件。可以为同一事件服务的其他 JMS 提供者安装更多的事件服务 MDB。图 6 也显示了此内容，不过我们将仅参考缺省的事件服务 MDB。下表显示了用于异步通信的相关资源：
- 公共事件基础结构 (SI-) 总线
- CEI 总线上用于每个事件服务的目的地
- 指向目的地的 JMS 构件
事件发送者和事件使用者
为帮助您了解 CEI 的配置，本文将介绍从事件发送者 (Event Emitter) 到事件使用者 (Event Consumer) 的每项内容，其中包括用来对资源进行抽象的构件。
- 事件发送者工厂概要
- 事件发送者工厂概要 (Event Emitter Factory Profile) 是研究事件发送者中用到的最重要的配置构件。您可以配置事件发送者工厂以同步方式和/或异步方式发送事件。可以使用所谓的事件总线传输概要 (Event Bus Transmission Profile) 进行同步发送，使用 JMS 传输概要 (JMS Transmission Profile) 异步发送事件。还可以配置首选通信方式。发送者可以单独定义通信方式。考虑到性能和可靠性，事件发送者工厂概要定义是在同一事务中发送事件还是在自已的事务中发送，这一点非常重要。
- 事件总线传输概要
- 事件总线传输概要 (Event Bus Transmission Profile) 为发送事件定义对应的事件服务运行的位置（事件服务可以在相同的单元中运行，也可以在不同的单元中运行）。JMS 总结传输概要 (JMS Bus Transmission Profile) 引用发送 CBE 的 JMS 队列 (JMS Queue) 和 JMS 队列连接工厂 (JMS Queue Connection Factory)。
- 过滤器工厂概要
- 您可以在过滤器工厂概要 (Filter Factory Profile) 中指定自定义过滤器，仅将特定的事件发送到事件服务。
当应用程序发送 CBE 时，它将使用 Java 命名和目录接口（Java Naming and Directory Interface，JNDI）检索事件发送者工厂概要和传输概要。CEI API 使用这些构件创建用来创建发送者 (Emitter) 对象的事件发送者工厂 (Emitter Factory) 对象。可以同步或异步发送事件，具体取决于您使用的传输概要。在同步发送情况下，事件发送者和事件服务之间的通信由标准的 EJB 机制完成。在异步发送的情况下，事件被发送到定义的 JMS 队列，由对应的事件服务 MDB 处理,然后将 CBE 转发到事件服务。
事件服务对接收的 CBE 执行的操作取决于配置。您可以将事件服务配置为将所有事件数据写入数据存储和/或将事件分发到其他 JMS 目的地。
事件组概要
应路由到相同 JMS 目的地的 CBE 被所谓的事件组概要 (Event Group Profile) 采用。每个事件组概要指定一个定义属于该特定事件组的事件的过滤器条件。而且，还确定此事件组的事件是否存储在事件数据存储库中。对于每个事件组，您可以定义若干 JMS 队列和最多一个 JMS 主题，其中对应的 CBE 应该由事件服务发送。
重要说明：了解在事件数据存储库中存储事件组的事件数据的影响至关重要。如果处理大量的 CBE 或者高负载运行，则意味着这可能导致性能问题。另外，从数据存储库不能自动释放 CBE，因此，CEI 的总体行为可能会随着时间的推移变得越来越差，甚至会摧毁您的文件系统。
事件使用者应用程序通过直接查询事件服务（使用 CEI API）或通过 JMS 获取事件来检索 CBE。如果事件数据以前已存储，则只接受第一种方法。
CEI 的操作视图
下图说明了上述缺省消息传递的概念。所有必需的资源（CEI 总线、目的地等）都随着事件服务的配置自动创建。还创建了一组缺省的配置构件。
图 8：CEI 的操作视图
对于事件发送者，生成了缺省事件发送者工厂概要 (Default Event Emitter Factory Profile)，它将引用同步和异步发送者概要，并将首选交互模式设置为“同步”。缺省事件发送者工厂概要引用的构件是缺省事件总线传输概要 (Default Event Bus Transmission Profile) 和缺省 JMS 传输概要 (Default JMS Transmission Profile)。第一个构件称为事件总线 EJB (Event Bus EJB)，它是在配置事件服务本身的过程中安装的。缺省 JMS 传输概要指示事件传输到 CEI 总线。在此总线上，运行事件服务的服务器或集群注册为总线成员。
缺省情况下，对应的消息传递引擎分别在该集群的服务器中运行。在更复杂的 Process Server 基础结构中，较好的做法是将运行的消息传递引擎与部署的 SCA 模块隔离（通常在所谓的消息传递集群上）。
用于缺省消息传递的事件服务 MDB 会拾取 CEI 队列目的地中的事件，并将其路由到事件服务。
对于事件服务，创建一个事件组概要（所有事件组概要），它将所有 CBE 路由到特殊主题并将事件数据存储在事件数据存储库中。CEI 总线上对应的主题空间称为“所有事件主题目的地”。
这在考虑高负载场景或如何传输大量的事件数据时非常重要：缺省情况下，将存储所有事件数据。在生产系统中，由于性能原因，建议执行以下两种操作之一：
公共事件基础结构重要说明
当处理业务流程时，您要了解业务流程的管理人员需要大量信息，例如，流程实例的执行时间。Process Server 和 WebSphere Integration Developer（以下称为 Integration Developer）使流程开发人员只需选中标准事件的一个选项就能够发送 CBE，或输入一小段 Java 代码即可发送带有特定内容的 CBE。一些业务流程的标准事件示例是包含流程开始时间和活动结束时间的事件。作为事件使用者，您可以编写自已的应用程序，或者仅使用 BPC Observer（请参见参考资料部分）或 WebSphere Business Monitor 之类的产品从事件中收集信息，“实时”显示信息并分析历史数据。
您可以采用各种方法使用事件数据。始终应注意性能影响，事件提交和持久性可能取决于与公共事件基础结构相关的资源配置。
支持服务
在本章中，我们将介绍管理人员在操作 Process Server 基础结构时需要了解的其他服务。下表突出显示了管理支持服务所需的一些应用程序：
- 业务规则 - 业务规则管理器
- 关系 - 关系管理器
- 选择器 – 集成解决方案控制台
- 应用程序调度程序 – 集成解决方案控制台
- 适配器 – 集成解决方案控制台
- 失败事件 - 失败事件管理器
由于失败事件管理器对正确地操作 Process Server 环境非常重要，我们将详细讨论它。
业务规则和业务规则管理器
Business Rules Manager 是帮助业务分析人员管理业务规则的 Web 应用程序。业务规则是使用“规则组”SCA 组件开发的。可以使用规则组基于某个选择标准选择规则集或决策表。最常见的示例是基于当前日期的选择。
规则集本身是由一些规则模板和规则构成的。可以在规则集中创建以下类型的（业务）规则：
- 操作规则。指示一个操作，如调用另一个 SCA 组件，而无需指定任何条件。因此，在调用规则集时，总是执行操作规则。
- If/Then 规则。类似于操作规则，但是另外指定了一个条件，指示何时发生相应的操作。
- 模板规则。规则模板的实例化。
您可以将规则模板视为操作或 If/Then 规则的抽象，并添加了定义可配置参数的能力。这些参数能够以业务分析人员更可读的方式显示。这就用到了业务规则管理器。可以使用它更改模板规则的参数值，基于该参数值定义新的规则。可以在运行时灵活地进行此类更改。
对于管理人员，务必知道由于业务规则的使用，运行时的行为可能会更改。在业务规则管理器中发布更改时，这些运行时行为会立即生效。业务规则数据存储在 Process Server 的通用数据库 (Common-DB) 中。因此，当通用数据库不可用时，业务规则管理器将无法正确地运行，这会进一步影响尝试使用业务规则的组件。
关系和关系管理器
关系是帮助关联 Process Server 中不同业务对象的构件。关系的具体映射项称为关系实例。在运行时可以使用关系管理器应用程序管理这些构件。关系数据也存储在通用数据库中。
例如，假设有一个需要地址的邮政编码信息的业务对象和需要城市名称的另一个业务对象之间的静态关系。如果由于某种原因，在关系中忘记了将邮政编码映射到名称，则可以在使用关系管理器部署之后添加它们。更改关系可能会更改运行时行为，记住这一点也非常重要。
选择器
选择器是基于某一选择标准（大多为当前日期）引入的 SCA 组件，用于动态路由对其他 SCA 组件的调用。在运行时可以通过 WebSphere Integration Console 添加或更改选择器的 SCA 目的地。
使用选择器的一个常见示例是 SCA 模块交换案例。假设一个选择器组件调用应被新版本替换的另一个模块。如果选择器基于当前日期，则管理员将安装该模块的新版本，并向选择器添加其他条件，以调用在激活日期开始使用的新版本。激活日期之后的调用然后将路由到新版本，之前的调用仍由旧模块版本处理。
应用程序调度程序
应用程序调度程序基于日期和时间信息提供启动和停止应用程序的功能。您可以使用它运行应用程序，例如，仅在夜间系统负载较低时运行那些需要占用大量资源的应用程序。应用程序调度程序使用的数据存储在 Process Server 的通用数据库中。
失败事件和失败事件管理器
本文将详细描述失败事件管理器，因为它对正确地操作 Process Server 至关重要。
在异步通信路径中发生问题时，SCA 运行时的行为与正常的 SIB错误处理不同。本文将讨论创建所谓失败事件的特殊情形。假设有一个从一个 SCA 模块到另一个 SCA 模块的模块间单向异步调用。这里重点回答以下问题：如果没有安装目标模块并发送了请求，会发生什么情况？
SCA 运行时无法在 SCA 系统总线中找到该请求的相应目标目的地。调用方无法通过异常或类似方法得到错误通知，因为通信是单向的，因此未创建指示该错误的任何响应。通常，您会考虑在 SIB 级别处理这些错误，即将该消息放入为发送方定义的系统异常队列。然而，系统异常队列难以处理，因为不存在任何在修复问题之后将消息放回相关目的地标准机制。因此，Process Server 使用专门为此类情况设计的所谓失败事件管理器。
下图显示了当描述的问题出现时所发生的情况。SCA 运行时无法找到目标目的地，将创建一条失败事件消息，在这种情况下，该消息被放入 SCA 系统总线上的特殊目的地（步骤 1.1），并且还会记录发生失败事件的语句。失败事件目的地必须为运行调用 SCA 模块的服务或集群完成以下命名约定：
- WBI.FailedEvent.<Nodename>.<Servername>
- WBI.FailedEvent.<Clustername>
映射到可能运行 SCA 模块的所有集群和服务器的失败事件管理器从这些目的地拾取消息（步骤 1.2），并将失败事件数据存储到 Process Server 的通用数据库中（步骤 1.3）。此数据由以下信息组成：如调用模块和目标模块的名称、尝试进行异步 SCA 调用时包含的业务数据、某些错误信息等。
图 9：失败事件管理器的操作视图
管理人员必须监视失败事件管理器前端应用程序 (Failed Event Manager Frontend Application)，它是集成解决方案控制台的一部分。此应用程序将查询失败事件管理器，从 Process Server 通用数据库 (Process Server Common Database) 获取关于失败事件的信息（步骤 2.1-2.2）。管理人员现在能够通过安装应调用的 SCA 模块分析错误情况，并解决所描述的问题。
解决该问题之后，管理人员可以使用前端应用程序重新提交失败事件（步骤 3.1）。从失败事件数据提取原始消息，并将其放入 SCA 系统总线上的目标 SCA 目的地（步骤 3.2）。SCA 运行时使用此处的消息，继续执行常规处理（步骤 3.3）。
在许多情况下，分析失败事件有助于一目了然地发现导致“不可解释”行为的原因。一个示例是由于基础 SCA 通信错误业务流程可能挂起（保留运行状态）。显然，如果调用另一个 SCA 模块以创建失败事件而结束，且没有发送回响应，则流程将无法继续处理，因为除上述的情况外，失败事件还可能中断双向调用。
资源适配器
本章将简要概述适配器的操作方面。由于有许多不同的适配器，这里我们将重点介绍 WebSphere 适配器（基于 J2EE Connector Architecture（以下称为 J2CA））。J2CA 是按照以下两个契约集定义的（请参见图 9：J2CA 的各个部分（来源：http://www.ibm.com/developerworks/library/ws-soa-j2caadapter/index.html））：
- 服务提供者接口 (SPI) – 定义应用服务器与适配器的交互方式
- 通用客户端接口 (CCI) – 定义客户端查看适配器的方式。
图 10：J2CA 的各个部分（来源：http://www.ibm.com/developerworks/library/ws-soa-j2caadapter/index.html）
由于资源适配器用于连接到企业信息系统，因此它们在面向服务的体系结构中可以扮演重要角色。数据被存储在不同的位置，当访问这些数据时需要连接性。
当使用适配器时，必须记住只有 J2CA 和 WebSphere 适配器可以作为事务的一部分（并且只有某些适配器支持两阶段提交）。另外，由于 J2CA 和 WebSphere 适配器只能由 WebSphere 的高可用性管理器管理，因此需要重点关注可用性。
可以用不同的方式安装 WebSphere Adapters：
- 作为应用程序的一部分
- 作为资源适配器存档文件 (RAR) 单独安装
在应用程序中安装 WebSphere 适配器
如果在创建使用适配器的应用程序过程中不进行明确设置，将以缺省方式在应用程序中部署适配器 RAR 文件。用于出站适配器的资源（如 J2CconnectionFactories）通过应用程序管理页管理。重新部署应用程序将覆盖在此站点上所作的更改。另外，其他应用程序无法重用在应用程序级别定义的资源。在应用程序中部署 RAR 文件的一个优点是对类加载器的隔离。
安装 WebSphere Adapter RAR 文件“单机版”(6.1+)
安装独立于企业存档的 WebSphere 适配器将改变适配器的管理。可以独立于使用该适配器的应用程序来管理资源，并且在部署/更新应用程序的过程中不会覆盖它。
但一定要小心！独立适配器没对类加载器的隔离。在 Java 虚拟机中只有适配器 JAR 文件和第三方库的一个副本。
支持服务重要说明
Process Server 环境的管理人员和操作人员离不开对适配器、业务规则、选择器、关系、应用程序调度程序尤其是失败事件的管理。由于对所有这些组件的处理可能对部署的业务应用程序（甚至使用它们的其他远程应用程序）有重要影响，因此开发人员和操作人员之间的协作是至关重要的。
结束语
在本系列文章的第二部分（也是最后一部分）中，我们从操作角度了解了位于 Process Server 运行时层和功能层中的许多组件。另外，您还学习了 SCA 运行时如何构成运行业务应用程序的基础，以及在 Process Server 基础结构上成功运行 BPEL 流程的重要方面。
参考资料
作者简介  | | |
Sebastian Faulhaber 是在 IBM Software Group for WebSphere (ISSW) 工作的 IT 专家。在加入 ISSW 德国团队前，Sebastian 已经拥有了强大的 J2EE 开发背景，尤其擅长 WebSphere Application Server 的相关工作。加入 ISSW 之后，他的工作重点是 WebSphere Business Integration 和 WebSphere Extended Deployment，并成功参与了多个客户合作项目。 |
| | |
Konstantin Luttenberger 是一名 IT 专家，成为 ISSW (IBM Software Services for WebSphere) 德国团队的成员已有近两年时间。他参与了若干 WebSphere Process Server 项目，在其中的主要工作重点是基础结构和操作。Konstantin 为客户编写了若干技术文档，还编著了若干科学著作。 |
| | |
Anne Faulhaber 是 ISSW 德国的一名成员，自从 WebSphere Process Server 首次发布以来，到现在已有三年的工作经验。她从若干客户项目中获得了大量的 WebSphere Process Server 操作方面的经验。 |
对本文的评价
| 
