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