SOA BPEL ESB的前生後世:—-作者：呂建偉

SOA BPEL ESB的前生後世

我不是賣中介軟體的，所以我也不必鼓吹SOA概念和大道理。
我也不是準備寫一本SOA書的，所以我也不必寫部落格心得分享時咬文嚼字。

這篇文章涉及到SOA、SCA、SDO、工作流程、BPEL、ESB、訊息中介軟體、WebService、EAI、分析設計方法、物件導向、面向組件眾多技術，不仔細看，你仍然會混淆SOA=WebService=EAI。BPEL=工作流程。ESB=訊息中介軟體。但這些混淆全是錯誤的，你需要在以下的閱讀中體會他們的差異。如果你沒有耐心去理解這些技術的差異和來龍去脈，那麼你可以直接閱讀最後一段，那裡是總結。你可以無需瞭解過程，直接瞭解正確的結果。但可能會造成你只知道什麼是正確的，但不明白為什麼它是正確的。如果你正好想要這種結果，那麼正合你的心意。

SOA很難，是因為領導SOA影響力和市場產品的公司把許多東西都裝進了SOA，以希望獲得一攬子解決方案。
這個解決方案從SOA項目的方案規劃諮詢方法到專案管理方法（如RUP，項目崗位角色職責流程評估）到業務描述方法（如UML）到中介軟體到業界標準（如WebService、SOAP、SCA、SDO）到系統整合診斷到系統整合介面設計（如如何設計面向服務的介面）到系統整合的商務程序整合（如BPEL），而商務程序整合往往被業界的工作流程和業務基礎平台牽扯。而國外項目一牽扯到系統整合，就牽扯到遺留系統，什麼Corba、COBOL、PL、SAP、JAVA，更是讓國內的程式員茫然失措。

不僅僅是眾多領域的名詞、技術標準、產品名稱讓國內程式員心慌，而且國內的IT技術發展時間短，根本沒多少遺留系統，而且國內的程式員也大多年輕，對過去的技術發展和遺留系統的產生和應用曆史，也不太清楚。所以把各種因素都綜合在一起，讓程式員望而卻步。而企業的CIO們，一看這麼複雜，而且還搞不清楚有什麼用，而且一定很貴，而且一定實施周期長風險大，就聽說業界鼓吹SOA有利於系統整合、SOA可以使你的IT和業務能靈活的隨需應變，但業界也始終沒有拿出讓人易懂和信服的案例說明怎麼就能靈活的隨需應變和系統整合。於是，CIO們更是迷茫。

我想起劉韌在2008CSDN技術大會的一句話：不講假話，要講實話；不講道理，要講經曆。

我就拿自己所感受所經曆的，跟大家分享一下。

去年，做了一個中大的項目，項目周期耗時半年，中間當然還少不了經常鬥爭併合作著的IBM、SAP兩個老熟人。

項目是一個大型國企全國系統整合，從C/S的軟體到B/S的軟體都要整合在一個資料中心，並且在網路門戶中可存取，還有專門的分析室使用資料中心資料進行商業智慧分析。

當然，少不了Webservice、XML、訊息中介軟體、BEPL、ESB。

過去區域網路C/S管理軟體系統之間的整合，往往是通過互相讀取彼此的資料庫。但是在正規的項目中是不這樣做的。為什麼。因為讀取和改寫哪個表的哪個欄位，需要定義一個特殊的資料庫使用者，這還防不勝防，不知道是哪個系統把資料改亂了，誰來承擔責任。你如果只整合過兩個系統之間的資料交換，而且是寥寥幾個表的幾個欄位的資料彼此讀寫，覺得這還沒什麼，如果七八個系統都要整合在一起，互相讀寫，而且深度關聯，就天下大亂了。你往往會感歎怎麼CIO這麼沒眼光，用了不同公司的不同產品，現在遭到報應了吧。其實，話不能這麼說，很多時候的項目的上線由於天時、地利、人和，各種因素影響，就是形成了現在你所看到的現狀。如果你是CIO，這麼多年下來，估計你的現狀不比現在好多少。企業就是這麼發展的，雖然可能你在聚會吃飯的時候大發牢騷埋怨公司的管理和戰略和老闆的決策，但真換你來做，你不見得會比你的老闆強。就這個道理。現狀已經形成，曆史不能倒退，但未來還要前進，我們還不能把包袱扔掉，推倒重來。企業不是這麼運作的。企業就是在不斷困境和限制中不斷前進，就看誰能把握好平衡和資源的調度，堅持執行好決策。

過去我就遇見一個區域網路C/S管理軟體系統整合的項目，人家不讓讀資料庫。人家給寫了一個DLL。可惜的是該死的PB寫的DLL。我們這方是DELPHI寫的DLL給他們。大家知道PB是偽編譯代碼，而且代碼是Script形式的，而DELPHI是二進位，而且是結構化OO編程形式的。所以在資料記憶體表示和格式和資料類型上都不匹配。最後都改成了字串也不行。因為DELPHI的String，其實質上也是指標型的。好不容易周折解決了資料類型問題，還有資料批量傳輸的效能問題。一個DLL函數，我想把一條資料庫記錄傳給對方，怎麼拼這個字串。當時想定義N個參數，最後由於對方需要的欄位不斷變動，最後介面老變，於是定義N個參數方案被廢棄，改為傳一條記錄。記錄的每個欄位用特殊字元隔開，然後拼在一起，拼一個總的字串，對方再拆出來處理。這還是一條記錄就這麼麻煩，對於N條資料被資料集修改，就要調用N次介面函數，處理速度太慢。而且，還面臨雙方資料事務的阻礙。另外，由於我們不斷變動介面升級DLL，DLL版本黑洞也讓我們叫苦不迭。

這就是整合。這還不算雙方利益不統一引起的明爭暗鬥，延遲給介面，提供錯誤資訊和介面，提供很有限的資訊。使項目整合周期異常的長，中間充滿了變數。所以，企業CIO一提到系統整合就頭疼，能躲就躲。

於是，WebService、XML、訊息中介軟體、BEPL、ESB英明神武的上場了。

咱們也別定義N個參數了，也別拼字串了，也別DLL互相寫入程式碼綁死了，也別費盡心思處理資料事務了。

有XML給咱們批量傳遞資料，資料是有格式的。介面也別你是PB的DLL，我是DELPHI的DLL了，咱們都是統一的資料類型和介面調用方式，都是WebService了。咱們倆也別綁死了，都發送到ESB中吧，讓ESB來處理事務、訊息資料路由吧。咱們也別互相寫入程式碼，BEPL的XML格式描述的業務介面調用整合編排語言來幫忙，讓ESB引擎來驅動執行BEPL。

ESB有點像訊息中介軟體，用於訊息資料的安全的、事務的路由。ESB也有點像組件中介軟體，提供了組件註冊，組件安全，組件版本、組件部署的功能（我懷疑很多功能是元件伺服器功能增強後提供的，而不是ESB提供的）。但是ESB最獨特的是提供了BPEL的解析執行監控管理。BPEL設計器提供了BPEL的編排，而ESB提供了指令碼的執行。

整合省了不少的事。

但大家有沒有注意到一件事，我這個整合之事，我並沒有提到SOA。真是怪怪，滿篇案例講的洋洋洒洒，居然沒有SOA這個字眼出現。那怎麼國際巨頭都拿這樣類似的整合項目來鼓吹他們的SOA呢。難道WebServvice+ESB+BPEL就等於SOA？那過去我們做的系統整合、EAI，豈不是我們N年前就SOA了？哈哈。

看來，這並不是SOA。我們需要從另一個角度分析SOA。

SOA，中文全寫是服務導向架構。這個名稱定義讓我們很是似曾相識。

面向服務？？？我們聽說過面向組件，物件導向，面向函數。是不是和這些有些淵源？

體繫結構？我們聽說過EJB、COM+、CORBA體繫結構，難道和這些體繫結構類似？

服務導向架構（Service-Oriented Architecture，SOA）是一個組件模型，它將應用程式的不同功能單元（稱為服務）通過這些服務之間定義良好的介面和契約聯絡起來。

介面是採用中立的方式進行定義的，它應該獨立於實現服務的硬體平台、作業系統和程式設計語言。這使得構建在各種這樣的系統中的服務可以一種統一和通用的方式進行互動。

這是完整的定義：
1 是一個組件模型
2 不同功能單元，稱為服務
3 服務之間通過介面和約定聯絡起來
4 介面是中立的

這個定義是很虛的。

(？？ 這怎麼和我多年前學習COM時說的一模一樣？

我找到別的網站上的一篇文章說的：

SCA服務元件與傳統組件的主要區別在於：

　　1. 服務元件往往是粗粒度的，而傳統組件以細粒度居多。（不對，過去我們做COM，也有流程集合組件，是粗粒度的）

　　2. 服務元件的介面是標準的，主要是WSDL介面，而傳統組件常以具體API形式出現。（不對，只是介面實現技術不同而已，有這樣區別的嗎？）

　　3. 服務元件的實現與語言是無關的，而傳統組件常綁定某種特定的語言。（不對，很多語言都能實現COM）

　　4. 服務元件可以通過組件容器提供QoS的服務，而傳統組件完全由程式碼直接控制。（不對，傳統組件也業由組件容器提供了若干服務）

)

雖然，一再聲稱WebService（XML/SOAP/UDDI/WSDL）不是SOA唯一的可介面中立的描述方法。但事實上，WebService是現在最成熟最有體系最獲得業界廠商支援的介面中立描述方法。所以，無論業界廠商怎麼闢謠說WebService不是唯一方法，但大家都已經預設。廠商的闢謠是因為有些遺留系統，現在沒有WebService的改造能力了，不支援WebService，不辟這個謠，就要丟單子。而國外很多老掉牙還不捨得扔的系統。所以國外非常羨慕中國，一上手就是最先進的技術和標準，沒有曆史包袱，不走彎路，整合花銷和風險和周期都會好很多。

SOA是一個組件模型。組件模型我們知道，COM+、EJB都是組件模型。組件有屬性、方法、事件。組件運行在組件容器中。組件容器來保證組件的建立、並發、池化、日誌、銷毀。

而組件是脫胎於對象的。看看各個語言實現的組件模型，其實現都是應用物件模型。對象具有資料和方法，沒有事件。而資料，也沒有什麼讀寫限制。這是組件和對象非常明顯的區別。

我們曾經面向函數編程，更早時候我們還寫過大流水沒有函數的程式碼（現在想來甚是幼稚，簡直是一團漿糊，但我現在代碼複查的時候居然還能看見這類代碼，其跟蹤錯誤修正、品質保證、變化裁減擴充、閱讀理解都不符合，如何能商業化開發）。

但是函數無法表現函數間的關係。只好放到不同的原始碼檔案中表示邏輯群集。但這種表示方法很是糟糕。資料和方法仍然沒有分離，也沒有屏蔽可見層級。於是，我們必須走向物件導向。其實我們對OO，並不是像業界理論那樣分析業務、映射成對象，然後設計對象。其最開始就是為瞭解決代碼可視層級的事情，繼承和多態並不是我們所考慮的。也沒有很專業的去分析設計對象。但確實是人以群分物以類聚，實現出來的東西，等我們真正理解懂了OO的理論，回頭看我們的代碼，居然還真的很符合OO理論。讓我感歎現在很多入道不幾年的程式員，為了OO而OO，為了實踐OO理論而強制自己寫OO代碼，最後是OO的表面形式，而思路卻是大流水，連函數流程都閱讀不出來，思路分叉判斷很多。建議先踏實把面向函數用起來，再自然過渡到物件導向。

物件導向也有解決不了的問題。那就是沒有事件和屬性。於是面向組件產生。但是大家仔細分析原始碼，屬性和事件，都是通過物件導向的方法做到的。如一個屬性，往往是Getxxx和Setxxx構成，一個事件是一個特殊形式的屬性而已。

事情都是承接的，自然而然過渡的，就和面向大流水到了面向過程，然後是物件導向，然後是面向組件。

面向組件，我們又遇到了問題。而這些問題，都是由於我們順其自然理解習慣而引起的。

很多人分析完業務，不管你是用UML還是什麼組織圖-流程-考核的方法，你在軟體設計的時候，總是要有個艱難的映射。就是把現實要映射成類，要影射成組件。而這個映射是如此的不符合順其自然的思考習慣。你需要變換一種思路，而這分析和設計兩種思路，老是擰不在一起。

我們不想繼續擰巴了。我們就想很直白的說：我要完成這個事情。我現在有這麼多資訊，我輸入進去，你就給我產出我需要的計算結果。OK，就這麼簡單。我不想再映射什麼類，什麼組件了。

這就是很自然的人類思考習慣。我們業界老前輩老專家兜兜轉轉，研究發表了N多理論和方法，但最終仍然科學理性擰不過人類順其自然的分析習慣。又回來了。但這個迴歸已經升華了，我們在簡單的介面之下再也不會有大流水的實現了。在我們的服務介面之下，我們自由的應用我們擅長的開發實現方法。我們再也不用和客戶講類映射，客戶再也不用和我們講商務程序了。我們統一了，我們就想這麼做：我要完成這個事情。我現在有這麼多資訊，我輸入進去，你就給我產出我需要的計算結果。OK，就這麼簡單。

讓客戶學會UML，不可能。過去讓我們和客戶，想拿RUP過程管理方法和UML事務描述方法來統一，只是個理論理想。

SOA，不是面向組件升級到面向服務這麼簡單。是我們的軟體分析方法、軟體設計方法、軟體開發方法的變革。是業界對過去這些理論和產品的反思。業界對世界的抽象方法變了。

SOA需要將應用程式的不同功能單元（稱為服務）通過這些服務之間定義良好的介面和契約聯絡起來。但怎麼聯絡起來。高內聚，低耦合是我們一貫的原則。像過去我們互相開放DLL的方式根本不合適，都是寫入程式碼進自己的系統中。一旦介面改變，都需要修改。幸好，業界發現了有個工作流程的東西，聽說可以驅動商務程序。於是，滿心歡喜的奔了過去。

真正一用才發現不對。工作流程的規範世界早已固定。工作流程產生的時候，還沒有SOA呢。SOA需要的商務程序串連，工作流程的原理類似，但並不是最適合軟體服務的串連。於是，業界又集體聯合起來研發了BPEL，商務程序處理語言。但有些工作流程廠商也唯恐被稱為落後時代腳步，於是強嘴說自己已經是SOA了。於是，業界李鬼李逵一堆。各有各的利益，各唱各的調。

SOA這種世界觀也需要落地到一個可實現的架構。於是SCA和SDO出現。SCA是SOA的落地架構架構規範，SDO是資料結構規範和資料存取原理規範。而這些規範，用現有的開發語言和技術架構都可以實現。所以，對於現有系統，無須認為現有的系統落後了，不符合SOA了，需要重新上一套SOA軟體了。

但是，我粗略閱讀SCA規範，特別類似於我過去熟悉的組件模型體系。只不過SCA在組件模型基礎上又提供了服務定義和服務Wire。組件模型是提供了個體的規範，而SCA不僅提供了個體，更提供了個體之間串連的規範。組件模型讓我熟悉了介面與實現的分離，讓我熟悉了容器運行保護，讓我熟悉了中繼資料管理。沒有經過面向組件時代的人，不會感受到SOA到來的必要性。

我們曾經用組件模型開發應用軟體，其目的就是想像這些組件都是獨立的個體，然後我們用一種指令碼把這些組件穿在一起（過去我想到是VBA指令碼，然後是Javascript指令碼，然後是ASP指令碼，然後又關注了工作流程，均不滿意，最後才落眼到BEPL）。而如今，SCA、SDO、BEPL、ESB給我們多年的設想提供了可落實的體系模型。我們需要這樣靈活組合的應用軟體，我們不需要一個上千個參數配置的航母軟體（如SAP R/3）。

只有瞭解了SOA、BPEL、ESB的前生後世，我們才能平和的看待這些技術，看待和這些技術相關的技術，我們才能有的放矢的去學習它、利用它，為我們更快速的適應客戶需求變化而有益。

最後一句話：

對於我個人從業經驗，我經曆過面向過程、物件導向和面向組件三個架構思想的產品開發曆史，我們一直試圖解決軟體組件粒度靈活組合的問題，我學習技術也一直是抱著解決問題而研究，而不是怕趕不上潮流而學習。我個人片面的認為SOA的架構思想就是我們過去應用的面向組件思想的延伸，然後再套上WebService的外殼，我們過去開發COM+，為了跨防火牆為了異構串連CORBA可費死了勁。SOA還結合了業務靈活的BPEL思想，整合了中介軟體訊息匯流排WebService治理的技術思路。SOA整合了這麼多架構思想和企業產品技術，根本目標就是使我們的IT更加靈活。我們過去做面向組件也是為了這個根本目標。SOA就是通過面向業務的分析方法+WebService中立技術+BPEL指令碼業務編排+ESB服務治理匯流排中介軟體來達到IT靈活的。

SOA是面向服務，OO是物件導向。就這麼簡單，一個問題領域。SOA不是EAI，不是系統整合的一種方式。那是業界某些公司為了達到自己的利益目的做的宣傳，混淆大家的視聽。怎麼學習面向的時候，沒有人提這些系統整合。到了面向服務，就牽扯到系統整合了？被人忽悠了？過去我做企業整合，用的是讀取資料庫，然後是DLL，然後是WEBSERVICE，但沒有使用SOA。

過去業務設計使用的是一種思路，軟體設計使用的是另一種思路，老對接不上去，SOA統一了。都必須從業務角度看問題，而不能一方是流程，一方卻是類圖和時序圖。

給大家舉一個例子。

有一個業務，是使用者在網站上選擇自己想買的車型，然後點一下計算，就顯示自己購這台車的總費用。

那這個功能就是一個軟體服務。SAAS，軟體即服務。

業務設計員設計好這個業務。功能設計員就定義了一個軟體服務介面，可能叫CalcTotalFee(CarType:XML)。

使用者輸入的資料，被程式員程式處理成SDO傳入，調用服務介面，返回總費用。但介面裡面是怎麼計算的，用了哪些OO技術或組件技術，或乾脆就是大流水帳代碼，那是你程式員自己的事情。而業務設計員和功能設計員是統一認識的。

這就是業務設計、功能設計、功能開發三者的關係。

有了SCA和SDO，SOA概念踏實多了，否則和過去的面向組件和現在微軟鼓吹的webservice式的SOA很容易迷惑。

小結：

SCA是SOA的落地規範，否則SOA就是個概念。
BPEL是為了編排串連各個服務的，BPEL不是為了工作流程審核審批的。根本就是兩個目的兩碼事，不要混淆。用BPEL實現工作流程，或者用工作流程想實現BPEL，都是錯誤思路。
ESB是運行服務，並且驅動BPEL的。
SDO是為了規範介面間的傳輸資料的格式和資料操作的規.否則，你傳輸的XML就自己瞎編格式了
SCA和SDO是OSOA組織制定的

但微軟也鼓吹自己的SOA，但沒有具體理論（微軟一向不愛宣稱自己的理論，雖然微軟做了很多專利和論文），微軟有具體的WCF和微軟的webservice實現模型作為SCA的對照，也有也有LINQ和ADO.NET作為SDO的對照。
因為微軟的SOA服務元件，不遵守SCA/SDO規範，所以在微軟的體系裡很自在，和IBM陣營整合，就有些困難。因為大家往往用Visual studio工具開發webservice，而自動產生的這個架構，並不符合SCA/SDO標準。

如果你非要讓我用什麼誰加誰等於誰來說明SOA。我只能暴力的用SOA=WebService+SCA+SDO+BEPL+ESB來表達。如果你覺得SCA+SDO只是IBM、SUN、BEA之類制定的標準而不是業界SOA的標準，如果你覺得BEPL屬於商務程序整編的範疇不是SOA模型的範疇，你可以執著的人為SOA=WebService。這種認識就類似於把WINDOWS、OFFICE、Visual Studio、SQLSERVER都從微軟去掉一樣。那樣的微軟仍然是微軟公司。但那真的還是微軟嗎？就如同人是一個完整的概念，你非要把人=頭+手+腳+...就等於人，這樣粗暴而簡單的定義和認識，顯然是不對的。