日期：2004年5月17日
摘要
讓我們也趟一趟建模這潭混水吧，描述建模的一些挑戰(zhàn)，并提供一個業(yè)務(wù)流程建模狀態(tài)概述。在本系列中的第一篇文章（WLDJ，第3卷，第4期）中，我論述了架構(gòu)藍(lán)圖的重要性，同時也詳述了為構(gòu)建健壯的、企業(yè)級集成解決方案而創(chuàng)建可重復(fù)方法的最佳實踐，目的是服務(wù)于那些能夠適應(yīng)和靈活的企業(yè)。
作者：Labro Dimitriou
讓我們也趟一趟建模這潭混水吧，描述建模的一些挑戰(zhàn)，并提供一個業(yè)務(wù)流程建模狀態(tài)概述。
在本系列中的第一篇文章（WLDJ，第3卷，第4期）中，我論述了架構(gòu)藍(lán)圖的重要性，同時也詳述了為構(gòu)建健壯的、企業(yè)級集成解決方案而創(chuàng)建可復(fù)用方法的最佳實踐，目的是服務(wù)于那些能夠適應(yīng)和靈活的企業(yè)。在高度分布和時刻變化的業(yè)務(wù)生態(tài)系統(tǒng)中，作為連接性的支柱，我認(rèn)為該服務(wù)是將SOA和BPMS與Web服務(wù)合并起來的統(tǒng)一結(jié)構(gòu)。在業(yè)務(wù)流程和BPMS是一個進(jìn)化性的新技術(shù)革新（計算中的頭等公民）的分布式計算中，SOA是一個進(jìn)化性的步驟。最后我用基本業(yè)務(wù)服務(wù)（EBS）的概念結(jié)束，EBS是通過企業(yè)信息總線（另外一個時代錯誤的和重載的術(shù)語）可用于企業(yè)的小的工作單元。EBS組合提供企業(yè)級重用的最終指南。通過將現(xiàn)有的EBS、新業(yè)務(wù)事件以及人力資源與自適應(yīng)公司目標(biāo)相結(jié)合，新的業(yè)務(wù)流程正在接近實時的情況下出現(xiàn)。
在本文中，我介紹了新出現(xiàn)的業(yè)務(wù)流程設(shè)計模式，這些模式提供可應(yīng)對長期的、企業(yè)級業(yè)務(wù)挑戰(zhàn)的以BPM為中心的架構(gòu)解決方案。在描述了模型的外觀之后，我們將業(yè)務(wù)流程分解成已知組件并試圖理解伴隨而來的設(shè)計挑戰(zhàn)。最后，我將提供一個業(yè)務(wù)－流程設(shè)計模式的建議分類法。
與此同時，虛構(gòu)的汽車保險代理機構(gòu)（其業(yè)務(wù)流程是獲取汽車保險報價，這正是我要建模的）的董事會要求我在提出解決方案之前等待一段時間。他們正在經(jīng)歷業(yè)務(wù)流程的重新設(shè)計階段并準(zhǔn)備通過一項新的政策。該政策規(guī)定所有的報價都要由外部保險商提供。保險商通過虛擬的協(xié)作式B2B交易獲利。此外，作為流程的一部分，他們通過安全的Web服務(wù)進(jìn)行信譽報告檢查的談判。因此，不管我在第一篇文章中許諾了什么，且為了完整性，我將不得不推遲到下一篇文章中進(jìn)行本討論。
建模的問題
Booch et al告訴我們“模型是現(xiàn)實的簡化”和“最好的模型是和現(xiàn)實相聯(lián)系的”；但是我們要對誰的現(xiàn)實進(jìn)行建模呢？而且，我們使用哪種建模范例或者說框架來對建?？蚣苓M(jìn)行建模呢？以及為什么我們需要模型？模型可能會比較恐怖，因為它會使您忘掉現(xiàn)實?？紤]以下類比：業(yè)務(wù)領(lǐng)域（business domains）好比是夢，而模型就是您對夢的闡釋。不久您會只記住了夢的闡釋而忘卻了夢。為此，我的目標(biāo)不是去詳盡的解釋所有這些問題，即使我有這個能力。這里只是闡明基本的概念，并簡要描述涉及以下幾個方面的且為人們所普遍接受的觀念和挑戰(zhàn)，（1）用流程－業(yè)務(wù)流程對業(yè)務(wù)生態(tài)系統(tǒng)進(jìn)行建模；（2）使用對業(yè)務(wù)流程進(jìn)行建模的建?？蚣?；（3）選擇一種語言/語法來表示建?？蚣?；和（4）選擇一個圖形符號來可視化呈現(xiàn)業(yè)務(wù)流程。
業(yè)務(wù)流程可很好地對協(xié)作式業(yè)務(wù)生態(tài)系統(tǒng)進(jìn)行建模，且BPMS框架可成功的消除業(yè)務(wù)和IT之間的阻抗失配問題。但是我們應(yīng)該使用誰的建模標(biāo)準(zhǔn)呢？BPML的出現(xiàn)和使用已有一段時間了，但看上去BPEL4WS是贏家。很明顯，兩個標(biāo)準(zhǔn)都使用XML作為實現(xiàn)之選擇。另一方面，UML陣營也沒有停滯不前。UML序列圖表用于建模已經(jīng)足夠好了嗎？關(guān)于OMG的模型驅(qū)動架構(gòu)，而不和特征驅(qū)動架構(gòu)或域驅(qū)動設(shè)計相混淆的亂哄哄的是什么？當(dāng)然，更不用提眾多的其他標(biāo)準(zhǔn)了，如XPDL、ebXML、XLANG、WSCL、WSFL和許多其他正在研制過程中的標(biāo)準(zhǔn)，如YAWL（yet another workflow language）?，F(xiàn)在是打破公共謬誤的好時間了：與流行的看法相反，工作流和流程確實有非常相似的方面。在工作流軟件公司劫用了術(shù)語“工作流”來表示文檔流和工作分配之前更是如此，BPM技術(shù)推廣人，包括我自己，不希望和過去的事情如<e>AＩ和工作流引擎有什么關(guān)系。（這里我使用<e>而不是傳統(tǒng)的E來表示防火墻之外和整個業(yè)務(wù)生態(tài)系統(tǒng)的AI。）很明顯，圖形化、控制流表示和圖形理論是工作流和類似流程的公共方面。所以從現(xiàn)在開始，我將交替使用工作流和流程這兩個術(shù)語。
業(yè)務(wù)－流程模型并不封裝特定業(yè)務(wù)領(lǐng)域的知識，但卻有定義業(yè)務(wù)內(nèi)容的表達(dá)力。另一方面，業(yè)務(wù)內(nèi)容的不透明對業(yè)務(wù)協(xié)議有著不確定性的影響，使得異常處理和補償交易（compensating transactions）更具挑戰(zhàn)性。
流程建模所采用的兩個主要的數(shù)學(xué)/建模理論是：（1）Petri網(wǎng)，和（2）π-微積分（π-calculus）或差分和補充概念分別是狀態(tài)圖表、時間隨機網(wǎng)絡(luò)和環(huán)境微積分。
Petri網(wǎng)是由C.A.Petri在20世紀(jì)60年代早期提出來的，作為對分布式系統(tǒng)進(jìn)行建模的數(shù)學(xué)工具，特別用于并發(fā)、不確定論、通信和同步的概念。π－微積分（π－calculus）是由Milner、Parrow和Walker所定義，作為“移動流程的微積分（Calculus of Mobile Processes）”?；?/span>Petri 網(wǎng)語言的性能優(yōu)于基于狀態(tài)的工作流，但是在對多個并發(fā)流程和復(fù)雜同步需求進(jìn)行建模時，它卻有一定的困難并可能提高復(fù)雜程度。
圖１
簡單來說，曲線圖含有與邊緣線相連的節(jié)點。Petri網(wǎng)是一種帶有節(jié)點的曲線圖，節(jié)點是位置（圓形）或轉(zhuǎn)換（矩形）和令牌。不同類型的節(jié)點通過弧線連接在一起。弧線有兩種：輸入和輸出。一個位置可擁有一個或多個令牌。流程的狀態(tài)是由位置和令牌建模的，而狀態(tài)轉(zhuǎn)換是由轉(zhuǎn)換建模的。圖1圖示了作為Petri網(wǎng)的B2C和B2B的交互，一客戶分別從一個代理和保險商流程請求保險報價。私有流程從本質(zhì)上說獨立運行，但是必須通過共享點進(jìn)行同步。Wil van der Aalst教授的論文用了若干個很好的示例對Petri網(wǎng)進(jìn)行了簡單的介紹，并提供了一個applet來設(shè)計您自己的Petri網(wǎng)。
π－微積分對通過網(wǎng)絡(luò)拓?fù)淇蓜討B(tài)改變的通道所進(jìn)行并發(fā)流程通信進(jìn)行建模。節(jié)點是流程，邊緣線是命名通道。流程可以通過通道交換名稱，且除了通道名稱外沒有其他值。例如，符號x(y).P 表示流程P通過通道x接收一個值y。P1|P2表明P1和P2是兩個并發(fā)流程。最后，（y）表示通過一個通道a發(fā)送一個名稱y。例如，某用戶通過一個保險Web站點請求報價的情況可能是這樣的：
webChannel(sendData).RequestQuote | webChannel (getData).ProcessQuote,
其中RequestQuote和PeocessQuote是兩個并行運行的流程。
您可能會問，為什么要用這些形式主義使事情更加復(fù)雜化呢？因為不這樣的話，它等于不用雙帳簿入帳技術(shù)和普通的分類總帳進(jìn)行賬目管理，并希望最后的總和為0?；镜牧鞒處缀螏椭覀儯?/span>BPM引擎和下一代業(yè)務(wù)活動監(jiān)視器）來找到死鎖和競態(tài)條件、將流程簡化為更簡單的，并找到最佳路徑、更好的機遇（基于業(yè)務(wù)規(guī)則）和回答其他感興趣的問題。BPMS的視野遠(yuǎn)遠(yuǎn)超過了流程的簡單執(zhí)行。正是由于BPMS的形式主義，才使我們現(xiàn)在有一個該運行時企業(yè)的直接實時API并實現(xiàn)執(zhí)行的天堂。
至于圖形符號，業(yè)務(wù)流程建模符號（BPMN）是學(xué)術(shù)界之外所不得不使用的惟一符號。當(dāng)有人在談?wù)撝?/span>BPEL4WS頂部實現(xiàn)BPMN時，一些提供商已經(jīng)宣布了愿意遵從，包括Popkin Software（一個軟件分析工具提供商）和Intalio（一個專業(yè)BPM工具）。基于WebLogic Server（事實上的應(yīng)用服務(wù)器行業(yè)標(biāo)準(zhǔn)）的WebLogic Platform 8.1自帶的集成開發(fā)環(huán)境（IDE）用于設(shè)計和部署分布式應(yīng)用程序。該IDE使用了一些強大的和直觀的結(jié)構(gòu)來推動業(yè)務(wù)－流程的設(shè)計和開發(fā)?？梢暬独晒Φ仉[藏了面向?qū)ο缶幊獭?/span>J2EE、J2EE CA、JMS和WS-WSDL的苛刻要求。而其他大多數(shù)供應(yīng)商使用典型的類似Visio的工作流或者面向?qū)ο蟮?/span>UML符號。
分解業(yè)務(wù)流程
圖2
業(yè)務(wù)流程管理方法實際上是一個自上而下的方法。起始于頂端，流程的寬度整合了靈活企業(yè)內(nèi)部的所有知識領(lǐng)域：業(yè)務(wù)情報、主題專業(yè)知識交互（UI和其他）、位置和組織邊界、遺留應(yīng)用程序、集成點以及數(shù)據(jù)需求。隨著我們增加流程的深度，我們要識別子流程（一些位于一組業(yè)務(wù)邊界的內(nèi)部的流程），直到單個業(yè)務(wù)規(guī)則的微觀級別。這個分層的自上而下的方法使BPMS成為正在消失的遺留產(chǎn)品的理想工具。企業(yè)級流程可以觸發(fā)并執(zhí)行子流程，依此類推。很明顯這個自上而下的方法推動著遞增式改變而不是“宇宙大爆炸式”。
Gregor Hohpe 和 Bobby Woolf（見 Enterprise Integration Patterns）的結(jié)論是：
業(yè)務(wù)流程組件將一系列的服務(wù)結(jié)合到一個邏輯單元，該單元和其他這樣單元通過消息傳送以實現(xiàn)高度的可伸縮、高彈性的邏輯和數(shù)據(jù)流。流程、對象和交互模式到業(yè)務(wù)流程組件的合并是將來的事情。
圖2提供了一個業(yè)務(wù)流程的分層視圖以及每層所涉及的相關(guān)設(shè)計模式。啟動一個業(yè)務(wù)流程始于參與者、真人（該組織的內(nèi)部或外部的人員）或者一個系統(tǒng)所觸發(fā)的業(yè)務(wù)事件。一個業(yè)務(wù)流程含有動態(tài)和靜態(tài)部分。
動態(tài)部分設(shè)計使用一個IDE內(nèi)的拖放機制，并通過控制流語言和消息傳送/連接點（包括<e>AL、遺留適配器和Web服務(wù)）來封裝。該控制流軟件具有發(fā)散性，這使領(lǐng)域?qū)＜液驮O(shè)計建模人員只需單擊一個按鈕，就可以對其進(jìn)行更改和部署。消息是使用抽象和具體類實現(xiàn)的。具體類將依賴于協(xié)議的實現(xiàn)細(xì)節(jié)從控制流中隱藏了起來。
靜態(tài)層含有通常的幾個方面：業(yè)務(wù)服務(wù)、業(yè)務(wù)邏輯和數(shù)據(jù)。業(yè)務(wù)流程中的數(shù)據(jù)有兩個位置：在協(xié)議消息和業(yè)務(wù)內(nèi)容的交換中，和持久存儲堆棧和其他業(yè)務(wù)－流程元數(shù)據(jù)存儲庫的底部。為限制任何的RDBMS建模觀念，我想起了Graham的來自面向?qū)ο蠓椒ǎ?/i>Object-Oriented Methods）: 原理和實踐（Principles and Practice）的數(shù)據(jù)視圖：“我堅信在受過傳統(tǒng)關(guān)系型數(shù)據(jù)庫系統(tǒng)教育的或者有這方面經(jīng)驗的一些人員的手中，數(shù)據(jù)驅(qū)動方法是危險的”。
BPEL4WS只是根據(jù)Web服務(wù)論述了消息傳送。與之相反，BEA的WebLogic Platform 8.1巧妙地使任何可想像的實體作為一個控件進(jìn)行封裝，并暴露出可用作連接點的方法調(diào)用。通過自省，它甚至可以暴露出內(nèi)部方法作為“直接”連接點。在下一篇文章中我將討論控件的更多功能。
業(yè)務(wù)流程設(shè)計模式
很明顯，業(yè)務(wù)流程的動態(tài)層創(chuàng)建了業(yè)務(wù)流程模式的基礎(chǔ)：將工作流和Web服務(wù)/消息傳送模式的結(jié)合。此外，作為OEM的一個新的品種，特定業(yè)務(wù)垂直的主題專業(yè)知識和技術(shù)的合并，啟動了高度可配置可執(zhí)行業(yè)務(wù)流程的組合和庫的延伸，我們將見證政策模式或最佳實踐業(yè)務(wù)流程的出現(xiàn)。
它們也將解決立法問題，如愛國法案（Patriot Act）和Sarbanes-Oxley、解釋最佳實踐、復(fù)雜的和充滿政治色彩的組織間引用數(shù)據(jù)問題、風(fēng)險管理、數(shù)據(jù)緩沖策略和網(wǎng)格計算的SLA。
考慮一下引用數(shù)據(jù)問題：一份Tower引用數(shù)據(jù)報告告訴我們（1）組織每年花費320萬美元于數(shù)據(jù)引用；（2）有48%的受訪組織透露引用數(shù)據(jù)包含在超過10個系統(tǒng)中，8%的受訪組織說引用數(shù)據(jù)包含在令人驚訝的150個或更多的系統(tǒng)中；（3）劣質(zhì)引用數(shù)據(jù)導(dǎo)致30%的業(yè)務(wù)失??；和（4）同樣的Tower報告透露人工輸入和有錯誤傾向的人工維護(hù)仍然是一個普遍的實踐。我還需要繼續(xù)說嗎？您已經(jīng)明白是什么意思了。傳統(tǒng)的EAI技術(shù)、數(shù)據(jù)復(fù)制以及企業(yè)級數(shù)據(jù)標(biāo)準(zhǔn)化的幼稚觀念不僅限制了成功，而且實際上將問題放大了，因為它會在整個企業(yè)范圍內(nèi)復(fù)制壞了的、不可靠的和沖突的數(shù)據(jù)。
但是基于BPMS的解決方案是如何可以解決這么大的一個問題呢？完整的答案和策略方法可以占滿BPM實踐指南的一章或兩章，或者是一個額度為百萬級的項目。不用給出大多的細(xì)節(jié)，這里給出該方法的一些描述：對一塊具有與之相關(guān)聯(lián)的許多屬性引用數(shù)據(jù)進(jìn)行可視化，比如一個大約為600的數(shù)量級。暗含的假定是企業(yè)內(nèi)部的不同組織對不同的屬性段或簇具有第一寫作權(quán)；因此，按照主要的LOB用戶所有者將屬性分為主要的簇，比如6個域，每一個含有大約100個屬性。最后，對每一個域而言，設(shè)計和實現(xiàn)流程可管理每個屬性子集的生命周期，并包含該簇的生命周期和批準(zhǔn)的政策（見圖３）。
圖３
換句話說，拿部門所有權(quán)、過程以及策略并在BPMS中實現(xiàn)之。這就是所有的BPM，對嗎？可執(zhí)行進(jìn)程。該問題的核心現(xiàn)在是一個成功解決方案的關(guān)鍵。最后但并非最不重要的，您已經(jīng)解決了另一個和企業(yè)集成有關(guān)的具有挑戰(zhàn)性的問題：公司治理和技術(shù)解決方案的所有權(quán)。
學(xué)術(shù)團(tuán)體已經(jīng)開發(fā)出了一組20個基本模式來準(zhǔn)確定義所有主要的工作流模式。然后工作流可以依據(jù)已建立的模式進(jìn)行測定。這些被分為6個主要種類：（1）基本控制流模式，（2）結(jié)構(gòu)化模式，（3）基于狀態(tài)的模式，（4）高級分支和同步模式，（5）取消模式，和（6）多實例模式。
1. 基本控制流模式是（a）順序，（b）并行分支，（c）同步，（d）互斥選擇，和（e）簡單合并。
2. 結(jié)構(gòu)化模式是（a）任意循環(huán)和（b）隱式中止。
3. 基于狀態(tài)的模式是（a）延期選擇（b）交叉存取并行路由選擇，和（c）里程碑。
4. 高級分支模式是（a）多重選擇，（b）同步合并，（c）多重合并，和（d）識別器。
5. 取消模式是（a）取消活動和（b）取消案例。
6. 多實例模式是（a）不帶同步的多實例，（b）具有先驗設(shè)計時知識的多實例，（c）具有先驗運行時知識的多實例，（e）不帶先驗設(shè)計時知識的多實例。
Eiendhoven 大學(xué)的Wil van der Aalst通過一個示例流程詳細(xì)描述了以上的一些模式。
模式3的（b）、模式5的（a）和（b）以及所有的模式6都需要消息傳送和Web服務(wù)模式。這些模式可以分為以下類別：服務(wù)訪問和配置模式包括包裝器外觀、組件配置器以及截取器。事件處理模式，包括反應(yīng)器、前攝器和接受器－連接器以及并發(fā)模式，包括活動對象、監(jiān)控對象以及領(lǐng)導(dǎo)者/追隨者架構(gòu)模式。Douglas Schmidt等在Pattern-oriented Software Architecture (第2卷): Patterns for Concurrent and Networked Objects 一文中對以上模式進(jìn)行了很好的描述。Martin Fowler等的Addison Wesley Signature Series 也是連接性模式的另外一個好的來源。
BEA WebLogic Platform 8.1 去除了低級實現(xiàn)的需求。然而，必須認(rèn)識到由于BPM實際上是憑借自身的實力成為一個編程范例的，制作意大利面條流程的前景和充滿GoTo的基本意大利面條一樣真實。合適的設(shè)計是我們強烈推薦的。
結(jié)束語
在本文中，我描述了建模背后的推理、對模型進(jìn)行建模的必要性以及BPM標(biāo)準(zhǔn)前沿的當(dāng)前狀態(tài)。我描述了BPMS如何提供一個自上而下的遞增式的方法以統(tǒng)一企業(yè)內(nèi)部所有的知識領(lǐng)域，并介紹了用于解決企業(yè)引用數(shù)據(jù)難題的一個高級最佳實踐方法。最后，我對工作流和連接模式進(jìn)行了總結(jié)。
在本系列的最后一篇文章中，我將描述獲取保險報價業(yè)務(wù)案例并介紹BMP建模選項。然后我將使用本文介紹的一些工作流和連接性模式用BEA的WebLogic Platform 8.1實現(xiàn)一個解決方案，然后討論一些仍舊存在的限制和可能的解決方案。
屆時：流程無處不在。您能看到它們嗎？
參考文獻(xiàn)
l Engberg, U. and Nielsen, M. (1986). "A calculus of communicating systems with label-passing." Report DAIMI PB-208, Computer Science Department, University of Aarhus, Denmark.
l Milner, R.; Parrow, J.; and Walker, D. (1992). "A calculus of mobile processes, Parts I and II". Information and Computation, 100, 1, pp 1-77.
l van der Aalst, W. "Classical Petri nets: The basic model." http://tmitwww.tm./staff/wvdaalst/Courses/pm/pm2classicalpn.pdf
l ter Hofstede, A. (QUT); Kiepuszewski, B. (QUT); Barros, A. (UQ); Ommert, O.(EUT); Pijpers, T. (ATOS); et al. Workflow patterns. www.tm./it/research/patterns/
l Booch, G.; Rumbaugh, J.; and Jacobson, I. (1999). The Unified Modeling Language User Guide. Addison-Wesley.
l Hohpe, G. and Woolf, B. (2004). Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions. Addison-Wesley.
l BPEL4WS, Business Process Execution Language for Web Services. BEA, IBM, Microsoft.
l BPML, (2002). Business Process Modeling Language. Bpmi.org.
l Reference Data, (2001) "The Key to Quality STP and T+1." A Tower Reuters CAPCO report.
l Graham, I. (2000). Object-Oriented Methods: Principles and Practice. Addison-Wesley.
關(guān)于作者
Labro Dimitriou是BPMS主題專家和網(wǎng)格計算顧問。他在分布式計算、應(yīng)用數(shù)學(xué)和運籌學(xué)研究領(lǐng)域已經(jīng)工作超過20年了，并開發(fā)了用于貿(mào)易、工程和地球科學(xué)的商業(yè)軟件。在過去的5年中，Labro一直致力于基于BPM業(yè)務(wù)解決方案的設(shè)計。(更多)
