对于这个工作流的学习真的是不断深入的过程，总觉得不能理解的，不可能实现的要求，现在它就出现在你的面前，真心让你哭笑不得！
我们再来说说使用工作流的优势：
1，流程管理业务（切记）
2，能方便的应对业务的变更（业务结点和流程分离）
3，实现流程的复用，结点的复用
4，记录流程追踪过程
5，状态的维护等
一直在说要用流程来管理业务（控制业务的处理流程），工作流的每个结点并不知道接下来改做什么，也不知道业务要想要做什么，而只管根据流程的顺序执行，至于做什么我无需关心。
理解误区：
对于WF4.0的工作流来说，每个结点由我们开发人员自己开发，简单来说就是开发业务结点，实现相应的业务功能，再抽象一步就是我们将所有的业务结点进行抽象，使得一个抽象业务结点可以被所有的业务复用。那么这个来说我们很容易理解抽象结点，然后需要使用工作流的话，将结点拖到工作流中，那么这些结点就被工作流管理起来了，我们要做的就是开发结点池，也是实现我们所说的工作流不知道要做什么，而是去控制业务流程的执行。
那么，再过来说JBPM，做了一个JBPM的实例之后，觉得jbpm没有什么要开发的公共结点，因为我直接拖到流程中的任务，并不需要写什么代码，只需要指派到某个人，或者绑定上某些表单，这些仅仅是一些属性的设置，并不需要开发什么结点呀？所以对于要开发结点池一直很困惑。而且在实现的过程中，我们也在不断思考，工作流到底带给我们了什么？做着做着，实现的方式便成了这样（以下进行说明），大家可以看看存在什么问题！
实现方式：
1，首先，我将所有调用工作流的方法均抽象出来，供所有的业务使用（实现工作流方法复用）
2，对于画好的流程图来说，工作流引擎就会给我们实现，按照流程图的方式自动执行，不需要我们再去实现什么
3，针对每个流程节点配置每个结点的操作人和操作页面
4，每个业务需要工作流操作时，即可调用（互用），具体的业务中掺杂着工作流的方法。
实现功能：
1，针对已经应用工作流的业务来说，应对了流程图（业务）的变更。
例如：
流程图的顺序为：开始---申请修改课程信息--导员审批--教学秘书审批--结束
修改为：开始--申请修改课程信息--导员审批或班长审批---教学秘书审批--结束
对于这个业务的流程变更，我们并不需要重新修改代码，唯一要做的就是部署一个新的流程即可
因为所有的流程处理由工作流来操作和记录（表单和人员指定即可）
2，记录着流程的流转记录
3，针对这个业务来说，无论我怎么变更业务，工作流都可以帮我们处理（对于其他业务也同样对待）
就这样我们就以为大功告成了，确实是吗？当然不是，只能说我们局限了！
那么，还有什么地方不对呢？这些不正是我们需要的吗？问题出在哪里了？应对变化，记录流转。当做到这一步的时候，真的以为已经万事大吉了，一切都OK了，但是这时并不理解老师说的开发结点池，以及工作流并不知道我接下来要做什么的问题。这时我们只看到了能应对当前业务的变更，看似实现了工作流的思想，却没有站在更高的高度去思考。
下篇继续介绍以上问题