基于WWF的工作流引擎实现文档格式.docx
- 文档编号:17280653
- 上传时间:2022-11-30
- 格式:DOCX
- 页数:6
- 大小:20.66KB
基于WWF的工作流引擎实现文档格式.docx
《基于WWF的工作流引擎实现文档格式.docx》由会员分享,可在线阅读,更多相关《基于WWF的工作流引擎实现文档格式.docx(6页珍藏版)》请在冰豆网上搜索。
另外由于工作流引擎部分开发难度高,自行开发难度大,给工作流引擎的应用带来了困难。
微软最新发布的WWF工作流引擎,不失为一种方便、低成本的工作流引擎实现途径。
1WWF和现有工作流产品在应用范围上的区别
为什么很多人感觉WWF和自己以前接触过的工作流产品大不相同,用起来比较麻烦,主要是因为现有的工作流产品和大多数我们的应用都面向的是企业应用;
而WWF的应用范围要广得多,从工业控制、企业应用到商业应用等等,它实现的是所有种类工作流应用的一个子集,比如工业控制中的工作流就不需要企业应用中所必须的组织结构和角色管理等,但它们流程逻辑却可能一样复杂。
WWF是工作流领域的一个划时代产品,它解决了工作流应用中难度最高的引擎部分,并且可以应用于几乎所有的工作流应用领域。
相对引擎而言,构建于WWF之上的应用的设计开发难度大大较低,只需要较少的投入就可以实现很好的工作流产品。
2使用WWF技术实现工作流的原因
2.1开发工作流引擎的难度太高
很多人说WWF用起来这么麻烦,还不如自己做呢!
笔者想可能是因为这些人还没有遇到复杂的需求,或者对工作流引擎的难度认识还不够吧。
笔者见过3家公司开发自己的工作流产品,每家开发的原因都各不相同,其中一家还投入了数百万,但无一例外都没有成功。
而WWF成功的背后是什么呢?
流程设计器有微软在Visio上十几年的积累,流程文件XAML有微软在XML上十几年的积累,引擎有微软在SharePoint和BizTalk等多个版本的积累,没有这些积累,是做不了一个成功的工作流引擎的。
2.2WWF是优秀的工作流引擎
WWF有很多的特性,但对实际应用看来最重要的是下面两个特性:
细粒度的流程设计模式:
WWF是面向开发者的工作流引擎,它的Activity非常多,虽然每个Activity都只实现最基本的功能,但采用这些Activity设计出的流程可以非常复杂,非常灵活;
现有的其他一些工作流产品,既想讨好开发者,又想讨好用户,结果两头都不靠,要么只能实现一些简单的流程,要么对于复杂的流程实现起来非常麻烦。
状态机和顺序流的分离:
状态机是工作流的基础理论,只要流程中有退回操作,就涉及到状态机;
我们在画逻辑图的时候可以把整个流程只画到一个图上,如果我们直接实现这个流程图,就会遇到状态的入口问题;
而状态机和顺序流的分离很好的解决了状态入口的问题。
3WWF企业应用的模式
上面我们说了WWF仅仅实现了工作流引擎的功能,如果我们直接在上面进行应用的开发,会遇到很多困难,工作量也会非常大。
所以我们必须首先实现一个工作流平台层,在这层上才可以方便的进行应用的开发。
我们将WWF企业应用的模式分为3层,每层完成工作流应用的一部分功能。
3.1工作流引擎层
工作流引擎层解决的是流程驱动的问题,就是下一步做什么?
这一层的功能已经由WWF为我们实现了,对于所有类型的流程,这一层都是相同的。
3.2工作流平台层
工作流平台层解决的是角色驱动的问题,就是由谁来做?
这一层的功能我们需要自己实现,为什么WWF没有为我们实现呢?
①这不是工作流的通用需求,企业应用需要,但工业应用并不需要;
②每类企业对角色的驱动的模型是不同的,有的企业角色是一维的,有的企业角色是二维的,没法实现一个完全通用的角色驱动模型。
工作流平台层是WWF应用的关键,一个设计良好的工作流平台层能够封装引擎层,使流程的开发只需绘制流程图,不需编写代码;
角色的驱动也能够满足各种复杂的逻辑。
3.3业务应用层
业务应用层解决的是用户交互的问题,就是怎么做?
这一层是传统的用户界面设计,有时需要根据流程的当前节点,控制用户可以进行的操作。
在这一层我们可以通过扩充ASP.NET的数据访问控件,来提高页面开发的效率。
4对工作流平台层的技术要求
WWF已经为我们实现了难度最高的工作流引擎层,我们只需要实现工作流平台层,就可以方便的进行业务流程的开发;
工作流平台层的技术难度相对工作流引擎虽然已经大大降低,但仍然高于一般的项目开发,还需要较高的架构设计和技术能力,才能成功的实现工作流平台。
4.1明确的需求
前面说到为什么WWF没有实现一个工作流平台,是因为无法实现一个通用的企业数据模型;
我们也只能根据具体项目的需求和技术实现的风险,确定工作流平台的初步架构,然后不断的根据其他项目进行扩充,从而实现多个项目的超集。
所以要求我们必须非常清楚客户的需求,这样才能架构适用的工作流平台。
4.2较高的架构设计能力
架构设计能力是实现工作流平台的关键,有两点要求,一是要能够利用WWF来实现业务流程,二是要把所有流程中公共的代码提取到平台中。
架构能力是设计出来的,不是学出来的,没有几年的设计经验,是很难架构一个较好的工作流平台的。
4.3较高的技术能力
WWF是一项非常复杂的技术,学习起来已经很不容易,应用就更难了,有时遇到问题,不得不查看他的源代码才能解决。
WWF会涉及到.NET技术的方方面面,所以没有几年的.NET技术基础,要熟练应用WWF还是比较困难的。
5基于WWF的工作流平台
5.1需求分析
很多公司把平台作为一个产品独立的进行开发,这种方式对业务积累要求高、投入大、周期长,需要公司具有相当的实力。
我们部门的主要业务是项目的开发和实施,没有投入专门的产品研发人员,所以只能在项目开发过程中构建产品的原型,然后进行重构,从而实现一个产品;
这种方式投入低,但对技术要求高,风险也比较高;
其实有足够的技术能力和较高的标准要求,每一个项目完成以后,都应该完成一个产品的原型,但大多数管理者没有用这个标准来要求,也没有这个奢望。
5.2流程的需求
(1)部门经理逐级审批。
客户的组织结构有全国总部、区域级、城市级和部门级等,所有的流程都要求从申请人所在部门开始,逐级向上由各级经理审批,直至权限足够的经理。
(2)每级经理可以对每一项业务设置权限。
不同级别的经理的权限是不同的,比如休一天假,只要部门经理批即可;
休三天假就要区域总经理批。
每一项业务的权限也是不同的,比如休假是天数,借款是金额等等。
(3)流程处理角色和申请人所在的部门相关。
每一项业务都需要一个角色进行处理,但承担角色的人是和申请人所处的部门相关的;
比如北京的休假申由华北的人事休假管理员负责,而上海和广州的休假申请都由华东的人事休假管理员处理。
5.3问题的分解
分层是解决问题的一个方法,它降低了系统的难度,提高了灵活性;
同样的,一个复杂的流程看起来很难,但如果把它分解为上文提到的3个层,就相对容易一些了。
(1)首先一定要分离页面逻辑和流程逻辑。
客户的流程复杂在交互逻辑和流程逻辑都很复杂,按照很多人的做法是把它混在一起处理;
我们的建议是一定要分清楚,流程的部分都放到流程中,交互的部分放到界面中。
所以在上面的描述中,我们已经忽略了很多的交互逻辑,否则内容会多得多。
(2)其次要充分利用WWF的功能。
对粗粒度的模式来说,每个业务功能可能都需要一个组件完成;
所以我们经常听到有人问,你们的工作流有没有实现什么什么功能?
对于WWF这种细粒度的模式来说,他的每一个功能都是很多组件共同完成的,所以他几乎可以实现所有的流程功能,关键是你能不能设计出来。
我们以前总结过六种通用的会签模式,用WWF的流程设计器都可以非常方便的实现。
(3)通用的部分抽取到平台。
流程的大部分功能WWF已经替我们实现了,剩下的要么在平台中实现,要么在特定流程中实现,如何确定呢?
我们的原则有两个:
①只要两个流程都用到的部分就放到平台实现,否则只在需要的流程中实现;
②具体业务相关的部分放到特定流程实现,因为平台不应该知道任何特定业务的信息。
5.4用WWF的思想来设计逻辑图
前面提到要充分利用WWF的功能,WWF因其细粒度流程设计模式,可以实现强大的功能,并具有很高的灵活性,但同时学习难度也稍高。
逻辑图是流程的关键,清晰明确的逻辑图是流程实现的基础,可很多有多年工作流经验的设计人员画出来的逻辑图还是让人摸不着头脑;
这主要有两方面的原因:
一是客户怎么说就怎么画,但有时客户并不具备逻辑图设计能力;
其实画逻辑图是一个设计的过程,是把你将来的可能的实现方法,用客户可以理解的方式展现出来;
而且客户由于经验所限,需求经常是矛盾的,必须在画逻辑图的过程中发现并纠正,不能拖到开发期才发现。
二是和经验有关;
现有的大多数流程开发方式都是粗粒度的,很多流程逻辑被封装在了代码之中,在流程图上也就无法展现这些流程逻辑了,缺少了细节,流程图也就难以理解了。
一个好的逻辑图应该是WWF流程图的抽象,开发人员根据逻辑图就可以进行WWF流程的设计;
用户又很容易理解流程真实的运行模式。
这是我们示例的一个部门逐级审批的逻辑图和WWF流程图,实际的还有更多的内容,但这两个图的流程逻辑是一样的,用户也很容易理解。
我们一般在需求报告采用职能图,系统设计采用逻辑图,代码就是WWF流程图了。
图2、图3是两个真实的逻辑图和WWF流程图,节点多但不是太复杂,因为所有的流程逻辑都在状态机上,所以两个图非常接近。
5.5系统架构
前面我们谈到WWF已经实现了工作流平台的最难的引擎部分,但为了这个引擎的通用性,它的编程接口比较复杂,并且和应用领域相关的部分也都没有实现,所以我们必须首先实现一个工作流平台,在这个平台之上才能方便的进行业务系统的开发;
现在谈谈我们是如何构架这个平台的。
平台的构架分为引擎的封装和平台数据两部分。
5.6引擎的封装
WWF和应用之间的交互是通过接口和事件来实现的,在一些WWF相关的例子中,为每个流程都定义了一个接口,并且在接口中又为每一种状态的每一个操作操作都定义了一个事件,一个复杂的流程就可能会定义几十个事件;
这种方式仅仅是一个学习的示例,如果实际应用在项目中,那么开发和维护的工作量就太大了。
实际上我们仔细分析一个流程会发现,不同状态之间的操作都是很类似的比如同意、退回或拒绝等,而状态机流程一个时刻只能处于一种状态,所以不同状态之间完全可以共用事件,这样一个流程的接口的事件就可以压缩到只有几个。
我们再分析一下触发流程事件的参数ExternalDataEventArgs,他是包含Instanced的,WWF是根据这个Instanced找到相应的流程,然后在触发相应的事件的;
也就是说,我们在不同的流程之间可以共用一个接口;
所以我们只需定义一个接口,在该接口中为每一类操作定义一个事件,定义一个实现该接口的类,将该类实例化一次,就可以平台满足所有事件驱动的需要。
WWF流程设计器支持自定义控件,引擎的封装还包括用于与平台数据进行交互的自定义控件。
比如添加审批人控件根据流程中设置的角色,将相应的人员添加到流程审批表中等等。
5.7平台数据
企业应用是工作流应用较广的一个领域,但WWF为了保证工作流引擎较广的应用范围,设计为领域无关的,没有为企业应用提供更多的支持,所以需要由平台来维护这些企业应用所必需的数据。
很多流程都是按照组织结构来逐级审批,所以我们必须在平台中维护一套用户和组织结构的数据;
不同的部门对同一个业务可能运行不同的流程,所以我们要维护流程配置的数据;
不同的流程是由不同的角色参与的,所以我们要维护角色管理的数据;
不同的角色有不同的数据访问权限,所以我们要维护菜单管理和权限管理的数据。
当前运行流程的状态和审批人都是不断的变化的,所以我们要维护流程管理的数据。
这些数据几乎是每一个企业应用都需要的,但在每个软件开发商中,这些数据结构又几乎都是不同的,WWF给了软件开发商足够的空间,使其擅长的数据结构,能够和WWF完美结合,满足其应用的需要。
6结束语
目前该套工作流引擎已经在WindowsServer2003操作系统下,使用VisualStudio2008、C#、SqlServer2005开发成功,并在笔者所在的博物馆的多个管理信息系统中进行了应用,效果良好。
使用这套工作流引擎系统,开发成本低、速度快、维护方便快捷,另外由于无需关心工作流,应用系统结构也得以简化,增强了系统的稳定性和安全性。
参考文献:
[1]范玉顺,吴澄.工作流管理技术研究与产品现状及发展趋势[J].计算机集成制造系统CIMS,2001
(1).
[2]范玉顺.工作流管理技术基础[M].北京:
清华大学出版社,2001.
[3]WFMC.WorkflowManagementCoalitionSpecification:
Terminology&
Glossary[C].DocumentNumberWWFMC-TC-1011,Brussels,1996.
[4]何清法,李国杰,焦丽梅,等.基于关系结构的轻量级工作流引擎[J].计算机研究与发展,2001
(2).
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 基于 WWF 工作流 引擎 实现