架构设计

1. 文档编写目的

该文档通过对Tempo这个开源工作流引擎的架构设计进行描述，学习其设计方法，重要的是了解其对于BPEL4People规范的实现机制，以其在后续的项目开发中可以集成到BPEL引擎中。

本文档主要分为以下几个部分，首先是对Tempo的总体架构的一个简单描述，再就是对于其各个子模块进行描述，其中着重了解其BPEL4People的实现方式，最后，对于Tempo与ODE的集成提出自己的看法。

2. Tempo系统架构

Tempo是一个具有很高模块化的软件，它以此来给开发人员提供最大限度的灵活性，开发人员可以根据自己的不同需求来替换或修改任何其中的模块。

从一个较高层次来看，Tempo可以分成三层结构，以top-down的方式主要有以下几个方面：

1) 终端用户用来管理他们的任务列表的用户接口（界面）。Tempo有两个模块提供最终用户接口：用户接口框架（User Interface Framework）和XForms管理器（XForms Manager）。

2) 管理任务生存周期的工作流逻辑。这部分是由一组WS-BPEL流程来实现的，叫做任务管理流程（Task Management Processes），这些流程可以一个Web Service接口来访问。

3) 负责以一个安全的方式，来负责持久化任务属性的持久化层。这部分是通过任务管理服务（Task Management Service），通过Web Service接口进行访问。

其他的组件提供了额外的/可选的功能，这些功能可以来完成Tempo与一个BPEL环境的集成工作以及Tempo的管理。

1) 安全框架是一个基于角色的访问控制框架（授权、认证、单点登录）。

2) 任务附件服务（Task Attachment Service）是一个接口，用来将附件存储到数据存储或者内容管理系统中。

3) 表单调度服务（Form Dispatcher Service）就像一个代理，它位于任务管理流程（Task Management Processes）和用户接口框架（User Interface Framework）之间。

4) 工作流部署服务（Workflow Deployment Service）提供一个接口来在工作流数据库中部署工作流组件，并且提供其他方法来访问这些组件。

最终，任务对象模型（Task Object Model）定义了任务的属性，它定义在一个通用包中，其他模块都可以重用该对象。

下图描述了这些模块是怎样一起协同工作的：

图 1 创建和完成一个完整任务

3. Tempo模块

该部分更细致的介绍上面提到的各个组件

3.1 XForms Manager（XFM）

XFM负责提供XForms的代码，并且提供与这些表单对应的工作流操作（workflow actions）。这些是通过User Interface Framework所调用的，当用户在自己的任务列表上点击相应任务时，便会发生对于XFM的调用，当然这些任务对应的表单就是一个XForms document。接着XFM调用TMS（Task Management Service）来取得对应的任务数据，并通过WPS（Workflow Deployment Service）取得XForms表单。当用户在其任务列表上选择一个任务时便会生成一个表单。XFM同样可以为工作流操作中添加工具，例如一个提交/完成一个任务的按钮，一个用来管理附件的工具等等。这个机制允许在不影响表单代码的前提下，添加新的操作。事实上，工作流操作是在Form Manager中进行编码的，而不是在表单中。表单开发人员可以专注于表单的开发而不需要担心工作流动作。而XFM只是处理XForms形式的表单以及用于这些表单上的工作流动作。尤其是，它不提供任务列表也不提供任何其他形式的表单。

XFM使用了Orbeon Presentation Server（http://www.orbeon.com/）来支持XForms。还需要了XPL语言用来实现工作流动作以及调用TMS（Task Management Service）和暴露为Web服务的BPEL流程。

XFM几乎可以以一个war包的形式部署在所有的J2EE应用服务器中，或者一个Servlet容器，像是Apache Geronimo（http://geronimo.apache.org/）。

3.2 User Interface Framework（UIFW）

用户接口框架（UIFW）是一个以web应用程序，用户通过它来访问工作流系统。它提供了一个登录界面和工作列表。当用户选择一个任务时，由它负责提供一个合适的表单管理器。在这一点上，UIFW仅仅支持XForms Manager，它是负责XForms 表单的，但是其他的管理其他类型表单的表单管理器可以plug in到系统中。表单管理器可以基于表单的URL来自动选择，表单URL是每一个任务的元属性。根据不同的表单URL，不同的表单管理器将被调用来生产相应的表单来支持所选择的任务。

UIFW使用了Spring框架来进行实现，同样也可以以一个WAR包的形式部署在几乎所有的J2EE应用服务器上，或者Servlet容器像是Apache Geronimo。

3.3 Task Management Processes（TMP）

任务管理流程（TMP）工作流任务的生存周期，从一个任务被创建的那一刻知道该任务完成。在这些流程中，它负责根据一定的规则和定义好的用户交互来变更任务的状态。TMP调用TMS（Task Management Service）以一种可靠的安全的方式来改变任务的状态。它提供一些服务来让用户执行工作流动作。同时在用到工作流活动的地方还与BPEL流程进行交互，这些都是通过Form Dispatcher Service来完成的。

TMP是用WS-BPEL2.0实现，它可以部署在几乎所有的WS-BPEL2.0引擎中，例如Apache ODE。

3.4 Task Management Service（TMS）

任务管理服务（TMS）将任务数据持久存储到底层数据库中，并且以一种安全的方式提供客户端程序访问和改变任务数据的服务。TMS被User Interface Framework用来去取得任务列表，XForms Manger用它来取得任务数据，还有TMP用它来改变任务状态。

TMS是使用Java实现的一个Axis2的服务，它可以部署在Apache Axis2中。

3.5 Security Framework（SFW）

安全框架给安全系统提供一个基于角色的访问控制接口，主要包括授权、认证和单点登录。它被User Interface Framework用来在用户login的时候鉴定用户身份，同时被Task Management Service用来给任何的TMS调用授权。对于该接口的不同实现可以加入到Tempo中，以此来集成不同的安全系统。Tempo提供了一个默认实现，使用XML文件来定义用户和角色。该框架同样支持从一个LDAP目录服务器中取得用户和角色组织结构。

SFW是用Java实现，以JAR包的方式部署。

3.6 Task Attachment Service（TAS）

TAS是一个将附件持久化地链接到任务的服务。它的API支持添加和删除附件（二进制文件）、还有一些描述和内容类型。

TAS是用Java-Servlet实现，以一个WAR文件部署。

3.7 Form Dispatcher Service（FDS）

FDS可以对用户流程的消息表示和任务管理流程的消息表示进行相互转换。有必要提供一个具体任务的创建/完成模式（schemas）给用户流程，同时给任务管理流程提供处理任何任务类型的能力。

FDS是用Java Servlet实现，部署为一个WAR文件。

3.8 工作流部署服务（WDS）

工作流部署服务允许设计时间和自动化工具来远程部署任务描述以及表单内容。WDS将存在的和可用的任务定义注册到Task Object Model持久化存储中。

WDS用Java Servlet实现，部署为一个WAR文件。

3.9 Task Object Model（TOM）

任务对象模型（TOM）是一个数据访问层，用来创建、查询和管理任务定义和任务实例。

TOM实现为一个Java library（jar文件）

如何创建和完成一个任务

1. 创建和完成一个任务的序列图

图 1 创建和完成任务序列图

上图中的缩写词意义：

1) UBP：User Business Process。它就是创建该任务的流程。一般情况下是一个BPEL流程，但是事实上它可以是任何形式的应用程序。它发起一个Web Service调用来创建一个任务，并且提供一个Web Service操作来完成该任务。

2) FDS：Form Dispatcher Service。它就像一个UBP和TMP之间的代理器。

3) TMP：Task Manager Process。BPEL流程负责管理任务的生存周期。它在接受来自FDS的createTaskRequest流程时被初始化。

4) TMS：Task Management Service。这是一个提供工作流动作，持久化任务到数据库还有处理安全事务的Web服务。

5) UI-FW：UI Framework。显示任务列表和转发表单的管理到表单管理器（XFM）。

6) XFM：XForms Manager。这是一个表单管理器的实现，XForms forms。

7) WDS：Workflow Deployment Service。管理表单的存储和访问。

注意：创建和完成一个任务是完成分开的。任务的ID被用来将createTaskResponse消息和notifyTaskCompletionRequest消息连接起来。这个ID是由TMP产生的。

2. 创建一个任务

创建任务是由对于FDS的一个Web服务调用启动的。接着FDS将这个请求转发给TMP，接下来TMP通过调用TMS来创建任务。

FDS是为了将“任何流程”都转化为“一个TMP”的关系而存在的，这一步是无法在BPEL中完成的。从TMP的角度来看，createTaskRequest的消息只能由一个特别定义的partnerLink发出。每一个不同的UBP就是一个不同的parterLink。为了解决这个问题，FDS设计为一个servlet可以处理any-to-one的关系，它通过接收所有发往/fds/workflow的createTaskRequest请求消息，并且动态的将命名空间转变成TMP所期望的一样，接下来将这些请求转发到TMP。

当TMP返回createTaskResponse消息时，它同样发送到/fds/workflow，当然会被FDS所截获，接着FDS改变它的命名空间到该请求的最初模样。命名空间可以在createTaskResponse消息中找到，它是由先前的createTaskRequest中映射过来的。这就是为什么在UBP中创建一个任务时必须做命名空间映射的原因。这个命名空间可以通过createTaskResponse消息传回到FDS中，因此FDS才可以创建这样的消息，这个消息是UBP实例所一直等待的。

3. 完成一个任务

当一个用户登录系统，或者刷新了任务列表，这时UI-FW将会向TMS发送一个调用来取得最新的任务列表。当用户点击一个任务，这个请求被转发到相应的表单管理器上。目前，UI-FW还只适用于XFM，但是这个可以扩展成为根据一个任务的属性动态选择一个表单管理器。接下来，XFM调用TMS来获得所有任务细节。它同时还调用WDS来取得实际的表单。基于这些所有信息，XFM生成一个表单，包括有它所需的输入数据，还有让用户完成任务的按钮或者任何其他的工作流动作XFM所支持的。

当用户点击完成按钮，XFM调用TMP去完成该任务。注意：在这里FDS不需要被调用，这个调用根据任务ID来进行关联。

接着，TMP通过调用TMS来改变任务的输出以及它的状态。

接下来，TMP通过FDS将任务输出转发到UBP。任务ID在这里做完任务的关联标识。

最终，TMP在接收到UBP的回应之后，向XFM发送结果。