繼續 粘貼前人的一些 關於 workflow 的想法，現在看看很多當時的想法已經變成現實，但是對於我這個 流程引擎的新人還是有必要學習下的，爭取儘快把自己的知識更新下，修改下自己當前使用的一個 引擎框架
流程引擎在上世紀70年代就在辦公自動化領域展開，但最初是失敗的，一方面由於當時計算機的普及程度不夠，另外一方面“人們觀察到這樣一種現象，一個成功的組織往往會在適當的時候創造性的打破標準的辦公流程；而工作流技術的引入使得人們只能死板的遵守固定的流程，最終導致辦公效率低和人們對技術的反感。（from wiki http://zh.wikipedia.org/wiki/%E5%B7%A5%E4%BD%9C%E6%B5%81%E6%8A%80%E6%9C%AF）”
OSWorkflow 的 GUI Designer 確實很差，不過我們可以手工編寫流程定義 XML 文件。如果要給最終用戶用這個 Designer，項目組要對它做擴展才行。
試用了一把 OSWorkflow，個人感覺還是不錯的，它的工作流模型比 WfMC 的簡單，而且感覺更靈活一些。
我覺得工作流之所以在國內不流行，是因爲原來 WfMC 定義的模型太死了，在實際應用中有人工干預流程的正向、反向、任意跳轉的需求，但 WfMC 沒有提供這方面的支持，一般的工作流引擎對這方面支持的也不好。基於 OSWorkflow 開發一個適合實際情況的工作流引擎是可行
工作流引擎我曾經負責了很長時間，做過兩個，一個很土，很早以前用數據庫觸發器做的，很好實現，數據驅動的小型辦公應用可以試試用這種方案，另一個在02年時和三個小夥一起做的，也不是很麻煩，把wfmc簡化了做的，03年則用的是開源的工作流引擎。
符合wfmc的開源工作流引擎很多，光有工作流引擎，只能在開發時使用一下，想做成一個完整產品還需要很多東西。
一個業務應用，比如OA的審批流程，需要很多引擎來支持，比如組織機構、角色、規則、文檔、表單、腳本等，如果再加上工具，那麼跟做一個Notes也沒有什麼區別，所以工作流產品想做到業務人員輕輕拖拽就可以把一個應用從無到有配置出來，我認爲是不太可能的，不可能一行代碼都不寫。
工作流應用比較麻煩的是表現和規則，表現處理我們一般稱爲Form引擎，主要包括：在Form上每個字段域要進行校驗、操作方法、顯示、權限等定義處理，Form的模板選擇、操作方法、控制數據對象集、檔案夾等定義處理；規則則要求工作流引擎能通過規則引擎或者腳本引擎來調用業務對象的方法或屬性，並能用表達式進行處理，這跟編寫程序沒有什麼區別。
還有一種類型的應用，更注重業務規則，表現形式不是很重要，比如在電子商務的應用中，購物車程序可以視作一個pipeline型工作流應用，每個活動的處理，都可能會和規則打交道，比如折扣規則，業務人員可以通過修改規則配置文件來及時調整折扣策略。
我個人看法是工作流引擎和設計配置工具想做到極度通用對一個公司而言難度較大，主要在於設計工具，很麻煩，光一個Form Designer就跟做一個Frontpage沒多大區別，還有規則定義等。
工作流引擎有兩種用法：
一種是將它納入到公司的開發框架中，在某些業務領域使用工作流引擎，使產品或者項目有良好的架構和靈活性；
另一種就是做工作流應用產品，比如我們常見的工作流產品一般都是OA的公文流轉應用，商務上叫工作流，是具體的業務應用模塊。
根據產品的業務特點，先進行模塊封裝，比如OA中的流程審批，可以先把流程、活動、業務對象等基於工作流引擎進行預定義形成應用模板，然後基於業務模塊編寫配置程序，用戶可以在此配置程序上進行配置，一般可以滿足要求，如果用戶的業務出入不大，但配置起來較麻煩，那麼修改配置文件，實施工程師培訓一段時間後就可以做，如果根本就是不同的業務，那隻能二次開發，這時就是重新開發。
脫離業務的工作流引擎，對於不是專門做中間件的公司而言，可能很難在市場上有所作爲，除非有行業背景或者政府支持。
看來對工作流的研究都不少啊。做過兩年的工作流，主要是爲OA做的。OA大概是最容易聯想到工作流的，因爲公文流是個天然的流程處理。也是基於WfMC做的，但WfMC的規範裏缺少對細節的描述，比如接口3，就是工作流與應用間的數據交互。雖然這與應用的關係極大，但規範缺少了實質的指導意義。
基於WfMC的模型，可以把工作流的架子搭起來，基本的流程控制沒有問題，但對於實際業務中複雜多變的環境，比如OA中，隨意更改或增加的活動（完全由人來確定，很難完全窮舉），規範裏對這方面的論述極少。但總的來講，流程的控制還是比較容易實現的，流程控制的難點是實現會籤這類並行的處理，用戶甚至提出會籤的每個流程都是不同的，而且可以不必全部完成，就可以繼續處理。我考慮是用子流程來實現，但對狀態的控制還是要求有同步點，即子流程必須全部結束。
個人認爲，工作流的難點之一在於工作流和由它驅動的應用來如何交互數據，使得工作流能夠以預定的方式來運轉，完全自由的工作流實際就失去了工作流的意義，比如OA裏的交辦事項，一個一個傳遞下去，完全依據工作內容和人的判斷來處理，這時程序就很難控制去做判斷。有人就採取了自由流的做法，不定義流程，依據實際的行爲發生來確定流程的實例。這個就不多討論了。數據交互的問題，也影響到流程的定義，以及應用的對外接口。爲了避免過於死板的流程，在定義時就能有足夠的靈活性，儘量兼顧可能的流程控制。由於工作流面對的可能是不同的應用（當然，完全的通用工作流依我看是不可能的，或者說沒有必要，因爲工作流是爲應用服務的），數據接口部分就可能比較通用一些，並且不能理解數據的含義（因爲難以定義），只是機械地根據數據做判斷。應用也需要根據這個接口，提供數據訪問接口（應用的改造看來是不能避免了）。有用戶跟我討論過應用來驅動工作流，但我認爲這樣的話，應用本身會包含太多的流程的信息，使應用複雜化了，所以應用和工作流之間還是存在一箇中間層，來隔離相互間的影響，但這個中間層的存在，使得客戶化的工作不可避免。BEA的weblogic integration就是利用reflection,在定義時指定類和方法，來做工作流和應用的交互，這也是個辦法，但對於行業應用而言，可以制定一個比較通用的數據接口標準。
我們也試圖爲多數的審批流程提供表單的定製，並確定了和工作流的接口，只做了個原型，就放棄了，因爲沒有找到合適的實現技術。不過，這方面的嘗試還在繼續。
最近接觸了一下BEA的工作流，用workshop來設計，感覺思路大開，覺得和當初單純看OSWorkflow時有了更多的想法，而且覺得如果能夠很好的處理和規則系統的接口可以實現很豐富的功能，而不用大量的編碼工作。
我也是看了BEA的那套解決方案之後，才頓悟原來工作流/業務流程管理就是SOA的靈魂。缺乏工作流引擎的SOA是死水一潭。
YES,先握個手，我覺得如果用process管理加上各種分佈的control來控制，用SOAP來傳輸，可以把整個系統整合起來
我也是給oa做引擎的，不過在我看來，引擎根本不能稱之爲引擎，也許是我的用戶要求問題吧。工作流應該是自動流轉的，但是我們做的根本就不需要，全部是人工在選下一活動和處理人，我不清楚是不是所有的用戶都是這樣的要求，至少我現在做的就是這樣，後來想想，我的工作流引擎最終被使用的意義僅僅是給選擇處理人時設定了一個範圍，也就是performer標籤定義的那個id而已，其他的都是沒意義的東西
說說我的看法：
我認爲工作流引擎是實現業務流程管理的技術實現。不管他是基於什麼標準的，無非engine, processes, and activities.但是現在的技術人員個個都是好漢，有標準也不遵循，這不，幾個大公司BEA，IBM，M￥等現在爲工作流引擎技術制定的BPEL標準嗎？我認爲這個是有前途的，不過現在網上的資料很少。
工作流引擎技術是爲了實現業務流程的管理，經過近一週的學習和實踐，我自己有如下的感覺：
1）、基於單個應用內的工作流引擎技術，比如OSWORKFLOW，當然他也支持RPC，但是我沒有試過。
2）、基於多個不同應用內的工作流引擎技術，它的技術實現要依靠web service來進行實現，本人推薦的實現組合是：AXIS+J2EE+ACTIVEBPEL ，我的J2EE是STRUTS+SPRING+HIBERNATE 的MVC框架，使用SPIRNG和AXIS組合使用。業務流程由BPEL4WS生成，主要有兩個文件.bpel和WSDL，由ACTIVEBPEL服務器分析並與AXIS服務交互。
我的示例正在調試當中，假如完工合一定給大家發一個示例上來。
如果有什麼不同的看法，歡迎大家討論
msn:[email protected]
以偶的經驗來看，1人開發一個基本的工作流引擎需要6個月，能夠支持特複雜的流程再加6個月。加上設計器，監控器等GUI可能還要再加3個月。一般是拿開源的來改，比如我們用enhydra shark，它完全按照wfmc標準開發，而且做了很多模塊的反射配置，方便拆卸，經典案例是把數據庫管理由DODS改成Hibernate。
BPEL沒用過，不予評論。
光有引擎沒用，要考慮在什麼地方調用引擎API(主要是業務邏輯處理完之後)，如何與表單、查詢列表結合，組織結構，權限設置等等。
感覺目前工作流引擎產品的第一輪蛋糕已經分得差不多了(國內公司10+，國外公司4+，04年底的數據，相關數據所在論壇已關閉)，再做引擎開發可能要做好打價格戰的準備。
可能接下來比較需要具備將工作流引擎和其他模塊整合的技術。
結合實踐我們多討論一下基於企業應用的工作流技術，提提這方面的需求和功能看。我先說以下幾點：
1. 人工步驟、自動步驟、定時步驟。
2. 同步分叉和選擇分叉，多用戶接收，多用戶接收佔用策略。
3. 聚合Or和聚合All。
4. 安全退回，安全終止
5. 接收者實現可配置，也可以由客戶端程序自定義。
6. 接收者委託機制。
7. 工作日機制。
從技術可行上說說我的看法：
我現在使用的技術如下：
BPEL做業務流程建模，並依賴WEB SERVICE發佈服務，生成相應的服務代理
WEB SERVICE描述流程控制
使用MVC架構構建J2EE架構，在控制層引用業務流程的服務代理，並做事務處理。
可以參考如下框架：
優點：可以在多個異構應用間（夥伴）重組業務流程；
本人已經使用WebSphere做中間件服務器，以STRUTS（ACTION當中引用服務代理）+SPRING+HB,已經測試通過。認爲是一個可行的技術實現，也是一個成熟、容易理解的操作，很快將會伴隨着WEB服務的一起火熱。
沒有辦法的事情
老外用流程規範業務
中國要流程遷就人和業務，能用就怪了
但是客戶指定要工作流。。。。中國IT，嘿嘿
偶目前在修改OSWorkflow來適合公司的需要，在我看來選用工作流產品，需要考慮兩個問題：
1。工作流在應用中的位置
2。工作流的表現形式
問題一：工作流在應用中的位置
1。以工作流爲核心，是工作流"拉"應用
2。以工作流爲模塊，應用"推"工作流運轉（你們的OA估計是這樣的類型）
那麼採用推、拉都要看具體的應用，如果你們的應用開發是後期採用工作流，這個時候工作流更像是一個模塊，採用推的模式也許更適合一些；而OA這樣的應用也許更應該以工作流爲核心
問題二：工作流的表現形式
至於將工作流作爲獨立的應用、模塊、服務或者其他什麼類型，都僅僅只是工作流的表現形式而已，在確定了工作流的位置就可以考慮它的表現形式了。