對(duì)BPEL的思考和評(píng)論

    讓我們近距離看一下上述過程的控制流程。這三個(gè)服務(wù)調(diào)用一起揭示了BPEL語言的關(guān)鍵動(dòng)機(jī)，即簡(jiǎn)化異步服務(wù)交互的處理。在客戶側(cè)，客戶端軟件發(fā)出一條請(qǐng)求 消息后就會(huì)被阻塞，直到收到該服務(wù)調(diào)用的響應(yīng)消息。這就是IN-OUT消息交換模式。假設(shè)服務(wù)綁定使用SOAP over HTTP，這意味著該HTTP請(qǐng)求在響應(yīng)通過相同的TCP/IP連接發(fā)出之前都應(yīng)該被阻塞。同時(shí)，在另一側(cè)過程自己也要等待提供商來執(zhí)行 submitQuote回調(diào)。

    所有的這些在企業(yè)服務(wù)總線（ESB)環(huán)境中都有很大的意義。ESB的思想是：多個(gè)組件按標(biāo)準(zhǔn)方式進(jìn)行連接，然后通過總線與其他組件進(jìn)行通信?？偩€上交換的 消息也是標(biāo)準(zhǔn)的（通常基于WSDL/XML）。一組適配器充當(dāng)協(xié)議（例如SOAP over HTTP、email、FTP、RMI）和總線之間的網(wǎng)關(guān)。

    WS-BPEL也是基于WSDL的，自然能綁定到基于XML的技術(shù)（如Web服務(wù)）。

 
    此外，企業(yè)應(yīng)用也可以被連接到服務(wù)總線上。一旦任何東西在總線上都可作為一個(gè)服務(wù)使用，就像與ESB的交互也是基于WSDL的一樣，BPEL因其技術(shù)基礎(chǔ)是WSDL而顯得意義非凡。因此，ESB是BPEL引擎理想的棲息地。

    ESB主要關(guān)注在基于XML的服務(wù)之間交換基于XML的消息。BPEL從來沒有脫離XML文檔。XPath一般用于剪貼輸入文檔的片段，然后將之保存到過 程變量中。被調(diào)用的服務(wù)、被暴露的服務(wù)和過程變量都是以XML為基礎(chǔ)的。執(zhí)行邏輯也直接用XML表示。在某種程度上這是個(gè)優(yōu)勢(shì)，因?yàn)闊o需在XML信息結(jié)構(gòu) 和編程語言對(duì)象之間進(jìn)行轉(zhuǎn)換。對(duì)于復(fù)雜文檔和對(duì)象結(jié)構(gòu)，這種轉(zhuǎn)換從來都不是透明和自動(dòng)的，需要進(jìn)行開發(fā)和運(yùn)行時(shí)性能調(diào)優(yōu)。

    BPEL復(fù)雜的關(guān)聯(lián)能力使之可以很方便地使用現(xiàn)有消息交換而無需任何修改。不用將過程實(shí)例ID放入消息或上下文的頭部，BPEL引擎可以根據(jù)交換文檔中的 任何信息片段完成關(guān)聯(lián)操作。這種在每一個(gè)文檔交換中標(biāo)識(shí)數(shù)據(jù)項(xiàng)和它們與其他文檔交換匹配的方法可以非常靈活。這非常有用，因?yàn)樵诤芏嗉蓤?chǎng)景中你無權(quán)控制 交換文檔所用的通信協(xié)議。

    但與業(yè)務(wù)過程管理（BPM）的聯(lián)系從何談起呢？從BPM建模者的角度看，這種關(guān)聯(lián)是有疑問的。我唯一找到的現(xiàn)實(shí)聯(lián)系是基于良好的市場(chǎng)營(yíng)銷而非特性。對(duì)于 BPM建模者來說，BPEL缺少了幾個(gè)重要的基本特性。但是當(dāng)你在一個(gè)你無法控制和哪個(gè)伙伴進(jìn)行文檔交換的ESB環(huán)境中用它編寫新服務(wù)的時(shí) 候，BPEL（即使不包括擴(kuò)展）是完備的。因此，就像Maserati和Hummer（譯者：兩種汽車品牌），喜好與否的關(guān)鍵在于你如何用它。

    我能發(fā)現(xiàn)的唯一關(guān)聯(lián)是BPEL過程可以用圖表示，以及語言支持等待狀態(tài)。這意味著某些由業(yè)務(wù)分析師創(chuàng)建的過程模型可以被轉(zhuǎn)換成BPEL過程。但是這種方法 有兩個(gè)主要的局限性。第一，業(yè)務(wù)分析師被假定為非技術(shù)人員。所以，分析模型中的活動(dòng)與現(xiàn)有Web服務(wù)相對(duì)應(yīng)的機(jī)會(huì)非常少（意思是：不存在）。第二個(gè)問題是 BPEL是塊（block）結(jié)構(gòu)。分析模型通常是以圖為基礎(chǔ)的。因此，一般說來，不加修改的把分析圖轉(zhuǎn)換成BPEL可執(zhí)行過程是不可能的。這也是BPMN 與BPEL難以映射，以及局限性如此之多的原因。

    使用BPEL for BPM的最突出的矛盾在于：分析員被假定為不懂技術(shù)，而BPEL過程中的活動(dòng)最終對(duì)應(yīng)到Web服務(wù)調(diào)用。此外，BPEL過程的塊結(jié)構(gòu)天性對(duì)于建模也有太多 的限制。分析員需要自由地畫出方塊和箭頭，它總是產(chǎn)生一個(gè)圖結(jié)構(gòu)和任意循環(huán)（arbitrary cycles）。BPEL過程并沒有變遷的概念。相反，一個(gè)BPEL過程是一個(gè)組合結(jié)構(gòu)，其頂級(jí)活動(dòng)是一個(gè)順序活動(dòng)（sequence）。這個(gè)順序活動(dòng)包 括一個(gè)嵌套的活動(dòng)序列。其中一些是基本（或原子）活動(dòng)，而另一些是復(fù)雜活動(dòng)。復(fù)雜活動(dòng)又會(huì)包含一個(gè)嵌套的活動(dòng)序列。通過好的工具，這些自上而下的活動(dòng)可以 很方便地被用來創(chuàng)建一個(gè)BPEL過程。但是將一個(gè)分析模型映射到一個(gè)BPEL過程則是完全不同的事情，并且很難說這種不同很小。

    使用BPEL for BPM的另外一個(gè)問題是BPEL有限的數(shù)據(jù)處理能力。從XML文檔中提取內(nèi)容片段是你在服務(wù)編制中最需要的功能。但對(duì)于BPM來說，過程步驟之間通常需要完成大量的數(shù)據(jù)處理。XPath和其他的基于XML的轉(zhuǎn)換技術(shù)顯然是不夠的。

    如果你是打算使用BPEL for BPM的架構(gòu)師，你應(yīng)該捫心自問一下是否想讓核心業(yè)務(wù)數(shù)據(jù)出現(xiàn)在ESB中。在IT行業(yè)從存儲(chǔ)過程轉(zhuǎn)移到如JEE這樣的企業(yè)技術(shù)過程中，對(duì)構(gòu)建數(shù)據(jù)在“云中 ”的新應(yīng)用的管理更方便了。BPEL引擎需要維護(hù)的數(shù)據(jù)和領(lǐng)域模型（如顧客、客戶、提供商等等）有關(guān)。這些領(lǐng)域數(shù)據(jù)通常存儲(chǔ)在IT基礎(chǔ)設(shè)施的關(guān)系數(shù)據(jù)庫(kù) 中。核心業(yè)務(wù)過程中的信息必須能夠很方便地鏈接到關(guān)系數(shù)據(jù)庫(kù)中的領(lǐng)域數(shù)據(jù)。假如你的JAVA應(yīng)用需要了解一個(gè)文檔的客戶引用怎么辦？你想將那個(gè)文檔作為過 程參數(shù)傳給BPEL引擎，然后使用XPATH從那個(gè)XML文檔中抽取引用嗎？這就暗示這個(gè)信息應(yīng)該包含數(shù)據(jù)庫(kù)的領(lǐng)域模型中，而不是在BPEL引擎中。 BPEL并沒有阻止你把這種信息存儲(chǔ)在領(lǐng)域模型數(shù)據(jù)庫(kù)中，但是它為這種做法添加了困難。你可能必須實(shí)現(xiàn)一個(gè)特殊的Web服務(wù)來獲取存儲(chǔ)在領(lǐng)域模型中的客戶 引用。所以，BPEL可能會(huì)很容易讓你的領(lǐng)域模型信息支離破碎。要小心。

    David的BPEL反例（Case against BPEL），Joe McKendrick就David Chappell的博客所寫的文章，以及Jeff Davis的“BPEL怎么了（What‘s wrong with BPEL）”，都持類似的觀點(diǎn)：BPEL不適合BPM。

    別誤會(huì)，我沒有貶低BPEL。我的觀點(diǎn)是BPEL非常適合將一組現(xiàn)有服務(wù)組合成一個(gè)新服務(wù)。但從我們目前所了解的情況看，它沒有交付它對(duì)于BPM的承諾。

    BPEL擴(kuò)展

    BPEL4People定義了在BPEL過程中包含人工任務(wù)的方式。BPEL4People使用BPEL擴(kuò)展機(jī)制將人工任務(wù)作為活動(dòng)加入到一個(gè)BPEL過 程中。這個(gè)規(guī)范定義了BPEL引擎和任務(wù)組件之間的消息交換協(xié)議。BPEL4People引入了人員鏈接（people link）的概念。任務(wù)分配就是對(duì)負(fù)責(zé)一項(xiàng)任務(wù)的人員或組的選擇（Selection）。BPEL4People規(guī)定了人員或組的描述方式。但是，對(duì)于選 擇（Selection）的運(yùn)行時(shí)計(jì)算和身份信息結(jié)構(gòu)并沒有包括在規(guī)范當(dāng)中。最近，支持BPEL4People的公司決定將此規(guī)范提交給OASIS進(jìn)行標(biāo) 準(zhǔn)化。因此，在不久的將來有望在大多數(shù)BPEL實(shí)現(xiàn)中找到BPEL4People。

    BPEL4People加入的工作流功能，通常被視為是對(duì)BPEL修正，這有助于BPEL更好的與BPM相適應(yīng)。但這種情況不現(xiàn)實(shí)。當(dāng)分析員建?；顒?dòng)時(shí)， 他們通常將之對(duì)應(yīng)到人工任務(wù)或系統(tǒng)處理。BPEL仍然強(qiáng)制活動(dòng)之間的通信需由基于XML的過程變量完成。如果開發(fā)者需要加入一個(gè)使用XSLT的轉(zhuǎn)換，即使 業(yè)務(wù)分析師根本不關(guān)心這個(gè)技術(shù)細(xì)節(jié)，它也會(huì)是一個(gè)突然出現(xiàn)在圖中的新活動(dòng)。BPEL過程圖的圖形活動(dòng)布局仍然與WEB服務(wù)和XML技術(shù)的耦合過于緊密，以 致于無法在保持分析圖完整的同時(shí)使過程可執(zhí)行。

    BPELJ是一個(gè)舊的白皮書，它是關(guān)注Java和BPEL過程綁定的標(biāo)準(zhǔn)提案。其中涵蓋了多個(gè)方面內(nèi)容，如在BPEL過程中包含Java代碼片段，將 Java對(duì)象作為變量和從BPEL過程調(diào)用Java beans。JCP中的JSR 207 Process Definition for Java試圖將此作為Java標(biāo)準(zhǔn)。但自從2003后，就沒有看到這方面的任何進(jìn)展。

    即使有了這些擴(kuò)展，BPEL的主要問題依舊存在。當(dāng)它用于業(yè)務(wù)過程管理時(shí)，它不能很好地支持過程建模。業(yè)務(wù)分析師在建模時(shí)不能自由發(fā)揮，因?yàn)閳D需要與 WSDL服務(wù)建立直接和緊密的關(guān)系。BPM需要將圖和底層技術(shù)解耦。分析師必須能完全自由地畫圖，而開發(fā)者必須能夠在不改動(dòng)圖的情況下把過程執(zhí)行嵌入到應(yīng) 用架構(gòu)中。BPEL對(duì)此無能為力。這意味這BPEL很爛嗎？不。假如BPEL被作為一種從細(xì)粒度服務(wù)中創(chuàng)建粗粒度服務(wù)的集成技術(shù)來使用的話，它擁有你需要 的一切特性。

    BPMN

    什么是BPMN

    BPMN目前被作為一種建模符號(hào)使用。它定義了用于過程建模的方框和箭頭的外觀。對(duì)于BPMN是否應(yīng)該定義執(zhí)行語義和它是否應(yīng)該只關(guān)注圖形表示的問題上，以前和現(xiàn)在都有非常多的討論。

    
 
    這個(gè)規(guī)范包括圖形形狀，含義描述和每個(gè)結(jié)構(gòu)的屬性集合。BPMN期望解決BPMN結(jié)構(gòu)和屬性與特定過程執(zhí)行語言的映射問題。規(guī)范本身就包括了一個(gè)這樣的 BPMN和BPEL映射。BPMN沒有定義XML或其他文件格式。一個(gè)可能性是BPDM（見下）在未來會(huì)定義一個(gè)這樣的文件格式。在給出對(duì)于BPMN的思 考和觀點(diǎn)之前，我想首先給出一些關(guān)于分析過程和可執(zhí)行過程之間差異的更多背景。

    分析和執(zhí)行

    當(dāng)某人用方框和箭頭畫了一個(gè)圖，這個(gè)圖可以表示許多不同的事物：

    *文檔，向其他人解釋人和系統(tǒng)是如何一起工作來達(dá)成某個(gè)目標(biāo)的
    *一個(gè)可執(zhí)行過程，就像任何其他軟件一樣，向計(jì)算機(jī)系統(tǒng)解釋其行為方式
    *一個(gè)與某個(gè)軟件技術(shù)部件（如Java類）相關(guān)聯(lián)的狀態(tài)機(jī)，它可能和任何業(yè)務(wù)過程都沒有關(guān)系
    *一種通信協(xié)議，描述多方間的消息交換
    *Web應(yīng)用的一組頁面，箭頭表示導(dǎo)航選擇

    讓我們進(jìn)一步看看圖的這兩個(gè)用途：為分析而畫的圖和為一個(gè)可執(zhí)行過程而畫的圖。首先，業(yè)務(wù)層面的人員不會(huì)考慮系統(tǒng)的邊界。對(duì)于一個(gè)分析過程中的自動(dòng)化模塊 而言，分析員通常不知道它如何執(zhí)行或在哪個(gè)系統(tǒng)上執(zhí)行。第二，當(dāng)分析員為業(yè)務(wù)過程寫文檔時(shí)，其目的是為了向另一個(gè)人解釋人和系統(tǒng)協(xié)作的方式。作為描述的一 部分，圖有助于給出一個(gè)快速的概覽。過程描述可以假設(shè)讀者對(duì)被解釋過程的上下文已知。因此過程描述的詳細(xì)程度可以變化。

    這與可執(zhí)行過程區(qū)別非常大，后者是業(yè)務(wù)過程管理系統(tǒng)（BPMS）的輸入?？蓤?zhí)行過程精確定義了這個(gè)BPMS應(yīng)該如何運(yùn)轉(zhuǎn)。從這點(diǎn)來講，它就是軟件，與編程語言唯一不同之處就是所用的語言。所以可執(zhí)行過程語言向系統(tǒng)解釋了它該做什么。

    當(dāng)使業(yè)務(wù)過程自動(dòng)化時(shí)，分析和可執(zhí)行過程的聯(lián)系來自于這一共同需求：一個(gè)計(jì)算機(jī)系統(tǒng)需要跟蹤業(yè)務(wù)過程中所有活動(dòng)的進(jìn)展。為了達(dá)到這個(gè)目的，活動(dòng)結(jié)束時(shí)需要告知管理這些信息的系統(tǒng)。系統(tǒng)或許可以自己執(zhí)行某些活動(dòng)，這些活動(dòng)被稱為自動(dòng)活動(dòng)。

    即使在今天，許多BPM系統(tǒng)的市場(chǎng)營(yíng)銷都是這樣：“讓你的業(yè)務(wù)分析師畫出業(yè)務(wù)過程的工作方式，然后這個(gè)圖形描述將在BPMS上運(yùn)行。”哪個(gè)經(jīng)理愿意讓一個(gè) 不懂技術(shù)的業(yè)務(wù)分析師畫的東西運(yùn)行在生產(chǎn)線上？！BPM系統(tǒng)的機(jī)會(huì)在于如下事實(shí)：業(yè)務(wù)過程分析圖可以和可執(zhí)行業(yè)務(wù)過程圖看起來非常相似。圖可以促進(jìn)分析員 和開發(fā)者的溝通，但始終是開發(fā)者負(fù)責(zé)可執(zhí)行過程的所有技術(shù)細(xì)節(jié)。

    當(dāng)分析員畫的圖作為可執(zhí)行過程的基礎(chǔ)時(shí)，假如可執(zhí)行過程語言不能靈活地將圖和技術(shù)解耦，圖就有可能不得不進(jìn)行改變。例如，假設(shè)需要先收集一個(gè)人提供的輸入 信息，然后再將其作為輸入傳給Java代碼去執(zhí)行，業(yè)務(wù)分析師可能會(huì)對(duì)此建模成兩個(gè)連續(xù)活動(dòng)。但是，如果要用BPEL使這個(gè)過程可執(zhí)行，可能必須加入一個(gè) 賦值活動(dòng)來將入?yún)⑥D(zhuǎn)換成Java代碼需要的格式。這說明當(dāng)分析過程作為可執(zhí)行過程的基礎(chǔ)時(shí)，通常需要進(jìn)行轉(zhuǎn)換。

    另一方面我想指出的是：過程語言在復(fù)雜度和適用范圍上可以有很大的不同。一些過程語言能力有限，只適用某一特定用途。一個(gè)文檔管理系統(tǒng)中用于批準(zhǔn)的語言就 是一個(gè)好例子。這種語言可以非常簡(jiǎn)單而且不需要太多的技術(shù)細(xì)節(jié)。這種圖在過程中占很大比重，非技術(shù)人員確實(shí)可以用這種方法構(gòu)建一個(gè)完全可執(zhí)行的過程。但對(duì) 于象BPEL或jPDL這樣的通用過程語言而言，情況就不一樣了。這些語言有更大的適用范圍，因此它們更加復(fù)雜而且需要更多的技術(shù)細(xì)節(jié)。此時(shí)，總是需要一 個(gè)開發(fā)者來管理技術(shù)細(xì)節(jié)。