BPEL中的用户解析技术剖析

文档选项 未显示需要 JavaScript 的文档选项

级别： 中级

金戈 谭佳, IBM中国软件开发实验室 软件工程师

2006 年 1 月 04 日

基于角色的任务分配是IBM WebSphere Business Foundation Server流程引擎所提供的重要功能，它弥补了BPEL规范在人员集成方面的不足，为基于流程的业务整合奠定了良好的基础。用户解析是基于角色的任务分配在技术层面的具体体现。本文试图对于WBISF流程引擎所提供的用户解析技术做深入讨论，并结合一个具体实例介绍了如何在流程开发中实现基于角色的任务分配。

业务流程执行语言(BPEL)是工业界在Web Service诸多规范的基础上提出的一种新型的流程描述语言，其初衷是为了更好地解决企业IT系统整合所面临的诸多问题。在当前激烈竞争的企业环境下，企业必须能够对于外界环境变化做出更快的反应，其中一种重要的适应策略就是改变和优化企业运行的业务流程。从技术支撑的层面来看，我们需要从流程建模、流程引擎和流程监测三个方面提供必要的支持。其中，流程建模帮助业务人员规约流程在功能层面和质量属性层面的基本特征，流程引擎负责管理和维护业务流程实例的生命周期，流程监测则为分析和评估业务流程的运行成本提供了可能，以上三个方面构成了一个闭环的回馈系统。BPEL作为一种新型的流程描述语言，是IT技术在流程建模层面的具体体现，它为基于流程的业务整合奠定了基础。

从编程语言的角度来看，BPEL定义了一套完整的程序执行原语，如顺序、并发、分支和循环等，提供了一套类似于传统编程语言的概念集合，所以使用BPEL描述的流程可以作为运行实体直接部署于流程引擎。从业务流程抽象描述的角度来看，BPEL支持在流程活动与用户角色之间建立映射，这一机制使得运行引擎在自动记录业务流程运行状态的同时，间接记录了用户在业务层面的操作行为，所以BPEL为流程监测奠定了基础。在BPEL提出之前，工业界也提出过若干种流程描述语言和开发环境，如FDML、SAP Flow和FileNet等，但是以上流程语言很难解决通讯协议及访问接口之间的异构问题。BPEL与以前诸多流程描述语言的最大不同之处在于BPEL对参与流程执行的协作方所采用的交互协议做出了明确的规定，即基于XML的SOAP编码。所以，BPEL在信息集成领域得到了广泛的应用。

基于角色的任务分配是IBM WBISF (Websphere Business Integration Server Foundation) 流程引擎所提供的一个重要功能，它通过为用户自动指派工作任务，为不同角色的用户提供了不同的工作事项列表。本文第一部分主要介绍WBISF流程引擎用户解析构件的用户授权模型及实现体系结构，介绍了查询模版和查询语句从逻辑层到物理层的转换细节；第二部分则结合一个银行贷款申请流程实例介绍如何在WSADIE 5.1.1开发环境中实现基于角色的任务分派。

1. 理论介绍

1.1 模型概述

本节主要介绍WBISF流程引擎所提供的用户解析模型。在流程运行的过程中，流程活动通常会经历多种不同的状态。每一种状态下不同角色的用户对于流程实例所能执行的操作是不一样的(图1是BPEL流程活动的状态转换图)。以Staff活动为例，当流程执行到Staff活动时，引擎首先将该活动从Inactive状态转化到Ready状态，并为相关用户创建工作条目，这一过程实际就是基于角色的任务分派。此时，流程引擎需要结合流程用户模型定义及用户注册表获取特定读者、编辑和潜在拥有者的列表。在Staff活动的状态转化为Ready后，隶属于潜在拥有者角色的用户允许声明该活动为其所有，此时Staff活动状态转化为Running/Claimed，并将该活动拥有者的权限授予该用户，该过程涉及到用户授权。最后，当活动拥有者填入相关参数并正常完成活动后，Staff活动的状态将转化为Finished。从以上过程可以看出，流程引擎的用户解析构件必须要解决两个问题：任务分派与用户授权。任务分派需要根据流程模型定义，从用户注册表中寻找特定角色的用户列表；而用户授权则需要根据用户角色，判定其是否拥有相关的操作权限。而以上两个问题都涉及到同一个主题：用户认证与授权的模型。

在J2EE的环境下，用户认证与授权的过程相对简单：首先，开发人员在构件开发阶段定义若干用户角色，每一种角色都拥有特定的资源访问权限。在系统部署时，部署人员将预定义的逻辑角色与物理存在的用户或组绑定，从而完成角色映射。在系统运行时，EJB容器或Web容器在调用任何方法时前都必须将用户身份与资源角色比较，判定用户是否拥有合适的访问权限。从本质上来看，J2EE的认证与授权模型是基于用户身份的按名匹配，其特点在于其简洁性，并且支持同一角色与多个物理用户或组的多重映射，但是灵活性相对不足。WBISF流程引擎的安全模型吸收了J2EE的特点，它将整个认证与授权模型分为三个部分：授权角色(Role)、查询模版(Verbs)和查询参数(Parameters)。首先，WBISF流程引擎预先定义了若干授权角色类型，如流程管理员，活动读者和活动编辑等，每一种角色对于各种流程实体分别拥有不同的权限，如流程管理员允许启动、察看、终止和删除流程实例，而活动读者只允许察看流程特定活动的状态信息。WBISF流程引擎并不支持自定义的角色声明，其原因在于用户对于流程实体所能执行的操作相对稳定，并不需要开发人员自定义用户角色类型。其次，在开发人员选择授权角色后，需要建立业务角色与用户注册表中实际存在的用户与组的关联，这一步骤在流程引擎安全模型中体现为选择用户查询模版以及输入相关的查询参数。WBISF流程引擎针对J2EE安全模型灵活性不够的特点(只支持按名匹配)，引入了查询模版的概念，每一个查询模版都对应于一条参数化的查询语句，该语句支持按照用户属性确定用户身份。开发人员通过为模版提供合适的查询参数，决定了逻辑角色与物理用户或物理组的绑定关系。

从实现细节来看，流程引擎提供了如下构件以实现用户解析功能：工作条目管理器(Work Item Manager)、用户解析服务(Staff Support Service)、用户解析插件提供者(Staff Resolution Plug-in Provider)和用户注册表(Staff Repository)，它们之间的调用关系如图1所示。工作条目管理器主要负责处理所有与用户工作事项相关的功能，如创建和删除工作条目，按照用户身份查询其工作安排等。当流程引擎遇到业务流程中的Staff活动时，引擎会暂时挂起流程的执行，并调用工作条目管理器为相关用户创建相应的工作事项。用户解析服务则负责回应来自于工作条目管理器的用户解析请求，并管理和维护诸多用户解析插件的生命周期。工作条目管理器在创建工作事项前必须首先获取相关用户的列表，此时用户解析服务根据开发人员填入的查询模版(如雇员经理)和查询参数(如雇员ID为peter)，从用户注册表中获取合法的用户列表。用户解析插件提供者则负责执行具体的用户查询请求，并需要验证查询请求格式的合法性，该插件屏蔽了底层查询接口的不一致。用户注册表在整个体系结构中处于最底层，它主要负责管理和维护人员存储目录。当前WBISF流程引擎缺省支持两种用户目录：WAS内置的User Registry和LDAP。WBISF流程引擎只能读取用户注册表中的内容，但是不能做任何修改。

1.2 内置角色类型

接下来我们来看WBISF流程引擎所提供的内置角色类型。BPEL角色定义分为两个层面：首先是流程(process)层面的角色定义，它关注于整个流程运行层面的用户授权，其角色定义包括流程管理员、流程读者和流程启动者等；其次是活动(activity)层面的角色定义，特别是Staff活动。Staff 层面的用户授权关注于单个工作条目的访问授权，其角色定义包括活动读者、活动编辑和潜在活动所有者等。在开发人员设计Staff活动时，一个重要的问题就是决定什么用户能够执行该操作，并在运行时刻拒绝不具备相关权限的用户访问。活动层面的用户授权解决了该问题。下表是流程引擎所提供的内置角色详细信息的列表：

1.3 查询模版

每一个查询模版都提供了一条参数化的查询语句，该查询语句通过XSLT转换后，变为可被用户注册插件提供者接受的物理查询语句，由用户解析服务执行查询以获取合法用户列表。查询模版相对于J2EE中简单的按名绑定模型的优点在于提供了更为丰富的查询原语，它不仅支持简单的按照用户名和组名绑定，也支持使用预定义的查询模版描述物理用户之间及用户与其属性之间的关系，如允许按照用户属性判定用户是否存在，也允许使用环境变量在运行时刻动态绑定用户等。但是，WBISF流程引擎的授权模型在提供诸多好处的同时，也存在若干缺点：首先，流程引擎无法在流程部署到服务器时决定逻辑角色与物理用户的绑定关系。在WSADIE开发环境为BPEL流程生成EJB部署代码时，已经预先生成了流程实体各种安全角色与物理用户的绑定关系，而不能在部署时刻绑定；其次，同一授权角色只能绑定一类物理用户，即角色与用户的绑定是一对一的，这一点弱于J2EE中支持逻辑角色与物理用户一对多的绑定关系。在开发人员根据应用需求选择待授权的用户角色之后，需要为该角色指派特定的用户查询模版。WBISF流程引擎提供了以下缺省用户查询模版：

BPEL流程执行引擎还支持开发人员自定义查询模版，该特征使得引擎能够支持更加丰富的人员验证类型，比如按照用户的电子邮件地址查询用户身份等。前面已经提到，用户解析插件提供者为用户注册表提供了封装，屏蔽了底层查询接口的异构性，但是并不是所有的用户解析插件提供者都支持以上缺省查询模版(Everybody、Nobody和Users缺省被所有插件提供者支持)。WBISF当前支持三种用户解析插件：User Registry、System和LDAP。

• User Registry：该类型的用户解析插件使用WAS内置的User Registry API判定用户身份的合法性。在当前的WBISF流程引擎实现中，除Everybody、Nobody和Users外，User Registry还允许按照Users by user ID、Group Members、Person Search、Group Search和Native Query等模板来查询用户身份。
• System：该类型的用户解析插件只支持静态的用户指派及环境变量引用，其后台并没有对应的用户注册仓库。所以，该类型的用户解析插件在真实生产环境下并不被推荐使用。
• LDAP：该类型的用户解析插件基于LDAP目录提供了用户身份判别的功能。由于LDAP支持按照纪录属性查找纪录的功能，所以该类型的用户解析插件支持所有缺省的查询模版集合，支持按照某些用户单个属性或属性集合来查找纪录。当然，在引入诸多方便的同时，使用LDAP类型的用户解析插件也需要提供相关的配置参数，如LDAP服务器地址等。

在选择合适的查询模版后，开发人员还需要填写查询执行所必需的参数，查询模版与输入参数结合在一起才成为逻辑完整的查询语句。由于BPEL流程执行引擎支持多种类型的用户物理存储格式，如User Registry和LDAP等，WBISF流程执行引擎使用XSLT屏蔽了不同插件提供者之间的差异性。在执行真正的查询语句之前，系统由特定构件将通用的逻辑查询语句转换为物理查询语句，该过程由用户解析服务完成。具体而言，在流程部署时，用户解析服务首先根据流程配置从JNDI中选择合适的用户解析插件提供者，然后将用户选择的查询模版和输入参数通过预定义的XSLT转换模版将通用的逻辑查询语句转化为插件特定的物理查询语句，最后调用用户解析插件部署查询语句。在部署过程中，用户解析插件提供者需要检查语句的合法性并存储生成的查询语句对象。在流程运行时刻，工作条目管理器在创建工作条目之前必须获取所有相关角色的合法用户列表。用户解析服务接受来自于工作条目管理器的请求，并将请求发送给特定类型的用户解析管理插件，获取合法用户ID列表后返回给工作条目管理器。

1.4 环境变量

WBISF流程引擎的安全模型不仅支持在开发时指定逻辑角色与物理用户的绑定关系，还支持在运行时刻动态解析合法用户的集合。这一功能通过环境变量来完成。环境变量使得流程引擎能够在运行时刻动态决定角色与用户的绑定关系，从而为用户解析提供了更大的方便性。流程引擎提供的环境变量分为两种：单值环境变量与多值环境变量。单值环境变量只包含一个用户身份，如%wf:process.starter%所代表的流程启动者等。多值环境变量则能同时包含多个用户身份，如%wf:process.administrators%所代表的所有流程管理者等。多值环境变量表明在查询合法物理用户列表时，需要多次执行查询语句。下面是WBISF流程引擎所定义的缺省环境变量的列表：

以上内容是对WBISF流程引擎在用户授权方面的相对完整的描述。总体而言，WBISF流程引擎的授权模型相比于传统J2EE授权模型的优点主要集中于以下方面：1. 查询模版：开发人员基于用户查询模版，可以为流程活动提供丰富的用户查询操作语义；2. 环境变量：环境变量的使用使得流程支持在流程运行时刻动态决定合法用户集合；3. 支持多种类型的用户存储机制。

回页首

2. 实例分析

本节将结合一个贷款申请流程阐述基于角色的工作分派的实现过程。为简单起见，我们对使用的流程场景做了相当程度的简化，其需求如下：

1) 贷款申请者在HTML页面上输入用户贷款的详细信息，主要包括用户身份证号及申请金额等。在完成以上内容的填写后，用户点击提交按钮，此时后台的处理程序首先判断用户输入是否合法，如果不合法则拒绝用户提交的内容，如果合法则调用流程API启动一个新的流程来响应用户请求，并将用户输入数据传入流程实例。

2) 当流程启动成功后，信贷申请首先必须经过信贷审批员的审核。在信贷审批员的工作条目列表中将出现一个新的工作项，信贷审批员点击该项，页面上将会出现信贷申请者的详细信息，如用户身份证号、申请金额及用户以往信用纪录等。如果用户信用记录较好，则信贷审批员可以直接批准。如果用户信息记录较差，信贷审批员可以直接拒绝用户的贷款申请。在以上任何一种情况下，部门经理接下来都必须批准审批员的审核结果。

3) 信贷审批员完成贷款申请审核后，信贷部门经理的工作条目列表中将出现一个新的工作事项。部门经理点击该项，页面上出现信贷申请者的详细信息以及信贷审批员的评估结果。如果部门经理认可审批员的结论，则直接批准。最后，流程将审批结果呈现在贷款申请者的工作事项列表上。贷款申请者点击完成按钮，整个流程成功结束。

从以上需求我们可以看出，整个贷款申请流程共涉及到三类角色：贷款申请者、信贷审批员和信贷部门经理。贷款申请者在流程中是审批结果察看活动的潜在拥有者，并且是流程的启动者。信贷审批员负责第一轮的贷款申请审核，是该活动的潜在所有者。信贷部门经理负责第二轮的贷款申请审核，是该活动的潜在所有者。为简单期间，我们不妨假设用户存储仓库中已经存在三个用户：david是贷款申请者，peter是信贷审批员，john是信贷部门经理。

2.1 流程设计与部署

为开发针对以上需求的流程，开发人员首先需要在IBM WSADIE5.1.1的开发环境中创建一个新的服务项目LoanProcessProject，然后在服务项目中创建一个新的BPEL流程LoanProcess。LoanProcess在WSADIE开发环境中如下所示，具体开发过程不再赘述：

流程的开始会有一个Receive活动来接收用户的贷款申请请求，并将用户输入的相关数据保存到本地变量中。接下来流程需要按照用户资料查询申请者的信用记录，并给予相应的信用等级评分，该活动对应于流程中的Retrieve Credit Rate活动。在成功获取申请者信用评分后，流程需要等待信贷审批员的批复，即流程中Specialist Approve活动。此时我们需要为该信贷审批员指派相关用户，点击流程中的Specialist Approve活动，从属性视图中选择人员选项，并按照下图填入信息：

以上输入表明我们为Specialist Approve活动的潜在所有者选择了Group Search的用户查询模版，即流程会按照组属性来确定用户身份，在GroupID参数域填入LoanSpecialist值，表明该活动只有流程管理员和LoanSpecialist组的成员才拥有相关权限来声明并完成该活动。在我们的用户注册表中，只有peter是 LoanSpecialist组的成员。

在Specialist Approve活动完成后，接下来需要信贷部门经理来批准审批结果，该活动在流程中体现为Manager Approve。经理批复的角色也只能限于部门经理，所以，需要在Manager Approve的人员属性中输入下列信息：

以上输入表明我们为Manager Approve活动选择了User by user ID的用户查询模版，在UserID参数域填入john，表明只有流程管理员和部门经理john拥有足够的权限声明并完成该活动。

最后是贷款申请者需要查看批复的结果，该活动在流程中体现为Applicant Review活动。显然，该活动只能由实际的贷款申请者查看，所以该活动的访问权限局限于流程启动者，其人员属性输入如下所示：

如果我们还希望在流程结束后能够察看流程运行的相关统计信息，必须为流程设定管理员。点击流程顶部的DebitProcess框，在属性视图中选择人员选项，在UserID属性域输入john，表明john作为管理员在流程运行过程中拥有最高权限，他不仅可以访问流程中任意活动的状态信息，而且可以在流程运行时终止并删除流程实例。

在设定所有人员相关属性后，开发人员需要为BPEL流程生成部署代码，然后将自动生成的EAR文件部署到应用服务器上加以测试。如果测试环境是WBISF5.1.1内置的测试环境，只需要将EAR文件添加到服务器上，然后启动服务器即可。特别需要注意的是，在配置流程测试环境时，必须要将服务器的全局安全性开启，本文使用User Registry做为用户解析插件的提供者。

2.2 使用通用测试端测试业务流程

WBISF流程引擎为开发人员提供了一个通用的流程测试客户端帮助调试业务流程。使用该测试端，开发人员可以在不编写任何测试代码的情况下验证流程运行是否正常。在服务器正常启动后，开发人员在浏览器中敲入http://localhost:9080/bpe/logon.jsp，此时浏览器中出现用户登陆界面。

1) 创建新的贷款申请流程。首先使用david用户登陆，此时david扮演的角色为信贷申请者，所以他需要创建一个新的流程。在界面左侧导航栏选择Process Template Lists下的My Templates链接，界面右侧将会出现当前可用的流程模版列表。在右侧界面选择DebitProcess条目，并点击Start Process按钮，用户界面将如图7所示：

填入相关参数，并且点击页面上部的Start Instance按钮，从而启动贷款申请流程。此时页面将自动跳转至david的My To Dos页面。贷款申请流程的第一个Staff活动将由信贷审批员peter来处理，所以david此时没有任何工作条目需要完成，但是他可以在Process Instance Lists下面的Created By Me页面中看到一个由他创建的DebitProcess流程。

2) 信贷审批员评估贷款风险。使用peter用户登陆，此时peter扮演的角色为信贷审批员。用户登陆后呈现的第一个页面通常是My To Dos。由于此时存在一个贷款申请，所以peter需要处理该工作条目，其界面如图8所示。

在页面上选择Specialist Approve任务，点击claim按钮，声明该任务由peter处理，然后再次选择Specialist Approve任务，点击complete按钮，页面上将会出现如下界面。在approved文本框内填入true，说明peter批准了该贷款请求，点击页面上的complete按钮，页面将自动跳转到My To Dos页。此时，由于工作已经被完成，peter的My To Do将不再显示任何工作条目。

3) 信贷部门经理审核：使用john用户登陆，此时john扮演的角色为信贷部门经理。显然，当前有一个贷款申请需要john来批复。在john的My To Dos页面上，我们可以看到一个工作条目Manager Approve。

在页面上选择该条目，点击Claim按钮，声明该条目由john来处理。再次选择Manager Approve工作条目，点击Complete按钮，页面将会跳转至如下界面。在approved文本框中填入true，表示贷款申请已被批准。此时页面会自动跳转至john的My To Dos页面，由于工作条目已被完成，所以界面上将不会显示任何待处理的工作事项。

4) 贷款申请者查看审核结果：在部门经理完成贷款批复后，贷款申请者能够在其My To Dos页面查看贷款申请的结果。再次以david登陆，界面上将会出现david的My To Dos页面。此时，页面上显示当前有一个Applicant Review的工作事项需要david来处理。

5)选择Applicant Review条目，点击界面上的Claim按钮，声明该事项由david来处理。再次选择Applicant Review条目，点击界面上的Complete按钮，页面上将会出现如下界面。在页面上我们可以看到贷款申请审核结果为true，说明申请已被批准。点击Complete按钮，完成整个流程的执行。

6) 流程管理者查看流程运行统计结果：在整个贷款申请流程完成后，如果在开发环境中设置流程结束后不删除流程实例，流程管理员可以查看流程运行的相关统计结果。以john的身份登录通用流程测试客户端。点击Process Instance Lists目录下的Administered By Me链接，页面将会显示刚刚完成的流程名称。点击该流程，可以看到如下界面：

从上面的页面可以看出，WBISF流程引擎记录了流程中每一个活动的开始时间和结束时间，并且记录了相关完成人。基于以上信息，企业可以按照需要分析流程的执行成本，统计相关工作人员的工作效率，以及为优化流程提供相关的依据。

2.3 流程API调用

以上讨论了如何使用WBISF所提供的通用流程测试客户端来测试所使用流程。WBISF流程引擎还提供了一组访问流程运行信息的API。通过该组API，开发人员不仅可以查看相关流程的相关状态信息，还可以执行所有与Staff活动相关的操作，如声明和完成Staff活动等。下表中列出了一个使用流程引擎提供的API查询特定用户所有工作事项的示例代码片断。

import com.ibm.bpe.api.*;
…
// obtain the default initial JNDI context
InitialContext initialContext = new InitialContext(…);

// lookup the EJB home interface of the BusinessProcess bean
Object object = initialContext.lookup("com/ibm/bpe/api/BusinessProcessHome");
BusinessProcessHome processHome = (BusinessProcessHome)
    javax.rmi.PortableRemoteObject(object, BusinessProcessHome.class);

// get the remote BusinessProcess interface
BusinessProcess process = processHome.create();

// run a query to show all activity names that are ready to be started
// and that I can claim (where I have a potential owner work item)
QueryResultSet resultSet = process.query(
// select clause - what do want to get?
"PROCESS_INSTANCE.NAME, ACTIVITY.TEMPLATE_NAME",
// where clause - what are the qualifying rows?
"WORK_ITEM.REASON=WORK_ITEM.REASON.REASON_POTENTIAL_OWNER"+
" AND ACTIVITY.STATE = ACTIVITY.STATE.STATE_READY" +
" AND ACTIVITY.KIND = ACTIVITY.KIND.KIND_STAFF",
// order clause = specify the sort order
"PROCESS_INSTANCE.NAME",
// threshold - return first 10 entries only
new Integer(10),
// no timezone specified
null);

// loop over results in the result set
while(resultSet.next())
{
// print out selected columns
System.out.println("Process instance name = " + resultSet.getString(1));
System.out.println("Activity template name = " + resultSet.getString(2));
}

以上代码首先从JNDI中获取BusinessProcessHome远程对象引用，然后创建一个新的BusinessProcess实例，最后使用query操作查询类型为Staff活动的工作事项。需要指出的是，以上代码只有在应用服务器全局安全性被正确开启的情况下，才能自动查找特定用户的工作条目列表。当用户以peter的身份登录系统，以上代码会自动查询peter所要处理的工作事项。当用户以john的身份登录系统，则以上代码会自动查询john需要处理的工作事项。但是以上代码并没有显式设定调用者的身份，其中的奥密之处就在于WBISF流程引擎利用了WAS在EJB内部调用之间自动传递用户安全上下文环境的特点，从而将安全代码与业务逻辑代码分离。但是，如果开发人员为流程活动指派了用户角色，而在访问者所在的应用中安全属性没有正确配置，则查询的结果会始终为空，以上代码将不会查询到任何工作条目。

回页首

3. 结束语

本文主要介绍了WBISF流程引擎所定义的用户授权安全模型，并以此为基础讨论了该模型所涉及的查询模版及查询语句转换的细节，介绍了用户解析构件的体系结构，并结合一个贷款申请的例子详细介绍了如何在基于BPEL的流程开发中的实现基于用户角色的任务分派。我们可以看到，WBISF中的授权模型不仅较好地完成了用户授权功能，而且支持按照用户角色分配工作任务，从而为基于流程的业务整合奠定了坚实的基础。

参考资料

1. BPEL Specification, http://www-128.ibm.com/developerworks/library/ws-bpel/
2. Websphere Application Server Enterprise Process Choreographer: Concepts and Architecture, Matthias Kloppmann, etc, http://www-128.ibm.com/developerworks/websphere/library/techarticles/wasid/WPC_Concepts/WPC_Concepts.html
3. Websphere Application Server Enterprise Process Choreographer: Staff Resolution Architecture, Kurt Lind, etc, http://www-128.ibm.com/developerworks/websphere/library/techarticles/wasid/WPC_StaffArch/WPC_StaffArch.html
4. Websphere Application Server Enterprise Process Choreographer: Programming model for staff resolution, Kurt Lind, etc, http://www-128.ibm.com/developerworks/websphere/library/techarticles/wasid/WPC_StaffModel/WPC_StaffModel.html
5. Websphere Application Server Enterprise Process Choreographer: Work Items and the query() API Call, Frank Neumann, http://www-128.ibm.com/developerworks/websphere/library/techarticles/wasid/WPC_Queries/WPCQueries.html

关于作者

		本文撰写的技术人员包括： 谭佳 IBM中国软件开发实验室 IBM中国SOA设计中心 软件工程师 金戈 IBM 中国软件开发实验室 IBM 中国SOA 设计中心 软件架构师 IBM中国软件开发实验室SOA设计中心是IBM全球四个SOA设计中心中最大的一个，成立一年多来，已经取得了可喜的成果。我们在全球范围内实施了多个 SOA 应用项目，为多个行业的客户提供了 SOA 解决方案。我们正在实施的 SOA 项目涵盖了很多的重要行业，包括零售业、航运业、电力、银行、保险等等。通过这些不断增长的成功案例，我们不仅深入地推广了 SOA 的理念，树立了 SOA 成功实施的范例，也为我们的队伍积累了经验，培养了人才。与此同时，我们还是 IBM 开发 SOA 的软件平台的主力军。这个新的平台基于模型驱动的思想，旨在最大化地重用软件资产，它为 SOA 项目的实施提供了一整套源自成功实践的方法论、设计范式和工具集。它的出现将极大地方便 SOA 系统架构师、设计人员、开发人员，使他们能够快速地开发 SOA 应用项目。

对本文的评价

太差！ (1) 需提高 (2) 一般；尚可 (3) 好文章 (4) 真棒！(5) 建议？

回页首