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

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

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

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

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

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