这段时间因为项目需要做了一小的工作流引擎，总结一下经验。
大概会分为这么几个阶段来介绍。
1.理论基础
2.实现技术
3.实际开发的一个例子。
如图:
一、理论基础
只是简单的讨论原理，详细数学理论不再这里讨论，会在附录里列出来，有兴趣的同学自行查看。
1.概念
为了实现业务过程自动化提出的概念。
以前去政府部门办过事大家都有体会，那个迷茫啊困惑啊，很多连个办事指南都没有。
办一件小事要盖十几个章，材料交上去后你根本不知道现在到了哪个部门，审核通过了没人通知你，没通过的话少什么资料也不告诉你，告诉你也不是一次都说，跑一趟说一点。通过了这个部门审核下一步应该去哪也没人告诉你。
这个时候有个对机关门清的人，知道哪里水深水浅，领着你办下来该有多好，该请客请客该送礼送礼，少跑很多冤枉路，还能随时查询状态。
这就是工作流引擎要做的事情。
2.发展历史
工作流技术起源于二十世纪七十年代中期办公自动化领域的研究，由于当时计算机尚未普及，网络技术水平还很低以及理论基础匮乏，这项新技术并未取得成功。
老外也是被扯皮扯怕了试图改进。
3.作用目标
工作流将作为一个公共基础子系统服务于整个平台产品的人力工作流和业务工作流环节。
通过将工作活动分解成定义良好的任务、角色、规则和过程来进行执行和监控，达到提高生产组织水平和工作效率的目的。
人多了事情多了，扯皮的情况也就多了。为了避免扯皮建立一个协调中心，提供办事指南，负责进度管理，公共信息维护。
处理这种有复杂流程的事情目前有两种解决思路:
1.针对业务领域开发一个系统，一个模块处理完成一件事件后根据情况来决定下一步跳到哪个模块，带点什么参数。适应于流程比较固定的业务，像财务系统虽然很复杂，但是各种处理规则都清清楚楚明明白白，也不会随便变动。
2.工作流方式，讲流程跳转规则由工作流引擎统一维护，每个具体执行任务的模块只管干自己的活，干完了告诉一声引擎，由引擎通知下一个模块。目前只能处理相对简单的一些工作流程，OA公文流转，IOM生产系统调度这类规则不是很复杂，流程上下文较简单的情况。
对于特别复杂的流程，开发量反而比定制业务系统还要多。工作流理论需要再有一次提升才能解决这个问题。
4.体系特点
可维护性和可扩展性
与业务系统实际关联低偶合
可以扩充表达式引擎，与界面绑定由界面引擎决定
可以适应与审核等人力流程，也可以适用在无人干预的商业自动化流程
安全性
易用性
5.模型表示
用例模型
应用用例
扩展用例
分析模型
架构性重要分析元素
架构性重要用例实现
设计模型
组件结构
部署结构
6.定义语言
7.参考资料