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等信息。