為了能更好的了解F2工作流引擎的架構體系，花了些時間畫了整個架構的體系圖。F2工作流引擎遵循參考WFCM規范，目標是實現輕量級的工作流引擎，支持多種數據庫及快速應用到任何基於.net管理系統，實現工作流審批、業務流（BPM）的智能性、靈活性、簡單實用性，具有強大的擴張性、集成性、獨立性、開放性和穩定性，實現了可視化的流程設計或優化，流程的定制完全是通過鼠標拖、拉、拽的方式來完成，常見的串行、並行、分支、聚合都可以非常方便快捷地實現，依托於工作流強大的自定義，管理員還可以隨時根據企業的情況調整流程，真正做到企業流程的不斷優化。圖形化、可視化設計流程定義通過Web端純JS流程設計器無需編程的“拖、拉”式圖形用戶流程設計環境，支持通用流程條件，多節點，多流向。
關於輕量級：易集成、真可嵌入式架構決定其是否為真正輕量級，所謂輕量級就是易用易集成，沒有臃腫的第三方框架，大量使用第三方的框架會使使用者的門檻很高，大量的應用第三方框架不僅集成時非常困難，而且要解決各種版本沖突問題，最終導致自稱輕量級的工作流卻無法達到真正嵌入式集成或者要做嵌入式集成時要花費大量的時間和人力成本來解決種種版本沖突問題，百度搜索到的幾乎都自稱輕量級，但是決多數都是為了自稱輕量級而叫輕量級，但實際應用還是依然是重型工作流，整合嵌入非常困難，各種DLL或Jar包沖突。
從我的理解，首先為什么要做到輕量級呢，原因就是你是要為別的系統服務的，做為工作流引擎是要面對各種業務系統，被業務系統集成整合進去的，由於這樣的應用就決定了工作流引擎自身必須是一個非常純凈的代碼環境。所以最極致輕量級的就是C#或Java的原生代碼，整個引擎最多使用一種行業最常用的架構，比如Java的SpringMVC，.net的asp.net MVC，除此以外不使用任何第三個架構，這樣你的引擎代碼將十分純潔，而且可以只編譯成一個DLL或一個Jar包。這樣不僅整合時沒有任何沖突，而且也不會導致因為過多的引用使原來的業務系統環境就得更加雜鎖復雜進而會導致將來的維護成本直線上升。
F2BPM工作流引擎的架構設計就是基於極致輕量級的設計，真正做到輕量級這個稱呼。實務做好事情，比漂亮的宣傳帶來實實在在的成就。
上圖：F2BPM工作流引擎微內核技術架構
上圖：F2BPM流程引擎五大接口
l Web建模工具：也叫“流程設計器” 即基於瀏覽器純JS流程設計器無需編程的“拖、拉”式圖形用戶流程設計器工具。
l 流程引擎：調度，推進工作流過程和活動。
l 任務管理器：維護活動，為外部系統調用參與者任務列表提供數據
l 組織模型:流程任務最終是應用到人，達到人機交互的效果，為流程運轉提供參與者。
l 支持多數據庫的ORM：工作流引擎需要應用到各個系統中去，需要有自己的ORM數據庫訪問層，同時支持多種數據庫類型。
l 流程數據：即模型庫數據，流程定義相關數據。
l 相關數據：即運動庫數據，相關待辦事項任務，活動實例等運動數據，流程上下文數據等。
l 流程實例：流程實例工單數據。
l 任務數據：待辦工作項數據。
l 形參數據：外部Tools,Apps中規定的參數類型數據。
l 控制數據：遷移的前驅ID，后續活動ID，工作流對象狀態等數據。
l 業務表單數據：工作任務活動界面的數據，即表單展現
l 外部組織模型數據：外部系統的用戶組織角色數據
l 外部應用數據：外部數據執行所需要的數據
工作流：Workflow
工作流定義：WorkflowDefinition
活動Activity：活動即是步驟的意思。
參與者Actor：參與者是直接或間接參與執行工作的人、機器或組織單元。
任務Task：用戶待辦任務實例，是工作的最小單位，即工作項。
遷移：流轉轉向,即帶劍頭的線所表示。即Petri網中的變遷
SplitXOR：異或散發，即后續步驟只能選擇一條分支。
SplitOR：或散發，即后續步驟可選擇大於等於１的分支
JoinXOR：異或匯聚，即前繼步驟只要有一條分支聚合就滿足
JoinOR：聚合，根據規則需要聚合1條或多條分支
WorkFlowEnactmntService（工作流執行服務）這個組件就是我們平常說的工作流執行服務或工作流引擎包含了多個工作流機，主要功能是讀取工作流定義、根據工作流定義驅動工作流的流轉，分為三個階段：
1、模型建立階段：利用工作流建模工具設計，並把XPDL文件解析導入到模型庫。
2、模型實例化階段：模型庫數據庫導入到運動庫，並做好狀態初始化，並分配每個活動執行所需要的資源參數等。
3、模型執行階段：根據運行庫的狀態，條件判定，推動流程狀態的遷移，並完成相關任務，同時提供注程實例運轉過程的監控跟跟蹤。