平常都會收到mail，討論工作流和BPEL技術問題，但很多人的問題僅僅是“請問現在什么工作流產品比較好”，這樣的問題我一般就沒有回復了，
因為的確不好回答，而且這樣問的人也太多了。但來的mail中也有問的問題非常不錯的（其中包括部分老總級管理人員的問題），下面這個就是
HW
的一個人的來信交流，為了privacy起見，刪掉了一部分內容。
?
1
、
HW
您好：我是工作流方面的興趣愛好者，當然也只是一個新手，請問BPEL有沒有什么比較好的全面的文章推薦？（除了BPEL2.0的規范外）還有就是我想找一個開源項目進行研究，你覺得activeBPEL怎么樣？可以推薦一下嗎?
?
HongSoft
您好！BPEL雖然也發展了好多年了，現在使用也開始多了起來，但目前的確沒有什么比較全面的文章。開源項目方面，我也跟蹤了很多BPEL項目，activeBPEL我也看了很久，目前不看好它。現在BPEL方面我在全力使用jBPM_BPEL項目。應該說jboss旗下的幾個項目發展都還不錯，hibernate/jboss?seam等，jbpm現在也被spring納入支持列表中。
?
2
、
HW
您好：非常感謝您的回信，據我所知現在工業界（如IBM,Microsoft,BEA,?Oracle等）都非常推崇BPEL，我想問一下你覺得這個語言是否真的很有潛力成為工業界中業務集成方面的標準語言？那WS-CDL這項標準你怎么看待它？會廣泛的被用到嗎？還有就是關于activeBPEL，能否幫忙講解一下它有什么缺點啊？相反jBPM_BPEL它有哪方面的優點？>是否有分布式工作流技術的項目啊，（個人感覺一個集中引擎總會產生一些效率之類的瓶頸問題）？是這樣的，我們在考慮能否把工作流技術運用到電信業務的集成系統中去，電信業務對系統容量，實時性和穩定性方面要求非常高，讀了您的一些文章，感覺你在這方面經驗非常豐富，所以向你請教了，問了這么多問題，呵呵，假如對口的話，能夠進行一些合作最好了，還有就是不知道你現在是否聽說過IBM及Microsoft都在推SOA，你他們推的產品和jBPM_BPEL是否有些競爭關系？。謝謝了！！打擾了！呵呵
?
HongSoft
您好：
1
） WS-CDL的問題
CDL的全拼是Choreography?Description?Language，顧名思義它是用來描述Choreography的。它和BPEL的區別是：a)CDL提供一個在所有的參與者間交換的形式化描述，BPEL提供的則是本參與者對外的形式化描述定義；b)CDL提供一個全局的消息交換協議。
而BPEL是描述“我和其他人”通信的消息交換協議。理論上看CDL比BPEL更好，但實際上它有2個缺陷：a)業務集成需求的產生，是因為工業界中已經存在的很多的legacy系統，這些系統已經按它自身的業務規則，實現了自己的功能；在這樣的情況下，突然安插一個Choreography進來，必然對legacy系統的實現和穩定性產生非常大的影響，這個是業務集成領域應該避免的。b)BPEL從工業界產生，被世界各大公司支持；而CDL的時間和支持力度，則明顯不足。
從上面的比較和目前工業界的實際情況看，我認為BPEL肯定會成為工業界中業務集成方面的標準語言。
2
） BPEL的問題
activeBPEL和jbpmBPEL的比較，應該說可以從很多方面來看。從系統結構，技術實現等技術角度來看，activeBPEL比jbpmBPEL要差；jbpmBPEL在jboss旗下，它的技術實力要可靠，后續支持也要可靠；active本身是家商業公司，擔心它的開源程度和信心不夠...等等。
3
） 工作流的問題
我們用Shark和jBPM就已經做過分布式工作流技術的項目，項目有用到電信的故障運維業務中去，也有用到700W用戶的網站項目中去。當然是否用分布式工作流技術，還需要具體分析。IBM及Microsoft都在推SOA，這個應該說和所有的BPEL產品都有一定的競爭關系，但我認為更大的是合作關系。SOA是套架構，我們要做的BPEL產品只是這個體系中的一個組成。IBM及Microsoft都有太多自己特性的東西是客戶不一定想要的，比如對數據庫的指定，在電信領域指定用DB2或者SQL?Server就不太可能。在這樣的情況下，我們可以理解為IBM及Microsoft幫我們鋪路，我們在最少投入的情況下，力求達到最大的產出。
?我說的幾點是我個人理解，不知道能否讓您明白。?希望多交流。
?
3
、
HW
您好：非常感謝您的回復，考慮到電信業務的系統容量，實時性方面的要求，我們對分布式的工作流很感興趣，想具體了解一下分布式工作流技術如何運用到業務集成，呵呵，準確的說應該是基于BPEL的分布式引擎之類的東東（因為這邊的業務集成主要涉及到如何靈活的快捷的進行業務組合，說工作流可能不是很準確，呵呵），能否詳細講解一下分布式工作流引擎的一些工作原理之類的？呵呵。謝謝了。說白了就是希望利用已有的各種service的能力，加快業務的開發和部署時間（web?service是一個不錯的選擇，但目前為止性能方面還是個比較大的問題，但考慮到各大IT廠商對其的關注度和投入，基本上也是我們非常重視的一個選擇），同時又希望保證系統的各種性能，主要還是系統容量和實時性。希望能夠加強交流，合適的話能夠進行一些合作最好，呵呵。期待您的回復。打擾了！
?
HongSoft
您好：您說到“分布式工作流引擎的一些工作原理”，這里分為2類：
1
） 非BPEL類：?就是按WFMC的標準，架構的系統為?一個工作流執行服務=多個工作流引擎，這個是標準實現，每個引擎的具體架設方法是不同的。
2
） BPEL類??：這個方法本來就是分布式的，基本是強制性的，不需要我們自己去考慮。
您說到的“加快業務的開發和部署時間”是個比較大的問題，具體可以參考一下我做的smart系統，基本上把開發時間降到了最低，但有一定的局限性；其他的方法也可以一起討論，和和。
?
4
、
HW
您好：不是很明白您說BPEL這個方法本來就是分布式的。。。
可能大家對分布式的理解不一樣吧？由BPEL所組合的各種service由于是統一的web?service接口，天生就是分布式的，但所有的控制邏輯都停留在BPEL引擎上，在這種情況下，我們擔心會產生瓶頸，或許在企業內部的系統集成方面不會出現這種問題，但象電信業務，如短消息，預付費這種本身對性能要求非常高的情況下是否會出現瓶頸？呵呵。對BPEL這塊接觸的還不是很深入，呵呵，打擾了。
?
HongSoft
您好：在BPEL中，service可以按coordination方式組合，在這個方式下，BPEL引擎一般不只一個，而是多個BPEL引擎的協同。一般來說是按功能進行分解為1，2，3號引擎（這三個引擎的功能是不同業務的實現）；然后如果3號的負載特別重，可以分為3.1和3.2號子引擎（這兩個引擎的功能是同一個業務的實現）。
電信企業內部的系統集成我是做過的，比如故障運維。而您說的電信業務比如短信這樣的對性能要求非常高的系統下用工作流引擎，我也是做過的。對后者，我們是改造了jBPM引擎，添加了自己業務的activity，然后用圖形的形式表達出來，業務人員可以用圖形化的方式來新建/修改業務；發布自己的流程定義后，業務就能自動執行了。不過我們是在
某
SP
內部使用，而你們可能是需要對應為非常多個的SP，負載要比我們做的業務重一些。我們在高峰期每秒60個流程Instance被create，平均起來每秒20-30個流程Instance。這個系統現在是在穩定的運行中。?
Trackback: http://tb.blog.csdn.net/TrackBack.aspx?PostId=1069051