Research on integration of workflow system and esb system

Transactions on Computer Science and Technology June 2014, Volume 3, Issue 2, PP.81-85

Research on Integration of Workflow System and ESB System Chuan Zhang #, Yanping Yang, Jiangjiang Wu, Yuehua Wang, Jun Li School of Electronic Science and Engineering, National University of Defense Technology, Changsha 410073, China #

Email: 15802536434@163.com

Abstract Introduced the relevant knowledge of workflow system and ESB system, discussed the necessity of integration between workflow system and ESB system from two perspectives: perspective of improving workflow flexibility and perspective of system integration. Based on the trigger relation between workflow system and ESB system, two typical scenarios of system integration are analysed. Selected the open source workflow and ESB system: Activiti and Mule ESB, listed the deployment process of two engines of systems, implemented the integration of Activiti and Mule ESB in an example of a specific business application, demonstrated the scenarios of system integration. Finally, the existent problems of two scenarios of system integration are listed and the potential research direction is pointed out.

Keywords: Workflow; ESB; System Integration

工作流与ESB系统集成研究 张川，杨艳萍，伍江江，王跃华，李军 国防科学技术大学 电子科学与工程学院，湖南 长沙 410073 摘 要：介绍工作流系统和ESB系统的相关知识，从提高工作流灵活性和系统集成两个角度论述了工作流系统和ESB系统 集成的必要性。根据工作流系统和ESB系统触发的先后关系，分析总结出了两种典型的系统集成场景。选取开源工作流 系统和ESB系统：Activiti和Mule ESB，给出二者引擎的部署过程，以某个具体的业务应用为例，通过实现Activiti和Mule ESB的集成，演示验证了两种系统集成场景。最后指出两种系统集成场景还存在的问题以及今后的研究方向。 关键字：工作流；ESB；系统集成

引言 随着企业和组织信息化应用水平的不断提高，在各个信息系统之间实现集成的需求变得越来越强烈。 其中，以工作流系统为核心的集成模式，以其灵活性、可配置和对业务的高度抽象能力等优点逐渐得到企 业和组织的广泛认可。工作流（Workflow）是指“业务过程的部分或整体在计算机应用环境下的自动化”， 它主要解决的是“使在多个参与者之间按照某种预定义的规则传递文档，信息或任务的过程自动进行，从 而实现某个预期的业务目标”[1] 。工作流系统是一个用来定义、管理和执行工作流的软件系统。 ESB （Enterprise Service Bus，企业服务总线）的概念从 SOA（Service Oriented Architecture，面向服务体系架构） 发展而来，它是传统中间件技术与 XML、Web 服务等技术结合的产物。ESB 提供可靠消息传输、服务接入、 协议转换、数据格式转换，基于内容的路由等功能，屏蔽了服务的物理位置、协议和数据格式[2]。ESB 系统 是一个实现了 ESB 技术的软件系统。 一方面，通过引入 ESB 技术，工作流能够更方便地访问外部应用，从而提高其灵活性。另一方面，从 

基金资助：受国家自然科学基金“适应动态拓扑结构的卫星协同任务规划技术研究”支持资助（61174159） - 81 http://www.ivypub.org/cst

系统集成的角度来说，SOA 的提出很大程度上是为了满足企业和组织应用集成的需求，而作为 SOA 架构的 基础设施，ESB 以“软总线”的方式并行挂接多个服务或应用程序[3]，单个服务的修改或增加取消挂接无须 影响到其他服务或应用程序，从而提高集成的灵活性和可配置性。综上所述，无论是从提高工作流系统灵 活性的角度，还是从系统集成的角度，研究工作流和 ESB 系统的集成都是十分必要的。现有的研究中，文 献[4]研究了一种基于构件技术的工作流集成框架，文献[5]设计了一个基于 Web Service 的工作流管理系统， 而作为实施 SOA 的重要技术，将 ESB 技术和工作流结合的研究还很少。

1

集成场景 本节从工作流系统和 ESB 系统的触发关系出发，分析了两种系统集成场景。

1.1 场景一：工作流系统触发 ESB 系统 该场景下，工作流系统需要在运行的过程中用到 ESB 的集成功能，因而是工作流系统对 ESB 系统的 “触发”。工作流本身具备一定的业务集成功能，比如能够通过特定的任务组件调用特定的外部应用，但 就其技术特点而言，工作流更加侧重于对业务的编排，当需要和多个复杂的外部应用交互时，就必须在工 作流系统中额外地实现对应各个外部应用的集成逻辑。而正如前面所介绍，ESB 更加侧重于实现系统的集 成，通过引入 ESB，工作流所需的集成逻辑可交由 ESB 来完成。 工作流管理平台 启动

任务1

结束

任务2

6

3

ESB集成平台 1

2 4

外部应用1

5

外部应用2

图 1 工作流系统触发 ESB 系统的集成场景

图 1 为工作流系统“触发”ESB 系统的集成场景，图中上层为工作流系统的管理平台，提供流程建模、 流程驱动、流程监控等工作流系统的基本功能。如图所示，工作流管理平台中有某个运行着的流程实例， 两端分别为“启动”和“结束”节点，中间有两个任务节点：“任务 1”和“任务 2”。流程启动后，首先 运行到“任务 1”节点，该节点利用工作流系统本身的集成功能调用了一个简单的外部应用“外部应用 1”， ①和②分别表示“任务 1”向“外部应用 1”发出以及“外部应用 1”反馈给“任务 1”的消息。接着流程 运行到“任务 2”节点，此时该节点无法通过工作流系统本身的集成功能调用“外部应用 2”，前面已经提 到，需要引入 ESB 系统来实现集成功能。 “任务 2”节点发送调用消息③给 ESB 系统的集成平台，ESB 中运行的消息流会对接收的消息进行诸 如格式转换、协议转换、消息路由等一系列的处理操作，使得处理后的消息和对应的“外部应用 2”相匹配， 并通过 ESB 中的核心组件（图中实心矩形）完成“外部应用 2”的调用。“外部应用 2”反馈的消息⑤则再 次经过 ESB 中消息流的处理，然后反馈工作流能够识别的消息⑥给“任务 2”节点，接着流程运行至“结 束”节点。 场景一中，工作流系统通过引入 ESB 系统，能够灵活地集成任意的外部应用，而不依赖于实现外部应 用的具体技术，以松耦合的形式实现了系统的集成，体现了 SOA 的思想。同时，在该场景下，工作流系统 - 82 http://www.ivypub.org/cst

也变得更加灵活，对于业务变化能够快速、有效地进行响应。

1.2 场景二：ESB 系统“触发”工作流系统 ESB集成平台 外部消息

1

2

3

工作流管理平台

结束

启动

图 2 ESB 系统触发工作流系统的集成场景

该场景下，ESB 系统中的消息流需要在运行的过程中启动工作流系统中的流程实例，因而是 ESB 系统 对工作流系统的“触发”。 一方面，业务流程的启动往往需要来自外部消息的触发，而工作流本身不具备读取复杂消息的能力， 借助于 ESB 的消息处理机制，能够很好地弥补工作流的这一不足。如图 2 所示，ESB 系统“触发”工作流 系统的集成场景中，ESB 集成平台提供相应的消息通道接收发送过来的“外部消息”①，接收到的消息经 过 ESB 消息流的处理后，消息流上的核心组件向业务流程中的“启动”节点发送消息②，接收到消息的 “启动”节点随即启动一个流程实例，与此同时还向 ESB 发送反馈消息③。另一方面，ESB 消息流在运行 过程中可能需要引入人工操作，而工作流的一个显著特点就是能够将人纳入系统，因此通过“触发”工作 流系统，ESB 系统得以引入人工操作，其“触发”机制同上一个方面类似。 场景二中，ESB 系统可以看成是工作流系统的消息接收器，即接收处理并转发用以启动工作流系统的 外部消息，同时，工作流的引入也让 ESB 中的消息流有了人工的干预，增加了 ESB 系统的扩展性。接下来 将选取开源的工作流和 ESB 系统，演示验证上述两种系统集成场景。

2

集成实现 选取开源的工作流和 ESB 系统 Activiti 和 Mule ESB，分析了两种系统的部署过程，以“订单处理”应

用为例，结合上节提出的两种系统集成场景，实现了 Activiti 和 Mule ESB 的集成。

2.1 系统部署 具体到实现层面上，工作流系统中的业务流和 ESB 系统中的消息流是由引擎来驱动的。从 Activiti 引擎 和 Mule ESB 引擎的部署关系出发，可以将二者的集成归纳为两种不同的模式：一种是“嵌入式”，即将 Activiti 引擎和 Mule ESB 引擎以依赖的形式注入到同一个 Spring 配置文件中，这样两个引擎都在同一个 JVM（Java 虚拟机）上运行，两者可以直接相互访问；另一种是“远程式”，即 Activiti 引擎和 Mule ESB 引擎分别在两个独立的容器中运行，即不同的 JVM 上，Mule ESB 可以通过 Activiti 提供的 REST API 访问 Activiti，而 Activiti 则通过 Web Service 向 Mule ESB 发送消息。 本文采用的是第一种“嵌入式”集成模式，其部署过程归纳如下： (1) 导入所需的Jar包 在实现 Activiti 和 Mule ESB 集成的过程中，利用已有的 Java 技术，导入了两个关键的 Jar 包：activitymule.jar 和 mule-module-activiti.jar。前者提供了将 Mule ESB 集成功能加至 Activiti 所需的 Java 类，后者提供 - 83 http://www.ivypub.org/cst

了 Mule ESB 运行环境对 Activiti 支持所需的 Java 类。 (2) 配置集成环境 为使二者能够在运行的过程中互相访问，还要对集成环境进行相应的配置。 首先，需要在 Activiti 配置文件 activiti-application-context.xml 中以 Spring bean 的形式定义 Activiti，简 化的配置文件如下： <bean id=”processEngineConfiguration” class=”org.activiti.spring.SpringProcessEngineConfiguration”> </bean> 然后，在 Mule ESB 的配置文件 mule-project.xml 中，以 Spring bean 的形式注入上面定义的 Activiti 配置 文件： <Spring: beans> <spring: import Resource="activiti-application-context.xml" /> </spring: beans> 最后，还要在 Mule ESB 中定义和 Activiti 有关的外部连接器 Activiti Connector（Activiti 也作为 Mule 的 一个外部应用），使得 Mule ESB 得以支持 Activiti 运行时的各个服务，配置如下： <activiti: connector name="actServer" repositoryService-ref="repositoryService" RuntimeService-ref="runtimeService" TaskService-ref="taskService" HistoryService-ref="historyService" /> 以上对 Activiti 和 Mule ESB“嵌入式”集成模式的部署过程进行了介绍，通过完成以上步骤，Activiti 能够直接利用 Mule ESB 的集成功能，而 Mule ESB 运行环境也提供了对 Activiti 的支持。

2.2 例子描述 “订单处理”的业务过程如图 3 所示，上层的 Activiti 系统中运行着“订单处理”的业务流程实例；中 间层的 Mule ESB 系统中运行着三个消息流：一个用于接收并处理外部消息，两个用于处理业务流程的调用 消息；下层是现存的能够完成一定业务逻辑的外部应用。 Activiti 未通过 通过

Mule ESB HTTP消息

消息流1 消息流2

消息流3

收费服务

订单数据库

图 3 “订单处理”业务过程图

首先，客户通过网页向商家发送请求下单的 HTTP 消息，运行在 Mule ESB 中的消息流 1 接收并处理该 - 84 http://www.ivypub.org/cst

消息，随后向 Activiti 中“订单处理”流程的启动节点发送消息，后者启动一个“订单处理”的流程实例。 启动后，流程首先运行至“信用审核”任务节点，在该任务，商家对客户的信用信息进行审核，如果审核 未通过，流程直接跳转至“结束”节点；审核通过，则流程运行至“订单收费”任务节点，该任务通过 Mule ESB 中的消息流 2 调用现存的“收费服务”应用，任务完成后，流程运行至“订单入库”任务节点， 该任务通过 Mule ESB 中的消息流 3 连接“订单数据库”并将生成的订单写入数据库，流程结束。

3

结论和展望 本文从工作流系统和 ESB 系统的触发关系出发，分析了两种集成场景，介绍了场景中业务流和消息流

的流转过程。选取开源的工作流和 ESB 系统 Activiti 和 Mule ESB，以“订单处理”业务为应用背景，参照 所提出的集成场景，实现了 Activiti 和 Mule ESB 的集成。 但是，本文只是分析了单一工作流系统和 ESB 系统的集成场景和实现技术，实际的应用集成可能会很 复杂，需要多个分布在不同位置的工作流系统和 ESB 系统配合来完成集成的工作。多个工作流系统和 ESB 系统的集成场景及相应的技术问题，将在未来的工作中加以解决。

REFERENCES [1]

Workflow Management Coalition, The Workflow Reference Model Document Number WfMC-TC-1003,19-Jan-95,1.1,Workflow Management Coalition(1995)

[2]

IBM, Patterns: Implementing an SOA Using an Enterprise Service Bus.2004-7. http://www.redbooks.ib m.com/abstracts/ sg246346.html

[3]

Jun Peng,Huai Cai. Research on Workflow Management System Architecture Based on BPEL and ESB[J],JISUANJI YU XIANDAIHUA, 2008(8): 25-28

[4]

YingBo Liu, Li Zhang, YaHui Lu. Component based open workflow integration framework[J]. Computer Integrated Manufacturing Systems.2007(7) 50-54

[5]

HongXu, Qian Wang. Research and Implementation of Web Service based Workflow Management System

【作者简介】 1

2

方向：遥感与地理空间信息集成。

程。Email: ypyang1980@gmail.com

Email: 15802536434@163.com

3

张川（1989-），男，汉族，硕士，研究

杨艳萍（1980-），女，汉族，博士后，研究方向：软件工

伍江江（1982-），男，汉族，博士，研究方向：智能优化

及任务规划。Email: jiang_wu_820@sina.com 4

李军（1973-），男，汉族，博士，研究方向：三维地理信

息系统技术。Email: junli@nudt.edu.cn 5

王跃华（1989-），男，汉族，博士，研究方向：遥感与地

理空间信息集成。Email: 631959321@qq.com

- 85 http://www.ivypub.org/cst