1編程模型
從消化系統講起，口腔、腸道、胃…等消化器官組成了消化系統，每個器官又是由更微觀的物質構成，比如細胞。細胞又可以細分。細胞可以分類，白細胞，紅細胞等等。這裡細胞可以認為是消化系統的基本組成元素。這種組成結構非常像面向對象的思維，因為它們都要解決同一個問題：現實世界復雜性。類可以認為是最基本的組成元素，類可以組成組件(構件) ，構件組成服務。知道了消化系統的組成，我們來看如何實現吃這個功能，吃的功能完成需要食物通過各種消化器官，使用消化器官的功能完成。這個過程是面向過程的，是一個流程。再看我們程序的實現，Staitc Main是程序的入口，C#中功能的實現也是通過調用相互關聯的類中的方法實現的。C#本身就提供了豐富的控制結構(if else,while等等) 。
分析：從最簡單的語句到類到組件，到子系統。代碼結構的最優化組織方式采用面向對象，可以更好復用，使用設計模式後可以更好控制變化。但是運行時邏輯往往是面向過程的。比如Main{}中的邏輯。就象細胞構成嘴、腸胃，這些器官又構成了消化系統，但是吃飯這個功能的完成是利用各個器官的功能，按照某種控制流程完成的。
結論：程序的目標之一是功能實現，其中實現方式是基於過程的，組織結構是面向對象的。
1.1過程控制模型
常見的過程控制模型有：1、C#語句控制流；2、XAML；3、數據庫表；4、DSL(領域描述語言) ，圖形(專用的圖形工具) 。數據庫表中可以存儲過程的調度邏輯，領域模式語言這幾年也非常流行。過程的描述可以用任何一種方法實現。
1.2C#控制流程的問題
看一看交互式過程：在流轉的過程中需要外部消息的響應的過程。可能某個處理會等待幾天甚至幾周。如果使用C#控制流實現，應該怎麼實現。一般的做法是新建一個線程異布執行某個流程，而主線程持續運行(類似Windows服務) ，如果流程停滯，線程會被阻塞，如果阻塞的線程一多，整個系統的性能就會有很大影響，畢竟線程池等系統資源有限。這種設計可以實現，但是可擴展性和可伸縮性都存在問題。Wf處理這類問題的思路是書簽機制，在線程停滯的地方加上書簽，並且書簽可以持久化保存到介質上，節約CLR中內存資源。管理器接收到消息後會繼續流程的運轉。書簽可以結合Observe模式和Delegate實現。第二講中我們可以進一步的了解到，wf的線程模型是天然的異步調用機制，可以非常好的解決這類情況。而工作流本身對過程模型的支持也強於目前的高級語言，下面的參考部分常見的工作流模式。
1.3工作流模式
工作流的概念起源於生產組織和辦公自動化領域，提出的目的是通過將工作分解成定義良好的任務、角色，按照一定的規則和過程來執行這些任務並對它們進行監控，達到提高工作效率、降低生產成本、提高企業生產經營管理水平和企業競爭力的目標。工作流從更高的層次上提供了實現物料流、資金流、信息流及其涉及的相關過程與應用的集成機制，從而使得企業能夠實現業務過程集成、業務過程自動化與業務過程的管理。通過定義不同任務之間相互關系的工作流模型, 無論是具體的操作動作，還是抽象的信息處理動作與決策過程，都可以用工作流的基本組成元素——活動來統一地進行描述。不同活動之間的關系，無論是具體的車間中零件加工順序關系、辦公自動化中的文件批轉、還是抽象的決策流之間的關系都可以用工作流的基本組成元素——連接弧來統一的進行描述。
基於Petri網原理研究了21種工作流模式。
基本模式（5個）
順序模式 – 按照順序執行各項活動
解釋：工作流流程中的一個活動只有當另一個活動完成後才能進行。
例子：當訂單登記活動完成後，客戶通知才可以進行。
並行分支模式 – 同時運行兩個活動
解釋：在流程中的一點一個控制線程分成可以並行執行的兩個控制線程，允許兩個活動可以同時運行。
例子：
同步模式 – 同步兩個並行的執行線程
單選模式 – 從多條路徑中選擇一個執行
簡單合並模式 – 合並兩個二選一路徑
高級分支與同步模式（5個）
多選模式 –從多條執行路徑中選出幾條
同步合並模式 – 合並多條路徑，如果有多條路徑被選擇，則進行同步；如果只有一條路徑被選擇，則進行簡單合並
多合並模式 – 合並多條路徑
鑒別器模式 – 合並多條路徑而不進行同步，只執行一次後續活動
M中的N模式 – 合並多條路徑，進行部分同步，只執行一次後續活動
結構模式（2個）
任意循環模式 – 沒有任何限制的執行工作流
隱含終斷模式 – 如果沒有事情可做，就結束
多實例模式（4個）
略
基於狀態的模式（3個）
推遲選擇模式 – 執行兩個可選線程中的一個，那個線程將被執行是隱含的
交替並行模式 – 兩個活動可以以任何順序執行，但不能並行進行
裡程碑模式 – 當一個裡程碑到達時，激發一個活動
取消模式（2個）
取消活動 – 取消當前活動
取消過程 – 取消該過程
參考：http://blog.csdn.net/tobeand/archive/2004/11/26/195106.aspx
Wf對工作流模式的支持
1．基於圖的模式
2．導航器
3．狀態機
可以構建基於wf的工作流管理系統嗎？
很多人都認為wf不是工作流管理系統，只是一個工作流引擎而已。從微軟的產品線來看，可以這樣認為。比如：wf提供工作流引擎，SharePonit和K2等工作流管理系統的工作流引擎就是wf。那麼如果我們的實際項目中需要使用工作流是否可以使用wf呢。
這是可以的。WF只是實現了非常基礎的部分，可以說只是提供了工作流的編程框架。和目前已有的工作流開發平台相比，微軟已經提供的Acitivity功能還是非常薄弱的。現在社區和微軟都沒有非常好的工作流實例。Start Kit是比較完善的一個例子，建議大家看一下。但是只要我們熟悉了WF的框架，通過自己實現一些基礎功能，絕對是可以做的工作流開發平台高度的。這就是為什麼要學習《WF框架編程》的意義。
按照國際工作流管理聯盟(Workflow Management Coalition，WfMC) 的定義，需要我們自己實現接口1到接口5。微軟的wf也提供了大量的服務，我們可以使用這些服務或按照接口約定，自己實現服務，實現完整的工作管理系統。要實現這個目標，需要先了解WFMC的工作流標准體系結構並熟悉上文的工作流參考模型。
2 WFMC的標准體系結構和工作流參考模型2.1 WFMC標准體系結構
為了實現工作流系統的特性，達到工作流產品之間的互操作性。國際工作流管理聯盟(Workflow Management Coalition，WfMC)提出了工作流參考模型的體系結構圖。
工作流系統標准體系結構模型
這為工作流的實現提供了公共的基礎，組成工作流管理系統的每個功能部件可以在不同的軟硬件平台上采用不同的方法實現，接口也可以在不同的軟硬件平台上采用不同的設計技術和編程語言進行編程，不同的工作流產品會按照互操作和協作的不同要求在一定層次上開放其接口。
從圖中可以看出，工作流管理系統主要由三類組成：
1) 軟件組件：完成工作流管理系統不同組成部分功能的實現
2) 系統控制數據：工作流管理系統中的一個或多個軟件組件使用的數據；
3) 應用與應用數據：對於工作流管理系統來說，它們不是工作流管理系統的組成部分，而是屬於外部系統和數據，它們被工作流系統調用來完成整個和部分工作流管理的功能。
2.2工作流管理系統應該提供的功能：
按照WFMC的定義，工作流管理系統應該提供3 種功能：
1) 建立階段的功能：主要考慮工作流過程和相關活動的定義和建模功能。
2) 運行階段的控制功能：在一定的運行環境下，執行工作流過程，並完成每個過程中活動的排序和調度功能。
3) 運行階段的人機交互功能：實現各種活動執行過程中用戶與IT 應用工具之間的交互
2.3 WFMC參考模型
工作流執行服務器周圍的接口是WAPI（Workflow APIs），通過這些接口可以訪問工作流系統的服務，這些接口還控制工作流控制軟件與其他系統組件間的交互。在這5 個接口中的許多功能，都是被2 個或更多個接口同時擁有的，因此WAPI 可以看作是統一的服務接口，可以交叉使用這5 個接口來支持工作流管理功能，而不是單獨的使用其中某個接口
通過參考模型可以定義：符合標准的工作流系統應該能夠實現接口1到接口5的這5個標准接口，即標准的工作流系統應該提供：
1.過程模型定義工具
2.工作流引擎
3.工作流任務管理器（工作流客戶端）
4.用戶管理監控接口
3 了解wf
了解了WFMC的工作流模型，我們再來看wf
3.1模型定義工具
過程定義包含，工作流執行軟件運行過程所需的過程所有詳細信息。包括過程的開始和結束條件、組成活動、在活動間進行導航的規則、需執行的用戶任務、可能會被調用的應用程序、所有工作流相關數據的定義等。
過程定義可能會涉及到一個組織/角色模型，模型包含組織結構和組織中的角色等信息。從而使過程定義在，與具體活動或信息對象相關的組織實體和角色功能方面，十分詳細。工作流執行服務器負責把工作流運行環境中的參與者與相應的組織實體或角色聯系起來。
vs提供了工作流設計器。這個是集成到vs開發工具中的，如果要實現自己的工作流管理系統需要自己實現工作流模型定義工具，也就是工作流設計器。工作流設計器的宿主可以任選，Winfrom和Webfrom都可以，為了方便還應該提供圖形化調試的功能。關於這些的具體實現，在以後章節中描述。
我們可以在設計時定義組織/角色，微軟提供了和membership的角色集成，但是由於membership不支持組織結構，並且for Oracle的實現需要自己做。所以在實際應用中會受到限制。解決方法是：1、自定義membership，使它能支持組織機構或者oracle。2、通過自定義的Acitivity掛自己的權限管理模塊。
任務分配考慮：
設計時基於角色分配(分配到角色)
設計時基於人員分配(分配的具體的人,或者某個分支機構中的所有人)
運行時分配(比如指定審批人，指定時實例已經運行)
WF沒有任務表的概念，WF引擎也不關心流程什麼時候流轉，向什麼地方流轉。WF引擎按照狀態機理論，負責控制Acitivity和WF實例的各種狀態，具體請看第二部分第三節，WF調度部分。
所以是沒有辦法獲得某個人員的待辦任務之類的任務列表的。這塊要自己實現。以前我的做法是在應用程序中控制，通過應用程序指定的任務進入任務列表，待辦任務也是檢索這個列表，整個實現和WF沒有關系。但是實際運用中發現了很多問題。最好還是通過自定義Acitivity來實現任務列表。大家在跟我熟悉WF框架之後，就可以想到更好的實現。
3.2工作流引擎
WF就是一個工作流引擎。先了解下WFMC對工作流引擎的要求：
● 解釋過程定義
● 控制過程實例—創建、激活、掛起、終止等
● 為過程的活動導航，可能要包含順序或者平行的操作、最後時間期限、對工作流相關數據進行解釋
● 參與者簽名和退出*
● 確定任務項目，實現用戶意圖；提供接口，支持用戶交互
● 維護工作流控制數據和工作流相關數據，在應用程序間或者用戶間傳遞工作流相關數據
● 提供調用外部程序的接口，連接所有工作流相關數據
● 提供控制、管理和審查功能
WFMC對流程調整和流程模型的要求
按照WFMC的要求，工作流引擎要能支持串行、並行、分支、匯合、循環、同步、子流程多種關系模型；同時工作流引擎要能夠實現版本控制，即業務流程的動態調整。最好能夠實現下面三種方式的業務流程調整：
1、只修改單個業務流程實例的模板
2、所有正在運行的流程實例都按新的模板運行
3、已有實例仍按調整前模板運行
WF的版本控制看後續章節
流程異常處理
發生異常，流程能回退及業務補償,暫停、取消。
超時處理
通知SMS,電子郵件...
WF需要編程實現
幾個問題：
1.wf對各種關系模型如何支持的(參考文檔) ?
2.wf版本控制實現方式?
3.wf異常處理?
4. wf超時處理?
3.3工作流客戶端
WFMC任務表
任務表—由工作流機分配給用戶的任務序列。任務表處理器是一個軟件組件，管理工作流參與者與工作流執行服務器間的交互,工作流參與者的簽到和退出、請求過程實例的開始、任務排隊等候特殊的參與者，等。在某些系統中，用戶接口可能會與任務表處理器組合到一起，構成一個簡單的功能實體。也可以是用戶接口是一個單獨的軟件組件，負責提示和處理用戶對話框，並控制本地用戶的本地接口(參考體系結構) 。
最簡單的情況是，工作流機訪問任務表，來把任務分配給用戶；任務表處理器訪問任務表，向任務表中添加任務項。有許多不同的產品來實現任務表的交互（參考模型）
在WF中沒有任務表的概念。流程調度參考第三章。
在wf中有宿主的概念，工作流引擎在宿主中注冊，定義相關的服務，例如持久化服務，監控服務。宿主和wf引擎通過remoting或者wcf方式通信。角色定義信息存儲在.rule文件中
3.4 接口3(應用程序調用接口)
WFMC定義：
創建會話（Session Establishment）
● 連接/斷開應用程序會話
活動管理功能（Activity Management Functions）
● 開始活動
● 掛起/恢復/放棄 活動
● 活動完成通知
● 信號事件
● 查詢活動屬性
數據處理功能（Data Handling Functions）
● 提供工作流相關數據
● 提供應用程序數據或數據地址
WF實現
wf:CallExeternalMethod,CallWebServcie
3.5 接口4
分布式多工作流引擎支持
3.6 接口5(管理監控)
WFMC的定義
用戶管理操作（User Management operations）
● 建立/刪除/吊銷/修改用戶或工作組的權限
角色管理操作（Role Management operations）
● 定義/刪除/修改 角色的參與者
● 設置或取消角色屬性
審查管理操作（Audit Management operations）
● 查詢/打印/新建/刪除審查記錄或事件日志，等
資源控制操作（Resource Control operations）
● 設置/取消/修改 過程或活動並發級別
● 訪問資源控制數據（數量、開始、使用參數等）
過程管理功能（Process Supervisory Functions）
改變工作流過程定義或其擴展過程實例的運行狀態
● 使用/不使用 某個版本的過程定義
● 改變某一類型的所有過程/活動實例的狀態
● 為某一類型的所有過程/活動實例的屬性賦值
● 終止所有的過程實例
過程狀態功能（Process Status Functions）
● 打開/關閉 過程/活動實例查詢，設置過濾標准
● 取得過程/活動實例的詳細信息
● 取得特殊過程或活動實例的詳細信息
實際中應該實現的功能
1、實時跟蹤工作流的運行狀況
2、超時任務監控
3、跟蹤查詢歷史工作流的處理過程?工作流異常處理
4、可執行任務改派
5、可以掛起/恢復工作流
6、可以取消工作流
7、可實現業務流程動態調整
wf對管理監控的支持：流程級和活動級的日志(TrackingService) 。默認只支持保存到sql server,需要按照重新實現接口才能實現保存到oracle或者文件。默認是控制台界面的日志顯示，需要圖形化的監控和管理界面。
結論：WF只是實現了非常基礎的部分，可以說只是提供了工作流的編程框架。和目前已有的工作流開發平台相比，微軟已經提供的Acitivity功能還是非常薄弱的。現在社區和微軟都沒有非常好的工作流實例。Start Kit是比較完善的一個例子，建議大家看一下。但是只要我們熟悉了WF的框架，通過自己實現一些基礎功能，絕對是可以做的工作流開發平台高度的。這就是為什麼要學習《WF框架編程》的意義
沒有任務表對wf的影響
在3.1節中任務分配考慮時說到，WF沒有任務表的概念，WF引擎也不關心流程什麼時候流轉，向什麼地方流轉。這是目前為止。這種設計本身非常好，但是WF不提供任務表對待辦任務的檢索造成很大影響。非常有必要再明確討論一下。考慮一下待辦任務查詢：我們如果遍歷工作流實例，再看每個活動的角色指定是否是當前角色，肯定會存在嚴重的性能問題。如果我們自己建任務表，考慮下面兩種情況：1、運行時指定角色，這個時候我們可以在應用程序級別插入任務信息（工作流ID，指派人，提出人…等等），但是如果這樣流程的運轉其實不是靠WF而是靠任務表實現的，相當於沒有使用WF。而且任務表的維護工作非常麻煩，任務執行後要更新任務表，回退，會簽邏輯要頻繁在業務邏輯層面維護任務表。反而麻煩。所以對任務表的維護必須用工作流自身完成。這個也是建議使用自定義Acitivity方式維護任務表的原因。2、設計時指定WorlflowRole。這種情況下一般也是使用自定義Acitivity做維護任務表。
問題：一、是否有必要自己實現任務表
二、如果要自己實現，文中方法是否可行，是否有更好的方法
