Fire Workflow2.0规划(2)——引擎设计的调整

1、废除ProcessInstance，ActivityInstance，WorkItem对 IRuntimeContextAware, IWorkflowSessionAware两个接口的实现
    1.0引擎设计中一个最大的败笔就是让ProcessInstance，ActivityInstance，WorkItem这3各对象实现 IRuntimeContextAware, IWorkflowSessionAware这两个接口，把一个较为纯粹的POJO搞得不伦不类。
    改变这个实现将对API造成小小的变动，相关的操作都需要一个WorkflowSession作为入口参数，如：WorkItem.claim()变成WorkItem.claim(WorkflowSession session)

2、再论“工作流数据 vs 业务数据”
   1.0版本中，将业务特征数据填充到TaskInstance的扩展类中造成了大量的数据冗余，非常不合理，将考虑填充到ProcessInstance的扩展类中。

    我还是认为将业务特征数据在流程系统中进行一定的冗余是一个好的想法，有利于流程系统和业务系统解偶，从而为流程系统独立运行打下基础。

3、任务分配
3.1  1.0版任务分配的缺点
    1.0版的任务分配设计有如下几个缺点：
    A) T_FF_RT_WorkItem表表示资源的字段仅仅只有ActorId，不利于统计查询。
    B) 1.0版的资源只能采用“前期绑定”的方式，即WorkItem创建时绑定操作者到该WorkItem。在某些情况下，“前期绑定”不适合，例如：当某个角色的成员众多时，效率较为低下；当角色的成员无法确定时，该方案无法绑定操作者。

3.1  2.0版本改进的方向
    首先，T_FF_RT_WorkItem将增加ActorName, DepartmentId, DepartmentName等字段，方便系统进行业务统计
    2.0版本将增加资源“后期绑定”方式，后期绑定的意思是，在WorkItem创建的时候并不解析角色中的具体成员，仅将WorkItem分配给角色；只有当角色中的成员签收该WorkItem后才将WorkItem绑定到特定的成员。
    但是系统默认采用“前期绑定”。前期绑定的优点是查询待办工作项方便，容易实现自动委派等需求。“后期绑定”仅在前期绑定不能实现业务需求的情况下使用。
    2.0版本将增加WorkItem.disclaim()接口，即“退签收”。退签收的WorkItem将被重新分配给其他操作者，或者退回到“工单池”，以便于其他操作者签收。
    2.0版本将增加适当的管理接口，可以将尚未完成的TaskInstance的WorkItem进行重新分配，或者追加操作者。
    2.0的Performer将增加Type属性，如Role, Team, Department,等等，便于AssignmentHandler进行更加精确的操作员解析。
    2.0版本中IAssignable.assignToActor(String actorId) 接口参数将发生变化，由actorId变成一个Actor对象。Actor对象包含id, name ,departmentId ,departmentName等信息。

2.0版本将增加资源“后期绑定”方式，后期绑定的意思是，在WorkItem创建的时候并不解析角色中的具体成员，仅将WorkItem分配给角色；只有当角色中的成员签收该WorkItem后才将WorkItem绑定到特定的成员。
——确实存在两种需求，前期绑定一般适用于“人工推”的业务场景，比如必须指名道姓让后续环节谁来处理，此时需要解析出具体的人来（不管设定的是角色还是特定角色，特定角色如“流程启动者”）；后期绑定适用于自动化流程：管他谁呢，反正我要报销，自然会有对应的领导签字，此时免去了“推”的麻烦
后期绑定在取待办时性能有点影响，如果再考虑“自动委托转发”的话，更明显

Performer还需要考虑一种特殊的角色，比如上级领导、流程启动者等，交由特定的借口/实现解析，利于扩展。

非也兄对于流程运行控制模块的设计有什么新的想法呢？ 我觉得我们国内做开源流程系统设计的朋友应该联合组成一个流程系统设计平台，相互多交流

哈哈，我们联盟对流程系统设计还是有一定的分工，JWFD准备专门研究流程系统运行控制设计和方法，FIREWORKFLOW专门走整体应用方向。。。。。。。

2.0 什么时候能退出来呢？
有时间表么？

非也，加油，我们国内的开源软件一定能够搞好。。。