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都從微軟去掉一樣。那樣的微軟仍然是微軟公司。但那真的還是微軟嗎？就如同人是一個完整的概念，你非要把人=頭+手+腳+...就等于人，這樣粗暴而簡單的定義和認識，顯然是不對的。

總結

以上是生活随笔為你收集整理的SOA BPEL ESB的前生后世:----作者：吕建伟的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。