中国 [选择]

首页

产品

服务与解决方案

支持与下载

个性化服务

developerWorks 中国 > WebSphere >

白皮书：WAS 企业流程编排器: 概念和体系结构

文档选项

未显示需要 JavaScript 的文档选项

级别：初级

Matthias Kloppmann (Matthias-Kloppmann@de.ibm.com),
Gerhard Pfau (GPFAU@de.ibm.com),

2003 年 3 月 01 日

WebSphere Application Server 企业流程编排器（WAS Enterprise Process Choreographer）在 WebSphere Application Server 中支持业务流程。它可以用于编排各种业务流程或流。

前言

WebSphere Application Server 企业流程编排器（WAS Enterprise Process Choreographer）在 WebSphere Application Server 中支持业务流程。它可以用于编排各种业务流程或流。

在企业中实现的业务流程一般都要求人力资源和 IT 资源的结合。业务流程的类型可以多种多样，从 Web 服务导航到对业务事务的支持。业务流程可以是自动的、可恢复的流程，也可以是需要与人交互的流程。使用 WAS 企业流程编排器，您可以将业务流程技术和开放的 J2EE 体系结构提供的任何其他服务结合在一起。

本文使用一些案例展示了如何通过在当今的商业环境中使用 WAS 企业流程编排器受益。本文解释了 WAS 企业流程编排器使用的一些基本的业务流程概念，并描述了如何开发、使用和管理业务流程。最后，本文还概述了体系结构。

回页首

当今商业环境中的业务流程

今天的公司面临着一个日益严重的问题。业务逻辑和应用程序数据分散在整个组织的多种软件资产中。其中的许多数据都驻留在数据库、打包的应用程序（如企业资源规划（enterprise resource planning（ERP））系统）或后端系统（如 IBM CICS）中。其他的业务逻辑可以在现有的 Java 和 J2EE 应用程序中找到。

随着开放标准的出现，业务逻辑和应用程序数据不久就可以通过内部和外部可用的 Web 服务获得。公司需要一种方法使他们能够在开发新的基于 J2EE 的应用程序的过程中重用他们现有的软件资产，并且能够利用 Web 服务的力量，而不必在构建每个新应用程序时都另起炉灶。

WebSphere Application Server 企业版附带的集成 J2EE 工作流功能为应用程序开发提供了一种新的、面向服务的方法，名为 服务编排（Service Choreography）。使用直观的基于业务流程的开发工具，您可以利用现有的软件资产并迅速地定义如何在一个新的 J2EE 应用程序中使用这些资产。例如，您可能想把来自于已打包的 CRM 解决方案的客户信息和来自于现有的面向客户应用程序的 J2EE 组件与新的业务逻辑结合在一起创建一个新的、基于 Web 的订单输入应用程序。然后，通过将该应用程序作为一个 Web 服务向您的业务伙伴公开，您可以扩展它的可用性。

使用 WebSphere Application Server 企业版，开发者可以用可视的方式编排各种软件资产之间的交互。开发者的工作效率还可以更高，因为他们有一种标准方法用来有效表示任意软件资产、并与之有效交互，因此就不必花时间处理不同的接口和低级 API。拖放（Drag-and-drop）工具使他们能够定义软件资产之间信息的顺序和流。各个软件资产，甚至较大的应用程序工作流都变成了可以在开发其他应用程序的过程中重用的构件。生产率还有可能得到进一步的提高，因为对这些新 J2EE 工作流功能的运行时支持完全集成在应用程序服务器中，从而提供了一个单独的管理和部署环境。

下面几部分将向您展示如何使用业务流程创建各种类型的应用程序。

Web 服务的整合－基于业务流程的应用程序

传统上，应用程序包含实现各种业务功能（如“创建订单条目”）的代码以及符合业务要求（如“高价值的订单消息必须被单独批准”）的应用程序的流逻辑代码。只要业务要求发生了变化，代码就必须更改。这些更改通常是针对业务流逻辑的，并且极少影响各个业务功能的实现。

业务流程的使用改变了应用程序的构建方式。流程引擎允许这样一种应用程序体系结构：它把业务逻辑（流逻辑）的描述与业务功能的实现分开。产生的应用程序结构被称为 基于业务流程的应用程序。控制流由工作流管理系统管理，它负责根据业务逻辑调用各种业务功能。

基于业务流程的应用程序的结构

编写一个基于业务流程的应用程序需要完成两个独立的步骤：

编写组件－各种业务功能被“照常”实现，即为它们编写代码、购买它们或它们已经存在。业务功能的实际表示可以是，例如：
- 一个 EJB 方法
- 一次 JCA 连接器调用，它实现到后端系统（如 CICS）的连接
- （WSDL）端口类型的一个操作，例如，一个基于 SOAP 的 Web 服务
编写业务流程－业务逻辑被描述成一个流程，该流程由流程中需要执行的步骤、这些步骤彼此之间的关系以及它们的排序约束组成。

业务功能被分配给流程中的每个步骤。一个流程步骤可以是基本步骤，也可以是复合步骤，这就形成了递归的编程模型。

基于业务流程的应用程序优于传统的应用程序，因为它们拥有许多由负责它们的执行的中间件所保证的特性。这些特性包括：

并发性。如果一个进程包含若干并行的分支，那么中间件可以保证这些分支在并行的线程中（甚至可能在一个群集的不同节点上）并发地执行。
可恢复性。如果系统在执行一个基于进程的应用程序时崩溃，那么该应用程序的执行就从它以前停止的地方继续－已执行的步骤就不再重做了。
异构的、分布式的执行。一个业务流程的各种功能的执行（它的步骤）可以分布在一个网络中、分布在异构的操作系统和硬件平台上。
服务的质量范围。流程引擎支持不可中断的流程（微流）、可中断的流程（宏流）以及二者的结合。

涉及的人群

许多企业正在寻求使其业务流程自动化的方法。无需与人交互的全自动流程的执行成本低，吞吐量高并且响应时间比较短。

然而，许多现实的流程并不能实现完全自动化。例如，特殊的批准可能必须由被授权的管理人员批示，而不是由机器自动批示。因此，业务流程通常是由自动化的步骤和与人交互的步骤结合在一起组成的。

下图显示了一个需要与人交互的流程的示例。当一条消息到达该流程的输入队列时，该流程被触发。这种类型的流程也被称为 消息处理流或 消息流。一般来说，处理这种消息时需要把实现业务流程的步骤和产生一条适当的结果消息的步骤结合起来。然而，当其中任何一个步骤的执行过程中发生异常时，业务流程都需要与人交互来处理异常。

需要与人交互来处理异常的消息处理流

只要自动化步骤简短并且不产生异常，那么处理这种类型的流程时吞吐量就会比较高，并且响应时间比较短。虽然与人交互是流程定义的一部分，但如果没有实际执行这些步骤，那么就不会影响流程的执行。业务流程范例轻松地将整个业务流程的描述（包括手工步骤）作为一个单独的流程来支持。流程引擎负责自动流程的高效执行，并负责包含与人的交互来处理异常。

用补偿撤销复杂的操作

如今的应用程序一般都要求事务属性，特别是要求保证复杂的请求要么全部执行要么根本不执行。对于传统的事务来说，这是用 ACID 属性原子性、一致性、隔离以及持久性描述的。这是通过事务管理器、资源管理器以及后端系统按照 XA 标准或类似的协议进行合作实现的。这种协作可以确保代表事务执行的操作要么被全部提交要么被全部回滚。

然而由于许多原因，复杂的请求经常不能被作为一个 ACID 事务来运行：

后端系统或资源管理器可能无法参与 XA 协议。对这些系统的更新被立即执行并且不参与整个事务。如果事务失败，这些更新不会被撤销；复杂请求的处理会产生不一致的状态。
只要事务尚未被提交，那么对它进行的任何更改对于外界来说都是不可见的。隔离属性保证了只有达到事务的最终状态时，这些更改才是可见的。这非常适用于短期运行流程（它们调用同步操作）。
不过，当一个流程包含异步步骤（例如，由 JMS 消息驱动的后端系统实现的步骤或涉及到与人的交互的步骤）时，必须使流程的中间结果可见。这就意味着 JMS 消息必须被发送出去、有关人们必须执行的步骤（工作项）的信息必须是可用的等等。因此，流程的中间状态必须被提交。
业务流程中有本质上就是非事务性的操作。向客户发送一封信就是一个这样的操作－只要信已离开发送方，就无法撤销该操作了。
可中断的流程中的活动可以是事务性的，也可以是非事务性的。事务活动在自己的事务中运行，但一个可中断的流程中并没有一个包含流程中所有活动的事务。因此，没有任何锁来确保整个流程的数据完整性。如果流程失败了，那么可以用补偿来撤销活动已成功进行的更改。

在所有这些示例中，业务流程的中间结果都是可用的，并且不能仅通过借助事务管理器回滚一个 ACID 事务就撤销它们。相反，必须执行显式恢复原操作的另一个操作：

如果已经调用了一个后端系统来更新数据（例如，增大一个值），就必须再次调用系统（例如，减小该值）。
如果已经将一封信错误地发送给了一个客户，就必须发送另一封信为该错误道歉。

如果其他操作已经开始使用那些错误提供的结果，那么可能需要一层一层地撤消这些操作。

为了帮助您定义撤销操作及其自动执行，您可以将一个流程的步骤指定为 补偿对（compensation pairs）。这意味着除标准的“向前”操作之外，还要给活动分配一个“向后”操作，如下图所示。

使用补偿对向前处理流程

流程使用向前操作运行。另外，每次调用一个向前操作都要在一个补偿列表中记录它的输入和输出数据。在流程执行期间的任何时候，您都知道已经用哪些数据调用了哪些操作。

如果流程在其执行过程中发生了故障并且必须被补偿，那么将使用补偿列表驱动流程的向后执行以便重新建立前一个流程状态。对于那些在流程的向前执行过程中已成功执行的操作，将调用与它们相关联的撤销操作并传送原来的数据。例如，撤销操作可能发送一封补偿信告诉客户上一封信发错了，应该被忽略。

下图显示如何对流程的向前执行过程中执行的活动执行撤销操作。对于那些未定义撤销操作的活动以及在流程的向前执行过程中未被处理的活动，什么都不做。

使用补偿对向后处理流程

企业到企业（business-to-business（B2B））流程

业务流程一般不限于企业中的应用程序和人，它们还涉及到业务伙伴。与这些伙伴的交互可以被轻松地建模为流程的一部分。

与伙伴的交互有两种类型：

入站（inbound）请求。一个由伙伴发送的请求，请求启动一个业务流程，或者请求将数据作为“对话”的一部分传送给一个正在运行的业务流程。
出站（outbound）请求。一个发送给伙伴的请求，请求启动伙伴处的一个业务流程，或者请求将数据作为“对话”的一部分发送。出站请求的一种特殊情况是业务流程完成并将其结果传递给伙伴。

对于这两种类型的请求来说，与伙伴的交互都要使用 WebSphere 组件－ Web 服务网关（Web Services Gateway）。该网关负责将入站 Web 服务请求路由到适当的 WebSphere 组件（例如流程引擎）以及将出站 Web 服务请求路由到正确的伙伴。

一个通过 Web 服务网关与伙伴进行交互的 B2B 案例中的业务流程

回页首

业务流程概念

这一部分解释了 WAS 企业流程编排器所使用的一些基本的业务流程概念。

业务流程

元模型（meta model）的顶层构造是流程本身。流程是一个多步骤的操作。流程的图形表示是一张有向图。这张流程图中的主要构造是活动和控制连接器。这些活动描述了要执行的任务，控制连接器则描述了执行这些活动时可能采用的顺序。下图显示了这样一张流程图的示例。

业务流程的图形表示

活动用已命名的矩形表示；名称一般描述活动的用途。活动拥有的实现可以包含与人的交互、执行同步或异步调用或者等待传入的事件。提供同步活动实现的服务的示例是基于 SOAP 的 Web 服务、CICS 事务以及 EJB 方法调用。异步调用的一个示例是通过 JMS 发送和接收一条消息。

控制连接器用箭头表示；箭头的头描述控制流在流程中的流动方向。控制连接器开始处的活动被称作源活动；控制连接器终止处的活动被称为目标活动。

业务流程有两种类型：不可中断的流程（微流）和可中断的流程（宏流）。这两种类型之间的主要差别在于它们的事务行为和资源占用量的大小。

活动

有不同类型的活动来执行不同类型的任务。WAS 企业流程编排器支持下列类型的活动：

基本活动
个人活动
接收事件活动
流程活动
空活动

基本活动被用于调用操作或服务。有两种被支持的样式。

调用同步操作（如 EJB 方法、Java 片段、J2EE 连接器或 SOAP 服务）的基本活动。这包括对调用"射后不理（fire and forget）"的基本活动。这种活动的示例是发送一条 JMX 消息而不等待响应，或者是发送一封电子邮件。
调用异步服务（如带有一个 JMS 消息绑定的服务）的基本活动，它稍后要接收响应。

个人活动用于在流程中包含与人的交互。当一个流程进行到一个个人活动时，就为一个人或一组人创建一个工作项。按照流程需求的定义和中心目录中的定义找到适合做此项工作的人被称为 人员分析（staff resolution）。一个人可以检查是否已经为他创建了一个工作项。如果已经为他创建了，那么他可以通过声明该工作项来接受这项工作。当他完成该工作项后，他把产生的数据提供给工作流系统使用。完成这些之后，流程继续进行。

接收事件活动允许流程等待外部事件。例如，与另一个程序（可能是一个伙伴流程）握手、发出消息、进行一些操作，最后等待外部触发器的触发来继续其操作的流程。通过使用 WAS 企业流程编排器 API，事件被发送给流程。

流程活动用于对流程进行嵌套。一个流程可以调用本身就调用其他流程的流程，依此类推。这种构造使您能够创建分层流程。这种构造通过将流程分解为子流程还使您能够重用流程逻辑。

空活动不执行操作。相反，它们充当流程中并行分支的显式同步点，或者允许显式连结或分支节点。

流程中的活动对数据进行操作；输入数据被传送给一个流程，该流程返回输出或出错数据。在流程内，数据保存在全局变量中。由 Java 片段实现的映射活动可用于转换数据。这些映射活动从一个或多个变量获取输入。结果被写入另一组变量中。为调用一个要求输入消息的活动，各变量被读取。如果该活动产生输出或故障数据，那么这些数据将被映射回同一个变量或另一个变量。

不可中断的流程（微流）

不可中断的流程具有以下特征：

它们的运行时间短。
它们运行在一个事务中或者不在事务中运行。
如果一个流程运行在一个事务中且仅包含事务活动，它就被称为一个 原子球（atomic sphere）[1]。
它们可以包含有事务实现和非事务实现的活动。
它们不能拥有异步活动实现或涉及与人的交互的活动实现。
异步请求-响应操作要求提交事务以发送请求。然后在一个新事务中处理请求结果。异步通知不期望得到响应。因此，不可中断的流程中支持发送通知。接收事件活动要求有自己的接收事件的事务，因此在不可中断的流程中不被支持。
不可中断的流程中的所有活动都是在一个单独的线程中处理的。因此，所有活动共享同一个线程上下文。

下图显示了一个不可中断的流程及其事务边界。

不可中断的流程及其事务边界

WAS 企业流程编排器版本 5.0 仅支持不可中断的事务流程。当一个事务回滚发生时，事务管理器回滚一个不可中断的流程的所有事务活动。其实现不是事务性的活动保持原样。

不可中断的流程向开发者提供可视化的建模、易于维护以及图形化的调试等优点。只要开发者想开始编写 Java 代码来定义企业 bean 的交互、Java 类、J2C 连接器交互、Web 服务等，就可以使用它们。

可中断的流程（宏流）

可中断的流程是现有的工作流系统（如 WebSphere MQ Workflow）中的知名流程类型。例如，可中断的流程可以转到这样一个活动，这个活动需要与人交互或需要来自远程服务的响应，并且数小时、数天、甚至数年地等待，直到期望的事件发生。

可中断的流程由一组 分层事务（stratified transaction）[3] 组成。这意味在一个包含一组活动的流程中，每一步都是在自己的事务中执行。例如，当一个执行同步服务调用的活动被处理时，将发生下列活动：

事务开始
从持久的流程-引擎消息队列中获取携带连接器的布尔值的消息
如果所有传入的连接器都已触发，就检查开始条件：

如果为 true，则启动活动，也就是调用同步服务
如果为 false，则跳过该活动

为每个出站控制连接器将一条消息放入持久的流程引擎消息队列中
将状态更改写入数据库
提交事务

如果一个活动是非事务性的（即它的活动实现不参与事务的 2PC 协议），那么发生故障时，可使用基于补偿的恢复来撤销该活动执行的更改。

下图显示了一个简单的可中断流程中的各事务边界。

一个简单的可中断流程中的事务边界

可中断的流程支持所有的活动类型。事务中执行的活动取决于各种活动类型各自的语义。为了阐明这一点，下图显示了一个几乎使用了所有类型的活动的复杂流程。

一个复杂的可中断流程中的事务边界

为了可靠地保存一个流程的导航信息，数据库要存储该流程的持久状态，同时消息传递系统要保存持久的导航状态（即有关流中哪些活动将进入下一个状态的信息）。一个活动实现所使用的数据库、消息传递系统以及事务资源都参与一个两阶段提交（two-phase-commit）协议。因为一个正在运行的流程的完整状态存储在数据库中，所以流程不依赖于特定的应用程序服务器。可中断的流程的资源占用量比不可中断的流程的资源占用量要多得多，因为它们使用持久的存储和事务。

当一个可中断的流程在一个群集中运行时，每个流程步骤都可以在任何节点上并行执行。负载自动分布在不同的服务器上。

可中断的流程是完全可向前恢复的。如果正在处理一个可中断流程的应用程序服务器意外终止，任何信息都不会丢失。该流程要么在群集中的另一节点上继续，要么在非群集化的应用程序上等待，一直等到该服务器再次启动。因此，可中断的流程可以被说成是有 涅磐行为（phoenix behavior）[1]。

流程的生命周期

当一个可以启动流程的 WAS 企业流程编排器 API 方法被调用时，一个流程的生命开始。所支持的 API 方法是 call和 initiate：

调用 initiate时，当流程结束时不向调用者返回响应。然而，通过使用个人、同步或接收事件活动，交互可以发生在流程与流程启动者、其他人或其他服务之间。
调用 call时，当流程结束时，流程启动者接收到一个响应。响应机制可以和从一个同步的不可中断流程返回结果一样简单。作为一种替代方法，也可以在流程被调用时提供应答上下文（reply context）。当流程最后返送了响应时，流程引擎使用该上下文。

当流程被启动时，一个现有流程模型的流程实例被创建并被启动。然后流程引擎开始为该业务流程导航。即，流程引擎确定要激活业务流程的哪些活动以及激活的顺序。一个流程的常规导航继续进行，直到该流程的所有活动都处于终态为止。有效的终态是 finished、 failed、 expired或 terminated。

当流程进行到它的一个故障终点，或者对流程接收器（sink）的所有传入的控制连接器都求值之后流程就会结束。如果流程是用 call启动的，那么将向流程的调用者返回一个响应。

请参阅对业务流程引擎的导航器的描述，以获取关于活动实例的状态过渡的更多信息。

回页首

开发、使用和管理业务流程

开发、使用和管理业务流程需要好几种不同的工具：

WebSphere Studio Application Developer －集成版（WSAD-IE）使您能够创建、部署、安装、测试和调试流程应用程序。WSAD-IE 将一个用于 Java 类、servlet、JSP、EJB 以及静态 HTML 页面的基本开发环境与创建 Java 连接器和 Web 服务的强大企业功能集成在一起。
WSAD-IE 通过 WAS 企业流程编排器的流程编排动态构件。
WAS 企业流程编排器提供了一个现成可用的 Web 客户机，该客户机使工作流参与者能够访问工作流应用程序及其业务流程。
WebSphere Application Server 提供了一个管理控制台来管理业务流程。

用 WSAD-IE 开发流程

在典型的流程开发案例中，业务分析家和领域专家在抽象级别上定义了业务流程。这包括定义流程、流程的活动及一些条件（这些条件确定按哪条路径执行流程以及何时执行）。

然后，开发流程的实现。这包括指定哪些服务实现哪些活动。这些服务可以通过 Java 连接器访问后端系统（如 CICS 或 IMS）中的功能，或者使用 Web 服务访问 ERP 系统中的服务。还必须创建涉及到与人的交互的活动。必须定义 GUI 页面和查询为将使用应用程序的人员提供最好的支持。

您可以在不离开 WSAD-IE 环境的情况下完成所有这些任务。当应用程序准备测试时，您可以在 WSAD-IE 的单元测试环境中部署并安装它。调试和跟踪功能提供了一种非常高效的方法来获取一个准备好用于生产的流程应用程序。

当在 WSAD-IE 中对流程应用程序进行了充分的测试后，您可以将它部署在生产系统中。除了要额外安装流程压缩文档（process archive（FAR））外，带流程的企业应用程序的安装和任何 J2EE 应用程序的安装都一样。下图显示了如何在 WSAD-IE 中创建企业应用程序以及如何在一个 WebSphere 生产环境中安装它。

WSAD-IE 中的流程开发

使用流程、工作项及工作列表

WAS 企业流程编排器 Web 客户机是基于 servlet 和 JSP 的。您可以按现状使用 Web 客户机，而不必实现任何代码。这使您能够开发和展示以用户为中心的工作流应用程序，而不必对用户界面设计提前进行任何投资。

然而，工作流用户界面经常需要定制以符合特定的业务流程情景，或者符合现有 Web 站点内公司的外观和感觉。WAS 企业流程编排器提供了一篇教程和一些编码样本来帮助您在保存标准工作流最终用户交互时更改 Web 客户机的外观。

工作项（也被称为分配）是将“工作的各部分”分配给人们的方式。只有为用户或他所在的小组创建了一个工作项，他才可以使用 Web 客户机与 WAS 企业流程编排器应用程序进行交互。
为决定是否有工作项在等待，用户要执行一个查询（如 工作项查询）。查询结果就是与查询条件相匹配的工作项。WAS 企业流程编排器既支持特别查询，又支持预定义的查询。预定义的查询被作为工作列表存储。

工作项

工作项代表一个人或一组人与一个对象之间的关系，通常是一个特定的活动实例。指定对象类型的属性以及将该对象分配给用户的原因进一步描述了这种关系。

工作项是在下列情况发生时由流程引擎创建的：

一个流程被启动
然后下列工作项被创建：
- 供流程启动者处理的工作项
- 供每个流程读者处理的工作项
- 供每个流程管理员处理的工作项
流程启动者就是启动流程的人。流程读者就是拥有读流程及其所有活动的值的权限的人。例如，这包括：如果出现了某些错误条件，就强迫一个流程进入结束状态。
个人活动做好准备。
然后下列工作项被创建：
- 供活动的每个可能的所有者处理的工作项
- 供活动的每个读者处理的工作项
- 供活动的每个编辑者处理的工作项
活动的可能的所有者就是可以执行活动所要求的任务的人。活动的读者就是拥有读活动的值这种权限的人。活动的编辑者就是拥有操作一个活动的输出这种权限的人。
个人活动被声明。
这发生在活动可能的所有者之一声明将对其进行操作的活动时。然后为活动所有者创建一个工作项。
一个个人活动的声明被取消。
这发生在活动所有者决定异常中止以前声明的一个活动的执行时。然后，声明活动时所创建的工作项被删除。
一个接收事件被激活。
然后下列工作项被创建：
- 供活动的每个可能的所有者处理的工作项。可能的所有者被允许发送等候的事件。
一个未经处理的故障在流程的一个活动中发生。
然后，下列工作项被创建：
- 供流程的管理员处理的工作项，它允许手工强制重启或强制完成活动。

当流程结束时，缺省行为就是该流程被删除。为流程创建的工作项也都被删除。

工作列表

工作列表是持久存储在数据库中的查询。工作列表可被流程应用程序的客户机用来根据预定义的标准过滤工作项。例如，工作列表可以查询某个流程的所有购买请求活动以发现那些要求得到确认的活动。随后，一个流程-应用程序客户机可以使用这张工作列表向角色为“购买请求批准者”的用户展示工作项的结果列表。

这些查询是使用类似于 SQL 的语法定义的。您可以在查询中包含构造来限制查询结果、对结果进行分类、限制返回对象的数目并指定时区中的差异。只有 WAS 企业流程编排器管理员才可以创建工作列表。

WAS 企业流程编排器 API 提供了处理工作列表的功能。工作项管理器负责处理工作列表。工作项管理器使您能够进行以下操作：

定义一张工作列表并将其添加到工作列表管理器管理的工作列表集合
从工作项管理器中删除一张工作列表
通过执行各个查询求出工作列表

管理业务流程

业务流程管理包括对以下几个方面的管理：

业务流程容器
流程模块
流程模板

本文不讨论其他的管理任务。

业务流程容器

业务流程容器是为每个安装了 WAS 企业流程编排器的 WebSphere 应用程序服务器配置的。业务流程容器的配置发生在创建新的应用程序服务器时。在配置期间，创建了业务流程容器、它的数据库以及它所要求的不同消息队列之间的关联。完成了最初的配置步骤之后，管理员就可以使用 WebSphere 管理控制台更改业务流程容器的以下设置：

无法处理的流程消息的重试次数
维持队列（retention queue）中消息的最大数目

如果业务流程容器检测到一个暂时的错误情况（如数据库死锁或连接失败），就把消息存储在维持队列中。一旦错误情况被解决，该消息就从维持队列被送回正常的处理中。

业务流程容器包含流程模块。

流程模块

流程模块包含一组流程模板。当把一个企业应用程序安装到应用程序服务器上时，就会在企业应用程序资源库（enterprise application repository（EAR））中为每个流程压缩文档（FAR）创建一个流程模块。随后该流程模块就被添加到应用程序服务器的业务流程容器中。

流程模板

流程模板是一个部署好的流程模型。流程模板支持下列管理任务：

启动
停止
获取状态

各个流程模板可以被单独启动和停止。如果一个流程模板被停止了，那么就不能再创建相应流程的新流程实例。这意味着管理员可以禁用一个工作流应用程序的某些功能，例如，出于维护原因。每个流程模板都有一个状态，要么是 started，要么是 stopped。

回页首

体系结构

这一部分将概述业务流程引擎的内部结构。这一部分将带领大家看一下各种编程接口，客户机程序可以用这些编程接口来访问业务流程服务。另外，这部分还将更深入地讨论每个组件，描述每个组件的功能以及它在整个系统中的角色。

编程接口

WAS 企业流程编排器既提供了一般的编程接口，又提供了特定于流程的编程接口。请参阅 WAS 信息中心以获取关于这些编程接口的更多信息，包括对根据流程引擎编程的介绍、代码示例以及所有外部接口的完整 JavaDoc。

一般的编程接口

下列流程引擎功能可用作一般的编程接口：

启动流程
可以通过指定流程模板的名称以及供新实例使用的输入数据来启动一个新的流程实例。另外，您还可以将这个流程实例与一个用户定义的标识关联在一起。稍后，可以用这个标识作为一个辅键来检索这个流程实例。当流程实例完成时，您还可以指定一个由流程引擎调用的回调。
向正在运行的流程发送异步事件
对于包含接收事件活动的流程实例，可以使用编程接口来发送相关联的事件。必须传递的参数包括系统生成的或用户定义的目标流程实例标识、事件名称以及事件数据。
分配给个人的查询工作
该功能可用于检索工作项，方法是使用类似于 SQL 的查询或预定义的工作列表。
处理分配给个人的活动
这包括一些编程接口，这些接口声明活动（人们就是据此活动接收工作项）并完成所声明的活动。
执行管理任务
编程接口可用于查找关于正在运行的流程实例的信息、终止一个正在运行的实例，还可以用于修复已经失败的活动。

这些一般的编程接口可以通过下面两种形式获得：

一组完整的函数作为业务流程容器提供的无状态会话 EJB 的方法。
这是首选的从客户机程序（比如提供的 Web 客户机）与流程引擎进行交互的方法。
用于启动新的流程实例并将事件发送给正在运行的流程实例的功能可以通过消息驱动的 bean（message-driven bean（MDB））获得。这个 MDB 接受通过消息的主体传送输入或事件数据的 JMS 消息及其 JMS 属性中的附加信息（如流程模板名称或事件名称）。
流程引擎接受并认可标准的 JMS 属性（如应答队列的规范）。流程实例一旦完成，就将发送对启动流程消息的应答。

特定于流程的编程接口（façade）

对于每个流程模型，您都可以使用 WSAD-IE 工具来生成一个相关联的 EJB（ façade EJB）和一个相关联的 MDB（ façade MDB），它们提供用于启动流程实例并将事件发送给正在运行的实例的强类型接口。这些 façade 简化了与某个特定的流程模型进行的交互的编码工作。

WebSphere 中的业务流程组件

下图显示了 WebSphere 流程引擎的内部体系结构，又被称为 业务流程容器。

业务流程容器及其组件

导航器（Navigator）

导航器组件是流程引擎的核心。它管理所有流程实例的状态过渡以及这些流程实例中所有活动的状态过渡。各个流程实例和活动实例的状态表如下面的各图所示。

流程实例的状态过渡

一个流程实例的正常寿命从一个启动请求开始。开始时先创建流程实例，并使其进入 running状态中。当该流程实例包含的所有活动都达到结束状态时，该流程实例被标记为 finished。该流程实例隐式停止并退出，或者通过一次显式的 API 调用来停止并退出。

在异常情况下，流程实例也许会碰到一个没有被作为流程逻辑的一部分处理的故障。在这种情况下，在使流程进入 failed状态之前，它等待活动着的活动完成。如果已经为流程定义了补偿，那么就随后调用补偿。

流程实例也可以由流程管理员终止。在这种情况下，完成活动着的活动后，流程实例就进入它的 terminated状态。

活动实例的状态过渡

创建了一个封闭的流程实例后，流程的各个活动的生命从 inactive状态开始。

随着流程实例的开始，所有离开其输入节点的控制连接器都被激活。我们可以通过求与它们相关联的过渡条件的值来确定它们的布尔值，这样就会为每个控制连接器产生一个为 true 或 false 的值。然后，向那些作为这些控制连接器的目标的所有活动方向正常继续。

只要通过控制连接器到达了一个活动，导航器就会检查该活动是否拥有不止一个传入的控制连接器。只有对通向该活动的所有控制连接器都求值后，导航器才尝试激活这个活动。否则，活动的激活将被延期到对所有的连接器都进行求值后，并且该活动仍将处于非活动（inactive）状态。

当对所有的控制连接器都求值后，开始检查活动的启动条件－在 WAS 企业流程编排器中，这个启动条件始终是“至少有一个传入的控制连接器必须为 true”，不能更改。根据对启动条件的求值，将发生下列情况之一：

活动的启动条件值为 false。活动被标记为 skipped。这意味着该活动不被执行，流程将继续进行下去。在不对过渡条件求值的情况下，离开该活动的各个控制连接器的布尔值均被设置为 false。这种处理被称作 死路删除（dead-path elimination）。
活动的启动条件值为 true，并且该活动是一个个人活动。在这种情况下，工作项被创建，活动进入 ready状态。在这种状态下，用户可以声明一个活动，当用户对其进行操作时，这种声明将使该活动进入 claimed状态。
活动的启动条件值为 true，并且它是一个由服务实现的元素活动。在这种情况下，活动进入调用期的 running状态。
活动的启动条件值为 true，并且它是一个接收事件活动。在这种情况下，活动进入 waiting状态（图中没有显示），直到接收到一个事件为止。

当分配给个人活动的个人或基本活动的实现完成活动并产生一个结果时，该活动进入 finished状态。当一个接收事件活动接收到一个等候的事件时，也会进入 finished状态。流程的控制逻辑继续对从该活动开始的控制连接器的过渡条件求值。

最后，在删除流程时，这个活动作为其中的一部分也被删除。

有许多用于活动的异常处理的附加状态：

当流程中未处理的活动抛出故障时，该活动就进入 failed状态，并为该活动设置 continue-on-error 标志。
当流程中未处理的活动抛出故障时，该活动就进入 stopped状态，不为该活动设置 continue-on-error 标志。这就有效地产生了缺省的“stop-on-error”语义。
在 stopped 状态下，活动可以被重试，也可以被完成。这就产生了到 ready、running、finished 或 failed 状态的过渡，过渡到哪种状态取决于请求和活动的类型。
当封闭的流程实例被终止时，如果一个活动是活动的，那么就进入 terminated状态。
最后，如果活动超时，就进入 expired状态。

插件

导航器将它必须执行的一些任务委托给各个插件。这些插件将导航器与它需要使用的组件分开，使 IBM 将来能够轻松地扩展流程引擎的功能。

这些插件是为以下操作提供的：

调用活动实现。流程引擎有两个用于此目的的插件，一个插件用于通过 Web 服务调用框架（Web Services Invocation Framework（WSIF））调用（外部）服务，另一个插件用于调用 Java 片段。
在流程中 处理数据，如求条件的值。流程引擎有一个插件可以根据 WSDL 消息理解用 Java 编写的条件。
在 审计跟踪中记录“有趣”事件。流程引擎有一个插件可以把数据写入到流程引擎的数据库的审计跟踪表中。
根据外部目录 分析员工查询。流程引擎有许多使其能够与外部目录一起工作的插件，如 WAS 用户注册中心或 LDAP 目录。

工作项管理（Work Item Management（WIM））

WIM 组件负责：

在流程引擎的数据库中创建和删除工作项。
根据该数据库分析来自流程参与者的工作项查询。
根据流程引擎中使用的人员目录来分析 员工查询。为了支持不同类型的目录，与目录的交互是通过人员分析插件进行的。
基于实例的授权是以为用户创建的工作项为基础。只有当用户接收到适当的工作项来做时，他们才被授权对一个活动或流程执行操作。例如，只有当流程参与者拥有一个活动的“可能的所有者”工作项时，他们才可以声明该活动。

工厂（Factory）

工厂组件负责管理流程引擎处理的“物理”状态信息。

它使得数据能够以下列形式之一被存储：