工作流第二版設計總結
一、Existing Problems
沒有進一步總結工作流領域模型，還基本停留在第一版的層次上，導致：
層次不甚清楚
增加新功能困難
事務腳本過多，帶來重複代碼
組件職責相對混亂，尤其是服務組件與其它模塊耦合太多，應更清晰的定義一個內核服務層
沒有做併發設計，導致：
性能低下
存在死鎖可能
二、Design Principles
針對接口編程與控制反轉
整個系統針對接口編程，降低了編譯時依賴；利用IoC，通過配置來組裝系統，定製運行時行爲；帶來的最大好處就是，我們獲得了一個可在分佈式和嵌入式之間通過配置切換的引擎，不需要修改源代碼，大大提高了持續集成的方便性和速度，提高了適用性
三、Architecture Patterns
1、分層（POSA1）
通用類庫：供所有其它層調用 |
內核服務層：供內核調用 |
內核：獨立運行或作爲普通類庫被調用 |
內核開發包：開發外圍服務時使用 |
外圍服務：與內核一起運行，供應用開發包調用 |
應用開發包：開發具體應用時使用 |
具體應用：調用應用開發包來與系統交互 |
其中，內核中的工作流領域模型又分三層
語法層：負責將流程定義的文本形式轉化爲內存對象 |
語義層：負責將這些內存對象無意義的擴展屬性解釋爲有意義的模型屬性 |
實例層：表示運行期的語義層對象，其中各個屬性使用運行期實際的值來實例化 |
2、微內核（POSA1）
內核服務層＋內核，完成了最基本的工作流引擎，如實例化流程並調度之，產生任務表，處理消息請求等；
外圍服務則提供了做爲一個產品化的工作流引擎所必備的特性，如持久化，超時處理，任務通知，查詢接口，命令接口等
外圍服務以插件的形式配置到系統中
四，Design Patterns
1、領域模型(PEAA)＋Visitor(GoF)＋事務腳本(PEAA)＋命令處理器(POSA1,GoF)
Problem：
P1：目前對工作流領域模型瞭解的不夠透徹，而開發過程中需要不斷增加目前的模型不能直接支持的功能，如撤回、回退等
P2：如果堅持使用領域模型，則增加一個功能基本對應着爲領域對象增加相應的方法，則同時增加多個功能時，增加了並行開發和版本控制的難度，降低了開發效率
Constraint：
C1：需要在不修改領域模型的情況下動態增加功能
C2：需要在不修改領域模型的情況下動態爲客戶端提供新功能調用接口
Solution：
S1：使用“領域模型(PEAA)”爲當前所瞭解的工作流領域建模，支持基本功能
S2：使用“Visitor(GoF)”爲領域模型動態添加功能，這些功能通常還不是很清晰，需要迭代開發，逐漸合併到領域模型中
S3：使用消息對象爲客戶端動態的添加調用接口，使用“命令處理器(POSA1,GoF)”爲服務端動態的增加相應的處理接口
S4：命令處理器的執行體則是“事務腳本(PEAA)”，它調用領域對象的方法，或“Visit”領域對象來完成功能；目前這一部分存在重複代碼，需要進一步弱化或減少事務腳本，豐滿領域模型；另一種方案就是“元工作流”，即工作流系統中的事務腳本也用工作流來實現，困難在於抽象出一個工作流的元層次
2、主動對象(POSA2)＋異步完成標誌(POSA2)
用於自動型活動；自動型活動在自己的線程中獨立、主動的運行，從引擎傳入的異步完成標誌中獲取參數，執行完畢後將結果填寫到異步完成標誌中，並向引擎發送完成消息，以使“堵塞”的流程繼續運行（此處的“堵塞”並不是真的堵塞，而是當自動型活動對流程來說必須是同步完成的時候，流程的一種無所事事的狀態）；這裏更像是“收集參數(TDD)”模式，而不是異步完成標誌
3、反應器(POSA2)＋監聽器
用於將內核事件發送給外圍服務，實際上是一種手工AOP實現，下一版可將目前手工觸發事件的地方重構爲pointcuts，將監聽器重構爲advisors
4、插件(PEAA)
用於將外圍服務動態配置到系統中
5、查詢對象(PEAA)
就是前一版的“通用查詢接口”，這一版用“Generic + Functional Programming”重構了一下；目前系統中所有的查詢條件都是通過查詢對象來設置和獲取的，問題時效率較低
6、包裝器外觀(POSA2)
用於對Xml、消息系統等外部資源的訪問，在將系統從.Net平臺移植到J2EE平臺時，該模式發揮了巨大作用，大大縮短了移植時間
See Also：