體系架構藍圖（第1部分）----SOA和BPM的合并

時間：2004-09-17 作者： 瀏覽次數： 1377 本文關鍵字：BPM,  集成, SOA

文章工具  推薦給朋友  打印文章

面向服務的體系架構（Service-oriented architecture，SOA）已經成為軟件工程中一個最重要的主題。無疑，隨著Web服務的推廣和廣泛接受，以及支持基于SOA解決方案開發(fā)的case風格的IDE這一新浪潮的興起，SOA已經成為構建企業(yè)級分布式應用程序的首選藍圖。與此同時，業(yè)務流程管理（business process management，BPM）作為操作靈活的新企業(yè)并為其建模的主要支持者，正在強力反彈。

面向服務的體系架構（Service-oriented architecture ，SOA）已經成為軟件工程中一個最重要的主題。無疑，隨著Web服務的推廣和廣泛接受，以及支持基于SOA解決方案開發(fā)的case風格的IDE這一新浪潮的興起，SOA已經成為構建企業(yè)級分布式應用程序的首選藍圖。與此同時，業(yè)務流程管理（business process management ，BPM）作為操作靈活的新企業(yè)并為其建模的主要支持者，正在強力反彈。基礎結構廠商已經使BPM成為他們出售的系列產品的主要組件，瞄準機會的廠商使用專用的BPM系統提供垂直的業(yè)務解決方案，純使用BPM的廠商正在得到更加廣泛的接受。

盡管兩種趨勢均顯露出了征兆，它們的趨同現象仍不明顯，而且關于這種現象沒有統一的看法。它們是互補的表示法嗎？它們會重疊嗎？我該如何一起使用它們？這樣做有沒有另外的優(yōu)點？此外，為什么80年代末期的企業(yè)流程重構（BP reengineering）失敗了，而第三次BPM浪潮卻將要取得成功呢？

在這一系列三篇文章中，我將解決這些問題。首先，我將討論一個體系架構藍圖的最佳實踐如何將面向服務體系架構與BPM框架合并，從而為構建健壯的企業(yè)級集成解決方案并對其建模提供可重復的方案。我描述了為什么在當今，任何使用技術支持其任務陳述需要的企業(yè)比以往更能擁有合適的體系架構藍圖。最后，我討論了什么是實時交易的挑戰(zhàn)，以及BPM方法如何能夠實現企業(yè)靈活性、智能企業(yè)建模、系統開發(fā)和以客戶為中心的運作優(yōu)點。

在第二篇文章中，我將應用BPM技術來為一個支持“用于汽車保險”業(yè)務場景的軟件解決方案建模和設計體系架構。我將講述兩種設計：一種純BPM設計和一種混合型設計。我還將講述一些新興的建模工具和標準，并討論一些建模和各種體系架構選擇和策略方面的難題。

在第三篇（也是最后一篇）文章中，我將使用BEA的WebLogic Platform 8.1 構建一個POC。我將討論BEA的IDE新引入的可視化編程范型及其優(yōu)缺點，和構建完全分布式的企業(yè)級應用程序所需的一些技術。我還將解釋，為什么流行的請求/響應模式的WEB協議與基于事件的流程建模，以及它在進行架構決策時的意義不一致的原因。

體系架構模式 —— 誰需要它們?
軟件工程是藝術還是科學？在科學中，我們有明確的定義、定理和證據。在藝術中，我們有工具和技術、趨勢以及最佳實踐?？茖W中提出了一些假設，其中一些變成定理，另外一些在經過數個世紀的研究之后得到驗證，還有一些永遠沒有答案。在藝術中，新技術帶來新的趨勢，比如新聞和數字攝影。如果軟件工程是一門科學，定義我們在日常業(yè)務語言中使用的所有術語不應該是一件困難的事情，像服務、Web服務、面向服務的體系架構、BPM和BPM系統（BPMS）。的確，我可以利用數學精度來證明一個數據庫查詢算法的正確性。但是，我能夠以一種干脆、簡潔且通常會被接受的方式來回答，J2EE中的B2B集成是與純.NET Web服務解決方案相對的正確答案嗎？據我了解，對于我們中間的一些人來說，這不是問題。最后，任一種常見的貿易出版物的隨機調查指出，每個人都可以給出自己的定義，而有些人甚至質疑IT存在的本質。我不得不得出結論，軟件工程仍然是藝術多于科學。這正好是我們需要合適的最佳實踐、框架和可重復過程的原因。

模式封裝了最佳實踐，簡練地定義了域問題，描述了使問題值得關注的原因，并提出了解決方案。模式并沒有解決獨特的問題。專業(yè)人員結合各種模式來解決更為復雜而且有時更為獨特的問題。Christopher Alexander說：“模式同時也是發(fā)生在世界上的事件和告訴我們如何創(chuàng)建該事件的規(guī)則，以及我們必須創(chuàng)建它的時刻。它既是過程，也是事件。”我回想起我一直以來最喜歡的定義：對象是帶有狀態(tài)或數據及行為的數據結構。就目前來說，可以把Web服務看作帶有一個方法的對象。就像BEA WebLogic Platform 8.1所實現的那樣，會話式Web服務看起來更像是真正的對象：對它進行一次初始化，然后一直執(zhí)行方法。萬一您仍然不能肯定Web服務是粗粒度的對象，考慮：(1) IBM、BEA和 Microsoft宣布了WS-Eventing規(guī)范。它就像是優(yōu)秀但老式的對象觀察者模式。(2) 開放式網格服務體系架構（Open Grid Services Architecture）實現了網格服務協議的Web服務接口繼承。因此，Web服務提供數據和行為（Alexander的定義中的事件和規(guī)則），而BPMS 實現模式的流程組件。SOA是一個用于解決企業(yè)集成和系統開發(fā)問題的體系架構模式。

我們已經看到，SOA不是體系架構趨勢的革命，而是它經過一段時間發(fā)展的演變成果。它圍繞為企業(yè)構建分布式系統而發(fā)展。誠然，Web服務以一種普遍接受且無二義性的方式提供底層技術，以解決系統連接性問題。也許是頭一次，Web服務成功地解決了互操作性的問題，而這是 CORBA、COM、 DCOM和 RPC 做夢也從未想過的事情。我肯定，作為中立語言，XML對此也準備一展身手。然而，SOA中包括進來的BPMS框架是一個新的、革命性的元素。Howard Smith 和Peter Fingar 描述的第三次浪潮是指一組全新的概念、框架和主流產品。它正在顯著改變企業(yè)轉化的方式，從而靈活地管理和運行全局的和協作的電子商務實體。

業(yè)務流程管理的出現已經有一段時間，它更多地用于工業(yè)中，而與IT無關。并發(fā)工程和六西格瑪被開發(fā)用來解決生產和流程改進中的及時協作問題，并且確實取得了相當的成功。然而，在80年代晚期，出于多方面的原因，業(yè)務流程重構管理獲得的成功非常有限。但是最根本的原因是，重構是紙上談兵。沒有軟件來支持這樣一個復雜的任務。BPM在沒有考慮IT系統的情況下設計了自適應的企業(yè)。正如David Taylor 所寫：

“對連續(xù)性流程優(yōu)化的需要要求從根本上重新考慮如何設計和構建信息系統。提出解決固定問題的固定解決方案已經不再夠用。”

信息系統，像它們支持的業(yè)務模型一樣，必須在本質上就是自適應的。

Taylor提出一種基于OO的開發(fā)技術，作為開發(fā)自適應IT的一種方法，這種技術稱為聚合工程（convergent engineering）。然而，OOP無法成功解決分布式計算和企業(yè)集成的問題。另外，負責對企業(yè)建模的業(yè)務分析人員也沒有采用OO。

BPMS將流程建立為用于建模、軟件設計和運行時執(zhí)行的統一結構。過去，開發(fā)趨勢一直在影響我們對企業(yè)建模的方式。功能式編程使功能需求技術流行起來。關系數據庫帶來了RDBS分析和設計的流行。面向對象的編程則為OO分析和用例開發(fā)鋪平了道路。但是在大多數情況下，業(yè)務分析人員不會使用開發(fā)專門術語，因此產生了對需求可跟蹤性中通常影響的另一種翻譯的需要。

BPM規(guī)范正在快速演變?yōu)闃藴?。市場中已經出現了支持業(yè)務建模、優(yōu)化和運行時執(zhí)行的產品。正如BEA的WebLogic Platform 8.1和其他BPMS產品所實現的那樣，以流程為中心的BPMS 方法用于系統開發(fā)生命周期，它消除了對運行時阻抗不匹配的業(yè)務需求。

靈活的企業(yè)擁有自適應的業(yè)務和自適應的IT系統。如果構建企業(yè)解決方案的過程中出現一個新的問題，那么它一定是需求變化的速度。它的速度之快是前所未有的。BPMS引擎添加了一個新的層到傳統的開發(fā)堆棧（參見圖1）中，并引入服務質量來解決企業(yè)集成中的根本問題。BPMS引擎使編程最易變的部分——集成點——的軟布線變得容易。軟布線是以正式語言顯式描述的，并由BPMS引擎（又名有限狀態(tài)機引擎）執(zhí)行。正如BEA WebLogic Integrator和其他BPMS產品所實現的那樣，業(yè)務與IT資源可以同時在一個可視化的只能IDE中查看和修改流程。只需輕擊鼠標，便可部署到運行時BPMS執(zhí)行引擎。業(yè)務模擬可以運行，而性能工程可以在系統完成之前完成；這種方式聽起來就像CASE工具。SOA和BPMS工具將靈活企業(yè)的實時執(zhí)行儀表板帶向主流。

在本文余下的部分中，我將描述一個典型的金融服務企業(yè)的開發(fā)，并提出一條通向基于BPMS的SOA的遷移路徑。該路徑是增量的，但是它需要戰(zhàn)略思考和對未來遠景的承諾。作為回報，它將允許投資的早期回報，并將遺留企業(yè)轉化為完全自適應的靈活企業(yè)。

從企業(yè)遠景到組織筒倉（Silo）
企業(yè)從遠景開始。CEO和董事會采用遠景和行業(yè)使命陳述。C級管理人員定義策略，并適當地安排流程來管理執(zhí)行（參見圖1）。定義功能角色和責任，然后創(chuàng)建企業(yè)界線。業(yè)務分類（Line of business，LOB）在本質上可以是水平或垂直的（參見圖2）。垂直LOB具有以下特征：

獨立的操作域。

特有的管理和策略。

開發(fā)和維護自己的IT—自動化孤島。

足夠大以至于可以創(chuàng)建多種業(yè)務分類；例如，抵押貸款證券、市政公債、貨幣市場，等等

水平LOB具有不同的特征集合：

提供業(yè)務控制。

管理的支配和一致。

需要訪問由垂直LOB管理的數據。

合適的手動流程和書面報告。

在第二個信息紀元（不要與第二次浪潮混淆）中，我們使用了各種編程技術來鏈接自動化孤島，從FTP、數據庫復制、EAI和消息收發(fā)開始。此方法產生了一整套新問題：

·  接口的多重性: 一份Morgan Stanley Dean Witter報告表明，通常的金融服務客戶需要維護6000個接口，為此每年花費2500萬美元，而且每年還需構建900個新的點到點接口，為此需另外花費2500萬美元進行構建，并且還要花費400萬美元進行維護。

· 調停流程: 必須在每一個倉庫上實現，需要消耗有價值的時間和昂貴的資源。這是一項常用技術，用于檢驗由多個實體修改的引用數據。

·  流程: 在中間件中進行硬布線。在分析過程中捕捉流程所花費的時間和金錢屬于浪費。企業(yè)最重要的資產——流程——隱藏在n(n-1)個意大利面式接口的迷宮中。

·  開發(fā)新的水平流程：需要多個LOB 的協調。

·  實現特定和專用的接口：需要專門化和一次性編程。重用消失，維護方面的投入顯著增加。

·  異常難于跟蹤： 錯誤解析通常需要訪問多個系統。人工干預和解釋是不可避免的。找尋答案需要花費大量寶貴時間，并對客戶滿意程度和收益性方面的大致情況有著直接影響。

流程無處不在。您能發(fā)現它們嗎？

對于企業(yè)來說，流程可以是客戶層面上的，也可以是內部的，或者可以是更大流程的組成部分。我們在同樣的企業(yè)中可以找到內部流程。流程通常涉及到人與系統的交互，或者只是系統之間的交互（參見圖3）。交易流程是大規(guī)模流程的一個很好的例子。行政管理部門的交易人員在他的銷售訂單系統中接收一個來自對沖基金管理人員的交易執(zhí)行命令，或者他接到一份傳真或一個電話。交易人員檢查庫存系統的安全性或資金，并借助他的交易對手執(zhí)行交易?？梢灾圃旒堎|入場券，而交易助手可能必須在下行系統中進入它。

當因為下行系統之一錯誤地再進入，而幫助臺分析人員收到一份異常報告時，另一個內部流程啟動了。然后，他在內部記事薄之一中查找數據（原始進入記錄），請求來自事務部門的傳真（我們假定討論的交易超過了結算日期），而且因為他在兩天內沒有收到回復，也許他會再次重復同樣的行為。這個流程最終當分析人員解決了問題時終止，當然，除非他調到另一個部門或者調出公司。然后，顧問們必須參與進來，跟蹤問題和流程，這通常需要一大筆錢。

每月的客戶聲明是定期性企業(yè)范圍內流程的一個傳統例子，通常為水平LOB所特有。在大多數情況下，客戶在被不同LOB支持的產品中擁有賬號，例如，股票、U.S.證券和外匯。在月末發(fā)送多個聲明將會十分混亂。法律和一致性問題還需要交叉引用多個倉庫的數據。Patriot和 Sarbanes-Oxley Acts (一個新的業(yè)務流程，但是不賺錢)的一個主要問題是要訪問由大量LOB所擁有的數據，有時還要環(huán)繞半個世界。EAI技術和消息收發(fā)試圖借助早先闡明的限制解決這些問題。

通向靈活性的道路：以BPM為中心的SOA
讓我們考慮帶有Web服務的、以BPM為中心的SOA如何將現有的遺留企業(yè)轉換為自適應性的企業(yè)。水平流程和異常管理是用于SOA啟用的理想候選者，可以演示可調整的和速度快的ROI。沒有經歷業(yè)務流程再造的嚴謹，我們必須定義良好的流程圖。流程圖也是實行業(yè)務流程重新設計的第一步。如果使用BPMS 設計工具(Proactivity, Intalio, Interfacing Technologies)，您可以把度量關聯到流程和行為，例如，性能、開銷、IT資源、FTE、逝去的時間、容量，等等。許多BPMS設計工具允許您運行模擬，并繼續(xù)進行流程優(yōu)化（運行what-if場景），但是這并非本文的重點。對于我們的重點來說，以下列出的是良好流程圖的一些特征：

·  考慮流程而不是功能 : 流程告訴您完成什么工作以及如何完成。功能描述誰在哪里來完成它。

·  從客戶的觀點出發(fā)： 考慮從外部業(yè)務事件開始的流程，例如，一次交易、一份訂單、一個主張、一個報價請求。

·  在更寬泛的意義上并基于不同的服務質量來劃分客戶類別： 您生態(tài)系統中的性能、供應商、業(yè)務伙伴。

·  流程反映狀態(tài)變化：交易訂單、現金支付。從可管理的流程數量6－10開始。記住，大多數人最多只能保留一個頁面上的七樣東西。

·  定義核心流程和子流程：這里沒有科學理論，只有最佳實踐。然而，要當心P-calculus2 和Petri-nets；它們將在接下來的10年內帶給BPM科學的嚴密性。

·  將流程分解為行為

下一個目標是通過分解行為來定義小單元。我們將這項工作稱為Elementary Business Services (EBS)。如果您從多維矢量代數開始回想，空間中的任意一點都可以被定義為單元矢量的線形組合。在我們的例子中，我們以可以通過編排EBS子集來構造任何流程的方式定義了所有EBS。正如您可能猜想的那樣，我們將EBS實現為Web服務。識別EBS的正確集合和粒度水平很重要。這與設計對象的重要程度相同。相同的規(guī)則和技術——封裝、狀態(tài)相關性、內聚性、松散耦合和重構——同樣適用，這并不使人驚奇。

EBS的業(yè)務量體現出了大量實際優(yōu)點：

1.         它是要重用的最終指南?？梢酝ㄟ^任何想像得到的方式編排EBS，以形成新的LOB。

2.         連續(xù)性流程改進不必等到IT適應新的業(yè)務模型。

3.         EBS對企業(yè)生態(tài)系統中的企業(yè)和業(yè)務伙伴可用。

4.         放棄使用一個系統并不是一個一蹴而就的過程，而是一個循序漸進的過程。

5.         可以以一種易于管理且性價比高的方式合并和獲得IT。

6.         可以幾乎實時地設計和執(zhí)行一個新的業(yè)務流程。

從圖4中可以看出，我們可以使EBS在BEA WebLogic Platform 8.1（集成組件）的一個實例中可用。從技術上說，在BEA WebLogic Integration中，Web服務被稱為業(yè)務流程資源。我們使用IDE編排新流程，使用門戶添加UI，然后將它部署為一組EJB來執(zhí)行。就是這么簡單！現在流程是一項IT資產了，就像數據庫表、存儲過程、遺留COBOL書籍和專用的計算c庫。

許多金融服務機構的業(yè)務分類是水平的，管理高凈值的私有客戶。在啟用了BPMS SOA的企業(yè)中，開發(fā)IT基礎結構來支持這樣的新LOB完全可以與正確放置業(yè)務模型并行完成（參見圖5）

考慮Amazon.com 現象，它們并沒有創(chuàng)造任何新的EBS。所有EBS位于任何其他郵件訂單一覽表書店中的恰當位置：定購書籍，檢查庫存，信用卡付帳，打印聲明，準備裝運，給客戶發(fā)送電子郵件。但是它沒有創(chuàng)建新流程，沒有質疑已經建立好的流程，甚至不用花費什么力氣。

正如Howard Smith 和 Peter Fingar所說的那樣：“在BPM的第三次浪潮中，筒倉式思考和點到點的技術集成被靈活的、基于業(yè)務流程的體系架構所代替。”此外，Gartner Group 現在聲明，繼續(xù)將業(yè)務邏輯硬布線到軟件或中間件中或者堅持人工步驟的公司將輸給部署流程管理體系架構的競爭對手。

實時處理業(yè)務
退一步說，預測將來是很困難的事情，但是我們用非?？茖W的態(tài)度對待它，而且始終試著這么做，不管對還是錯。統計和預測是關于預測將來的兩門科學。投資組合評估和保險統計研究是有關預測的科學。實際上，我們的預測僅僅基于我們已經經歷過的、過去的性能和趨勢。實時處理業(yè)務需要預測未來的業(yè)務情況。然而，基本的業(yè)務協議和框架必須合適。今天，技術革新、BPMS和SOA是將業(yè)務目標與IT相結合的基礎。流程提供一個封裝了變化的新層。90年代早期，PowerBuilder和VB風格的工具使客戶端/服務器和關系數據庫系統的開發(fā)流行開來，通過與此相同的方式，BPMS引擎將在未來建立流程驅動的企業(yè)。事實上我預測，在我們的一生中，我們將看到對運行時流程的需求，該類流程用于實時變化或對自修改流程的需要。無疑，人類希望能夠掌管該類變化，但是通過使用UDDI-š (š 代表流程)找出最可能的服務契約和使用描述域專業(yè)知識和市場情況的規(guī)則進行決策，BMPS能夠使這項工作更加容易。隨著BPMS的普及，靈活性將被極端自適應所代替。

結束語
在本文中，我描繪了合并SOA和BPM的藍圖。從一幅企業(yè)的自頂向下流程圖開始，我們定義了基本業(yè)務服務的組合選擇。垂直LOB擁有并部署EBS。Web服務實現它們，并使它們對企業(yè)可用。通過使用BPMS引擎的一個實例，可以設計、開發(fā)、測試新的流程，并通過結合現有的EBS，在數日內添加業(yè)務值。

在我的下一篇文章中，我將：(1) 講述用于給現實世界業(yè)務保險流程建模的BPM技術，并提出一個純BPM解決方案和一個混合解決方案；(2) 使用Web服務和JMS連接設計EBS并實現它們；(3) 提出一個使用WebLogic Platform 8.1的物理基礎結構；并 (4)討論面向服務體系架構中的BPMS難題和新出現的模式。

直到：流程無處不在。您能發(fā)現它們嗎？

參考資料

·  Carr, Nicholas G. (May 2003). "IT doesn‘t Matter". Harvard Business Review.

·  Alexander, Christopher. (1979). The Timeless Way of Building. Harvard University Press.

·  Gamma,E.; Helm, R.; Johnson, R.; Vlissides,J. (1995) Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley.

·  Smith, Howard, and Fingar, Peter. (2003). Business Process Management: The Third Wave. Meghan-Kiffer Press.

·  Shina, Sammy. (1991). Concurrent Engineering and Design for Manufacturing of Electronics Products. Van Nostrand Reinhold.

·  Pande, Peter S., et al (2000). The Six Sigma Way. McGraw-Hill Trade.

·  Taylor, David A. (1992). Business Engineering with Object Technology. John Wiley & Sons, Inc.

·  Morgan Stanley Dean Witter, (April 2000). "The B2B Internet Report".

·  Gartner Group (November 2001). "Business Process Management - Are you experienced?"