貌似很久以前的一篇博文了，最近想整个超轻量级的引擎玩玩，故转载，经典就是经典啊。
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
自开博以来不断有朋友来探讨工作流引擎该如何设计、工作流的数据库如何设计、应用筐架如何搭建等，这些问题其实都是很难有答案的。开发设计一个工作流引擎是要能够帮助客户营造价值，而不是为了一时兴趣实现某些技术特性。工作流管理联盟(Workflow Management Coalition, WfMC)早已定义了工作流技术的标准体系，但并未指明具体实现的方法。工作流引擎在实现方法上可以基于不同的软件技术架构，引擎本身应该是与具体业务无关的，但又需要考虑各类应用领域，工作流引擎设计的重点应该是有一定差异的，但无论基于什么架构，无论基于哪个领域，有些原理是相通的。
主要是以下方面
一、易用性原理
工作流引擎在多数应用中是由客户或实施人员来设计相关业务流程，因此易用性相当重要，有些工作流引擎的设置器，在设计流程时按照代码语言的语法，或其它技术化强的术语去设置，让人不知道如何开始，也不太容易明白相关设置的具体意义。
因此要求图形化视觉效果，包括流程设计时的图形化和流程应用时的图形化。设计时的图形化以拖拉的方式就能去设置流程，应用时图形化让用户非常直观的感觉到流程运作情况；也要求操作便利，提供鼠标单双击、键盘快捷方式、工具栏、流程导入导出、打印、节点导航、流程复制粘贴、流程校验等等功能方便用户快速设置流程
二、功能完整性原理
工作流引擎必须支持各种流程特性，包括串行流程、并行流程（分流合流）、子流程、条件路径、条件人员、环节信息权限设置、普通环节、机构环节、会签环节等等，这里就不一一列举了。既然提供用户在代码外定义流程，那么流程定义工具就要求能够支撑到所有流程特性。
三、数据完整性原理
工作流本身对于业务系统而言，其作用是隐藏在背后，业务系统包括大量的业务处理数据，工作流引擎本身也有数据的处理，如何保证业务数据和流程数据的事务完整性？如何设计才能保证业务数据与流程数据的关联完整性？流程是自定义的情况下，业务数据如何统计？这些都是设计工作流引擎及工作流应用框架时必须解决的。
四、伸缩性原理
设想一个企业应用，如果公司只几十个人，又在一个办公室，工作流应用的价值不是很大，真正有价值的工作流应用是在集团公司大量烦琐的事件处理，如省级邮政的OA系统，15000的用户量，跨各个地市的不同流程模式。还有就是大的业务处理量，处理环节涉及多个职能部门，流程引擎协调和处理这些部门和人员之间的工作等，这些应用场景均是大处理量，流程跨越大，而且业务流程本身会有调整，会有不同组织结构层次复用同一流程模式的需求，因此在处理能力上需要有伸缩性，流程设置上也需要有伸缩性。
五、扩展性原理
工作流引擎设置工具能包括各种特殊权限的支撑，如交接、跳转、自动处理、终止流程、自定义时限等等，企业在某些特殊情况下应用流程时不一定需要按照流程设置去运作，流程设置工具能扩展特殊权限的功能去实现这样一些特殊要求。
工作流应用框架能够支撑业务上的扩展，如与财务系统集成、ERP集成、消息平台的集成、SPS的集成、INFOPATH的集成等。
六、接口原理
其实接口是工作流引擎的关键，也是面向对象设计与分析的关键，工作流应用筐架只需做“我要做什么”，工作流引擎返回结果，内部“我怎么做”，是不需要搅在一块的。关键接口包括：启动、发送、回收、退回、消息通知、结束等等，当然实际业务需求中的接口需求远不止这些。
七、可行性原理
现在工作流技术非常流行，很多朋友希望能开发自己的工作流引擎，如果要自己开发，其实可以先考虑以下几个问题。
1、 经济的可行性：工作流引擎是需要能帮助客户创造价值才有前途的，如果我们自行开发的工作流引擎给客户带来多大价值，获得多少回报，对比付出的成本及浪费的机会成本，收益如何？有得赚再自己做。
2、 技术可行性：工作流引擎设计并不复杂，关键是稳定、成熟的过程中，其它技术都在发展，工作流引擎需要集成的技术甚至解决方案的思想也在进步，工作流引擎能否与时俱进？盘算一下，如果有把握再自己做。
3、 时间的可行性：工作流引擎本身对客户来说没有价值，但可以降低应用开发的成本。具体的企业应用需要工作流引擎时，是否在规定的工期内能够提供一个稳定可靠的工作流引擎去实现具体应用？计划一下，来得及再自己做。
