過程組件模型
-- 下一代工作流？
作者：Tom Baeyens 2008-08-05
【IT168 技術(shù)文章】 這準(zhǔn)確道出了BPM行業(yè)中或許并不明顯的巨大分歧。“BPM族人”是指那些專注過程建模的人。他們的出發(fā)點在于分析那些描述組織內(nèi)人和系統(tǒng)協(xié)作方式的過 程。在建模者眼中，最初的焦點并非技術(shù)，而是描述人和系統(tǒng)協(xié)作方式的非技術(shù)業(yè)務(wù)分析。過程自動化在許多這類BPM項目中甚至根本未被考慮。這些項目的最終 目標(biāo)實際是要通過記錄核心業(yè)務(wù)過程來更深入地了解組織是如何運作的。由這個背景所產(chǎn)生的純BPM產(chǎn)品旨在通過軟件自動化來簡化對這類業(yè)務(wù)過程的描述。這個 陣營我稱之為BPM建模者。 “WS族人”是指那些專注創(chuàng)建可執(zhí)行過程的人?？蓤?zhí)行過程是作為業(yè)務(wù)過程管理系統(tǒng)（BPMS）輸入的軟件部件。它通常由圖形化的圖表表示。目前，只有一種 可執(zhí)行過程語言被大型提供商采用，它就是BPEL。BPEL是基于WS-*標(biāo)準(zhǔn)的，這也是那些專注自動化的人被稱為“WS族人”的原因。隨著BPEL逐漸 得到認(rèn)可，服務(wù)編制最近也受到了吹捧。這個陣營我稱之為編制開發(fā)者。 兩個流派的共同之處在于都關(guān)注圖形化的圖表且都包括了等待狀態(tài)。對BPM建模者和編制開發(fā)者來說，圖表是一個很重要的工具。圖表能為某個過程提供一個快速 概覽。盡管這是個強大的工具，但對于這種可察覺的簡單性要保持警惕。因為，看起來相似的圖表會由于所使用的符號或底層可執(zhí)行過程語言的不同，其含義會有巨 大區(qū)別。另外，圖表的用途也是一個非常重要的考慮因素。對于業(yè)務(wù)分析師來說，過程圖表的目的是為了幫助向另一個人解釋業(yè)務(wù)過程。這些圖表提供了一個整體概 覽，一定程度的模糊性是允許的。對于可執(zhí)行過程語言，圖表是定義計算機系統(tǒng)必須遵循的行為方式的過程的一部分。因此，這種過程必須含義明確且能被準(zhǔn)確地解 釋。 本質(zhì)上，等待狀態(tài)的包含是個更技術(shù)性的話題，但在兩個流派中也都找到它的蹤跡。當(dāng)業(yè)務(wù)分析師繪制業(yè)務(wù)過程時，不同的活動可能會關(guān)聯(lián)到不同資源。一些活動會 翻譯成人工任務(wù)，而另一些則會翻譯成可在計算機系統(tǒng)中執(zhí)行的一段軟件代碼。假如這一過程是自動完成的，過程引擎會驅(qū)動過程的執(zhí)行。這意味著引擎內(nèi)部會自動 地執(zhí)行一些活動。否則，如果活動在過程引擎外執(zhí)行，那么引擎就需要跟蹤當(dāng)前狀態(tài)并在接收到外部實體發(fā)來的信號前保持等待。例如，這個外部觸發(fā)器可能是用戶 對Web應(yīng)用中表示任務(wù)完成按鈕的一次點擊。類似的還有，ERP系統(tǒng)可能通知過程引擎某個發(fā)票已經(jīng)處理完畢。等待狀態(tài)的概念或許顯得有些抽象，你或許會問 這和工作流或過程語言的討論有什么關(guān)聯(lián)性。一個重要原因就是象Java這樣的傳統(tǒng)編程語言不支持可持久化的等待狀態(tài)。 這篇文章認(rèn)為業(yè)務(wù)過程的分析和實現(xiàn)間的差距遠(yuǎn)比當(dāng)前工作流工具市場所顯現(xiàn)出的還要大。同時，本文還提出了解決這種狀況更現(xiàn)實的辦法。文中對當(dāng)前標(biāo)準(zhǔn)和項目 進(jìn)行了足夠深入地探討，以便讓你可以理解它們與這些流派的關(guān)聯(lián)方式及其原因。在討論中，我會指出每一個被提及技術(shù)的優(yōu)缺點，以及正確使用它們的方式。 文末，我會介紹一種名為過程組件模型的工作流新技術(shù)。這種框架可以處理多種過程語言，為那些能將分析過程圖更好地轉(zhuǎn)換成可執(zhí)行過程的過程語言提供了支持。 WS-BPEL 什么是BPEL WS-BPEL是一個用于服務(wù)編制的OASIS標(biāo)準(zhǔn)。服務(wù)編制就是將一組現(xiàn)有服務(wù)組合成一個新服務(wù)。 這是對BPEL過程的簡單地剖析：部署一個BPEL過程會導(dǎo)致為該過程發(fā)布一個服務(wù)。這個BPEL過程會指定必須發(fā)布的服務(wù)，以及這些服務(wù)操作的實現(xiàn)。 下一步是調(diào)用（invoke）活動。調(diào)用活動會調(diào)用另一個WSDL服務(wù)并將響應(yīng)消息收集到一個過程變量里。在我們的例子里，getQuote在供應(yīng)商上被調(diào)用。 來自輸入消息的信息可以被存儲在過程變量中。整個消息都可以被存儲，包括XML片斷或XSD基本類型。象extractProductName這樣的賦值 （assign）活動可以從一個變量中（一般是基于XML的內(nèi)容）提取部分信息，然后將之保存到另一個變量中。這樣，變量就可被用來為其他調(diào)用或當(dāng)前請求 的響應(yīng)合成消息。 接收活動receiveQuote將使過程實例處于等待狀態(tài)，直到提供商調(diào)用submitQuote服務(wù)操作。擁有submitQuote 操作的服務(wù)也會在BPEL過程部署時發(fā)布。當(dāng)供應(yīng)商傳入了與這個訂單有關(guān)的報價后，過程將繼續(xù)執(zhí)行并離開receiveQuote活動。 應(yīng)答（reply）活動用來為未完成的服務(wù)請求組織一條響應(yīng)消息。因此，應(yīng)答活動只有在這種情況下才有意義：在進(jìn)入一個具有IN-OUT消息交換的服務(wù)操作前，接收操作接收到了一條消息。 注意，在供應(yīng)商調(diào)用submitQuote操作時，輸入消息必須通過離開這個接收活動來觸發(fā)過程繼續(xù)執(zhí)行。這是BPEL的另一特性，它被稱為關(guān)聯(lián) （correlation）。在BPEL過程中，關(guān)聯(lián)是指輸入服務(wù)請求消息和當(dāng)前正在等待此消息的過程實例間的匹配。假如一個接收節(jié)點被標(biāo)記為開始，該操 作上的輸入消息將會創(chuàng)建一個新的過程實例。一般說來，輸入文檔中的某些數(shù)據(jù)項這時會被標(biāo)記為一個唯一的關(guān)聯(lián)ID，如訂單ID。根據(jù)輸入消息文檔中包含的訂 單ID，過程中接收節(jié)點的輸入消息稍后會關(guān)聯(lián)到對應(yīng)的過程實例上。在現(xiàn)實中，關(guān)聯(lián)集可以由多個屬性的多個個體集合組成，但為了簡單起見，那些額外的復(fù)雜性 略去不談。 伙伴鏈接（partner links）用來標(biāo)識那些參與BPEL過程通信的外部團(tuán)體。從BPEL過程到伙伴的服務(wù)調(diào)用和伙伴對BPEL過程的調(diào)用都關(guān)聯(lián)到伙伴鏈接。這兩個方向都被 稱為角色（roles），每一個角色對應(yīng)一個端口類型（port type）。端口類型指定了伙伴鏈接中該方向的通信接口。因此一個伙伴鏈接可以聲明兩個角色，需要指出這兩個角色中的哪一個代表了BPEL過程端。與伙伴 鏈接中BPEL過程角色相對應(yīng)的服務(wù)會在部署過程的時候發(fā)布。另外一個則會在服務(wù)調(diào)用時使用。 這里總結(jié)了BPEL的大部分基本內(nèi)容。另外一些是BPEL的更高級特性，如補償處理（compensation handling）、事件處理（event handling）、并發(fā)執(zhí)行路徑和定時器。因它們與以后的討論沒有太大的關(guān)系，所以沒有在這里介紹。
對BPEL的思考和評論 讓我們近距離看一下上述過程的控制流程。這三個服務(wù)調(diào)用一起揭示了BPEL語言的關(guān)鍵動機，即簡化異步服務(wù)交互的處理。在客戶側(cè)，客戶端軟件發(fā)出一條請求 消息后就會被阻塞，直到收到該服務(wù)調(diào)用的響應(yīng)消息。這就是IN-OUT消息交換模式。假設(shè)服務(wù)綁定使用SOAP over HTTP，這意味著該HTTP請求在響應(yīng)通過相同的TCP/IP連接發(fā)出之前都應(yīng)該被阻塞。同時，在另一側(cè)過程自己也要等待提供商來執(zhí)行 submitQuote回調(diào)。 所有的這些在企業(yè)服務(wù)總線（ESB)環(huán)境中都有很大的意義。ESB的思想是：多個組件按標(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ù)）。 ESB主要關(guān)注在基于XML的服務(wù)之間交換基于XML的消息。BPEL從來沒有脫離XML文檔。XPath一般用于剪貼輸入文檔的片段，然后將之保存到過 程變量中。被調(diào)用的服務(wù)、被暴露的服務(wù)和過程變量都是以XML為基礎(chǔ)的。執(zhí)行邏輯也直接用XML表示。在某種程度上這是個優(yōu)勢，因為無需在XML信息結(jié)構(gòu) 和編程語言對象之間進(jìn)行轉(zhuǎn)換。對于復(fù)雜文檔和對象結(jié)構(gòu)，這種轉(zhuǎn)換從來都不是透明和自動的，需要進(jìn)行開發(fā)和運行時性能調(diào)優(yōu)。 BPEL復(fù)雜的關(guān)聯(lián)能力使之可以很方便地使用現(xiàn)有消息交換而無需任何修改。不用將過程實例ID放入消息或上下文的頭部，BPEL引擎可以根據(jù)交換文檔中的 任何信息片段完成關(guān)聯(lián)操作。這種在每一個文檔交換中標(biāo)識數(shù)據(jù)項和它們與其他文檔交換匹配的方法可以非常靈活。這非常有用，因為在很多集成場景中你無權(quán)控制 交換文檔所用的通信協(xié)議。 但與業(yè)務(wù)過程管理（BPM）的聯(lián)系從何談起呢？從BPM建模者的角度看，這種關(guān)聯(lián)是有疑問的。我唯一找到的現(xiàn)實聯(lián)系是基于良好的市場營銷而非特性。對于 BPM建模者來說，BPEL缺少了幾個重要的基本特性。但是當(dāng)你在一個你無法控制和哪個伙伴進(jìn)行文檔交換的ESB環(huán)境中用它編寫新服務(wù)的時 候，BPEL（即使不包括擴展）是完備的。因此，就像Maserati和Hummer（譯者：兩種汽車品牌），喜好與否的關(guān)鍵在于你如何用它。 我能發(fā)現(xiàn)的唯一關(guān)聯(lián)是BPEL過程可以用圖表示，以及語言支持等待狀態(tài)。這意味著某些由業(yè)務(wù)分析師創(chuàng)建的過程模型可以被轉(zhuǎn)換成BPEL過程。但是這種方法 有兩個主要的局限性。第一，業(yè)務(wù)分析師被假定為非技術(shù)人員。所以，分析模型中的活動與現(xiàn)有Web服務(wù)相對應(yīng)的機會非常少（意思是：不存在）。第二個問題是 BPEL是塊（block）結(jié)構(gòu)。分析模型通常是以圖為基礎(chǔ)的。因此，一般說來，不加修改的把分析圖轉(zhuǎn)換成BPEL可執(zhí)行過程是不可能的。這也是BPMN 與BPEL難以映射，以及局限性如此之多的原因。 使用BPEL for BPM的最突出的矛盾在于：分析員被假定為不懂技術(shù)，而BPEL過程中的活動最終對應(yīng)到Web服務(wù)調(diào)用。此外，BPEL過程的塊結(jié)構(gòu)天性對于建模也有太多 的限制。分析員需要自由地畫出方塊和箭頭，它總是產(chǎn)生一個圖結(jié)構(gòu)和任意循環(huán)（arbitrary cycles）。BPEL過程并沒有變遷的概念。相反，一個BPEL過程是一個組合結(jié)構(gòu)，其頂級活動是一個順序活動（sequence）。這個順序活動包 括一個嵌套的活動序列。其中一些是基本（或原子）活動，而另一些是復(fù)雜活動。復(fù)雜活動又會包含一個嵌套的活動序列。通過好的工具，這些自上而下的活動可以 很方便地被用來創(chuàng)建一個BPEL過程。但是將一個分析模型映射到一個BPEL過程則是完全不同的事情，并且很難說這種不同很小。 使用BPEL for BPM的另外一個問題是BPEL有限的數(shù)據(jù)處理能力。從XML文檔中提取內(nèi)容片段是你在服務(wù)編制中最需要的功能。但對于BPM來說，過程步驟之間通常需要完成大量的數(shù)據(jù)處理。XPath和其他的基于XML的轉(zhuǎn)換技術(shù)顯然是不夠的。 如果你是打算使用BPEL for BPM的架構(gòu)師，你應(yīng)該捫心自問一下是否想讓核心業(yè)務(wù)數(shù)據(jù)出現(xiàn)在ESB中。在IT行業(yè)從存儲過程轉(zhuǎn)移到如JEE這樣的企業(yè)技術(shù)過程中，對構(gòu)建數(shù)據(jù)在“云中 ”的新應(yīng)用的管理更方便了。BPEL引擎需要維護(hù)的數(shù)據(jù)和領(lǐng)域模型（如顧客、客戶、提供商等等）有關(guān)。這些領(lǐng)域數(shù)據(jù)通常存儲在IT基礎(chǔ)設(shè)施的關(guān)系數(shù)據(jù)庫 中。核心業(yè)務(wù)過程中的信息必須能夠很方便地鏈接到關(guān)系數(shù)據(jù)庫中的領(lǐng)域數(shù)據(jù)。假如你的JAVA應(yīng)用需要了解一個文檔的客戶引用怎么辦？你想將那個文檔作為過 程參數(shù)傳給BPEL引擎，然后使用XPATH從那個XML文檔中抽取引用嗎？這就暗示這個信息應(yīng)該包含數(shù)據(jù)庫的領(lǐng)域模型中，而不是在BPEL引擎中。 BPEL并沒有阻止你把這種信息存儲在領(lǐng)域模型數(shù)據(jù)庫中，但是它為這種做法添加了困難。你可能必須實現(xiàn)一個特殊的Web服務(wù)來獲取存儲在領(lǐng)域模型中的客戶 引用。所以，BPEL可能會很容易讓你的領(lǐng)域模型信息支離破碎。要小心。 David的BPEL反例（Case against BPEL），Joe McKendrick就David Chappell的博客所寫的文章，以及Jeff Davis的“BPEL怎么了（What‘s wrong with BPEL）”，都持類似的觀點：BPEL不適合BPM。 別誤會，我沒有貶低BPEL。我的觀點是BPEL非常適合將一組現(xiàn)有服務(wù)組合成一個新服務(wù)。但從我們目前所了解的情況看，它沒有交付它對于BPM的承諾。
BPEL擴展 BPEL4People定義了在BPEL過程中包含人工任務(wù)的方式。BPEL4People使用BPEL擴展機制將人工任務(wù)作為活動加入到一個BPEL過 程中。這個規(guī)范定義了BPEL引擎和任務(wù)組件之間的消息交換協(xié)議。BPEL4People引入了人員鏈接（people link）的概念。任務(wù)分配就是對負(fù)責(zé)一項任務(wù)的人員或組的選擇（Selection）。BPEL4People規(guī)定了人員或組的描述方式。但是，對于選 擇（Selection）的運行時計算和身份信息結(jié)構(gòu)并沒有包括在規(guī)范當(dāng)中。最近，支持BPEL4People的公司決定將此規(guī)范提交給OASIS進(jìn)行標(biāo) 準(zhǔn)化。因此，在不久的將來有望在大多數(shù)BPEL實現(xiàn)中找到BPEL4People。 BPEL4People加入的工作流功能，通常被視為是對BPEL修正，這有助于BPEL更好的與BPM相適應(yīng)。但這種情況不現(xiàn)實。當(dāng)分析員建模活動時， 他們通常將之對應(yīng)到人工任務(wù)或系統(tǒng)處理。BPEL仍然強制活動之間的通信需由基于XML的過程變量完成。如果開發(fā)者需要加入一個使用XSLT的轉(zhuǎn)換，即使 業(yè)務(wù)分析師根本不關(guān)心這個技術(shù)細(xì)節(jié)，它也會是一個突然出現(xiàn)在圖中的新活動。BPEL過程圖的圖形活動布局仍然與WEB服務(wù)和XML技術(shù)的耦合過于緊密，以 致于無法在保持分析圖完整的同時使過程可執(zhí)行。 BPELJ是一個舊的白皮書，它是關(guān)注Java和BPEL過程綁定的標(biāo)準(zhǔn)提案。其中涵蓋了多個方面內(nèi)容，如在BPEL過程中包含Java代碼片段，將 Java對象作為變量和從BPEL過程調(diào)用Java beans。JCP中的JSR 207 Process Definition for Java試圖將此作為Java標(biāo)準(zhǔn)。但自從2003后，就沒有看到這方面的任何進(jìn)展。 即使有了這些擴展，BPEL的主要問題依舊存在。當(dāng)它用于業(yè)務(wù)過程管理時，它不能很好地支持過程建模。業(yè)務(wù)分析師在建模時不能自由發(fā)揮，因為圖需要與 WSDL服務(wù)建立直接和緊密的關(guān)系。BPM需要將圖和底層技術(shù)解耦。分析師必須能完全自由地畫圖，而開發(fā)者必須能夠在不改動圖的情況下把過程執(zhí)行嵌入到應(yīng) 用架構(gòu)中。BPEL對此無能為力。這意味這BPEL很爛嗎？不。假如BPEL被作為一種從細(xì)粒度服務(wù)中創(chuàng)建粗粒度服務(wù)的集成技術(shù)來使用的話，它擁有你需要 的一切特性。 BPMN 什么是BPMN BPMN目前被作為一種建模符號使用。它定義了用于過程建模的方框和箭頭的外觀。對于BPMN是否應(yīng)該定義執(zhí)行語義和它是否應(yīng)該只關(guān)注圖形表示的問題上，以前和現(xiàn)在都有非常多的討論。 分析和執(zhí)行 當(dāng)某人用方框和箭頭畫了一個圖，這個圖可以表示許多不同的事物： *文檔，向其他人解釋人和系統(tǒng)是如何一起工作來達(dá)成某個目標(biāo)的 讓我們進(jìn)一步看看圖的這兩個用途：為分析而畫的圖和為一個可執(zhí)行過程而畫的圖。首先，業(yè)務(wù)層面的人員不會考慮系統(tǒng)的邊界。對于一個分析過程中的自動化模塊 而言，分析員通常不知道它如何執(zhí)行或在哪個系統(tǒng)上執(zhí)行。第二，當(dāng)分析員為業(yè)務(wù)過程寫文檔時，其目的是為了向另一個人解釋人和系統(tǒng)協(xié)作的方式。作為描述的一 部分，圖有助于給出一個快速的概覽。過程描述可以假設(shè)讀者對被解釋過程的上下文已知。因此過程描述的詳細(xì)程度可以變化。 這與可執(zhí)行過程區(qū)別非常大，后者是業(yè)務(wù)過程管理系統(tǒng)（BPMS）的輸入?？蓤?zhí)行過程精確定義了這個BPMS應(yīng)該如何運轉(zhuǎn)。從這點來講，它就是軟件，與編程語言唯一不同之處就是所用的語言。所以可執(zhí)行過程語言向系統(tǒng)解釋了它該做什么。 當(dāng)使業(yè)務(wù)過程自動化時，分析和可執(zhí)行過程的聯(lián)系來自于這一共同需求：一個計算機系統(tǒng)需要跟蹤業(yè)務(wù)過程中所有活動的進(jìn)展。為了達(dá)到這個目的，活動結(jié)束時需要告知管理這些信息的系統(tǒng)。系統(tǒng)或許可以自己執(zhí)行某些活動，這些活動被稱為自動活動。 即使在今天，許多BPM系統(tǒng)的市場營銷都是這樣：“讓你的業(yè)務(wù)分析師畫出業(yè)務(wù)過程的工作方式，然后這個圖形描述將在BPMS上運行。”哪個經(jīng)理愿意讓一個 不懂技術(shù)的業(yè)務(wù)分析師畫的東西運行在生產(chǎn)線上？！BPM系統(tǒng)的機會在于如下事實：業(yè)務(wù)過程分析圖可以和可執(zhí)行業(yè)務(wù)過程圖看起來非常相似。圖可以促進(jìn)分析員 和開發(fā)者的溝通，但始終是開發(fā)者負(fù)責(zé)可執(zhí)行過程的所有技術(shù)細(xì)節(jié)。 當(dāng)分析員畫的圖作為可執(zhí)行過程的基礎(chǔ)時，假如可執(zhí)行過程語言不能靈活地將圖和技術(shù)解耦，圖就有可能不得不進(jìn)行改變。例如，假設(shè)需要先收集一個人提供的輸入 信息，然后再將其作為輸入傳給Java代碼去執(zhí)行，業(yè)務(wù)分析師可能會對此建模成兩個連續(xù)活動。但是，如果要用BPEL使這個過程可執(zhí)行，可能必須加入一個 賦值活動來將入?yún)⑥D(zhuǎn)換成Java代碼需要的格式。這說明當(dāng)分析過程作為可執(zhí)行過程的基礎(chǔ)時，通常需要進(jìn)行轉(zhuǎn)換。 另一方面我想指出的是：過程語言在復(fù)雜度和適用范圍上可以有很大的不同。一些過程語言能力有限，只適用某一特定用途。一個文檔管理系統(tǒng)中用于批準(zhǔn)的語言就 是一個好例子。這種語言可以非常簡單而且不需要太多的技術(shù)細(xì)節(jié)。這種圖在過程中占很大比重，非技術(shù)人員確實可以用這種方法構(gòu)建一個完全可執(zhí)行的過程。但對 于象BPEL或jPDL這樣的通用過程語言而言，情況就不一樣了。這些語言有更大的適用范圍，因此它們更加復(fù)雜而且需要更多的技術(shù)細(xì)節(jié)。此時，總是需要一 個開發(fā)者來管理技術(shù)細(xì)節(jié)。 過程開發(fā)的過程 在知道了這些之后，我想勾勒出一個對于業(yè)務(wù)過程自動化更實際的分析和開發(fā)過程例子。首先，一個分析員創(chuàng)建了一個包括圖的業(yè)務(wù)過程描述。然后需要將它翻譯成 可執(zhí)行過程語言。這種翻譯的影響將取決于這個分析員的技術(shù)技能和可執(zhí)行過程語言的能力。任何情況下的目的都是使轉(zhuǎn)換對圖影響最小，這樣業(yè)務(wù)分析師才能認(rèn)識 和理解可執(zhí)行過程圖。注意，圖只是冰山的一角，因為對分析師毫無興趣的可執(zhí)行過程將包括大部分的技術(shù)細(xì)節(jié)。翻譯之后，可執(zhí)行過程就成為了一個軟件，非技術(shù) 出身的業(yè)務(wù)分析師只允許以只讀方式查看它。 BPM帶來的巨大優(yōu)勢是分析員和開發(fā)者擁有一門公共語言。圖方便了業(yè)務(wù)分析師和開發(fā)者的溝通。這的確實現(xiàn)了由BPM帶來的‘敏捷’。但是幻想出現(xiàn)業(yè)務(wù)分析師在編輯圖表之后點一下‘發(fā)布成產(chǎn)品’按鈕就萬事大吉的情景顯然過于樂觀且不現(xiàn)實。 建模細(xì)節(jié) 這節(jié)將論證這一觀點：當(dāng)需要在分析圖和可執(zhí)行過程間建立直接關(guān)系時，圖中不要包括太多的細(xì)節(jié)。參與BPMN的人員背景是不同的。當(dāng)人們僅僅只站在BPM的 分析模型或可執(zhí)行過程側(cè)面看問題的時候，他們必然會象Frank McCabe在一次OMG會議中所發(fā)表的報告那樣感到驚訝： 關(guān)于BPMN和BPDM的關(guān)系有些爭論：BPMN‘僅僅’是一個符號，或者它確實有某種語義？所有的這些對BPMN團(tuán)隊來說都是新聞，因為他們（包括我） 都愉悅地認(rèn)為我們正在努力定義一種語言。對于我們來說，最大的問題好像是關(guān)于BPMN圖的執(zhí)行語義；對其他人來講，它只是一個圖形符號，完全不需要我們操 心執(zhí)行的事兒。你可能會猜到事情接下來會怎樣。 這表明建模專家需要一種非常準(zhǔn)確的符號以便在圖上能放置大量的信息。作為一種幫助記錄業(yè)務(wù)過程的分析語言，我認(rèn)為BPMN是一個很好的選擇。David Chappell提倡建模層次的移植性和實現(xiàn)（可執(zhí)行過程）層次的移植性至少同樣重要。 想一想我們一直以來想要達(dá)到的目標(biāo)，過程邏輯的移植性——把實現(xiàn)從一個平臺移到另一個平臺的能力——無疑是其中之一。但是人的移植性——允許我們把技能從 一種過程設(shè)計工具轉(zhuǎn)移到另一種工具的能力——也很重要。BPEL潛在地可以幫助完成第一個目標(biāo)，但卻不適合第二個；大部分創(chuàng)建過程的人從來不會直接使用這 種復(fù)雜的基于XML的語言工作……正在崛起的圖形化定義過程的標(biāo)準(zhǔn)就是業(yè)務(wù)過程建模符號（BPMN）。如果BPMN得到廣泛的支持——這好像是可能的—— 它將使人的過程設(shè)計技能可以移植。 這讓我得出這樣的結(jié)論：假如要將過程建模綁定到可執(zhí)行過程上，過程的圖形化表示不應(yīng)該包括太多的信息。當(dāng)在你的組織中使用BPMN來進(jìn)行過程建模的時候， 最好引入一個更基本的子集，并且只使用它們。因為，試圖在圖形化的圖表中表達(dá)太多的細(xì)節(jié)需要所有人都能理解它們。圖形符號中的細(xì)節(jié)越細(xì)，它們與可執(zhí)行語言 匹配的機會就越小。BPMN符號細(xì)粒度細(xì)節(jié)的復(fù)雜性不應(yīng)該被低估，且應(yīng)該只用在與可執(zhí)行過程沒有直接聯(lián)系的大型業(yè)務(wù)分析師團(tuán)隊中。 因此，我認(rèn)為過程語言（可執(zhí)行的和非可執(zhí)行的）的區(qū)別太明顯，以致于不能把它們統(tǒng)一到一種基于BPMN的圖形過程設(shè)計器中。我確實認(rèn)為為每一個過程語言都 可定義一個與之很好匹配的BPMN子集。設(shè)計工具應(yīng)該直接支持特定于這種語言的結(jié)構(gòu)和適當(dāng)粒度的細(xì)節(jié)。我可以預(yù)見到這樣的一種工具，其中設(shè)計者可以在不同 過程語言間切換身份。但是在每一種情形中，使用者都很清楚用哪種語言建模和開發(fā)過程。同樣，作為一個非執(zhí)行的分析語言使用的普通BPMN，是那些單獨的語 言之一。工具可以幫助處理轉(zhuǎn)換，但每次都是一個有損，單向的轉(zhuǎn)換。 映射和失配 BPMN的映射方式會使雙向工程出錯。雙向工程的思想是在BPMN分析模型和可執(zhí)行過程之間可以不斷地切換。業(yè)務(wù)分析師使用象BPMN這樣的建模語言，使 用圖形符號和BPMN屬性；開發(fā)者使用象BPEL這樣的可執(zhí)行語言。很明顯，這種方式的問題在于在實際應(yīng)用中很難維護(hù)兩套屬性。即使在兩個視圖中可以共享 一些屬性，但是業(yè)務(wù)分析師和開發(fā)者仍然會因為一個屬性在BPMN和BPEL中含義不同而難以相互溝通。另外一個問題是工具廠商很難創(chuàng)建一個支持無損雙向工 程的工具。 既然BPMN和BPEL正在成為最受關(guān)注的BPM技術(shù)，讓我們進(jìn)一步看看兩者的映射。第一個也是最顯眼的問題是兩種語言的結(jié)構(gòu)不匹配。BPMN是基于圖形 的，而BPEL是一個沒有變遷的樹形組合結(jié)構(gòu)。第二，兩者的并發(fā)模型差異巨大。Bruce Silver對此有很好的總結(jié)： 如何使過程模型（如BPMN）和對應(yīng)的BPMN實現(xiàn)（如BPEL)保持同步，就是我們所說的雙向工程問題……如果你一直在跟蹤BPMN Watch上的這個話題，你就會記得BPMN讓你畫出的東西并不能很方便地映射到BPEL——至少映射到一種你愿意編輯和維護(hù)的BPEL，但BPMN的有 些子集是可以自動映射的。假如是你控制BPMN工具，你可以通過禁止用戶畫那些不能映射的東西來解決這個問題。 其他BPM技術(shù) XPDL XPDL是工作流管理聯(lián)盟（WfMC）自1993年以來將BPM建模者統(tǒng)一到一個標(biāo)準(zhǔn)下的結(jié)果。這個標(biāo)準(zhǔn)關(guān)注于用來存儲和交換過程模型的XML格式。 XPDL過程是基于圖形的，這意味著它比BPEL樹形結(jié)構(gòu)更適合業(yè)務(wù)分析師。一個XPDL過程還可以在一個過程圖中包含圖形信息，如活動在過程圖中的坐 標(biāo)。當(dāng)過程建模者和模擬工具之間交換過程模型的時候，這個功能非常方便。XPDL還有任務(wù)管理功能，包括泳道。這種過程語言不會象BPEL那樣為不同活動 定義明確的執(zhí)行語義。 John Pyke和Keith Swenson不斷地強調(diào)XPDL并不是要與BPEL競爭。相反，他們認(rèn)為XPDL是一種文件交換格式。假如這就是目標(biāo)，那它們很可能會被即將到來的BPDM取代——如果后者曾見光的話。 與基于WSDL的BPEL不同，XPDL是技術(shù)中立的。這意味著XPDL有一個單獨的間接層來為所謂的‘應(yīng)用’服務(wù)。XPDL 2.0明確地為適應(yīng)BPMN而設(shè)計。XPDL本質(zhì)上是基于圖形的，所以它更適合BPMN。在XPDL 2.0中，規(guī)范明確指出所有的BPMN屬性都可以匹配到XPDL。XPDL絕對比BPEL更適合BPMN。但XPDL/BPMN組合和BPEL的很大程度 的區(qū)別在于后者有精確的執(zhí)行語義。 BPDM 盡管BPDM不是新東西，但它依舊還處于內(nèi)部討論階段，沒有正式發(fā)布。通常，BPDM應(yīng)該包括表示業(yè)務(wù)過程的模型和一個文件格式。因為BPMN和BPDM 都在OMG，未來它可能取代XPDL成為一種交換文件格式。關(guān)于這個項目還沒有多少正式的信息。Fred Cummins如此描述BPDM的宏觀目標(biāo)： 規(guī)范提供了BPMN圖形的底層模型表示。這意味著BPMN過程模型會有一個標(biāo)準(zhǔn)表示，以便在基于XMI(模型交換XML)的建模工具間的交換模型。規(guī)范為 編制過程（那些按規(guī)定執(zhí)行的過程）和編排（描述多個獨立過程間進(jìn)行交換的規(guī)范，這種交換仿佛發(fā)生在一個Web服務(wù)交換中）提供了正式的表示。 Keith Swenson保守地聲稱BPDM可能將取代最近15年在XPDL上的努力工作。Sandy Kemsley對Fred的介紹進(jìn)行了匯報總結(jié)。 jPDL jPDL實際上不是一個標(biāo)準(zhǔn)，而是我們作為JBoss jBPM項目一部分創(chuàng)建的一種可執(zhí)行語言。注意，jBPM以前只支持jPDL語言，但jBPM現(xiàn)在是一個過程語言平臺，jPDL只是所支持的語言之一。這 種語言的目的是成為一種可以清晰地把圖和技術(shù)細(xì)節(jié)解偶的可執(zhí)行語言。技術(shù)細(xì)節(jié)集中在Java平臺。 正如我們以上所見，BPMN適合分析員，但它是不可執(zhí)行的。BPEL是可以執(zhí)行的，但不適合BPM。因此，我認(rèn)為BPMN/BPEL組合依舊是BPM蹩腳的解決方案，因為它們不能很好的匹配。 從另一個方面來講，jPDL是一門關(guān)注自由建模的可執(zhí)行語言。首先，它是基于圖的。第二，具有大量支持更好解耦過程圖和技術(shù)細(xì)節(jié)的特性。例如，使用 jPDL，可以在圖中加入隱藏的代碼。它們被稱為動作。這種風(fēng)格的另一特性是可以引用節(jié)點運行時行為的客戶化Java代碼。這樣，開發(fā)者就可以自由地開發(fā) 出分析員在某個過程節(jié)點中想要的特殊行為。 另外，這種語言并不試圖統(tǒng)一分析模型和可執(zhí)行過程模型，但上述特性使它能夠更容易地支持分析和執(zhí)行小節(jié)所講的軟件開發(fā)過程。jPDL已在Java社區(qū)里得到了廣泛采納。 編排 ebXML & WS-CDL 是編排的標(biāo)準(zhǔn)化成果。John Reynolds這樣描述編制和編排的區(qū)別： 編制 == 可執(zhí)行過程 Web服務(wù)編制與執(zhí)行特定的業(yè)務(wù)過程相關(guān)。WS-BPEL是一種用來定義可以在一個編制引擎中執(zhí)行的過程語言。 編排 == 多方合作 Web服務(wù)編排與描述Web服務(wù)間外部可見的交互相關(guān)，WS-CDL是一種描述多方契約的語言，有些類似WSDL擴展；WSDL描述Web服務(wù)接口，WS-CDL描述Web服務(wù)間的合作。 編制是一種可執(zhí)行過程，而編排是用來指定多方合作的協(xié)議。所以BPEL是一種編制語言。這意味著BPEL過程可以在一個系統(tǒng)上執(zhí)行。因為一個編排過程定義 了多方合作的方式，一個編排過程本身并不能被直接部署。相反，必須為一個參與者采用一個投影，而那個投影可以是一個執(zhí)行過程。 在這個余下文章中，我將描繪可執(zhí)行過程語言市場現(xiàn)狀。編制語言沒有堅實的構(gòu)建基礎(chǔ)。在我看來，這是這種語言仍處于邊緣化最重要的原因。 過程組件模型 什么是過程組件模型 微軟的工作流基礎(chǔ)（WF）和JBoss jBPM是兩種具有過程組件模型的技術(shù)。jBPM的基礎(chǔ)在過程虛擬機中有記錄，它與微軟工作流基礎(chǔ)所采取的方式有很多相似之處。 它的思想是將過程圖中的活動與一個實現(xiàn)該活動運行時行為的組件相關(guān)聯(lián)，組件由一種通用編程語言實現(xiàn)。過程圖中的每一個活動都對應(yīng)一個實現(xiàn)組件。例如，一個Web服務(wù)調(diào)用活動，一個人工任務(wù)活動或一個電子郵件活動都對應(yīng)一個實現(xiàn)組件 這種方法的創(chuàng)新之處在于從BPM和工作流技術(shù)中提取了一個公共基礎(chǔ)層。WF或過程虛擬機都不能被認(rèn)為是BPM技術(shù)。相反，它們提供的是公共基礎(chǔ)層，可以把 這個基礎(chǔ)層擴展成為功能齊全的BPM和工作流產(chǎn)品?；蛳馜avid Chappell在這篇MSDN文章中明確表達(dá)的： 通過把工作流作為Microsoft .NET Framework 3.0的一部分實現(xiàn)，這種創(chuàng)建軟件的方式對任何需要它的Windows應(yīng)用都有裨益。包括運行在客戶端和服務(wù)器端的應(yīng)用，以及被最終用戶、獨立軟件提供商 和微軟自己創(chuàng)建的應(yīng)用。盡管需要些時間，Windows工作流基礎(chǔ)將會成為微軟產(chǎn)品和應(yīng)用的工作流基礎(chǔ)。 一個活動組件可以定義一組配置屬性。例如，一個電子郵件活動可以有接收者，主題和正文的配置。這樣，同一個活動實現(xiàn)在每次被使用的時候可以進(jìn)行不同的配置。 首先，可以觀察到的是在同一活動組件框架上可以實現(xiàn)多個過程語言。每一個過程語言由多個活動類型組成。對于每一個活動類型，運行時行為可以用諸如Java 或c#這樣的通用編程語言實現(xiàn)。因此可執(zhí)行過程語言就成為了一組活動類型的實現(xiàn)。這種活動組件最重要的部分是實現(xiàn)過程結(jié)構(gòu)運行時行為的代碼。但同時XML 序列化，配置過程組件的設(shè)計窗體，持久化和許多其他部分都可能被包括在過程結(jié)構(gòu)組件中。 因為它們可以支持多種過程語言，過程組件模型降低了單種語言的重要性。相反，它們使程序員可以為每一個過程選擇最適合的可執(zhí)行過程語言。與一個BPM引擎只支持一種過程語言相比，這種方式有效地分離了分析員和開發(fā)者間的關(guān)注點。 過程語言可擴展。假如你正在使用BPEL、jPDL或其他語言，你可以只實現(xiàn)你自己的活動并把它們加到語言中。也可以只暴露過程語言的子集，創(chuàng)建非常簡單的領(lǐng)域特定過程語言，例如文檔管理系統(tǒng)中用來指定批準(zhǔn)的語言。 從這個角度看，我們可以定出4個層次的細(xì)節(jié)，它們非常適合平滑地將分析模型轉(zhuǎn)換到可執(zhí)行過程模型： 1.過程圖形結(jié)構(gòu) 因此可預(yù)見工具會將過程分析員和過程開發(fā)者之間的合作帶到下一個層次。分析員可以使用設(shè)計工具來定義圖的結(jié)構(gòu)，但不用選擇圖中節(jié)點的活動類型。這將給建模 者帶來完全的自由。第二層的細(xì)節(jié)是選擇活動類型。例如，指定過程中的某個步驟是人工任務(wù)，或是一個Web服務(wù)的調(diào)用。這就把圖中節(jié)點和運行時行為關(guān)聯(lián)了起 來。第三層的細(xì)節(jié)是屬性配置。分析員可能不知道Web服務(wù)端點的URL。那可能是Web服務(wù)調(diào)用節(jié)點的一個配置屬性。做為最后一層細(xì)節(jié)，特定的客戶化運行 時行為可以由開發(fā)者編碼實現(xiàn)，作為從所用過程語言里選擇一個活動類型的替代方案。這個模式更好地支持了開發(fā)可執(zhí)行過程的分析活動，該過程在分析與執(zhí)行小節(jié) 中已經(jīng)講過。 過程組件模型和支撐它的編程語言間配合得非常好。例如，jPDL非常適合Java項目，因為它可以很方便地將Java代碼（如領(lǐng)域模型對象）包含進(jìn)一個過程。同樣的，Windows工作流狀態(tài)機可以容易地集成C#代碼。 過程引擎的操作管理變得更容易。軟件開發(fā)的很多方面可以用某種可執(zhí)行過程語言建模。設(shè)想這樣的一個項目，你用BPEL來做服務(wù)編制，jPDL來管理人工任務(wù)，pageflow來定義一個WEB應(yīng)用的頁面流轉(zhuǎn)。在一個框架里能夠同時運行這些語言是一個有利因素。 結(jié)論 BPEL是一種可執(zhí)行過程語言，它適合做集成，但因它與技術(shù)服務(wù)的緊密耦合而不適合業(yè)務(wù)過程管理。BPMN適合分析員做分析圖，但不能執(zhí)行。XPDL是一種較少采用的文件格式，可能會被BPDM替代。分析語言和執(zhí)行語言的鴻溝仍然不可逾越。 為了創(chuàng)建一個更實際的能被普遍采用的BPM方法，我們需要從理清分析過程模型和可執(zhí)行過程模型的區(qū)別開始。一旦我們放棄了讓不懂技術(shù)的業(yè)務(wù)分析師畫出馬上可以執(zhí)行的軟件的念頭，我們就可以找到一個更現(xiàn)實的業(yè)務(wù)過程管理方法。 當(dāng)把一個分析過程模型和一個可執(zhí)行過程實現(xiàn)聯(lián)系起來的時候，這暗示了不要給圖中的分析過程符號包括太多的復(fù)雜細(xì)節(jié)。只使用分析語言和執(zhí)行過程語言所提供的交集，可以為業(yè)務(wù)分析師和開發(fā)者創(chuàng)建一門以單一圖表為基礎(chǔ)的通用語言。 不同的環(huán)境和不同的功能需求要求不同的可執(zhí)行過程語言。目前想用一種過程語言覆蓋所有的BPM、工作流和編制的想法過于宏大。即使這一想法能夠?qū)崿F(xiàn)，最終的過程語言也會因太復(fù)雜而沒有實用價值。 工作流技術(shù)有了新的發(fā)展。微軟的工作流基礎(chǔ)和JBoss jBPM的過程虛擬機為運行時過程環(huán)境抽取了一個共同基礎(chǔ)。這些技術(shù)創(chuàng)造了一個組件模型，這樣就可以在這個共同基礎(chǔ)上構(gòu)建活動類型?；A(chǔ)定義了活動組件執(zhí) 行的運行時環(huán)境。每一種過程語言由一組活動類型組成?；顒宇愋偷倪\行時行為可以用一種通用編程語言實現(xiàn)。一個活動成為了一個組件。任何過程語言基本上都定 義了一組活動類型。接著，一個過程語言就可以在過程組件框架基礎(chǔ)上被構(gòu)建成一組活動組件。 |
|
|
來自： 夜郎 > 《workflow》
