工作流介绍
工作流介绍
工作流是针对工作中具有固定程序的常规活动而提出的一个概念,通过将工作活动分解定义良好的任务、过程、角色和规则来进行执行和监控,达到提高生产组织水平和工作效率的目的,工作流技术为企业更好地实现经营目标提供了先进的手段。
[@more@]
工作流介绍
1 背景
什么是工作流?
工作流是针对工作中具有固定程序的常规活动而提出的一个概念,通过将工作活动分解定义良好的任务、过程、角色和规则来进行执行和监控,达到提高生产组织水平和工作效率的目的,工作流技术为企业更好地实现经营目标提供了先进的手段。
工作流发展的历程
工作流(Workflow)的概念是在现代信息系统的建设中逐步形成的,它有一个从局部到整体、从初级到高级、从简单到复杂的发展过程,按其发展历程,我们一般把它分为三个阶段:
最初的工作流系统主要以企业内部的文档处理为主,这一阶段的典型特征是工作流系统不是作为一个独立的平台进行应用,而是将其思想运用到具体的应用系统中,尤其是文档的传递与处理。
第二阶段的发展标志是IBM的Domino notes产品的出现,极大地推动了工作流的成熟和应用,在文档的传输和处理中得到了非常成功的应用,这一阶段的主要特征是工作流系统作为一个平台以群件的形式运用于文档处理中,产品本身有自己独特的体系结构和基础的通信技术。
直到现在,由于计算机网络技术和internet技术的迅速发展,随着企业业务过程的规范化和内部效益的不断提高的需要,工作流技术发展到了第三个阶段 业务过程管理(BPM)阶段,和第二阶段的最大不同主要表现在:应用范围不同,业务过程管理不仅仅能够管理文档,而且能够管理各类业务过程,其应用范围将更加宽广;功能不同,业务过程管理包括业务过程的设计、分析、评测、仿真、运行和管理,可以管理流程、人和其它资源之间的关系,整合公司内外部的资源,监视整个流程的进行,不只是文档处理界面的设计与处理。
工作流参考模型
工作流是业务过程的计算模型,即将相应的业务逻辑和业务规则在计算机中以恰当的模型进行表示并对其实施计算。业务过程是若干业务活动的集合,这些业务活动按照一定的规则前后链接在一起,相互协作,以便达到一个共同的目标。业务活动则是能够完成特定的功能的一个实际环节,它在信息系统中通常针对具体的应用逻辑。为了对工作流管理系统的开发起到一个指导作用,工作流管理联盟(WfMC)给出了工作流系统的一个通用框架――工作流参考模型。在工作流参考模型中,工作流引擎是工作流管理系统的核心。工作流引擎是为工作流管理系统在定义提供支持、同时在运行时提供解释和执行服务的一组数据模型和软件。
WfMC的Workflow Reference Model Diagram
Working Groups |
Objectives |
Reference Model & Glossary |
Specify a framework for workflow systems, identifying their characteristics, functions and interfaces. Development of standard terminology for workflow systems. |
Process Definition Tools Interface (1) |
Definition of a standard interface between process definition and modeling tools and the work flow engine(s). |
Workflow Client Application Interface (2) |
Definition of APIs for client applications to request services from the workflow engine to control the progression of processes, activities and work-items. |
Invoked Application Interface (3) |
A standard interface definition of APIs to allow the workflow engine to invoke a variety of applications, through common agent software. |
Workflow Interoperability Interface (4) |
Definition of workflow interoperability models and the corresponding standards to |
Administration & Monitoring Tools Interface (5) |
The definition of monitoring and control functions. |
Conformance |
To develop the Coalition's policy on product conformance against its specifications and agree an approach to vendor certification. |
工作流管理联盟(WfMC)
1993年,国际工作流管理联盟(Workflow Management Coalition, WfMC)的成立标志着工作流技术开始进入相对成熟的阶段。为了实现不同工作流产品之间的互操作,WfMC在工作流管理系统的相关术语、体系结构及应用编程接口等方面制定了一系列标准,工作流管理联盟给出的工作流定义是:工作流是指整个或部分经营过程在计算机支持下的全自动或半自动化,在实际情况中可以更广泛地把凡是由计算机软件系统(工作流管理系统)控制其执行的过程都称为工作流。 一个工作流包括一组活动及它们的相互顺序关系,还包括过程及活动的启动和终止条件,以及对每个活动的描述。工作流管理系统指运行在一个或多个工作流引擎上用于定义、实现和管理工作流运行的一套软件系统,它与工作流执行者(人、应用)交互,推进工作流实例的执行,并监控工作流的运行状态。
网址:http://www.wfmc.org/
工作流引擎结构
工作流引擎主要包括数据模型和控制模型。
2 工作流技术标准简介
2.1 引擎标准:基于纯XML技术
﹡ XPDL(Xml Process Definition Language)
在工作流领域第一个致力于标准化工作的是Workflow Management Coalition (WfMC),它成立于1993年。1994年11月,wfmc发布了工作流管理系统的参考模型。参考模型提出了五类接口,有关过程模型的定义则构成了接口一的核心内容。接口一早期的标准为WPDL(Workflow Process Definition Language),后来,这一接口的规范变更为XPDL。XPDL是至今工作流领域最为重要的一个标准,目前大多数工作流引擎是依据该标准设计开发的。
﹡ BPML(Business Process Model Language)
WfMC和BPMI在2002年6月26日宣布将合作制定业务流程和工作流标准,即采用BPML来描述工作流过程,同时采用XPDL所定义的工作流模型。
﹡ OMG的Workflow Management Facility
OMG在其他领域也做的有声有色。OMG的Workflow Management Facility联合XPDL的WfMC规范,定义如何将工作流向CORBA转换---要知道, CORBA可是OMG的强项。
2.2 引擎标准:基于Web服务技术
﹡ WSCI
2002年6月26日,BEA,Intalio,SAP,Sun四家公司提出了基于xml的WSCI规范,推动Web服务进入了一个全新的阶段。这个规范主要描述了一个参与和其它服务进行协作交互的Web服务所交换的消息流。WSCI是第一个基于Web服务技术的规范。
其他的如WSFL(属IBM),Xlang(属MS),因有天生缺陷,均没有很大起色。
﹡ ebXML
ebXML是一组支持模块化电子商务框架的规范。ebXML支持一个全球化的电子市场,它使得任意规模的企业通过交换基于XML的信息,不受地域限制地接洽和处理生意。ebXML是联合国(UN/CEFACT,贸易促进和电子商务中心)和OASIS(结构化信息标准发展组织)共同倡导、全球参与开发和使用的规范。
﹡ BPEL
2002年8月9日,Microsoft, BEA, IBM, SAP & Siebel联合提交发布了BPEL规范。 BPEL统合了各种技术( XLANG, WSFL, BPML)。此规范描述如何处理输入的消息,它不是一个关于业务流程规格化定义的规范。简单的说,可以将它看作XML形式的编程语言,提供将WSDL-Services组合成控制流的能力。顾名思义,此规范重点在(也不只限于)Web Service。还有其它如RosettaNet等,因为适用范围很小,这里也不多说了。
2.3 开源引擎:
2.3.1 基于XML技术的开源引擎:
﹡ OFBiz
OFBiz最主要的特点是OFBiz提供了一整套的开发基于Java的web应用程序的组件和工具。其中包括实体引擎, 服务引擎, 消息引擎, 工作流引擎, 规则引擎等。OFBiz先前的工作流引擎基于WfMC和OMG的规范,使用XPDL作为流程定义语言,也就是说。 OFBiz新版的工作流引擎采用Shark工作流引擎,已经不再使用OFBiz自身的工作流引擎。
﹡ OBE
OBE 是由Adrian Price主持开发的一个开放源码的Java工作流引擎,支持WfMC规范,包括接口1(XPDL)、接口2/3(WAPI)和接口5。OBE主要基于J2EE实现。OBE的接口1实现得非常好,可惜,OBE的载体公司Zaplet已经于前不久被合并,合并后的公司没有继续发展OBE的打算。Adrian Price离开了原来的公司,投奔我们前面说过的大户Versata。Versata也不打算继续OBE。OBE至今没有release版,很是可惜。
﹡ Shark
Shark是完全根据WFMC规范实施的,可扩展功能的工作流引擎,它利用xpdl来定义流程,同时还包括服务器端的用于活动节点执行的WFMC工具代理API。Shark中的每个组件例如持久层,事物管理器,脚本引擎,流程库,都是可以按照标准实施运用的,而且还可以被具体项目的模块扩展和替换。Shark和XPDL定义工具的事实标准JAWE同出名门,市场前景被很多人看好。OFBiz新版的工作流引擎采用Shark工作流引擎,OBE的载体公司Zaplet被合并,对Shark的发展将很有利。2004年9月9日,shark发布1.0版本,对它的发展无疑是一剂强心针。
2.3.2 基于Web 服务技术的开源引擎:
﹡ OpenebXML
OpenebXML项目致力于提供一个ebXML框架,主要支持 UN/CEFACT和OASIS发布的ebXML规范2.0版。
﹡ Bonita
Bonita是一个符合WfMC规范、灵活的协同工作流系统。Bonita基于浏览器、使用SOAP和XML数据绑定技术的Web Services封装了已有的工作流业务方法并将它们以基于J2EE的Web Service形式发布。
﹡ Twister
Twister的目标是提供新一代、易集成、应用Java领域中最新成果、面向B2B的工作流解决方案。流程引擎基于BPEL业务流程规范和Web Service标准。
﹡ ActiveBpel
ActiveBPEL引擎是一个于今年7月发布的健壮的运行时环境,它能执行用户按BPWL4WS规范编写的业务流程。ActiveBPEL引擎由Active Endpoints公司开发和维护,该公司同时在它的多个商业产品中使用了该技术。本人将密切观注ActiveBPEL引擎的技术发展和产品状态。
2.3.3 基于其他技术的开源引擎:
﹡ OSWorkflow
OSWorkflow的最大特点是灵活
﹡ OpenWFE
OpenWFE是一个开放源码的Java工作流引擎。 它的思想来源于 Scheme,包括可升级的三个组件:引擎、工作列表和Web界面。
﹡jBpm
jBpm是tom baeyens编写的一个灵活可扩展的工作流管理系统。jBmp将工作流应用开发的便利性和杰出的企业应用集成(EAI)能力结合了起来。jBmp包括一个Web应用程序和一个日程安排程序。jBmp是一组J2SE组件,可以作为J2EE应用集群部署。国内目前有部分人研究jBpm。
3 各种不同的工作流产品
目前工作流产品有很多,可以参考附件。这里基本列出一些。
3.1 国外产品
﹡ BEA 的WLI
﹡ Fujitsu的 i-Flow
﹡ IBM的 Holosofx
﹡ SAP 的NetWeaver
﹡ Sonic 的Orchestration Server
﹡ http://www.ultimus.com.cn/products/modules/
﹡ Versata
﹡ w4 workflow
﹡ staffware
﹡ Adobe Workflow Server的前身是JetForm公司的InTempo。JetForm改名为Accelio后不久就被Adobe收购了。
﹡ COSA
﹡ Visual Workflow
﹡ Verve Workflow
﹡ InConcert
﹡ Changengine
﹡ 微软的Workflow Designer for Exchange
3.2 国内产品
﹡ 信雅达的SunFlow
﹡ 西安协同的协同工作流
﹡ 上海东兰的DLFlo
﹡ 明基工作流
﹡ joinwork
﹡ LinkeyWorkflow5.0
﹡ 北京有生博大
﹡ 北京东方易维
﹡ 中唐软件
﹡ 北京盛松科技
﹡ 北京美髯公科技
﹡ 北京华电园
﹡ 深圳中衡
﹡ 广州京华
﹡ 北京东方通
﹡ 北京万维易化
﹡ 华炎软件
﹡ 吉大正元
﹡ E3工作流
﹡ 北京朗川
﹡ 北京炎黄盈动
﹡ 京华网络
﹡ 华创软件
﹡ 四川金科成
﹡ 普元EOS
﹡ 世纪金政
﹡ 浙大网新兰德科技股份有限公司
﹡ 上海泛微
﹡ 浪潮LOUSHANG工作流
﹡ 清华同方eBuilder工作流
﹡ 博深ebpm
3.3 开源产品
﹡ Ofbiz
﹡ obe
﹡ JBpm
﹡ OsWorkFlow
﹡ Enhydra Shark
﹡ Bonita
4 工作流引擎杰介绍
工作流引擎分为控制模型和数据模型,控制模型是工作流引擎的控制中心。本节简单的描述了一个基于WfMC的工作流实现。
4.1 应用框架
下图是基于WfMC的一个简单的工作流引擎实现的框架结构。
可视化建模工具流程逻辑应用逻辑流程逻辑应用逻辑流程逻辑应用逻辑工作流引擎(各种协议) D B M S 机构模型信息模型日志信息应用数据引擎控制器 C/C++接口 Java接口
应用框架
如图所示,“可视化建模工具”即采用一套恰当的图示化的工具来对业务过程进行描述,然后将其转换成如机构模型和信息模型中所述及的关系结构,从而建立起工作流引擎的数据模型。因此,“可视化建模工具”是工作流引擎在构造时的定义中心,而“引擎控制器”则是工作流引擎在运行时的控制中心,它负责工作流引擎在运行时的协调、调度和控制功能。根据具体应用的开发环境的不同,工作流引擎在应用框架中为不同类型的应用提供了不同的接口,例如C/C++接口、Java接口以及直接基于数据库通信协议的接口,从而为不同类型的应用与工作流引擎的交互提供了方便。应用框架中的“应用数据”则由具体的应用逻辑自行管理,工作流引擎并不关心这部分的数据格式。
任务队列已完成任务队列日志信息调度中心任务管理任务指派转发控制依赖检查启动控制信息模型外部接口
引擎控制器结构图
4.2 控制模型
4.2.1 工作流引擎是控制中心
引擎控制器是工作流引擎在运行时的控制中心,引擎控制器结构图给出了引擎控制器的控制结构图。
l 调度中心
调度中心接受从外部接口发送过来有关流程控制的请求(如业务初始化、获取任务以及结束任务等),然后根据不同的请求类型调用相应的处理模块完成与本次请求相关的操作并将结果返回。也可以需要诸如请求队列等形式的数据结构。因此,事实上可以将调度中心看成一个多线程的并发服务器,它可以对多个外部请求提供并发服务。对外部请求的处理过程中肯定会涉及到对内部数据结构(即工作流引擎的数据模型),由引擎来实现了多个外部请求之间的独立性。
l 任务管理
任务管理主要根据调度中心的指示完成诸如任务创建、任务状态的转换以及相关数据的维护等工作。每次“结束任务”的外部请求将触发调度中心调用“任务管理”为后继活动(如果存在的话)创建新的实例,其状态为“Pending”;同时,其他不同的外部请求也将触发“任务管理”实施任务状态的切换。任务状态转换图如图4所示。
初态 Pending Waiting Processing Pausing 终态创建任务同步完成获取任务结束任务挂起复位汇聚同步
图4 任务状态转换图
l 任务指派
任务指派处理只是针对常规交互活动,通常情况下,在任务状态由“Pending”切换到“Waiting”过程中完成任务的指派工作。任务指派过程首先根据任务指派基准确定可以执行此任务的群体人员,通常情况下这是一个包含多个人员的集合;然后根据任务指派方法确定由这个群体中的哪些个体来执行任务。
l 依赖检查
依赖检查指的是活动的前依赖规则的检查,调度中心在将任务切换到就绪状态之前将进行相关的前依赖规则检查,只有满足检查条件的任务才可以进行状态的切换。当前活动的启动没有其他约束条件,相应任务可以立即由“Pending”状态转换到“Waiting”状态。
对于“与”汇聚前依赖规则,指明所有参与与汇聚的其他前趋活动,只有所有相关的前趋活动均到达各自指定的结束状态,当前活动方可启动。
对于“或”汇聚前依赖规则,此规则的检查将涉及到首先结束的前趋活动将启动当前活动,后结束的活动将被丢弃。
l 转发控制
当应用发出“结束任务”的外部请求时,该请求将触发调度中心启动“转发控制”。
对于顺序转发以及或分支转发规则,只包含一个活动;对于与分支转发规则,则中将包含多个活动。
l 启动控制
启动控制负责常规自动活动的所对应的自动执行体的启动并对其活动进行监控。
4.2.2 工作流引擎的核心调度算法
FSM(有限状态机)
l FSM的定义为包含一组状态集(states)、一个起始状态(start state)、一组输入符号集(alphabet)、一个映射输入符号和当前状态到下一状态的转换函数(transition function)的计算模型。当输入符号串,模型随即进入起始状态。它要改变到新的状态,依赖于转换函数。在有限状态机中,会有有许多变量,例如,状态机有很多与动作(actions)转换(Mealy机)或状态(摩尔机)关联的动作,多重起始状态,基于没有输入符号的转换,或者指定符号和状态(非定有限状态机)的多个转换,指派给接收状态(识别者)的一个或多个状态,等等。
l 遵循FSM流程引擎通过状态的切换来完成流程的流转。
PetriNet
l 信息流的一个抽象的、形式的模型。指出一系统的静态和动态性质。petrinet通常表示成图。图中有两类用弧彼此相连的结点(称为地点和变换)和指示其动态性能的标记(称为记号)。
l 遵循PetriNet流程引擎通过令牌来决定流程的流转。
4.3 数据模型
通过数据模型,可以方便地描述关键业务的业务规则、活动的依赖关系以及任务的指派等特征。它们都通过统一的关系结构来定义。
数据模型的核心是业务活动(简称活动)ACTIVITY,和过程PROCESS、业务规则(活动流转规则)ROUTING_RULE、活动前依赖规则PRE_RULE、任务指派规则ASSGN_RULE、任务列表TO_DO_TASK_LIST以及已完成的任务列表HAVE_DONE_TASKS。
4.3.1 常见活动类型
每个业务过程由若干业务活动组成,活动类型可以进行如下分类:
l INITIAL,初始化活动,业务过程的第一个活动,不针对具体业务环节。
l INTERACTION,常规交互活动,INTERACTION活动对应实际的业务环节,在前台对应实际的应用逻辑,完成此活动需要实际人员的参与。在所有活动类型中,只有INTERACTION活动才需要与实际人员交互。
l AUTOMATION,常规自动活动,同样对应实际的业务环节,但是实际的应用逻辑位于后台,由工作流引擎自动调用完成。AUTO_EXECUTIVE指明相应应用逻辑的执行体。
l AND_BRANCH,与分支活动,不针对具体业务环节,此活动将同时派生出若干后继活动。
l AND_MERGE,与汇聚活动,是一同步活动,不针对具体业务环节,流经此处的任务将进行与汇聚同步。此活动将进行活动的前依赖规则检查,只有所有的前依赖规则均被满足,才可流向后继活动。
l OR_MERGE,或汇聚活动,是一同步活动,不针对具体业务环节,流经此处的任务将进行或汇聚同步。它同样将进行活动的前依赖规则检查,但是在前依赖规则只要存在一条满足指定条件的,就可以流向后继活动。OR_MERGE_FLAG用于指定或汇聚条件。
l VOTE_MERGE,投票汇聚活动,是一同步活动,不针对具体业务环节,同一批次的任务只有达到NUM_VOTES_NEEDED所指定的票数才可流向后继活动。
l DUMMY,哑活动,不针对具体业务环节,它可以作为某些活动的虚拟后继活动,还可以使用它来构造更为复杂的业务规则。若哑活动有后继活动,则可以立即流向后继活动。
l COMPLETION,终结活动,表明相应业务过程的终结,不针对具体业务环节。
4.3.2 任务队列和已完成任务队列
一个活动可以同时具有多个实例,即任务,这些实例可以是属于同一批次的,也可能属于不同的批次,
工作流引擎中必须提供一种手段将任务与应用实体有机地关联起来,否则,单独的任务将不具有任何实际意义。其取值的真实含义完全取决于应用逻辑的自身解释,例如它可以是某个编号,也可以是某个文件的名字。其值也可以在业务流转过程中被随时改变。
任务队列TO_DO_TASK_LIST用于记录那些已经创建但尚未完成的任务,位于任务队列中的任务具有四种状态:(1)PENDING,任务正处于“与汇聚”同步状态,即正在等待其他相关的前趋任务的结束;(2)WAITING,任务已经就绪,处于“等待处理”的状态;(3)PROCESSING,任务处于“正在处理”的状态;(4)PAUSING,任务处于“暂停”的状态。
已完成任务队列HAVE_DONE_TASKS用于记录那些已经正常结束的任务,COMPLETION_FLAG表示相应任务的结束标记。
已完成任务队列记录那些已经完成的任务。
4.3.3 日志信息
存放各种操作的日志纪录。
5 关于工作流图形化设计器
工作流目前已经发展到BPM (Business Process Management) 的阶段。
5.1 国外产品
5.1.1 Ultimus产品
Ultimus是国外的一款比较出色的Workflow产品。以国外比较出色的产品 Ultimus为例。
图形化的设计器只是此产品的一个组件
对于他的图形化设计器(Designer),通过鼠标的点击、拖拽即可完成流程的定义
(2) 支持人工参与的进度安排和系统自动调用的进度安排
(3) 可定义工作顺序、支持并发、条件选择、同步、合并等业务路由
(4) 支持流程参数的定义,完成活动之间的信息传递
(5) 可以进行业务条件规则的定义
(6) 事件的超时检查、错误通知、定时启动
(7) 支持工作流程中任务的任意跳转
(8) 用户管理:支持用户、组织、角色、级别的建立,也可通过LDAP挂接
(9) 灵活的执行人的动态分配模式
下图是它的web浏览方式。