業(yè)務(wù)過程執(zhí)行的7個謬誤

申請免費(fèi)試用、咨詢電話：400-8352-114

經(jīng)過8年多的認(rèn)真研究之后，軟件行業(yè)和它的客戶正頭撞南墻。由DotCom時代BPM初創(chuàng)者提出的愿景依舊沒有得到實現(xiàn)：我們遠(yuǎn)沒有能力使用業(yè)務(wù)分析師設(shè)計出的業(yè)務(wù)過程模型來創(chuàng)建完全可行的解決方案（即使通過開發(fā)人員最低程度的干預(yù)）。過程驅(qū)動應(yīng)用模型的需求確實存在：業(yè)務(wù)過程改進(jìn)項目在G2000公司內(nèi)隨處可見，但是盡管持續(xù)改進(jìn)過程的需求十分強(qiáng)烈，可BPM的市場在2007年仍然很貧瘠（相比它能夠達(dá)到的程度），和那些迅速包裝自己的廠商言語形成鮮明對比的是，在2000年，Oracle業(yè)務(wù)過程管理系統(tǒng)的空白……

到底發(fā)生了什么？這其實非常容易理解。這就是通常的“你要什么，我就給你什么”的故事。在這些情況下，一系列的誤解常常導(dǎo)致非最優(yōu)解決方案。如果你加入到一個大多數(shù)產(chǎn)品經(jīng)理、架構(gòu)師和開發(fā)人員從不與業(yè)務(wù)分析師進(jìn)行交流的團(tuán)隊，由他們自己獨(dú)立設(shè)計超越一些方塊和箭頭的業(yè)務(wù)過程，任何人都不會對當(dāng)前的這種情形感到驚訝。

11月底，Bruce Silver在“再談雙向工程（Roundtripping Revisited）”中提出了一個關(guān)鍵問題。Bruce抱怨兩個關(guān)鍵的標(biāo)準(zhǔn)：BPM:BPMN（業(yè)務(wù)過程建模符號）和BPEL（業(yè)務(wù)過程執(zhí)行語言）之間存在嚴(yán)重的失配。他提到了一個研究者（Ouyiang、Dumas、van der Aalst和ter Hofstede）團(tuán)隊的杰出工作，他們提出創(chuàng)建一個BPMN到BPEL的編譯器，因為它是經(jīng)常提到的在當(dāng)前的BPMS架構(gòu)中缺失的一環(huán)。在解決這個問題上他們已取得很大的進(jìn)展，但是他們的工作仍然尚未完工。他也宣稱我們應(yīng)該完全放棄BPEL，而將精力放在有可能成功的方向：在符號之下再創(chuàng)建一個可執(zhí)行的BPMN標(biāo)準(zhǔn)層。

我從1997年就一直在這個問題上工作，在2002年我還寫了兩篇文章，它們都被OMG BPMN 1.0 規(guī)范所引用。我將重申我在這些文章中的一些觀點(diǎn)，可能更清楚一些，使用不同的例子。這里，我的目的是探討作為當(dāng)前BPMS架構(gòu)基礎(chǔ)的一些誤解，同時給出一個新的架構(gòu)藍(lán)圖，在此基礎(chǔ)之上可以構(gòu)建一個新型的業(yè)務(wù)過程管理系統(tǒng)。

謬誤 1：業(yè)務(wù)分析師從系統(tǒng)的視角建模他們的過程。

如果你跟從業(yè)者談過的話，他們會告訴你他們從用戶的視角建模過程，而不是從執(zhí)行的視角或系統(tǒng)的視角。這意味著他們的過程指導(dǎo)用戶做什么，他們從不建模系統(tǒng)對用戶輸入的響應(yīng)。這么做有充分的理由：業(yè)務(wù)連貫性。如果系統(tǒng)失敗了，用戶需要知道該做什么才能使業(yè)務(wù)繼續(xù)下去。這也是業(yè)務(wù)分析師思考，以及他們?nèi)绾味x和獲取過程指標(biāo)的方法。這個用戶視角對于業(yè)務(wù)非常重要，因為它直接關(guān)聯(lián)創(chuàng)造價值的工作流活動。業(yè)務(wù)分析師從不根據(jù)系統(tǒng)邊界、執(zhí)行、消息或業(yè)務(wù)對象進(jìn)行思考（開發(fā)人員是）。業(yè)務(wù)分析師所理解的系統(tǒng)至多就是一個等價于紙制格式電子版本的屏幕（閱讀或輸入信息）。

謬誤 2：業(yè)務(wù)用戶可以很容易的學(xué)會BPMN并使用全部特性。

BPMN是一份超過300頁的規(guī)范。即使你的若干業(yè)務(wù)分析師決心去掌握所有這些概念，它也是難以思考的。Michael zur Muehlen對BPMN中最常用的結(jié)構(gòu)進(jìn)行了一次調(diào)查，他的結(jié)論是日常使用的大約是25個結(jié)構(gòu)。我個人就為業(yè)務(wù)分析師寫過一份教程，它基于10個關(guān)鍵概念，同時附有相應(yīng)的BPMN。說服與我一起工作的精益六西格瑪（Lean Six Sigma）黑帶接受BPMN不是件易事。

Bruce Silver根據(jù)他的經(jīng)驗（因為他教過BPMN課程）進(jìn)行了評論：

BPMN有大量的只是用于產(chǎn)生BPEL的屬性，這些一般都可以被忽略。

謬誤 3：業(yè)務(wù)分析師應(yīng)該能從過程模型創(chuàng)建可執(zhí)行的解決方案。

我并不是說BPMS廠商毫無誠意地試圖向你推銷一個說得比唱得好聽的BPMS。BPM的出發(fā)點(diǎn)是好的：更好地靠齊業(yè)務(wù)/IT、更快的開發(fā)周期……其中蘊(yùn)含的思想是：業(yè)務(wù)的確可以產(chǎn)生一個能轉(zhuǎn)換成可執(zhí)行代碼的模型。這本無可厚非，它和一些CASE工具、MDA、MDD、DSL……處于同一戰(zhàn)線上。這個愿景道出了我們最想實現(xiàn)的夢想：快、易、省。每次我聽到廠商在這個話題上大噴口水之際，我就會想到John Lennon的那首Imagine（即I want to live in this world, but it is not going to happen in my lifetime）。廠商覺得基于一個堅實的想法有一個真實（并且巨大）的市場。當(dāng)你將之與來自風(fēng)險投資幾乎無限的資金量結(jié)合起來的時候，那樣，你就得到了我們目前的情形。在交付那個愿景的片斷上，一些廠商要比其它的好一些，但是我們不得不承認(rèn)這還不是愿景。沒有人可以大聲說他們已經(jīng)提供了一個通用的引擎，業(yè)務(wù)分析師可以用來（甚至通過IT的最小干預(yù)）從過程模型創(chuàng)建一個解決方案。 大項目失敗，BPMS使用的邊緣化，給組織帶來極少的益處。

我經(jīng)常告訴那些想讓他們的業(yè)務(wù)用戶“打造”解決方案的人們的一個笑話是：好消息是你剛剛給你的組織增加了2000名開發(fā)人員，而壞消息是你只是增加了2000名開發(fā)人員。你想讓你的用戶不用構(gòu)建或者甚至客戶化解決方案，就能個性化它們。注意，在一些好的約束條件下，讓業(yè)務(wù)用戶自定義一些業(yè)務(wù)邏輯（如規(guī)則）是可行的。

謬誤 4：如果我們增加了一個可以從業(yè)務(wù)分析師的輸入直接創(chuàng)建解決方案的魔力BPMS，我們就不需要開發(fā)任何與現(xiàn)有系統(tǒng)的集成，無需改變現(xiàn)有系統(tǒng)的記錄，也不用進(jìn)行任何QA工作。

這樣說吧，我期望到現(xiàn)在為止所有人都同意：至少在下個10年，我們不會在市場上看到這樣一個魔力BPMS。而且廠商的確完全放棄了將開發(fā)人員排除在外的做法。但是，Bruce寫道：

通過完全忽略BPEL，一些更小的公司開始示范了BPM購買者和行業(yè)分析師的成功做法。像Lombardi、Appian和Savvion這樣的廠商，把精力放在以人為中心的過程而不是集成。這樣導(dǎo)致了一種新風(fēng)格的BPMS，其中可執(zhí)行的設(shè)計直接建立在過程模型之上，以BPMN活動的實現(xiàn)的屬性的形式。

這種工具本身鼓勵整個實現(xiàn)周期中業(yè)務(wù)-IT的協(xié)作。并且非常適合敏捷迭代方法論，這種方法顯著地縮短了從模型到已部署的解決方案的周期時間。

Marlon Dumas對Bruce的反應(yīng)和我的一致：

你不能僅僅因為從來沒有業(yè)務(wù)分析師愿意書寫一些類似XPath表達(dá)式或其它表達(dá)式語言，就將開發(fā)人員排除在BPM生命周期之外。

和我前面所說的一樣，我會證明這些廠商的成功經(jīng)驗是有限的。正如Bruce指出他們關(guān)注以人為中心的過程，在很大程度上，我同意它非常適合由這些廠商開發(fā)的業(yè)務(wù)過程引擎的集中化視圖，尤其是需要對現(xiàn)有系統(tǒng)集成和進(jìn)行有限的定制時。

謬誤 5：業(yè)務(wù)過程執(zhí)行必須是集中化的。

讓我們在這個謬誤上花點(diǎn)時間。Bruce解釋了他面臨的一個新問題：

事實上，如果[他的BPMN使用者]已經(jīng)做出了他們BPM運(yùn)行時的決策，那么它通常就是BPEL。它是一個標(biāo)準(zhǔn)、一個日用品，而且可以找到開源實現(xiàn)。它被IBM和 Oracle用在他們的BPM運(yùn)行時中。因此，在選擇BPEL時有強(qiáng)制性因素。但是BPMN和BPEL不是都在進(jìn)行標(biāo)準(zhǔn)化嗎？不，這當(dāng)然不合邏輯。

    在“雙向工程已死”營地（roundtripping-is-dead camp）待了大約一年之后，我現(xiàn)在發(fā)現(xiàn)自己不得不再次面臨這個問題。在我的BPMN培訓(xùn)中，例如，學(xué)生想要知道在他們的BPMN圖中使用什么策略或模式才能非常匹配他們期望的BPEL實現(xiàn)。這并不是我一開始期望去考慮的問題。

BPMN/BPEL雙向工程已經(jīng)成為這個行業(yè)的圣杯。這最初本是由BPMI.org提出的愿景，該組織締造了BPML和BPMN。這兒發(fā)生了什么？在一些公司給BPMN增加執(zhí)行語義的時候連一個中介編制語言都沒有，他們怎么可能為以人為中心的過程創(chuàng)建一個成功的市場？其他人認(rèn)為這個問題來自于我們沒有找到合適的協(xié)調(diào)語言這一事實。例如，Arzul Hasni認(rèn)為在雙向工程上GRAFCET會是比BPEL更好的候選。GRAFCET是工業(yè)自動機(jī)的專用編程語言（Arzul在他的帖子中給出了細(xì)節(jié)）?；旧?，它非常接近BPEL。

Ouyiang、Dumas、van der Aalst和ter Hofstede在創(chuàng)建BPMN/BPEL映射上做了卓越的工作。對于那些像我一樣早就忘記了大學(xué)數(shù)學(xué)的人，我發(fā)布了BPMN和BPEL的UML圖，它們可能對于你理解兩個規(guī)范的語義（即，它們可以表達(dá)的事物）分歧有所幫助。來自這個研究組的結(jié)論非常的清楚：

未來工作的一個可能方法是擴(kuò)展提議的技術(shù)，覆蓋BPMN模型更大的子集，如對相關(guān)的異常處理和其它高級結(jié)構(gòu)（如OR-joins）建模。不幸的是，BPMN的許多高級結(jié)構(gòu)并沒有細(xì)化，依舊處于由相關(guān)標(biāo)準(zhǔn)化團(tuán)體改進(jìn)的過程中。

集中化過程引擎的概念并不新鮮。這是自90年代早期以來該領(lǐng)域已取得成果的99.99%的幕后基礎(chǔ)。通過這個優(yōu)秀的介紹可以很好的理解對集中化架構(gòu)的關(guān)注，它由Fujitsu Computer Systems（該公司也在XPDL上投資，為BPMN創(chuàng)建一個可交換的格式）的研發(fā)副總裁Keith Swenson撰寫。

不幸的是，這種觀點(diǎn)是有缺陷的，我非常愿意花些時間解釋這一點(diǎn)。使用這種思考方式，我們完全忽略了業(yè)務(wù)過程本來的天性：通過轉(zhuǎn)換資源給組織增加價值。像Source-to-make、Quote-to-cash……這樣的過程都沿著工作流活動移動“東西”，這些活動最終（且有望）給轉(zhuǎn)換中或消費(fèi)中的資源增加價值。信息系統(tǒng)在此只是推進(jìn)、捕獲和報告這些資源和活動的狀態(tài)。是的，你可以攜帶任何一個描述物理概念的業(yè)務(wù)對象：購買訂單、發(fā)票、庫存項、員工、客戶……它們都有生命周期（可用狀態(tài)圖描述--參見圖2）。

我愿意舉一個工作申請業(yè)務(wù)過程（即Candidate-to-Employee過程）的例子，它抽取一個候選者的申請，并將它處理到候選者要么被雇用要么申請被拒絕的位置。

以下就是典型的工作申請信息模型。

圖1 工作申請數(shù)據(jù)模型

這個工作申請有一個生命周期（請記住工作申請的數(shù)據(jù)模型——內(nèi)容——獨(dú)立于它的生命周期，反之亦然）：

工作申請生命周期本身獨(dú)立于任何Candidate-to-Employee業(yè)務(wù)過程。這是一塊很少變化的業(yè)務(wù)邏輯，即使與之交互的過程可能經(jīng)常變化。一家公司可能有幾個這樣的過程為這個相同的生命周期服務(wù)：例如，一個用于副總裁職位，一個用于經(jīng)理，一個用于其它所有的員工。另一種情況可能是因為規(guī)章制度，一些過程可能涉及額外的活動（檢查背景……）。這些過程變體是非常平常的。但是，在很大程度上一個工作申請就是一個工作申請，即使也存在一些工作生命周期變體，它們在很大程度上與它們的過程變體沒有瓜葛。

現(xiàn)在的問題是，你將如何動手實現(xiàn)這個工作申請生命周期組件？我要使用的方法是創(chuàng)建一個實現(xiàn)所有動作的服務(wù)，這些動作將導(dǎo)致狀態(tài)轉(zhuǎn)換：

圖3 工作申請服務(wù)

所有這些服務(wù)操作將有效執(zhí)行一些會導(dǎo)致狀態(tài)轉(zhuǎn)換的業(yè)務(wù)邏輯。什么是實現(xiàn)這個服務(wù)的最好的語言？Java/C#？BPEL？GRAFCET？

我的偏好是如BPEL這樣的一門面向消息的編制語言，因為這些資源生命周期是長期運(yùn)行的（日、周、月、年）。為了說明這點(diǎn)，讓我們舉一個客戶資源的例子：作為一個客戶，我這周剛剛?cè)∠艘粋€與信用卡公司12年的關(guān)系，（這使得我的客戶生命周期實例遷移到了它的最終態(tài)）因為必須支付額外的費(fèi)用，我覺得違反了計費(fèi)過程……是的，過程確實麻煩，他們可以完全無需改變我所喜歡的賬單生命周期就能給他們的過程增加一個活動，但是他們沒有，相反他們選擇了最大化費(fèi)用。對于這種長期運(yùn)行的生命周期（不是過程），BPEL是一個理想的實現(xiàn)語言，因為它理解消息（接收、發(fā)送、調(diào)用）、關(guān)聯(lián)消息，它可以處理并行流程（是的，一個資源可以有組合狀態(tài)）。此外，BPEL引擎被設(shè)計來自動處理過程實例狀態(tài)數(shù)據(jù)的持久化（dehydration/hydration），這個工作的麻煩相對少些。

我知道很多人會告訴我它是一個過程，但是它不是。它是一個實現(xiàn)了工作申請生命周期的服務(wù)，它獨(dú)立于那些推進(jìn)工作申請狀態(tài)的過程和活動。一個過程是推進(jìn)它的狀態(tài)的活動的集合。資源生命周期和過程是解耦的，我認(rèn)為這是無庸置疑的，然而每個人還是試圖在沒有清晰的理解資源生命周期的前提下建模和實現(xiàn)過程，它們或多或少“內(nèi)建在”過程模型中。

因此，大多數(shù)人將BPEL引擎作為標(biāo)準(zhǔn)選擇是正確的……目前為止是這樣。注意，由于SCA，你鐘愛的編程語言可以很容易地被擴(kuò)展結(jié)合BPEL語義。過去，我喜歡BPEL-J over BPEL，但是現(xiàn)在如果你需要在傳統(tǒng)語言中表達(dá)一些業(yè)務(wù)邏輯，SCA使得在你鐘愛的語言中使用編制能力這一工作真的變得非常簡單（Java、C++、COBOL、PHP、ABAP……）。

資源生命周期和編制語言之間存在如此強(qiáng)的關(guān)系，以致于一些領(lǐng)先的編制引擎提供了一個狀態(tài)機(jī)范式作為創(chuàng)建你的編制定義的一種方法。IBM Process Server和微軟Workflow Foundation就是例子（如果我還忘了哪些產(chǎn)品，我要在此說聲抱歉。如果你知道的話，請告知我）。

請注意，到目前為止我一直在建議使用一個編制引擎去實現(xiàn)那些管理資源生命周期的服務(wù)，我還沒有說到業(yè)務(wù)過程或業(yè)務(wù)過程引擎。

在了解生命周期和過程之間的關(guān)系之前，我們需要注意的是生命周期是一個非常直觀的概念。大多數(shù)業(yè)務(wù)分析師隨時可以輕易地描述這些生命周期（比方說使用UML符號）。可以這么說，不論他們是什么角色，組織中的任何人都可以理解這些生命周期。但是，我也要強(qiáng)調(diào)一下它的另一極端，幾乎沒有人有能力設(shè)計（使用BPMN進(jìn)行圖形化設(shè)計）滿足涉及的所有資源生命周期的業(yè)務(wù)過程。假如你創(chuàng)建了這樣一個模型，我們就說你現(xiàn)在創(chuàng)建了一個過程的變種。你如何能保證資源生命周期不受影響？你需要進(jìn)行多少Q(mào)A工作來驗證它？

過程和資源生命周期只能在過程實現(xiàn)時是一致的，而且可能要向過程“妥協(xié)”以確保它符合生命周期。這種活動只能由開發(fā)人員仔細(xì)地將業(yè)務(wù)分析師畫出的BPMN進(jìn)行映射，并重用那些管理他或她組織的核心資源生命周期的企業(yè)類服務(wù)來做到。

現(xiàn)在，讓我們看看業(yè)務(wù)分析師是怎樣使用BPMN創(chuàng)建一個工作申請業(yè)務(wù)過程定義的：

圖5 工作申請過程（藍(lán)組代表人工任務(wù)邊界）

首先，BPMN連表示“資源”的符號都沒有，更別提“生命周期”了。人們最多可以在過程的某一點(diǎn)（如上圖）使用期望的狀態(tài)對它的BPMN定義進(jìn)行注解。這非常好，BPMN就應(yīng)該是這樣。其次，業(yè)務(wù)分析師完全不關(guān)心工作申請會調(diào)用哪些操作來推進(jìn)它的狀態(tài)。它們屬于系統(tǒng)視角。期望業(yè)務(wù)分析師在他或她描述的用戶活動間加入“調(diào)用”活動簡直是癡人說夢。不幸的是，人們著手去建立的BPMN和BPEL之間的關(guān)系就是一個錯誤的例子。他們最終在過程符號中加入了核心BPEL操作語義，發(fā)送、接收和調(diào)用。這完全是畫蛇添足，不應(yīng)該被使用，除非被接收或發(fā)送的消息是一個業(yè)務(wù)消息而不是一個被調(diào)用的操作（如一份工作申請到了一個招募者的桌上）。

怎樣實現(xiàn)業(yè)務(wù)過程？一個業(yè)務(wù)過程執(zhí)行環(huán)境是一個彼此（非集中編制的服務(wù)集合）交互的服務(wù)的裝配（圖6）。它描述了實現(xiàn)資源生命周期的編制，以及人工任務(wù)執(zhí)行、事件和推進(jìn)過程的簡單服務(wù)調(diào)用的交互。

好消息是我們完全擁有了實現(xiàn)這一愿景的必需技術(shù)，包括裝配技術(shù)：服務(wù)組件架構(gòu)。你在圖中看到的一切可以結(jié)合SCA 1.0、BPEL 2.0、Web Services（XSD和WSDL 1.1——因為BPEL 2.0）、BPEL4People 1.0 and Human Tasks 1.0來完成。

Bruce先前宣稱：

使用BPEL你沒有忽略你不支持的元素的自由。BPEL就是BPEL，你必須支持規(guī)范中的一切。剩余的被稱為私有擴(kuò)展。它們只存在于它們自己的名字空間，BPEL 1.1的一個有根據(jù)的批評就是一個真正的過程需要太多的元素。BPEL 2.0要好一些，但是人工任務(wù)、子過程和其他的基本的東西仍需要2.0中的擴(kuò)展，如，近乎神話的BPEL4People。

在這個BPMS架構(gòu)藍(lán)圖中，他的言論不再有效。WS-HumanTask和BPEL4People屬于任務(wù)容器并且確實與BPEL本身隔離開?，F(xiàn)在，你可以爭論BPEL是否需要“子過程”，但是我會說作為一門資源生命周期服務(wù)的實現(xiàn)語言，它并不迫切：狀態(tài)機(jī)元素極少可被重用，它們完全屬于它們的資源。

在這一點(diǎn)上——不幸的是——微軟并沒有參與SCA或BPEL4People，因此你不能將Workflow Foundation作為BPEL引擎的替代品，即使它能很好的完成工作。但是，你可以將WCF當(dāng)作服務(wù)容器實現(xiàn)服務(wù)，你可以從SCA和你喜愛的BPEL引擎中調(diào)用這些服務(wù)。微軟本身并沒有裝配機(jī)制，因此你甚至不能在.Net中實現(xiàn)這個架構(gòu)藍(lán)圖。在開源方面，你可以找到大多數(shù)組件（SCA、BPEL和服務(wù)容器），但是BPEL4People容器除外。這并不要緊，基本的人工任務(wù)容器并不是太難構(gòu)建（但是還沒到BPEL4People和WS-HumanTask級別）。

為了理解開發(fā)人員在這個新架構(gòu)中的角色，讓我們仔細(xì)看看過程模型的“面試安排（Schedule Interview）”活動（圖5）。如你所見，這個活動在過程模型中被進(jìn)行特別對待（這是有意義的，這是因為，如果工作申請系統(tǒng)宕機(jī)了，用戶就不得不這么做），但是作為優(yōu)化，它由業(yè)務(wù)來決定，例如，任務(wù)安排在Exchange Server上自動進(jìn)行。工作申請應(yīng)用生命周期提供了在候選人的申請被保留后安排面試的鉤子（即，必需品）。記住工作申請服務(wù)并不知道這是如何實現(xiàn)的。它是人工任務(wù)也沒有關(guān)系。在這一點(diǎn)上我認(rèn)為，自動解決這種設(shè)計決策完全是不可能的。這就是過程模型必須完全和任何執(zhí)行語義分離的原因。另一個不會影響過程定義的設(shè)計決策是這樣一個事實：候選人申請能發(fā)生在一個不同的人工任務(wù)容器。我們能很好地將這個過程和發(fā)生在一個流行的求職站點(diǎn)的候選人申請“裝配”在一起。一旦申請被批準(zhǔn)面試，一個活動將給候選人發(fā)送一封郵件，告訴他或她下一步過程任務(wù)（復(fù)查錄用通知，輸入員工信息）。我打賭你現(xiàn)有的BPMS系統(tǒng)做不了（容易地）這件事。

作為一個附注，你現(xiàn)在可以看到任務(wù)引擎并不是一個業(yè)務(wù)過程引擎真正的子組件。當(dāng)然，當(dāng)今的BPMS系統(tǒng)就是這么設(shè)計的，但是事實上它確實不是，它是架構(gòu)的獨(dú)立組件，管理人工任務(wù)（圖6）。這些人工任務(wù)本質(zhì)上總是關(guān)聯(lián)一個或更多的業(yè)務(wù)過程，但是它們有它們自己的生命周期，而且直接和資源生命周期服務(wù)交互。正如Dominique Vauquier[1]在他文中所說的：“人工任務(wù)嫁接了資源生命周期”。此外，我們在前一段落看到，為了使“業(yè)務(wù)過程”能和幾個任務(wù)容器進(jìn)行交互，它至關(guān)重要。

在此，我并不想描述規(guī)則或主數(shù)據(jù)管理的角色（對不住了，James），但是它們的確扮演了關(guān)鍵角色并且需要特殊的服務(wù)容器，這就是眾所周知的BRMS（圖6）。Michael zur Muehlen或Mark Proctor問的問題就變得完全不相關(guān)了，因為SCA使這變得不相關(guān)（從運(yùn)行時的角度）。SCA會讓你選擇決策服務(wù)的最佳調(diào)用機(jī)制（技術(shù)上可行的話，它可以和你的BPEL引擎一起運(yùn)行在過程中）。SCA很大程度解耦了這個架構(gòu)的元素，這使得它們可以在不同的過程中被重用，同時為每個過程選擇可能的最佳運(yùn)行時配置。

我也不會談到B2B的角色，在我最初的兩篇文章中，關(guān)于它們我說了很多。通過支持定義裝配內(nèi)的任意邊界，這個架構(gòu)藍(lán)圖支持B2B。例如，我能“裝配購買訂單生命周期的兩個視角（買者和賣者）”。這是一個巨大的進(jìn)步。傳統(tǒng)的“集中化”執(zhí)行模型在B2B邊界強(qiáng)加了一個人工的斷層，被迫使用兩個不同的執(zhí)行模型：在每一端的一個集中化編制，以及中間的一個裝配。在某些方面，我的提議完全是基于OASIS ebXML Business Process最初的B2B過程定義，但是應(yīng)用在了資源級別，而不僅僅是業(yè)務(wù)伙伴級別。這就是執(zhí)行模型在組織內(nèi)外都連續(xù)的原因，因為它和它的業(yè)務(wù)伙伴交互。

謬誤 6：業(yè)務(wù)過程執(zhí)行語義可以簡單地從現(xiàn)有編程概念中派生出來。

我在“執(zhí)行”標(biāo)準(zhǔn)工作組（如BPML、BPEL、WS-CDL）中碰到的每個人（包括我在內(nèi)）幾乎都不是從業(yè)者。他們是開發(fā)人員和架構(gòu)師。他們經(jīng)常關(guān)注復(fù)雜的數(shù)學(xué)理論（如Pi-Calculus），從來不去驗證這些理論的語義是否真的足夠支撐一個業(yè)務(wù)過程執(zhí)行。一般來說，這些技術(shù)提交者會關(guān)注3~5個用例來書寫他們的需求。這些用例通常比較簡單，很少反映“現(xiàn)實世界”業(yè)務(wù)過程的復(fù)雜性。

業(yè)務(wù)過程執(zhí)行語義很難概念化。這個過程是實際上是如此的困難，以致在我們的解決方案中絕大多數(shù)的可執(zhí)行過程依舊是痛苦的硬編碼，一次一行。如果有更好的方法，我確定它能很快被每個人接受。我被推薦去閱讀“Java開發(fā)者為什么憎恨BPM”的討論。沒有一個評論抱怨抽象的有效性。即使是代碼大仙（code Kahuna），如JBoss的首席架構(gòu)師，Bill Burke（在他加入JBoss之前，我和他有過短暫的共事，當(dāng)時我們一起在做一個人工任務(wù)容器）如此評論：

我認(rèn)為BPM也一樣。只不過是編寫XML腳本，開發(fā)人員并不把它放在眼內(nèi)。直到我確實開始深入BPM框架……我并不認(rèn)為必須提供這些增值框架。當(dāng)我開始把它們當(dāng)作一個可靠的和容錯的狀態(tài)機(jī)思考的時候，我開始真正意識到BPM框架的潛力。然后，當(dāng)你結(jié)合你的過程和事務(wù)管理與補(bǔ)償使用時，你就得到了一個真的好的抽象，這在你開發(fā)你的應(yīng)用時可以派上用場。

根據(jù)我在前一節(jié)的解釋，他和其他人言論的方向是正確的。開發(fā)人員現(xiàn)在看到了一遍又一遍不得不編寫狀態(tài)機(jī)的困難，以及一個通用的引擎可以減輕他們的工作（大多數(shù)情況下如此）。

謬誤 7：Bruce Silver這樣總結(jié)他的帖子：“一個協(xié)作實現(xiàn)范式，其中可執(zhí)行設(shè)計位于BPMN模型之上的層級，這是正確的道路?！?/STRONG>