Fire Workflow2.0规划(1)——模型的优化

1、Fire workflow工作流模型的设计目标
    1.0版本的模型主要是从技术的角度进行分析得出的结论，遇到了不少的批评，这些批评归结起来有如下几点。
    A) 业务上不直观：流程图太技术化，业务描述有点啰嗦。例如，顺序连接的两个Activity之间也必须要有Synchronizer。
    B) 某些业务场景不能够很好地刻画：由于“每个Activity只允许一个输入”，使得一些公用的环节很不好表达。

    经过一段时间的回顾和思考，我认为，Fire Workflow模型的设计目标是：增强其表达力，能够更简洁通俗地刻画业务，同时便于计算机处理。

    如何增强表达力及其效果，在接下来的章节中详细描述。

2、模型更充分地体现“以业务过程为中心组织资源、逻辑和数据”的思想
    什么是“以业务过程为中心组织资源、逻辑和数据”的思想呢？
    我们以政府部门为例，以前我们的政府部门的架构以层次结构为主，注重纵向的上下级关系和职责分配。群众要申请某个事项必须亲自携带资料在这些政府部门之间穿梭；如果在办理过程中出现差错，群众更加不知所措，不知道找谁。这种组织结构和办事规则显然不是很好地实现政府部门的“服务群众”的业务目标。
    后来，很多政府部门提出了“一站式”服务的理念，群众只要在服务大厅提交申请事项即可坐等结果，后续工作由政府部门按照规章制度制定的业务过程自行调度组织。这个理念的目的是方便群众，其本质就是以业务过程为中心，调整政府组织架构和行为方式。

    那么Fire Workflow的模型如何体现“业务过程”，“资源”，“逻辑”和“数据”这些要素呢？
    首先，业务过程（Process）由Activity, Synchronizer, Transition , Loop来表达。
    资源有很多种，包括人、计算机、软件系统等等，在Fire workflow当前版本中，只对“人”进行了建模——Performer。
    逻辑和数据向来密不可分，逻辑操作的对象就是数据。在Fire Workflow中 Task代表的是业务逻辑，同时，由于没有找到简便的合理的数据业务数据建模方式，所以它同时也代表了业务数据。

    紧接着的一个重要问题是：这些要素之间是什么关系？如何体现“以业务过程为中心组织资源、逻辑和数据”的思想？

    在1.0的模型中有这样的描述：Activity是Task的容器。这句话首先太技术化了，另外，也没有从业务的角度看问题的意思。
    在2.0中Activity的图示没有变化，但是赋予了新的含义。如下图


    多个业务步骤（Activity）在Synchronizer, Transition, Loop等逻辑组织下形成一个业务流程（业务过程），资源、逻辑、数据都是以这个过程为中心进行分配和组织的。

2、Activity可以有多个输入
    在2.0的模型中，Activity可以接受多个Synchronizer的输入，但是Activity并不对这些输入做任何的同步操作（这不是Activity的职责），即在运行时任何一个输入都可以激活Activity。

    但是，Activity的输出仍然只允许1个。

    这个修正对于使得“转移到公共步骤”的场景更加简单。例如，银行贷款流程可以这么画。




4、增加“业务视图属性”和业务视图
    没有分支和汇聚节点Synchronizer自动被隐藏，空Activity可以设置业务试图属性来决定是否需要自动隐藏。

工作流引擎为基础打造业务流程管理平台是趋势，也就是说核心价值还是业务管理平台，虽然严格意义上说这是两回事，但客户不这么看。
继续努力！

支持FF,期待你的改进。的确ff1.0在使用的时候有些问题还是比较繁琐的。希望2.0能有所突破。