什么是工作流：
就是工作流程的计算模型，即将工作流程中的工作如何前后组织在一起的逻辑和规则在计算机中以恰当的模型进行表示并对其实施计算。工作流要解决的主要问题是：为实现某个业务目标，在多个参与者之间，利用计算机，按某种预定规则自动传递文档、信息或者任务。
工作流的应用场景：
soa中的时序编排，oa系统中的审批流转。大部分管理流程中都可以用到工作流。
工作流与业务的关系
一、业务集成到工作流中：一种常见的做法是把所有的业务集成到工作流中，如果有个业务就定义个function，然后放进去。例如要生成spcode。
1、带来的好处：
业务与工作流完全集成，只需要找到工作流配置文件，以他为主线就能找到所有的业务。让代码的阅读维护更方便。
2、坏处：
并不是最好的理念，仍然需要一次次的读原来的代码，复用性差，可剥离性差（比如我不想用工作流了），替换性差（比如我想从osworkflow到jbpm），侵入性高。跟现在大家说的最多的soa冲突。
3、适用环境
小项目开发，灵活，重写难度不大
二、业务单独写，工作流后加入进去
用非工作流的代码实现所有的业务，再用工作流编排
1、带来的好处：
符合soa的原则，可以分组件，分服务，分应用，复用性好，一旦复用消耗小，并不需要了解内部代码。
2、坏处：
初期消耗大，业务划分难度大，需要频繁调整。
3、适用环境
越大型的项目越好，甚至可以在应用之间组织。在电子系统集成中最有用。
工作流引擎：
字面意思理解，工作流引擎就是工作流核心元素解决方案。
那工作流的核心是什么呢？
有权限的操作者触发流程在各种条件下的跳转。
关键的是权限，条件，跳转。
所以工作流引擎实现的就是：
根据角色、分工和条件的不同决定信息传递路由
使用工作流引擎带来的便利：
1、开发简化
2、稳定性
3、易维护
理解工作流：
一句话：其实软件设计上更多的是借鉴非软件知识，比如设计模式来源于建筑。哲学上也有大同理论。
说了好久的工作流，知道它的好处，知道它的坏处，知道应用场景，但工作流还是有点朦胧，想到设计工作流，理解工作流还是有点头疼。特别是在大的场景，比如说我要实现任意方式定义的流程。听到这个就头大。那如何解决这个问题呢？
越是这类问题，约容易从理论的高度来解决。那么我们来看osworkflow是基于什么实现的？有限状态机。当我们放到宏观，我们要解决所有问题的时候会感觉很棘手，任意流程。但放到微观呢。虽然我们最终是要解决整个的路由。但是我只要解决任意两个step之间的路由。所有的路由就解决了。这也是数学上的归纳法。
好了现在的问题已经变成如何解决两个step之间的路由了，从两个step之间的路由，再次缩减到，我只需要知道一个step可以到什么地方，那我就知道是否两个step之间存在路由。
那放到一个step上是否就是有限状态机了呢？没错。
step就是状态，action就是状态转换，但是osworkflow赋予了action太多的功能，变成了action中的result才是转换，而action变成了转换过程中一些列操作及转换的集合。
有限状态机：
你熟悉他吗，一定的，一定熟悉他，想想有多少程序是基于他实现的。比如rpg游戏中迷宫的任意路口，比如rpg游戏中的情节设定。如果你写一个游戏引擎，你会发现fsm离你有多近。即使你不写游戏引擎，你玩游戏吗，在rpg中是否用笔通过一个个的点再现过迷宫地图，是否通过一次次的通关找到各种隐藏情节，这就是状态机。
osworkflow的设计工具：
为什么osworkflow不提供设计工具呢，osworkflow开发者说，要灵活，这是程序员干的事情。但是uml本身也是程序员干的事情。再想想因为osworkflow基于有限状态机，而对于有限状态机这种如果用uml表现出来是困难的。总会出一些难以控制的地方，再来看看jbpm，因为jbpm是基于状态图的，来源于uml，所以更容易出设计工具。
个人理解，大家交流