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

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

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

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

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

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

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

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

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

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

Bruce Silver根據(jù)他的經(jīng)驗(yàn)（因?yàn)樗踢^(guò)BPMN課程）進(jìn)行了評(píng)論：

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

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

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

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

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

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

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

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

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

你不能僅僅因?yàn)閺膩?lái)沒(méi)有業(yè)務(wù)分析師愿意書(shū)寫(xiě)一些類(lèi)似XPath表達(dá)式或其它表達(dá)式語(yǔ)言，就將開(kāi)發(fā)人員排除在BPM生命周期之外。

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

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

讓我們?cè)谶@個(gè)謬誤上花點(diǎn)時(shí)間。Bruce解釋了他面臨的一個(gè)新問(wèn)題：

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

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

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

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

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

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

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

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

以下就是典型的工作申請(qǐng)信息模型。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Bruce先前宣稱：

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

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

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

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

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

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

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

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

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

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

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

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

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