工做流技术分析

工做流技术分析

前言

基于上篇文章我决定写篇文章对工做流技术进行剖析和解读，授之以鱼不如授之以渔。因此决定讲讲原理，以便让你们对工做流有更深的了解。最先工做流是由外国人研发，慢慢被引近国内，我接触比较早的是Java的工做流如Jbpm、osworkflow、activiti都是比较成熟的解决方案，相比而言，采用Java研发仍是比较幸福，不像C# 那时候还没比较好的成熟解决方案，致使咱们在工做流技术框架方面不得不采用Java的解决方案。因为公司的缘由，最后咱们业务部分采用C#语言编写，流程部分采用Java下osworkflow技术方案，将Java中osWorkflow工做流封装成WebService服务与C#这边进行交互模式，增长实施的难度。微软发布的工做流产品（WF），咱们也研究使用过这款产品，这款产品只包含引擎和一个C/S版的流程设计器，并不支持在线设计流程。在使用方面，咱们并无用好WF，不知道是否是技术缘由，时常报些莫明其妙的错误，使用起来并不太稳定，最后不得不放弃转而使用Java的解决方案。目前市面上有不少公司或我的研发的工做流产品，有的是彻底遵循国际上制定的工做流标准实现，而有的则并无遵循标准，这两种实现暂且不论好坏，只要能解决自已的需求，在我看来，那就是好的产品。中国有位领导说过，无论白猫黑猫，能抓到老鼠的就是好猫。

工做流背景

引用上篇文章解释工做流产生背景以及使用场景。工做流是为解决现实中繁杂多变的业务审批流程，应运而生的一种技术。在现实中好多公司、政府、军工单位中审批业务流程是频繁变动，特别在研发ERP信息管理系统，或多或少都存在这种需求。工做流技术的出现为这种需求提供了一种更好的解决方案，将大大的减轻研发人员的工做量。在工做流技术未出现前，研发人员为应对这种状况是疲于应付，精疲力竭。一般都是经过硬性编码对固定的业务流程，进行针对性编码，这种编码方式，就很不适应业务频繁的变动，形成开发人员这种被动的局面。

工做流产品通常包含流程引擎和流程设计器两个部分，这两部分是工做流核心部件。流程引擎提供对流程解析，并驱动业务流程的流转。流程设计器则提供图形化操做方式，经过画图方式定义工做流审批流程，最终生成工做审批流程定义的XML文件。

流程设计器

市面上一般都是提供的在线流程设计器，在线的流程设计器主要基于Flash、SL、H5、SVG这四种技术实现。这四种技术实现画图各有优缺点。Flash、 SL这两种是必需要在客户端安装插件、学习成本也不低，这两种技术在逐步末落。H5、SVG这两种技术在近年是愈来愈流行，可是对老浏览器不支持。选择哪一种技术实现方式主要看目前自已的需求。也有些比较优秀JS开源画图框架如D3、SVGJS、Jsplumb等等，本质上都是基于上面几种技术方式实现的，有兴趣的能够自已去了解。

流程引擎实现原理

在系统中为了反映与现实的送审流程，工做流框架中一般都采用XML对送审流程进行描述定义。而后，由工做流引擎对XML数据结构解析，并将定义的流程节点和关联信息都序列化存储到数据库里。在序列化过程当中将与业务表单创建关联，后续将依据上述定义的流程，进行业务上的流转。市面上工做流框架基本上都是基于这种实现方式。固然我并无准备引入那些高大上的理论进行讲解，由于我以为那些专业术语让人听得都生畏，什么工做流泳道模型、顺序、状态机、事件等等这些专业术语的解释，有兴趣的可自行了解。其实，还涉及到到表单流转，这个话题等下次有时间，再来讲道说道。

开源工做流地址：https://github.com/chengderen/Smartflow-Sharp

结语

上述是我对流程定义、原理和实现，进行解读和分析。因为本人技术水平有限，有理解的不对地方，还请指教。写文章真的太折磨人，费神费力，但愿对你们有所帮助。顺便教你们一个排版的技巧，我也是前几天才知道的，写文章最好是先在Word文档中先调整好格式和排版，而后导出Html格式的文档，这样你的文章排版和格式看起来很舒服，不会错乱。以前一直苦恼纠结在博客园格编辑器中怎么调整好格式与排版。建议博客园的编辑器应该向csdn的学习，那个直接拷贝文档都不会乱格式。