什么是工作流：
就是工作流程的計算模型，即將工作流程中的工作如何前后組織在一起的邏輯和規則在計算機中以恰當的模型進行表示并對其實施計算。工作流要解決的主要問題是：為實現某個業務目標，在多個參與者之間，利用計算機，按某種預定規則自動傳遞文檔、信息或者任務。
工作流的應用場景：
soa中的時序編排，oa系統中的審批流轉。大部分管理流程中都可以用到工作流。
工作流與業務的關系
一、業務集成到工作流中：一種常見的做法是把所有的業務集成到工作流中，如果有個業務就定義個function，然后放進去。例如要生成spcode。
1、帶來的好處：
業務與工作流完全集成，只需要找到工作流配置文件，以他為主線就能找到所有的業務。讓代碼的閱讀維護更方便。
2、壞處：
并不是最好的理念，仍然需要一次次的讀原來的代碼，復用性差，可剝離性差（比如我不想用工作流了），替換性差（比如我想從osworkflow到jbpm），侵入性高。跟現在大家說的最多的soa沖突。
3、適用環境
小項目開發，靈活，重寫難度不大
二、業務單獨寫，工作流后加入進去
用非工作流的代碼實現所有的業務，再用工作流編排
1、帶來的好處：
符合soa的原則，可以分組件，分服務，分應用，復用性好，一旦復用消耗小，并不需要了解內部代碼。
2、壞處：
初期消耗大，業務劃分難度大，需要頻繁調整。
3、適用環境
越大型的項目越好，甚至可以在應用之間組織。在電子系統集成中最有用。
工作流引擎：
字面意思理解，工作流引擎就是工作流核心元素解決方案。
那工作流的核心是什么呢？
有權限的操作者觸發流程在各種條件下的跳轉。
關鍵的是權限，條件，跳轉。
所以工作流引擎實現的就是：
根據角色、分工和條件的不同決定信息傳遞路由
使用工作流引擎帶來的便利：
1、開發簡化
2、穩定性
3、易維護
理解工作流：
一句話：其實軟件設計上更多的是借鑒非軟件知識，比如設計模式來源于建筑。哲學上也有大同理論。
說了好久的工作流，知道它的好處，知道它的壞處，知道應用場景，但工作流還是有點朦朧，想到設計工作流，理解工作流還是有點頭疼。特別是在大的場景，比如說我要實現任意方式定義的流程。聽到這個就頭大。那如何解決這個問題呢？
越是這類問題，約容易從理論的高度來解決。那么我們來看osworkflow是基于什么實現的？有限狀態機。當我們放到宏觀，我們要解決所有問題的時候會感覺很棘手，任意流程。但放到微觀呢。雖然我們最終是要解決整個的路由。但是我只要解決任意兩個step之間的路由。所有的路由就解決了。這也是數學上的歸納法。
好了現在的問題已經變成如何解決兩個step之間的路由了，從兩個step之間的路由，再次縮減到，我只需要知道一個step可以到什么地方，那我就知道是否兩個step之間存在路由。
那放到一個step上是否就是有限狀態機了呢？沒錯。
step就是狀態，action就是狀態轉換，但是osworkflow賦予了action太多的功能，變成了action中的result才是轉換，而action變成了轉換過程中一些列操作及轉換的集合。
有限狀態機：
你熟悉他嗎，一定的，一定熟悉他，想想有多少程序是基于他實現的。比如rpg游戲中迷宮的任意路口，比如rpg游戲中的情節設定。如果你寫一個游戲引擎，你會發現fsm離你有多近。即使你不寫游戲引擎，你玩游戲嗎，在rpg中是否用筆通過一個個的點再現過迷宮地圖，是否通過一次次的通關找到各種隱藏情節，這就是狀態機。
osworkflow的設計工具：
為什么osworkflow不提供設計工具呢，osworkflow開發者說，要靈活，這是程序員干的事情。但是uml本身也是程序員干的事情。再想想因為osworkflow基于有限狀態機，而對于有限狀態機這種如果用uml表現出來是困難的。總會出一些難以控制的地方，再來看看jbpm，因為jbpm是基于狀態圖的，來源于uml，所以更容易出設計工具。
個人理解，大家交流