本文發表于《中國計算機用戶》雜志2009年第3、4期

http://media.ccidnet.com/art/2655/20090106/1652443_1.html

http://media.ccidnet.com/art/2655/20090223/1686267_1.html

大型企業信息化中的BPM和SOA實戰

萬星[1]

JPort Group

北京交通大學

1       概覽

對于BPM和SOA的理解一直是非常困難的，我認為如果沒有企業信息系統的豐富開發背景，以及對于軟件工程歷史的充分了解，想要從紛繁的概念中理清一條思路，進一步為己所用更是讓人難以下手。SOA和BPM概念的提出都具有悠久的歷史，在學術界的研究也在向語義SOA和語用SOA等方向發展（這也是我們另一個實驗室正在探索的方向）。而廠商的驅動使得SOA和BPM逐漸落地，從早期的大量文獻在解釋SOA≠Web Service，到后來ESB的出現，以及最近的SCA/SDO規范的完善（特別是具體產品的落地），直至今年興起的BPM和SOA熱潮，我們可以看到SOA離我們的工業實踐越來越近了，它不再是一個時髦的大詞。工作流抑或業務流程的辨析同樣也使用戶為難，簡單而言，業務流程∈工作流。業務流程管理，或BPM，強調的概念是企業應用集成（EAI）。而Workflow領域的研究則顯得單純一些。許多開發者都是從技術的角度來考慮SOA，因此相信SOA只是一種新的分布式架構或者是一種新的EAI方式。起初，我也興奮的認為將BPM和SOA結合起來是偉大的想法（兩種以EAI為目標的技術整合在一起），以流程的方式整合服務，這是比ESB的想法更加先進的主意。然而，隨著研究和實踐的深入，我越發覺得SOA和BPM結合帶來的好處遠不止于此。

1.1   我們做了什么？

我們JPort團隊主要研究了IBM的BPM和SOA方法論，并結合了企業管理中的一些方法，又融合了軟件開發領域幾十年的模式和最佳實踐，對于我國南方某大型港口企業的業務流程進行了優化，并基于優化的流程設計了SOA風格的IT系統。

我們的主要工作包括：

1 找到了從企業戰略到業務操作具有完整映射的組件模型方法論——IBM創造的CBM（組件化商業模型），設計業務組件模型；

2 引入了企業價值樹模型從企業戰略出發推導出業務流程的KPI（關鍵績效指標）；

3 結合既有的業務流程優化模式，CBM方法論，企業價值樹模型，創建了一套業務流程重構方法論，包括業務流程Bad Smell，重構名錄，以及評估測試模型體系；

4 利用用例對企業的既有業務流程和業務規則（包括國家法規和企業內部的規章制度以及其他更為細節的業務規則）進行了詳盡的調研；

5 通過使用IBM Websphere Business Modeler（WBM）對那些畫在紙上或Visio，甚至是Rational Rose中的現有業務流程模型（AS-IS Model）進行了重繪，并利用其按照我們提出的業務流程重構方法論進行業務流程優化，得到未來的業務流程模型（TO-BE Model）。在WBM中，我們可以為組件（在WBM中每個流程任務都是一個組件）的一些特別的事件屬性賦值，并將那些由企業價值樹模型推導出的KPI設置在相應的組件上；

6 利用IBM的SOMA（面向服務建模和架構）方法論識別，規約和實現服務；

7 使用IBM Websphere Integration Developer（WID）來設計和開發SOA系統。其中除了包含一般服務，業務流程服務，人員任務服務，狀態機服務和業務規則服務，還包括與第三方服務（無線通訊服務，消息服務以及金蝶財務系統，AIS等）的交互，與遠程RCP（Rich Client Platform）客戶端的交互，以及遺留系統集成；

8 將系統部署在IBM Websphere Process Server和IBM Websphere ESB之上，并通過企業Dashboard監控之前在WBM中設置的KPI；

9 提供了一份完整的投資回報分析報告。

1.2   本文提供什么？

在針對該大型港口企業信息化項目中，我們遇到了一系列的問題，在理清了SOA和BPM、企業信息系統這幾個大的主題紛繁復雜的知識結構，以及IBM在這些領域的眾多概念之后，對關于這些主題的如下問題進行了重新的審視：

兩個首先被提出來的大問題是：

n  從企業角度看SOA和BPM，SOA有何不同？

n  SOA如何幫助企業進行業務流程管理？

大量的文獻都在講解什么是SOA，然而關于它究竟有何不同的討論卻難以具有說服力。本文試圖結合理論和實踐，規范與實現來說明實戰中的SOA和BPM是如何相互作用幫助企業提升企業績效，滿足企業核心戰略，以及實現ROI（投資回報率）。

2       從企業角度看SOA和BPM

2.1   SOA有何不同？

正如前文所說，理解SOA一定要站在企業的高度，與其他方法學和技術相比，SOA具有以下特點：

n  SOA是一種架構模式（現在來看，其應該是一整套方法論），而非一個產品。

n  SOA比過去的任何IT技術都要更關注企業，其中的服務應該是指業務服務，或者說企業服務，而非具體技術提供的服務，注意這是一個識別和設計服務時選取視角的問題。與領域建模中所提到的服務區分比較困難，因為對于這兩個概念的理解因人而異。

n  SOA比過去的任何IT技術更加強調抽象、關注點分離，也更加強調基于標準和規范，平臺中立，技術無關，這與計算機科學的發展是密不可分的。

SOA絕不僅僅意味著企業應用集成（EAI），也絕不僅僅就是一種分布式架構，與JEE，.Net，以及更早的CORBA（公用對象請求代理（調度）程序體系結構Common Object Request Broker Architecture ）等技術相提并論。

SOA的革命性之處在于其把企業定義為提供服務的組織，服務提供的單元作為組件，就像OO（面向對象）是革命性的一樣（也不僅僅只是一個編程模型）。在從面向過程、結構化方法論向OO邁進過程中（其間還經歷過很多的開發范型），我們需要改變過去以機器指令看待業務執行的思維，而應以對象來建模業務。而SOA中，則需要我們從更加宏觀的企業關注點出發，其最高綱領當然就是企業戰略了。

在1.1節中我所提到的那些方法論，相輔相成，渾然一體，完成了一個從企業戰略逐步推向IT實現，又以IT實現幫助企業監控企業績效，從而調整企業戰略的過程。在環環相扣的BPM和SOA解決方案中，可以更好的體會，SOA中的服務，是如何從企業的高度得來的。  

2.2   Component Business Model

CBM是IBM提出的以組件方式重新理解企業的方法論，在這個方法論中，包括三個主要步驟：洞察，架構和投資。其中最為重要的就是設計業務組件模型。

業務組件模型就是將企業中那些使用了相似的資源（人員，技術等）的類似活動聚合起來，其實這一概念和好處是非常容易理解的。快速理解這一概念的好方法是（我們就是這樣做的），把企業的流程搜集起來，然后使用Excel將每個流程作為一列，然后行表示業務活動，你可以將那些相同的活動（不同的流程總是會共享一些共同的流程活動，比如付款，計費，查詢訂單號）放在同一行，給他們起一個名字，這個名字就是服務名，然后在將一些看上去屬于同一類的活動用一個彩色的方塊圍起來，這就是一個業務組件了。企業的組織結構將幫助你設計業務組件，然而對于大型企業進行分析，你就會發現其中存在很多冗余、重復甚至是莫名奇妙的組織單元或職能部門，因此需要注意的是，不要讓糟糕的組織模型限制了設計業務組件的思維。

CBM將組件放在一個二維矩陣中，橫軸是責任等級，縱軸是業務能力，交點是業務組件。責任等級與我們在信息管理專業課本上看到的那個信息系統分級是一致的，CBM中定為Direct（引導），Control（控制），Execute（執行），對應的信息系統分級實際上就是戰略層，戰術層和操作層。其中Control主要完成的是業務的監管，包括一些分析，報告等內容。

按照IBM的官方說法⁷：業務組件包含五個方面，分別是業務用途，活動，資源，治理模式和業務服務。如果你使用過WBM，那么看到活動，資源和業務服務一定會感到興奮，如果這些直接轉成IT設計，那么我們就完成了一次從業務直接映射到IT的過程！而其中的業務服務，就是我們在SOA中的服務的一部分（因為還包括其他兩類來源的服務，見2.3節）。

2.3   Service-Oriented Modeling Architecture

IBM的SOMA方法論主要就是用來識別、規約和實現服務的。識別服務主要有三種方式，第一種就是分解業務領域，其實這種方法可以借助CBM來完成，還記得前面所說的業務組件包含的業務服務嗎？那個業務服務實際上就是這么推導出來的。第二種就是基于對既有系統的分析（這也是SOMA方法論中包含的一個活動），在已有的系統中（這些系統不久就變成遺留系統了），提供了哪些功能，完成了業務，這就是服務了，第一種方法叫自頂向下，第二種方法叫自底向上，而第三種方法當然就是從中間向兩邊了（沒有創意的IT理論界）。這種方法就是從其他方面考慮一下，有沒有落下的服務。

第二個步驟是制定服務規約，包括接口簽名，數據對象，組件設計等。列舉出的就是最重要的。其實這些設計的原則以及模式，大都可以來自于過去分布式系統的經驗，而對于服務識別，我們亦可參考分析模式，我主要參考的是Martin Fowler的《分析模式》。在實際項目中，我主要需要研究計費模式。服務是通過接口暴露的，而由組件來提供相應的服務實現。這沒什么特別的。而數據對象設計，這里的數據對象并非單指持久化對象，也非表現層數據對象或者數據傳輸對象（DTO）¹、值對象（VO）²，而是指貫穿于各層之間的數據對象。這些數據對象就是Pure Data Object，只有屬性沒有方法。

第三個步驟就是決策服務的實現。每種服務究竟該如何實現，是自己實現還是封裝遺留系統提供的服務/第三方服務（映射已有/外部服務），自己實現是新建Java服務，還是流程服務（包括狀態機），或是人員任務，抑或是業務規則。

從這套思想的步驟我們就可以看到，從來自于業務域（其來自于更高層的企業戰略分析）識別出來的服務，到規約上的設計，以及最終的實現決策，充分的體現了，SOA方法論中更加注重從企業出發和關注點分離這兩個特點。換個角度，由于當前IT技術以及計算機科學的發展，才使得我們可以如此輕松的實現從業務到IT的映射。下面就來講一下技術標準，以及它在現實世界中是什么樣子的。同時，也可以體會一下思想，理論，技術與實現是如何很好的結合起來的。

2.4   SCA/SDO規范與實現

就在我擱置對于SOA的研究有半年之久的時候，忽然打開互聯網，發現SOA已經有標準了，那就是剛露頭角的SCA（Service Component Architecture）和SDO（Service Data Object）。因此，在SOA有何不同的論述中，我尤其強調了SOA注重標準和規范這一事實。

SCA

SCA是一個SOA的編程模型，就好比JSP是Web開發的一個編程模型一樣，Web是一種架構模式，而SOA亦然。SCA有很多部分組成，核心理念是1）將業務功能作為一系列的服務而提供，2）將這一系列的服務組裝起來。SCA致力于創建服務組件，以及解決各服務組件間的多技術互訪問題。SCA的核心工件是組件（Component）。⁵

如果想要問SCA與其他諸如JMS、CORBA這樣的編程模型有何不同，我覺得IBM的Barcia 和Brent給了我們最好的答案：SCA 向您提供一個以與技術無關的方式定義接口、實現和引用的模型，從而使您能夠將這些元素綁定到所選擇的某一技術的特定實現。³

OK，當我們談及組件或對象時，無非要涉及這么幾個抽象關注點（如果你認同每個實組件或對象都要將接口與實現分離的話）：其接口是什么，實現是什么，以及其依賴了什么（依賴的組件或對象當然又包含接口和實現）。SCA則把關注點分離發揮到了極致，接口，實現，以及引用都是可選的。如圖2.4-1所示。

圖2.4-1 SCA組件模型

于是在SCA規范中⁵，SCA當前支持接口類型系統包括：Java interfaces和WSDL（WSDL 1.1 portTypes和 WSDL 2.0 interfaces）

而對于實現，則可以包括Java，C++，BPEL流程，Web Service以及SCA Composite。在IBM WID中可以選擇實現（generating implements）為Java，Web Service，Process，State Machine，Rule，Human Task等。Process，State Machine（特定的Process）由BPEL技術支持。

當SCA模塊（在SCA規范中即Composite，在IBM的產品中被稱為Module）被導出（作為服務），或者需要導入其他服務時，SCA中還可以指定要訪問服務使用的機制是什么。這是通過Binding實現的。由于導入、導出都是抽象概念，因此需要綁定通訊機制。

通過Binding，來指出想要調用服務和服務被調用時的訪問機制，包括SCA，JCA，Web Service，JMS，無狀態會話bean等。

OK，接口，實現，Binding，引用，全是獨立變化，自由組合的，全面的靈活，與技術無關。前所未有，這就是SCA。

在IBM的實現版本中，可以借助WID，很方便的開發SCA程序，并且提供了很多便利的擴展。比如談及實現問題時，IBM提供的諸如Process，State Machine之類的實現類型。

SDO

SDO是一個數據應用系統開發框架，它包括架構和API。它在SOA系統中充當抽象數據。⁶

SCA規定了怎樣編寫SOA程序，組件、服務、引用等都是如何定義的，以及它們之間如何通訊，而且還規定了如何傳遞數據，數據的類型可以有很多種，但是首選SDO。

那么SDO又是如何超越以往任何技術或規范實現技術中立、平臺無關的呢？沒什么令人驚奇的，做到這些無非就是增加中介和中間層次，將不同的關注點隔離。SDO客戶端通過SDO框架工作在SDO數據圖（Data Graph）之上。數據圖中包含多個數據對象和改變摘要（Change Summary）。DMS（數據中介服務）訪問數據源，即DMS負責從數據源創建數據圖，并且基于對數據圖的改變更新數據源。

如果想要更新SDO數據，將如何做呢？首先SDO客戶端（即SDO應用）遍歷數據圖，修改其中的數據對象，然后將修改的數據圖傳回DMS，然后DMS根據修改的數據圖更新數據源。

可以看出，正是由于有了數據圖和數據中介服務這兩個隔離，才將具體的數據源與SDO應用分離開，而由SDO框架來做出相應的轉換。

IBM對SDO進行了擴展，就是所謂的BO（Business Object）。

閱讀和理解規范，并且與具體的實現產品聯系起來，可以更好的理解SOA思想。

BPEL

BPEL是用來編排流程服務的規范，這里的服務技術是WS*-堆棧的Web Service。BPEL規范中詳細的定義了如何引入Web Service，其中包含的各種活動（諸如Invoke，IF，Scope等）以及如何建立引用。在規范中，對于引用的其他服務稱為Partner，可以看出，這樣的說法更貼近于業務層次。⁴

正是由于SCA、SDO這樣的將抽象發揮到極致的規范，使得我們可以按照CBM、SOMA方法來設計SOA系統。我想使用一下WID來進行SOA系統的開發，將使你更容易體會我想說的內容。可見，SCA和SDO中規定的組件，服務，接口，數據對象，以及BPEL中提到的活動，與之前CBM、SOMA方法中提到的組件，業務服務，接口，數據對象，和活動，是非常吻合的，而且這是一個前后照應，完整的方法體系。

小結

寫到這，似乎可以將理論和實踐、規范和實現聯系起來了，再強調一次，SOA的思維是從企業業務出發，甚至是企業戰略出發，來考慮服務和組件，而不是從遠程方法調用（RPC），消息服務，或者是分布式對象（EJB等）的角度去考慮服務。

SOA不只是EAI，這句話的另一個意思是，SOA包含EAI的部分。前文我提到了，通過BPEL和SCA Composite這樣的技術，我們可以實現系統的集成，企業是流程驅動的，流程是由業務組件組成的，那么我們就可以通過BPEL將服務組合起來，或者通過SCA將服務組裝起來（SCA的基本理念之一）。那么，還要ESB干嘛？ESB在哪？

2.5   ESB在哪？

ESB（Enterprise Service Bus，企業服務總線）繼承了EAI的思想。我不必重復講解Hub/Spoke和Bus這兩種拓撲結構。因此，ESB的出現是為了解決集成問題。

ESB是SOA的一種實現模式，任何接入ESB的應用都將封裝為服務的形式，其核心是個中介流（在IBM Websphere ESB（WESB）中是通過策略SCA/SDO實現的中介流組件），可以在其中設計消息路由，然后由其來完成消息的路由，格式、協議的轉換/翻譯，以及消息的分發。消息路由當然是要按照業務邏輯來設計。兩個系統（包括但不限于異構系統）需要進行通訊難道不是因為業務邏輯的需要？這其中的業務邏輯就包括了業務規則和業務流程，不過也有可能就是某個業務需求，需要對兩個系統進行消息轉換。

可以簡單的說，SCA+BPEL就可以代替ESB的存在了，BPEL可以充當中介流，只不過它更為強大（尤其是IBM將SCA作為WESB的編程模型之后，這進一步模糊了直接使用SCA和使用ESB的界限，如果說狀態機是Process的一個特定實現，那么WESB就是SCA的一個特定實現了）。但是如果僅僅是想做EAI，或者嘗試用SOA的方式做EAI，而不是如我前文所講，采用一套完整的、從業務到IT的水到渠成式的SOA解決方案，則采用SCA+BPEL會面臨更加復雜的學習曲線，雖然我認為它是更好的實現。

3       BPM與SOA互動

    BPM是從BPR（業務流程重組）發展而來，在大型的企業中，想要實施ERP（企業資源計劃）往往都要經歷一個BPR的過程，然而想要一蹴而就的BPR很難在大型企業中實現。預先看不到一點好處的改革將會受到巨大的阻撓，因此，一個更好的方式，先將企業的流程監管起來，發現流程運轉中的問題，或者那些大幅度創造價值的熱區，然后在對業務活動揚長避短，以提高企業的效率。那么，如果才能有效的監管流程呢？答案當然是數字化業務流程，還記得CBM方法論嗎？我們需要一套從執行到控制再到戰略的、互相溝通的組件。然后在組件之上設定KPI和特別事件（執行時間和成本，資源，等待時間和成本，角色/人員等）的屬性。當企業正常運轉時，我們就可以從現場直接搜集到第一手資料，進行企業的監控了。然后根據監控結果進行流程優化。優化后再監控，再根據新的結果優化，如此反復。

    這里就存在兩個問題，一個問題是KPI如何得來；第二個問題，當發現了問題，并且找到了優化方案后，IT如何能夠快速的隨需而變。以下兩節將解決這兩個問題。

3.1   企業價值樹模型

企業價值樹可以幫助我們從企業戰略到業務流程KPI的推導，當然，這不是數學，嚴謹的推導是不可能的。我們可以先從企業戰略主題出發，然后由主題發現企業關鍵績效指標，然后在尋找影響這些企業關鍵績效指標的核心驅動流程，最終推導出流程的關鍵績效指標（KPI）。

不得不說，詳細完整的CBM方法論應該包括這個部分，但是這一方面大概是IBM內部的機密，因此我們只能通過引入其他的模型來解決問題。

3.2   SOA幫助企業數字化BPM

從CBM方法論我們可以看到（你可以回顧本文的相應章節），其核心的業務組件模型包括了活動、資源等，我們也提到過，業務組件是從業務流程中歸納出來的，它們是一個互動的關系。

從概覽部分你可以了解到JPort團隊做了哪些工作，這些工作連起來就是為了利用SOA幫助企業數字化BPM。

SOA的方法論支持BPM中需要監控業務組件的需求，因為SOA的服務是由業務組件來實現的。另外，SOA也可以滿足隨需應變的業務要求，就像領域驅動建模一樣，基于業務建立的模型，神奇的可以隨業務更好的變化。SOA的方法論可以完整的更好的以這種方式建模，就像本文始終所演示的那樣。

4       結論

    采用SOA方法論一定要站在企業的角度去思考問題，具體的、可操作的方法就是CBM，更重要的是其中蘊含的思想。首先要了解企業的戰略是什么，根據戰略再來了解企業的業務，可以通過業務流程建模軟件模擬企業流程，分析企業問題。然后俯視整個企業，設計出業務組件模型，并暴露服務。接下來在通過SOMA方法識別出所有的服務，之后再考慮服務規約，數據對象模型的設計。最后，才是決策實現的方式，復用遺留系統的功能，引入第三方服務，還是自行開發。當然并非所有的企業應用都有必要采用這樣的步驟，比如只是一個新的功能，可以不妨以SOA的思想來開發這個新功能，關鍵是要為企業提供合理的ROI。

新的SOA編程模型SCA，與過去的眾多用于SOA實現技術相結合，使得SOA的思想可以更好的實現，比如復用遺留系統，Web Service不再是不二法門，諸如無狀態會話Bean，JMS之類的應用，亦可無縫的連接到SOA系統之中。SDO也增加了更多的抽象層次，其目標也更為宏大，這與JDO等目標不同。

SOA和BPM結合起來，使得SOA找到了新的務實方向，對于企業信息系統而言是大有裨益的。

當然，本文主要是從IBM，BEA，Oracle，SAP，JBoss，Sun等這些Java世界的領導者的視角來看待SOA，以它們的產品和理論為基礎，然而不得不說Microsoft有其自己的一套產品和理念，但是，其根本的SOA理論是一致的：以企業為圓點，高度抽象，關注點分離，技術中立，平臺無關；另外，就是其亦看中與業務流程管理的整合。畢竟，微軟是BPEL的締造者之一。

    一種務實的精神是，開發那些真正為企業創造價值的系統，如果某個業務單元本身就是低效和沒有價值的，我們是不是可以考慮一下改變它的運作模式？

參考文獻

1.         Deepak Alur , John Crupi , Dan Malks ，Core J2EE Patterns: Best Practices and Design Strategies (2nd Edition)，Prentice Hall PTR

2.         Martin Fowler，Patterns of Enterprise Application Architecture，Addison-Wesley Professional

3.         Roland Barcia，Jeff Brent，使用服務組件體系結構構建 SOA 解決方案——第 1 部分http://www.ibm.com/developerworks/cn/websphere/techjournal/0510_brent/0510_brent.html

4.         Tony Andrews, Francisco Curbera,.etc,2003，Business Process Execution Language for Web Services，Version 1.1

5.         Michael Beisiegel,Henning Blohm,.etc,2007,SCA Service Component Architecture：Assembly Model Specification

6.         Bertrand Portier, Frank Budinsky,2004, Introduction to Service Data Objects:Next-generation data programming in the Java environment,http://www.ibm.com/developerworks/java/library/j-sdo/

7.         IBM商業研究院，2006，組件化業務模型：企業實現專業化的有效工具

8.         IBM Business Consulting Services, New competitive weapons in the insurance business: Insurance component business modeling, http://www-935.ibm.com/services/us/imc/pdf/g510-4033-new-competitive-weapons.pdf

9.         Anurag Goel, Enterprise Integration:EAI vs. SOA vs. ESB, http://hosteddocs.ittoolbox.com/Enterprise%20Integration%20-%20SOA%20vs%20EAI%20vs%20ESB.pdf