本系列围绕BPEL的一些高级话题展开讨论，侧重于探究SOA最新规范WS-BPEL4People 及其在WebSphere Process Server 中的实现。由IBM、Adobe、SAP、Oracle、BEA systems 和 Active Endpoints 所组成的业界著名的流程供应厂商，于 2007年6月25号发布了有关新提议的 WS-* 规范的最终草案——一份名为“WS-BPEL4People”的规范。相比于处理业务过程自动化的 WS-BPEL，WS-BPEL4People 规范，更侧重于为 SOA 增加一般的人员工作流能力，尤其是对最近被批准的 WS-BPEL 2.0规范而言。 Web 服务业务流程执行语言 WS-BPEL 当前并未涵盖人工用户交互；WS-BPEL 主要设计用于支持基于 Web 服务的自动化业务流程。不过，在实际中，很多业务流程场景都需要进行用户交互。由 IBM 和 SAP AG 联合发布的白皮书说明了业务流程中涉及用户的各个场景，然后定义了用于处理这些场景的相应 WS-BPEL 扩展。 IBM WebSphere Process Server 中引入的人工任务可为基于人工的 Web 服务提供基础设施。这些任务以典型的人工工作流系统提供的功能为基础，其功能经过了扩展，包含了成熟的升级和通知功能，以及为人工任务指定丰富的用户界面的功能。 本文从原理与业务场景的角度重点探究了这一 SOA 最新的规范 WS-BPEL4People，并基于规范分析了其在 IBM WebSphere Process Server 中的实现情况，最后提出了几种常见的 WebSphere Process Server 中基于人工任务的业务流程模式。

　　WS-BPEL4People 规范概述

　　业务流程的完全自动化虽然非常不错，但在实际中却是不可能实现的，因为有些活动要求相关人员做出判断，或要借助人员的专业知识（例如手动处理异常情况或审批请求等），这些活动将始终由人进行。在整个业务流程中，和任何其他任务一样，人工任务是一项服务，不过是通过人员活动（而不是程序）实现的，由相关人员（而不是计算机）执行。因此，在 SOA 编程模型中，人员活动可以作为 Web 服务实现。该服务被调用时，将通知承担任务的个人进行相关工作，并将输入数据以恰当的形式传递给此人。任务完成后，将产生相应的结果，服务会返回到其调用方，并将此结果作为输出数据传递给调用方。该结果实际由相关人员得出这一事实可能对调用方完全透明。该场景采用异步调用来支持运行时间长的服务，远程过程调用（remote procedure call，RPC）样式的同步调用并不适合处理人工任务（或任何其他运行时间长的服务）。将人工任务作为 Web 服务呈现还具有另一个优势，可以将人工实现替换为自动化步骤或自动与人工步骤的组合，而不必对业务流程剩下的部分进行重新编码。将由人实现的活动建模为 Web 服务是一个合理的设计选择，因为其他替代方法有很多明显的效率低下之处。例如，在业务流程编排中执行几个步骤后在需要借助人员的专业知识时直接停止，然后稍后再次重新启动流程编排，而两个断开的编排序列之间不存在任何逻辑连接。

　　为了说明这一点，以一个保险索赔处理流程为例。必须在流程中的某个位置审批索赔请求，才能向索赔人支付赔偿。其基本形式是这样，工作人员接收索赔信息，并确定是批准该索赔，还是拒绝或提交给理算人。在不改变总体业务流程流的前提下，可以使用服务替代该步骤，在此服务中，使用业务规则自动化例行的审批工作，而同时将较为困难的情况提交给相关人员决定。相关的专家现在不再受例行的烦琐事务困扰，可以将其特定的技能用于处理复杂案例上。这个变化同时改进了业务流程的结果和工作人员的工作满意度。

　　但将人工任务透明封装为 Web 服务并非总是适当的选择。考虑一下更为复杂的流程的情况，即需要两个人审批一个请求的情况（称为四眼原则或职责划分）。此类任务需要显式地表示为人工任务，而不是透明的 Web 服务，因为用于选择第二个审批人的规则必须将第一个审批人排除掉。

　　人工任务概念已经得到了行业认可，其标准化工作正在进行之中。由 IBM、Adobe、SAP、Oracle、BEA systems 和 Active Endpoints 所组成的业界著名的流程供应厂商，于 2007 年 6 月 25 号发布了有关新提议的 WS-* 规范的最终草案——一份名为“WS-BPEL4People”的规范。相比于处理业务过程自动化的 WS-BPEL，WS-BPEL4People 规范，更侧重于为 SOA 增加一般的人员工作流能力，尤其是对最近被批准的 WS-BPEL 2.0 规范而言。

　　Web 服务业务流程执行语言 WS-BPEL 当前并未涵盖人工用户交互；WS-BPEL 主要设计用于支持基于 Web 服务的自动化业务流程。不过，在实际中，很多业务流程场景都需要进行用户交互。由 IBM 和 SAP AG 联合发布的白皮书（ 下载 BPEL4People 白皮书 ）说明了业务流程中涉及用户的各个场景，然后定义了用于处理这些场景的相应 WS-BPEL 扩展。IBM 和 SAP 共同发表的白皮书中提出了人工任务标准化的未来方向。该白皮书中描述了即将推出的 WS-BPEL 标准的一个扩展，该扩展将人工任务包含在内，以让相关人员参与到业务流程中。针对 Business Process Execution Language for Web services 的 BPEL4People 扩展提供了通过嵌入人工任务扩展业务流程所需的扩展功能。它可处理将手动任务呈现为不透明的独立 Web 服务的场景（可从 BPEL 流程或采用 Java™编写的程序等调用该服务）。

　　IBM WebSphere Process Server 中引入的人工任务可为基于人工的 Web 服务提供基础设施。这些任务以典型的人工工作流系统提供的功能为基础，其功能经过了扩展，包含了成熟的升级和通知功能，以及为人工任务指定丰富的用户界面的功能。IBM WebSphereProcess Server 的 Human Task Manager 提供了基于人工服务的功能，在 IBM developerWorks 技术站点上有一篇讲述该产品和技术的文章（ 用于实现 Web 服务的 SOA 编程模型，第 8 部分 : 基于人工的 Web 服务 ），读者可以参阅其中的实现细节。

　　BPEL 规范重点讨论的是业务流程，其中的活动被假定为与 Web 服务的交互，不要求进行其他必需的行为。但通用业务流程包含的活动范围要大得多。业务流程的执行经常要涉及人员的参与，从而引入了一些新的方面，如人工交互模式等。为了支持广泛的涉及人员参与的业务流程场景，需要使用 BPEL 扩展。

　　BPEL4People 定义于 BPEL 语言之上，因此其功能可在需要时与 BPEL 核心功能进行组合，最新规范由两部分组成：

　　第一部分是 BPEL Extension for People，它将人工任务定义为一些可以作为 BPEL 流程定义中的第一级组件的活动，定义了在 WS-BPEL 上处理人工交互和任务的层级；它定义了一种新的基本活动类型，它使用人工任务作为实现，允许任务可以在本地的过程中，也可在过程定义之外。这个扩展基于 WS-Human Task 规范。
　　第二部分是 Web Services Human Task，它定义了独立人工任务，包括任务的属性、行为和运作，允许将人类任务作为服务引入 SOA 的接口，这些接口独立于 WS-BPEL。规范中的各种规定还可以用于 BPEL 流程之外的其他基于 Web 服务的应用之中。

　　人工交互的业务场景

　　下面讲述几种常见的应用于业务流程中的人工交互业务场景，并以此论证 BPEL4People 规范的应用范围。

　　人工活动

　　人员可以以一种特殊类型的活动实现方式参与到业务流程中，这种活动表现往往体现为人员交流的形式，也常被称之为人工活动。从用户的角度来看，人工活动是一种分配给该用户的任务，并要求该用户执行一定的操作。通过一种分发的机制将工作项添加到用户的任务列表中，从而用户可以很容易地察觉到分配给他的任务。工作项表示的就是分配给用户的一种任务，它明确特定的用户被授权执行特定的操作从而完成该任务。

　　表示人工活动的任务常常出现在用户的任务列表中，例如 IBM 协调办公工具 Lotus Notes 的 TO DO 任务列表、微软 Exchange 软件的任务列表、或者 SAP 协调软件中任务列表等。一旦参与到任务中，人员也可能会参与一些简单的交流或通知任务，这些交流或通知任务本质上指将信息传输到相关的组织。关于任务与通知之间最大的区别在于任务能够控制住流程的运行直到任务完成。

　　人工启动流程

　　人员除了可以以一种特殊类型的 BPEL 活动参与到业务流程中之外，实际的业务场景中还会有一些人工启动业务流程的情形，例如公司员工自助式服务中的旅行批准流程。属于正式员工组织的所有人员被授权可以直接使用旅行批准流程，而兼职员工或实习学生则必须需要经过他们经理的批准。实际上，人员所具有的属性对于流程的走向或者对工作项的分配常常起着重要的作用。为了支持这样的业务场景，将人员与 BPEL 流程相关联共同构建用于启动业务流程是十分有用的。

　　人工管理长运行时流程

　　在长运行时业务流程的生命周期中，要求人员参与的情形时有发生。一个典型的例子就是由于没有为人员分配特定的任务而使流程停滞不前。另一个例子则是如果一个流程由于等待用户的输入或者这些输入需要等待数小时才能获取到而处于停滞状态。此时，如果等待的时间超过预定时间，那么用户将会被通知决定如何处理停滞中的流程。

　　流程的停滞可能存在这种的情形：通过使用接收到的数据作为输入继续执行流程，或者延长等待期限继续等待所需要的数据，或者认为补充所需的数据以使流程继续执行。基于 BPEL 目前提供的语义，流程中能够提供了 Undo（取消）的功能。但是，假如流程已经运行了很长时间，并已经调用了若干合作伙伴的操作、收集了大量的数据等等，那么此时补偿机制未必是最佳权宜之计。这是因为流程的执行已经消耗了一定的资源，重新恢复流程将会造成一定的资源浪费。如果存在一个与该流程相关的业务流程管理员来决定流程的执行走向，换句话说如果能够有人员参与到此时的业务流程中，那么将会起到事半功倍的效果。业务流程管理员可以根据自身的业务知识确保流程顺利运行，为此应当提供为 BPEL 业务流程指定业务管理员角色的指派功能。

　　从业务管理员的角度来说，分配的任务就是指他如何与特定的流程实例进行交互，包括获取流程实例的状态，执行各种操作如输入所需数据、重新指派人员、重新指定流程执行的次序，甚至中断流程等。

　　人工与自动服务的转换

　　在很多情形下，某些服务对于运行中的流程来说并非可见，流程本身并不关注于服务的执行是否有人员的参与。例如，一个文档内容的翻译服务，这种服务的具体执行过程对于流程的运行并不重要。为此，在这种情况下人工与自动服务的转换、服务是否需要人员的参与应当对于流程的运行是透明的。

　　人工交互模式与原理

　　人工交互模式

　　除了上述简单的任务选择以及执行操作之外，人员与流程实例的交互之间还有很多复杂的交互模式。下面列举了四种经典的人工交互模式，BPEL4People 规范对四种模式都提供了相应的支持方案。

　　四眼原则

　　四眼原则也称之为职责划分原则，是在两个或两个以上人员独立参与决策的业务情形中常见的一种业务场景，尤其在银行金融、医疗保险等行业领域中。在这些业务场景中，由于考虑安全因素，用户可能不允许知道其他哪些人参与到决策中，从而避免人员之间的共谋。

　　任务升级

　　任务表示了人员所要执行的工作，它也描述了任务启动或完成所期望的特定时间范围。如果任务没有按照预期执行，例如执行该任务的人员突然生病不能坚持工作，或者任务工作量远远大于预期工作承受度，那么此时就需要任务升级的机制。

　　当任务没有按照预期执行，任务升级就会发生，通过人员分配机制告知一个或多个人员被作为任务升级的接收人。通知的机制既可以是及时通讯如聊天等，也可以是非及时通许如发送 E-Mail、短信息等。

　　任务升级还可以形成一个升级链，例如第一个升级可能是给一线经理的，如果任务仍然落后于时间进度，那么第二个升级则可能会给二线经理。这样任务升级在不同的阶段、不同情形下赋予给不同的人员，从而形成了任务升级链。

　　人员任命

　　有时候具体由谁执行任务并不明确，这种情形往往表现为任务的监管人员根据任务的性质、人员的技能等，手动指定任务的执行者。更复杂的业务场景则可能是这种指定规则本身也需要一个协作的决策制定过程。也就是说，人员任命需要多人共同参与决定。

　　执行链

　　任务执行链是指同一个人员按照一定顺序步骤执行的流程片断。这种流程片断有的可能在执行前预知，但也有的是在流程的执行过程中才决定的。人员在执行完每一步任务之后，需要返回到任务列表并刷新，才能发现新的任务项。
　　BPEL4People 规范提供了一种“短路”的机制，允许用户执行诸如“完成并宣称下一个任务”等并发的动作。基于该规范实现的工具也会提供基于向导的用户界面，帮助用户更好地按照一定顺序执行任务。

　　人工交互原理

　　人员活动是一种用于集成人员与 BPEL 流程交互的基本活动，下面的 图 1 列出了可能的几种不同的人工交互方式。 交互方式（1）和（2）都是将人工任务内嵌在 BPEL 流程中并作为流程的一部分。方式（1）中内嵌人工任务可以被定义为人员活动的一部分，这种情形下，人工任务的使用局限于包含它的人员活动之中。另外，人工任务还可以构建在 BPEL 流程或范围的上一层中例如方式（2），这种情形下，同样的任务可以被应用于多个人员活动中。因此，人工任务在方式（2）中的应用范围较在方式（1）中的应用更广泛些。

　　交互方式（3）描述了人工任务与人员活动在同一个运行时环境中，他们之间的调用特定于具体的实现，而不是依赖于 Web 服务之间的调用。这种情形类似于交互方式（2），区别在于方式（3）中人工任务独立于业务流程。

　　交互方式（4）中人工任务与人员活动处于不同的运行时环境，与方式（3）的区别在于人工任务提供了 Web 服务接口供人员活动调用。另外，WS-HumanTask 协调协议也用来在 BPEL 流程与任务之间通讯。通过这种机制，流程活动与任务之间的状态可以保持一致。

　　图 1 几种不同的人工交互方式
 
　　人员活动的语法如下 列表 1 所示，元素 包含在 BPEL 扩展元素 extensionActivity 中。其中，元素 、、分别描述了上述交互方式（1）、（2）或（3）、（4）。

　　列表 1. 人员活动的语法
               
　　　　outputVariable = “NCName”? isSkipable = “xsd:boolean”?
　　standard-attributes>
　　standard-elements
　　(…
　　|…
　　|…
　　|…
　　|…
　　|…
　　)
　　?
　　…
　　
　　?
　　 +
　　
　　?
 +
　　
　　　　Process = “all|newOnly|none”/>?

　　人工交互任务状态机

　　图 2 所示，描述了人员活动几种可能的状态以及状态之间的变迁。当流程执行中实例化一个人员活动时，会触发创建人工交互任务的事件，此时人工交互任务会由未激活状态迁移到运行中状态。接下来可能会出现几种不同的可能情况：

　　图 2 人员活动状态图
 
　　如果人员活动成功执行，流程将会继续进行，人工交互任务将由运行中状态变迁为结束状态，然后结束整个生命周期；

　　如果人员活动执行失败，并抛出能捕获的应用异常或不能捕获的 nonRecoverableError 异常，人工交互任务的状态将会由运行中变迁为失败；
　　如果跳过人员活动，流程还会继续进行，人工交互任务的状态则变为废弃状态；
　　而人工交互任务的状态由运行中变迁为中断的可能原因有几种，例如流程自身中断，或者流程发出了中断信号，亦或任务本身超时等。

　　人工任务策略断言

　　为了支持人工任务与其他 Web 服务之间能够协调工作，WS-Human Task 规范中定义了一种基于 WS-Policy 的新的策略断言——人工任务策略断言。每一个人工任务都只能对应唯一的业务操作，该操作被调用时，人工任务策略断言可以与之相关联。这样通过 WS-Human Task 协调协议，每一个人工任务的提供者与调用的组件之间可以进行通讯。

　　如下 列表 2 所示描述了人工任务策略断言的 XML 模式：

　　列表 2. 人工任务策略断言的 XML 模式
               
　　
　　http://www.w3.org/2001/XMLSchema” data-ke-src=”>http://www.w3.org/2001/XMLSchema</a>”
　　
　　targetNamespace = “http://www.example.org/WS-HT/protocol”
　　elementFormDefault = “qualified” blockDefault = “#all”>
　　
　　http://www.w3.org/XML/1998/namespace” data-ke-src=”>http://www.w3.org/XML/1998/namespace</a>”
　　schemaLocation = “http://www.w3.org/2001/xml.xsd” />
　　
　　
　　
　　
　　　　minOccurs = “0” maxOccurs = “unbounded” />
　　
　　
　　

　　在该 XML 模式中，描述了输入消息的发送方必须包含人工任务协调类型的上下文信息，作为接收方的人工任务也必须通过 WS-Human Task 协议初始化。一般地，一个 SOAP 绑定定义了消息头域（Message Header Fields）如何绑定到 SOAP 头上。对于 WS-Human Task 来说，就是指把人工任务上下文（Human Task Context）元素映射到 SOAP 头中。

　　如下 列表 3 描述的 SOAP 消息头例子中，包含了人工任务的上下文信息。

　　列表 3. 包含人工任务上下文信息的 SOAP 消息头
               
　　 　　>
　　
　　
　　0
　　
　　
　　
　　
　　Alan
　　Dieter
　　Frank
　　Gerhard
　　Ivana
　　Karsten
　　Matthias
　　Patrick
　　
　　
　　
　　
　　
　　
　　…

　　人工任务策略断言描述了单个操作行为，因此这些断言只能有一种对应的主题，即操作策略主题（Operation Policy Subject）。在 WS-PolicyAttachmen 规范中定义了两种附加到操作策略主题的点：一个是 wsdl:portType/wsdl:operation，另一个则是 wsdl:binding/ wsdl:operation。

　　WebSphere Process Server 中的人工任务

　　人工任务是涉及人员的组件，该人员与服务或另一人员进行交互。交互可以由人员或自动化服务启动，由人员启动的服务可以是自动化实现或者由另一人员提供的服务。可以轻松地将自动化服务调用的人工任务替换为自动化实现，反之亦然。可以使用任务来实现业务流程中要求人员进行交互的人员活动，例如以手工方式处理异常以及进行核准。所有其他异常处理都是在 Web Service 业务流程执行语言中使用故障和故障处理程序或者通过进行补偿来设计的。通过使用其中一种受支持的人员目录，可以确定能够与某个任务进行交互的人员。将为有理由查看该任务或者与该任务进行交互的用户创建工作项。

　　WebSphere Process Server 中的业务流程编排器 Process Choreographer 支持多种类型的人员目录，例如轻量级目录访问协议（LDAP）、WebSphere 用户注册表等。

　　人工任务的类型

　　参与任务

　　支持 Web 服务与人员之间的交互，此交互使人员能够实现服务。例如，参与任务可以是业务流程中的人工任务活动。如 图 3 所示描述了参与任务的交互过程。

　　图 3 参与任务
 
　　管理任务

　　管理任务与参与任务类似，不同之处在于管理任务由管理员用于解决流程中发生的技术问题。目前，管理任务只能用于业务流程。如 图 4 所示描述了管理任务的交互过程。

　　图 4 管理任务
 
　　发起任务

　　支持人员与计算机之间的交互，这些交互使人员能够通过图形用户界面来创建和启动服务。例如，用户可以启动业务流程或者通过发起任务向该业务流程发送事件。如 图 5 所示描述了发起任务的交互过程。

　　图 5 发起任务
 
　　纯人工任务

　　支持人员与人员之间的交互，这些交互使人员能够以结构化的受控方式与其他人员分担工作。纯人工任务不与业务流程或其他 Web Service 进行交互。如 图 6 所示描述了纯人工任务的交互过程。

　　图 6 纯人工任务
 
　　人工任务与业务流程的关系

　　直接插入任务

　　直接插入任务是作为业务流程的一部分定义的。不能将直接插入任务视为服务组件体系结构（SCA）组件，但是它可以与流程共享上下文数据。

　　独立任务

　　独立任务是 SCA 组件。此任务以服务形式实现人员交互（参与任务），通过图形用户界面利用人员与服务之间的交互（发起任务）或者支持人员之间的结构化协作（纯人工任务）。任务组件可以与包括业务流程在内的其他服务进行组合。

　　子任务

　　子任务是从父任务中分离出来的附加工作单元。可以从模板中选择子任务模型，也可以在运行时定义此模型。输入数据由创建或启动该子任务的人员提供。父任务将等待它的所有子任务完成。父任务的所有者或编辑者对子任务的输出数据进行合并，然后完成父任务。如果子任务无法在指定时间段内完成，则可以对父任务进行升级。升级表示父任务仍在等待子任务完成。子任务可以是纯人工任务或发起任务。

　　后续任务

　　后续任务是为了完成现有任务而创建的任务。可以从模板中选择后续任务模型，也可以在运行时定义此模型。输入数据由创建或启动该后续任务的人员提供。后续任务的输出和故障消息类型必须与先前任务的输出和故障消息类型相同。先前任务将进入“已转发”状态，并且不会向调用该任务的服务或人员报告运行完成。当后续任务完成时，它会将输出或故障数据报告给调用了原始任务的服务或人员。先前任务的升级将继续运行并进行升级。后续任务有自己的升级。后续任务只能是纯人工任务。

　　任务升级

　　任务升级是指任务在特定时间段内未能圆满完成时执行的操作过程，升级将用户可能无法及时完成所分配任务这一情况通知升级接收者。例如，如果在定义的时间限制内未声明或未完成任务，则会执行此操作过程。对于一个任务，可以指定一个或多个升级。这些升级可以并行启动，也可以作为一连串升级启动。升级将在相关任务达到生命周期内的特定状态时进行初始化。在定义的持续时间过后，将对任务状态进行验证。如果任务状态与预期状态不符，则将调用升级操作。WebSphere Process Server 中支持的升级操作包括为一组用户创建工作项、将电子邮件发送至指定的收件人或将通知事件发送至已注册的使用者等。

　　WebSphere Process Server 中基于人工任务的业务流程模式

　　会签模式

　　在业务流程中，某项任务需要由多人共同进行审批，根据每个人的批复结果，并依据一定的规则（如全数通过、按比例通过或否决等）确定是否被批准，这种业务常常被称之为会签模式。会签模式在需要多人审批的业务流程中常常出现，例如集成了企业资源管理 ERP 的供应链管理 SCM 系统、需要多人参与的办公自动化系统等。

　　IBM WebSphere Process Server 中也能支持这种复杂的业务流程模式，可以把会签提取成一个可复用的子流程。如 图 7 所示的流程图描述了这种模式的应用。

　　图 7 会签模式流程
 
　　其中，第一个片段中包含用于指定参与会签的人员情况，例如，下面的 代码列表 4 中指定了参与会签的人员 Person1～5。同时，在人员任务节点中，设置查询描述为 Users by user ID，UserID 为 %person%。

　　列表 4. 会签模式代码
               
　　try {
　　com.ibm.bpe.api.PIID piid =
　　 (com.ibm.bpe.api.PIID)this.processInstance().getID();
　　javax.naming.InitialContext initialContext =
　　new javax.naming.InitialContext();
　　Object obj = initialContext.lookup
　　(“com/ibm/bpe/api/BusinessProcessHome”);
　　com.ibm.bpe.api.BusinessProcessHome home = (com.ibm.bpe.api.
　　BusinessProcessHome) javax.rmi.PortableRemoteObject
　　  .narrow(obj, com.ibm.bpe.api.BusinessProcessHome.class);
　　com.ibm.bpe.api.BusinessProcess service = home.create();
　　service.setCustomProperty(piid, “person”,
　　”Person1:Person2:Person3:Person4:Person5″);
　　}
　　catch (Throwable e) {
        e.printStackTrace();
     }
 
　　此外，While 循环用来指定会签的规则。上述例子中，参与会签的人数为 5 人，假如要求半数以上（>=50%）通过，那么在 While 循环进入之前，设置一初始变量 passed，值为 0；每一人签过之后变量 passed 加 1。当变量 passed 值大于等于 5*50% = 2.5 时，跳出 While 循环直接进入下一步，完成会签过程。

　　追回模式

　　在业务流程中，有两个或以上相关的人员任务，如果第一个人员任务 HT1 在向第两个人员任务 HT2 提交了申请后，发现该笔申请的某些信息有误，需要向第两个人员任务 HT2 申请撤回该笔申请。撤回的前提是第两个人员任务 HT2 尚未对该申请进行审批。这种情况在业务流程中称为追回模式。

　　IBM WebSphere Process Server 中并不能直接支持这种复杂的业务流程模式，但可以通过程序实现以流程管理员的身份追回未处理的工作项。如下 代码列表 5 描述了如何在 WebSphere Process Server 中实现追回模式。

　　列表 5. 追回模式代码
               
　　javax.security.auth.login.LoginContext lc = null;
　　try {
　　lc = new javax.security.auth.login.LoginContext( “WSLogin”,
　　 new com.ibm.websphere.security.auth.callback.WSCallbackHandlerImpl( “admin”, “admin”));
　　}
　　catch (javax.security.auth.login.LoginException e) { }

　　if (lc != null)
　　try {
　　lc.login();
　　javax.security.auth.Subject subject = lc.getSubject();
　　com .ibm .websphere .security .auth .WSSubject .doAs(subject,
　　 new java. security. PrivilegedAction() { public Object run() {
　　BusinessProcess processServ = bph.getBusinessProcess();
　　processServ.claim(WF_AIID);
　　WSIFDefaultMessage message = new WSIFDefaultMessage();
　　ClientObjectWrapper messageObject = new ClientObjectWrapper(message);
　　processServ.complete(WF_AIID,messageObject);   
　　return null;
　　}} );
　　}
　　  catch (javax.security.auth.login.LoginException e) {}

　　重审模式

　　在业务流程中，重审模式是审批型流程中比较常见的业务，这种流程涉及人员审批活动。根据人员的输出内容，流程可能回退到之前的某一步骤。为解决这一问题，可以引用 BPEL 里的一个机制：连接行为属性（Join Behavior）。它主要存在于各种类型的流程节点中。该属性为 Boolean 类型，如果是 true，则该属性所在的节点被执行，否则被跳过。

　　基于这一机制，可以创建一个可复用的流程模板，实现任意步骤的回退，如 图 8 所示的流程包含了 N 个人员活动，其中人员 N 为审批人，他可以标示前面人员 1、人员 2 和人员 3 提交的内容是否通过，如果不通过，可以选择打回给相应的人员。

　　图 8 重审模式流程
 
　　在流程图的第一个片段中，设置当前步骤为 1，在 While 循环中，设置退出循环的条件为人员 N 审批通过。在循环的里面，第一个节点处，添加一个 Empty 空动作节点，其目的是在第一个人员前加链接，确保连接行为的执行。在人员 1 的连接行为内，选择条件类型为表达式，输入代码表明如果当前步骤大于 1，跳过第一个节点。同样地，在人员 2、3 中的连接行为内输入代码表明如果当前步骤大于 2、3 则自动跳过。

　　在人员 N 后的 Java 片段中输入代码，表明如果人员 N 同意，退出循环；如果人员 N 不同意，根据用户输入的值，选择回退给哪个人重审。

　　结束语

　　由 IBM、Adobe、SAP、Oracle、BEA systems 和 Active Endpoints 所组成的业界著名的流程供应厂商，于 2007 年 6 月 25 号发布了有关新提议的 WS-* 规范的最终草案——一份名为“WS-BPEL4People”的规范。相比于处理业务过程自动化的 WS-BPEL，WS-BPEL4People 规范，更侧重于为 SOA 增加一般的人员工作流能力，尤其是对最近被批准的 WS-BPEL 2.0 规范而言。 Web 服务业务流程执行语言 WS-BPEL 当前并未涵盖人工用户交互；WS-BPEL 主要设计用于支持基于 Web 服务的自动化业务流程。不过，在实际中，很多业务流程场景都需要进行用户交互。由 IBM 和 SAP AG 联合发布的白皮书说明了业务流程中涉及用户的各个场景，然后定义了用于处理这些场景的相应 WS-BPEL 扩展。 IBM WebSphere Process Server 中引入的人工任务可为基于人工的 Web 服务提供基础设施。这些任务以典型的人工工作流系统提供的功能为基础，其功能经过了扩展，包含了成熟的升级和通知功能，以及为人工任务指定丰富的用户界面的功能。 本文从原理与业务场景的角度重点探究了这一 SOA 最新的规范 WS-BPEL4People，并基于规范分析了其在 IBM WebSphere Process Server 中的实现情况，最后提出了几种常见的 WebSphere Process Server 中基于人工任务的业务流程模式。

　　关于作者

　　王夕宁是IBM中国软件开发实验室SOA(中国)设计中心的软件工程师，他的主要技能和专长包括SOA、Web服务、J2EE、业务流程、模型驱动技术以及Eclipse开发等领域。目前从事于SOA领域中的业务/IT策略、规则方面的工作。可以通过wangxn@cn.ibm.com联系他。