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

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

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

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

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

[b]3.1 2.0版本改进的方向[/b]
首先，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等信息。