在擁擠的公交車上讀完《工作流管理(模型、方法和系統(tǒng))》，自從搬完家，上班的路途突然變得遙遠。

這本書確實是按照它的副標題組織的，分別介紹工作流的建模模型、應(yīng)用工作流開發(fā)的方法以及部分商業(yè)的工作流產(chǎn)品。
對petri網(wǎng)的介紹是這本書的重點，如果想對petri網(wǎng)有個大概的了解而又不愿意接觸深奧的數(shù)學(xué)，那么可以一讀。本書隨后分析了如何對流程模型進行分 析，包括對建模正確性與否的定量分析以及對資源運行效率的定性分析。至于介紹的工作流產(chǎn)品，因為年代久遠，可讀性不高。應(yīng)用工作流開發(fā)的方法就更是理論 了，不過作為一本2000年的書，里面提到的一些原則還是很有敏捷的意思，例如和客戶在一起、迭代開發(fā)、交流的重要性等等。

讀完這本書，加上先前的范玉順的書，突然就明白為什么BPEL會如此之流行，原因在于它們都非常強調(diào)BPR的概念，即業(yè)務(wù)流程重組。也就是從一開始，工作 流系統(tǒng)就是瞄準BPR這個目標來的，想利用工作流系統(tǒng)將整個企業(yè)的業(yè)務(wù)流程都管理起來。目標如此遠大，整合自然是不能避免，整合包括了對人員的整合，也包 括了對IT系統(tǒng)的集成。如此以來，恍然大悟：BPEL這種強調(diào)服務(wù)集成的執(zhí)行語言無怪乎會大紅大紫了。至于說國內(nèi)最普遍的工作流應(yīng)用：將工作流引擎嵌入應(yīng) 用系統(tǒng)中，分離流程邏輯與業(yè)務(wù)邏輯，則自然登不了大雅之堂了。一句話說，就是國內(nèi)應(yīng)用工作流的層次太低。或者反過來也可以理解：現(xiàn)在的所謂BPM軟件都眼 高手低，不太適合國內(nèi)的應(yīng)用。

可是問題依舊存在，即BPEL根本上說是一種執(zhí)行語言，要業(yè)務(wù)人員理解簡直是強人所難，所以BPMN應(yīng)運而生。好吧，BPMN有了，自然BPMN到 BPEL的映射就出現(xiàn)了，可惜這終究是一廂情愿，一種是業(yè)務(wù)建模語言，一種是計算機執(zhí)行語言，中間的代溝比70、80還寬。就像科比，籃筐在他眼里比大海 還廣闊。

此外，BPEL的應(yīng)用還存在一個天然的障礙，即應(yīng)用集成從來都不是一件輕松的事情。將接口用web service包裝一下就SOA了？就面向服務(wù)了？這鬼話你也信，那可真是你服務(wù)，你全家才服務(wù)呢。應(yīng)用集成不輕松，所謂的企業(yè)敏捷性：能夠根據(jù)外部環(huán)境 的變化迅速調(diào)整服務(wù)編排流程那自然是鏡中月，水中花了。君不見，無數(shù)程序員們在開口大罵：靠，流程又要調(diào)整，早吃屎了？！

所以結(jié)論有三:
1、國內(nèi)的嵌入式工作流應(yīng)用還是什么適用就用什么吧，和XPDL\BPEL都無關(guān)；
2、一心要SOA、要BPEL。那別指望它能減少工作量，也別指望流程能夠迅速修改；
3、要對企業(yè)流程進行敏捷管理，那就考慮文檔化，別考慮執(zhí)行。