很多人了解計算機(jī)程序設(shè)計是從學(xué)習(xí)流程圖開始的，那些菱形矩形的簡單圖表往往能讓流程邏輯一目了然。但流程圖不是可以運行的軟件，充其量只是一種文檔，所以入門后大家往往將流程圖拋諸腦后直接分析設(shè)計上手寫代碼。但流程圖就真的只能作為文檔嗎？在很多方面代碼比不上流程圖：
1.一個程序員寫的程序另一個人需要花很長時間看懂其中的邏輯，不像流程圖一目了然
2.在運行時看不到代碼的運行狀況，不知道運行到了哪個階段，這對大型項目管理帶來障礙。
3.代碼總是被封裝在對象或過程里，對象（過程）之間需要額外的邏輯才能共享狀態(tài)。
盡管一直不是軟件開發(fā)的主流，但將流程圖用在運行時總是一個不錯的想法，尤其在文檔生命周期管理、內(nèi)部應(yīng)用程序邏輯流轉(zhuǎn)、BPM、Pageflow等場景下優(yōu)勢尤為明顯：流程圖在設(shè)計時高度靈活簡便、運行時高度可見、管理更加方便。根據(jù)軟件界水漲船高者生存的規(guī)則，以后很多公司為了提高自己的效率會不斷接受引入工作流引擎到自己的產(chǎn)品中以避免重復(fù)發(fā)明劣質(zhì)的輪子，面臨的首要任務(wù)就是挑選合適的工作流引擎。那什么是理想中的工作流引擎呢？有人總結(jié)過工作流應(yīng)該具備的一些支持模式，參見Workflow Pattern
http://en.wikipedia.org/wiki/Workflow_patterns
http://www.workflowpatterns.com/
這些都是很有益的總結(jié)，但由于有些廠商商業(yè)利益夾雜其中，所以硬扯了一些Process Model的東西。也有很多人和我當(dāng)年一樣，參照openwfc,bpel4ws或者其他一些需要實現(xiàn)的功能點寫過自己單位用的工作流引擎并冠以自主知識產(chǎn)權(quán)之名，但實際上離真正的工作流還有一段距離。簡而言之，一個相對完整的工作流平臺必須具備的功能如下：
1.能夠完成流程跳轉(zhuǎn)。
2.宿主進(jìn)程、宿主、運行時、工作流引擎等各層解耦完全
3.宿主進(jìn)程多樣化，至少要可以棲身與主流應(yīng)用服務(wù)器上，避免使用者在非必要情況下自寫應(yīng)用服務(wù)器。
4.宿主層包含持久化、定時器、跟蹤、事務(wù)支持等運行時服務(wù)。
5.運行時層工作流執(zhí)行必須的編排器、規(guī)則引擎、跟蹤基礎(chǔ)框架與工作流生命周期管理必須的狀態(tài)管理、激活、冬眠等解耦。
6.工作流引擎支持包含常用的時序、狀態(tài)等模型
一個理想的工作流引擎除此之外還需要具備的功能如下：
1.宿主層支持與外界交互、多線程多進(jìn)程支持等運行時服務(wù)，支持自定義運行時服務(wù)以便擴(kuò)展。
2.工作流引擎支持的時序、狀態(tài)等模型良好封裝便于調(diào)用；引擎支持基于策略/規(guī)則的模型，支持自定義活動，為基于其上開發(fā)行業(yè)組件包的合作伙伴留出一條活路。
3.API良好組織調(diào)用簡單，最好支持多語言多腳本。不要有稀奇古怪的流程定義語言，最好是業(yè)界已有的或者大家能很快接受的。
4.在設(shè)計時和運行時都有很多的輔助工具與注入代碼的地方。
5.在設(shè)計時與運行時都有人性化的開發(fā)、調(diào)試、測試模板視圖與設(shè)計器。
6.對常見中間格式如Plain Text,XML,Office Doc等有良好支持；對常見數(shù)據(jù)庫、常見工業(yè)交換標(biāo)準(zhǔn)有所支持或有擴(kuò)展支持的接口。
除此之外，還有好多功能其實不屬于工作流重點關(guān)心的，但由于技術(shù)決策者需要所以理想的工作流引擎也必須考慮的：
1.邊界清晰、服務(wù)自治、共享schema與策略而不是類、基于策略的服務(wù)兼容。明眼人可能一看就要拍桌子了，這不是WCF等分布式應(yīng)用服務(wù)的設(shè)計原則嗎，怎么扣到工作流頭上來了？原因很簡單，因為便于發(fā)布成服務(wù)的工作流才是可塑性最強(qiáng)的工作流，所以工作流在屋檐下，不得不低頭，這也是微軟為什么Silver(在.NET3.5中將WF發(fā)布成WCF)的原因。
2.支持長事務(wù)，支持人-人、人-系統(tǒng)、系統(tǒng)-人、系統(tǒng)-系統(tǒng)等四種方式的流程協(xié)作，支持全生命周期的動態(tài)透明管理，模型高度可擴(kuò)展。
3.可在不同工作流進(jìn)程/線程間方便地轉(zhuǎn)移操作狀態(tài)和數(shù)據(jù)，方便地進(jìn)行補(bǔ)償沖帳等操作。
基于以上考慮，大家可以看到微軟的Windows Workflow Foundation已經(jīng)完全可用了，當(dāng)然還不是最理想的。有一個需要注意的是，筆者估計以后微軟的工作流引擎會遇到一個發(fā)展怪圈，目前的WF雖然成熟程度已經(jīng)比大多數(shù)國內(nèi)公司做的自己的工作流引擎好多了，但還是抽象層級不高，雖然現(xiàn)在有Enterprise library在做的Pageflow，上文提到的Sliver等修修補(bǔ)補(bǔ)的工作，仍然難以挑起一統(tǒng)天下的重任。更大的原因是再往上做可能會碰到BizTalk Server或BizTalk Service的地盤（再次澄清一下后二者都不是工作流引擎）。只能寄希望于在Oslo中的表現(xiàn)了。
總體來說，基于流程開發(fā)將在近年對軟件開發(fā)產(chǎn)生深遠(yuǎn)影響。大家可以現(xiàn)在開始按照以上標(biāo)準(zhǔn)選擇自己心儀的工作流并應(yīng)用到日常工作中。
重要申明：以上純屬個人觀點，不代表任何公司意見，轉(zhuǎn)載務(wù)請注明出處。
本文部分借鑒Paul Andrew，James Conard的見解，在此致以感謝!
|
