深入淺出 SOA 思想

轉自：陶邦仁

鏈接：http://my.oschina.net/xianggao/blog/638195

1 SOA是什麼

SOA的全稱是Service-Oriented Architecture，面向服務架構。是一種架構，不是一種具體的開發技術。

SOA的出現，預示著一個以服務為導向的新IT（Information Technology）時代的到來。

SOA服務的理念思想，本質上是一種業務和技術完全分離，業務又能和技術自由組合的思想，它達到了軟體設計的最高境界。

SOA是為軟體集成而服務的，它實現了技術和架構的完全分離，消除了軟體服務集成的所有障礙。

SOA超越了所有的具體技術（如WebService），也超越了所有具體的架構（ESB），同時，SOA也包含這些具體的技術和架構。

SOA在Java領域有兩套標準：一個是SUN推出的JBI（沒有得到BEA和IBM的承認），另外一個是：IBM和BEA等公司推出的SCA和SDO標準。

要真正理解什麼是SOA需要從軟體開發的技術發展史談起。真正的軟體開發從開始到現在經歷了四個階段，也可以說成是四代：

彙編語言開發；

面向過程的軟體；

面向對象的組件開發；

面向服務的架構開發，也是今天要談論的SOA架構；

SOA與前面三代的軟體開發技術對比，不同點是SOA超越了軟體開發語言本身。是一種面向服務的架構，與軟體開發語言無關。

但就軟體開發本身來說，SOA是一種技術，又超越了所有具體的技術。

IT的中文翻譯為信息技術，是為企業的需要出現的。IT的本質上包括兩種信息的使用方式：創建信息、調用信息。

IT的進一步發展：信息集成。使信息的應用價值提高。

IT語言的發展史：面向過程--》面向對象--》面向組件--》標準的WS--》面向服務。

IT語言的發展過程：逐步的解耦與封裝。

2 SOA的技術革命

SOA既然能成為第四代軟體開發技術，究竟帶來什麼革命。

首先，SOA是一種開發思想。是一種松耦合的框架。可以讓軟體超越開發語言。

其次，SOA的開發需要SOA體系的支撐，就像J2EE應用一樣，離不開應用伺服器。SOA也一樣，也有一個類似J2EE伺服器的東西支持著整個SOA體系架構----ESB（ Enterprise Service Bus），企業服務匯流排。通過這個匯流排，將多個系統連接起來。

其次，SOA是基於消息請求響應的一個系統，對請求類型有高度的兼容性。與一個Web應用容器相比，web應用容器只能處理HTTP請求，而SOA的ESB可以接受HTTP、FTP、WebService、JMS...等請求。這就使得SOA架構具有高度的兼容性，可以將不同的平台集成到一起，從而相互協調工作。

3 SOA火起來的真正原因

軟體開發技術的不斷提高。

硬體性能的提升，價格下降，投出SOA所消耗的成本為企業所能忍受。

SOA受到了IMB、Oracle、Sun、Microsoft等大公司的熱力追捧，被捧紅了，實際上，一直以來都是這些公司在引領軟體應用的潮流。

SOA技術革命每年有上千億美元的市場價值。軟體要升級，這些服務提供商才可以買出更多的中間件伺服器，賣出更多的硬體，賺取更多利潤。

很多企業的軟體應用系統已經滿足不了信息高度集成化的要求，為了提高企業的核心競爭力，企業不惜重金，上SOA。

SOA的招牌很響亮，超越了一切，兼容了一切。它不摒棄舊系統，而是將很多舊系統繼承起來，就可以實現。—–實際上，我個人認為這是一個騙局。

4 SOA最有前景的舞台

基於SOA是的思想和技術，SOA最適合最擅長的就是系統集成。而系統集成的關鍵就是提取公共的有價值的服務。各個系統通過暴露服務，經過ESB這條匯流排連接後，就將幾個系統集成起來了。這在新一代軟體開發中也許會得到應用。

SOA的架構註定SOA在中小企業內部沒有多大價值。中小企業的攤子還不夠大。

SOA系統集成難點在於抽取公共的服務。對於老的系統來說，抽取服務就是抽筋。很難很難，意味著要修改軟體，要適合SOA的胃口。因此，對一些不同語言開發的系統來說，使用SOA進行系統實際上是扯淡。

5 SOA發展現狀

對SOA口號叫的最響的是IBM，出書最多的也是IBM，成功的案例還沒看到。所有的大公司都在忽悠，希望拿到第一筆大單。

SOA以來ESB，ESB本身也是一種中間件，或者說是一個增強了的企業應用伺服器。目前開源的有幾個，也沒見過成功的案例。估計SOA技術從起步到成熟還有很長一段路要走。ESB的實現還需要一個發展過程。

相反與SOA有緊密聯繫WebService技術已經深入人心。現在用的比較多。

6 WebService與SOA的區別

SOA是在WebService的基礎上發展起來的。

WebService實現了松耦合和粗粒度的服務。

7 SOA基本要素

鬆散耦合：服務之間、介面與實現之間、業務組件和傳輸協議之間。

粗粒度：SOA中服務的介面更接近實際中的用戶操作。

位置和傳輸協議透明：不論服務組件的傳輸協議如何改變，客戶端的調用程序傳輸協議不需要改變。

8 SOA目標

敏捷的、不受限制的業務集成。

9 JBI架構思想

SOA在Java領域有兩套標準：一個是SUN推出的JBI（沒有得到BEA和IBM的承認），另外一個是：IBM和BEA等公司推出的SCA和SDO標準。

JBI之關注Java組件只處理Java組件的集成。

SCA實現了業務組件和傳輸協議的分離，可以處理各種平台組件的集成。

SDO可以的自由讀取各種不同數據源的數據。

另外，BPEL本質上是一種集成WebService服務的語言，也可以算作為SOA的一部分。

9.1 認識JBI

JBI（Java Business Integration）中文翻譯為「Java業務集成」，是SUN發布的一個用於Java組件進行集成的一個標準。

JBI的本質是一種服務匯流排思想。

JBI的目標是創建一個用於各種Java組件服務集成的運行環境。

9.2 認識JBI容器

JBI是一種思想，JBI思想的實現就是JBI容器。

JBI容器是為彌補現有J2EE容器的不足而出現的。

現有應用伺服器的容器類型：Servlet容器、EJB容器、JMS容器。

現有應用伺服器的容器不足：

a) 每種容器都有自己特殊的傳輸協議，相互之間不能直接通信。比如：Servlet容器只能接受HTTP/SOAP的傳輸協議，EJB容器只能處理RMI的傳輸協議，JMS只能處理JMS的傳輸協議。

b) 一個純粹的服務提供者，不是一個服務的集成者。也就是說，容器之間不能繼承服務。

c) 容器間服務的調用需要編寫客戶端代碼。

JBI容器以一種可插拔的方式集成不同類型的服務，而不是通過編寫客戶端代碼來實現服務的集成。

9.3 JBI容器的組成與架構

1. JBI容器的架構圖

2. JBI容器的組成的三大部分

綁定組件（BC：Binding Components）：專門用來接收各種不同傳輸協議的請求，原理是JBI實現了各種不同協議的綁定組件，綁定組件可以細分為接收BC和發送BC。接收BC主要負責發送請求和接收響應，發送BC主要用來調用外部的服務。

服務引擎（SE：Service Engines）：這類組件只處理JBI容器內部的消息。JBI容器通常在接收到消息後，需要對請求的消息做一些「處理」，然後再調用外部服務的提供者。根據功能的不同，將SE組件分為以下三種類型：

Transform SE：專門處理各種傳輸協議和格式變化。

BPEL SE：專門負責將Web Service進行流程編排。

Rules SE：專門負責通過規則將各種服務進行集成。

JBI的規格化消息路由器（Normalized Message Router）：是JBI內部消息系統的核心，所有的組件之間不能交換消息，只能通過NMR來傳遞。

在JBI容器內部，只有一種標準的規格化消息（Normalized Message）。任務服務組件進入JBI環境之前，通過BC轉換為規格消息NM。在JBI環境里，所有的服務都不能相互調用，不論是請求還是回答消息，都要先轉給NMR，再由NMR分發。JBI運行環境裡面的組件（SE、BC）和NMR都是通過NM來進行信息交換的。

9.4 JBI容器工作的概念圖

如上圖：

外部請求者將一個HTTP請求發送給JBI容器，容器的HTTP BC接收請求，並將請求的消息格式化為NM發送給消息接收轉換引擎，然後再將NM發送給NMR，由NMR再將NM發送給SOAP BC，SOAP BC將NM轉換為SOAP消息發送到外部的WS組件。執行後，消息按照原路返回。

10 SCA架構思想

10.1 認識SCA

SCA（Service Component Architecture）中文翻譯為「服務組件架構」，是一種全新的軟體架構思想。

SCA中，最重要的一個概念是Service----服務，它的內涵是獨立於具體的技術。因此，SCA不會稱之為 Java組件架構，或Web Service 組件架構。所謂的具體技術，主要有兩層含義：一是程序語言，而是傳輸協議。

現有的組件是和傳輸協議緊密耦合的。比如EJB組件採用的是RMI傳輸協議，Web Service組件採用的是SOAP傳輸協議。SCA組件則能自由地綁定各種傳輸協議。

SCA是對目前組件編程的進一步升華，其目標是讓服務組件能自由綁定各種傳輸協議，集成其他的組建與服務。

SCA與傳統的業務組件最大區別在於SCA實現了兩個功能：一是組件和傳輸協議的分離，二是介面和實現語言的分離。

SCA的本質是一種軟體架構思想，SCA架構是獨立於程序語言的SOA架構。

SCA的目標是創建一個可集成服務組件的運行環境。

為什麼需要SCA？答案：集成的需要。

先看沒有使用SOA技術的系統的集成的情況，需要相互約定和暴露介面。需要編寫集成的客戶端調用代碼。調用方和被調用方要「知彼知己」才能很好的集成，而這又都帶來高昂的代價和複雜度。

使用SCA的好處：組件之間處於一種松耦合的狀態，不需要在自己的代碼中加入對方組件的介面代碼。

10.2 認識SCA容器

SCA是一種思想，SCA思想的具體實現是SCA標準和SCA的容器環境。

SOA容器也分JBI容器、SCA容器等。SCA容器也是SOA容器總稱的一種，通常都單獨稱SCA容器，而直接泛稱SOA容器。這裡為了區別與別的SOA容器開來，而稱之為SCA容器。

SCA容器實現了將複雜的服務組件集成過程隱藏在容器內部，開發者之需要按照SCA的標準去開發和集成服務，最終部署到SCA的容器裡面即可。

SCA容器的實現很複雜，有關其容器的組成與架構也是一種商業秘密。開發人員只需要關係如何遵循SCA標準去開發和集成服務組件即可。

為了更好去實現SCA架構，理解SCA服務組件概念的內涵和外延對開發者來說是非常重要的。

10.3 服務組件

概念服務組件準確講沒有確切的概念，它更貼近於一件實實在在的物品，只能從他的形狀、組成、結構、功能、狀態、屬性等側面來描述它。

服務組件是SCA裡面最基本的功能單元，它主要包括介面、實現、引用、屬性等部分。可以從一下側面來描述服務組件。

a) 是在一個模塊（Composit）內的通過配置生成的一個實現的實例。

b) 多個組件可以用同一個實現（思考：一個Java的對象可以同時實現多個介面）。

c) 提供服務和消費服務（組件可以調用別的組件的服務）。

d) 通過配置來實現對象的屬性值（配置節點為property）。

e) 組件通過連線（Wire）來設置服務引用。連線可以連接到別的組件的服務，也可以連接到模塊的引用（模塊的概念後面會詳細講述）。

服務組件的組成部分服務組件的組成包含四個部分：服務、組件實現、引用、創建屬性。

下面給出服務組件的結構圖如下：

如上圖，分別講述服務組成的各個部分：

a) 服務（Service），用來讓其他組件調用。是一個介面。如果是基於Java的SCA，它就是Java的介面；也可以是WSDL的ProtType介面，目前只有這兩種形式。

b) 組件實現(Implementation)，實現所創建的服務，對Java來說，就是介面的實現類。

c) 引用（Reference），一個組件可能需要調用其他組件，需要創建於igeqita組件的引用。對Java來說，就是其他組件的Java介面。

d) 屬性（Property），對組件實現的一種屬性參數注入。

對一個服務組件來說，服務和實現時必須的，引用和屬性是非必需的。例如，對上面Hello World的例子來說，組件的結構圖如下：

10.4 服務模塊

SCA是通過模塊（Composite）將SCA組件集成在一起的。

SCA的模塊是實際上是將SCA組件（做為零件）重新組合集成度更高的組建，從整體看來SCA模塊和SCA組件的結構式一致的。從構成組件的「零件」角度看，SCA模塊是用了組件作為零部件重新組裝為新的組件（模塊）。

其實道理也非常簡單，下面是SCA模塊的基本原理圖：

如上圖，可以看到，模塊從整體上也是個組件。

模塊是通過SCA的配置文件配置組裝形成的，不需要程序的硬編碼。

提升（Promote）：就是將組件的介面、屬性、或引用裝配為模塊的對應的介面、屬性或引用。

連線（Wire）：就是在模塊內部，組件之間的調用關係。比如組件A的實現調用了組件B，那麼組件AB間就存在一個連線。

當組件之間需要調用的時候，由於目前組件（如EJB、WS、JMS）傳輸協議的多樣化，這樣在相互的調用的時候，需要將綁定不同的協議去調用。這裡儘可能避免讓人迷惑而又沒有價值的綁定（Binding）一詞的概念。

在一個大的項目裡面，可能會有很多服務模塊，多個服務模塊之間如果需要相互調用，那麼就可以將多個服務模塊通過WS或者JMS等技術綁定在一起，形成服務子系統。

理解了模塊的概念，就不難理解服務子系統了。

11 SCA與JBI的異同

相同點目的是一樣的：都是為了集成。

大致方向一樣：都是為了將服務和傳輸協議解耦。

不同點SCA以介面作為切入點，從組件介面層將傳輸協議和介面實現解耦，是從編程的角度出發，一種全新的編程模型。

JBI是以請求消息和相應消息作為切入點，在集成時將消息和傳輸協議解耦，形成一種與傳輸協議無關的標準消息，這樣形成一種全新的區別於現有應用伺服器的集成容器，是從容器的角度出發，一種全新的容器模型。

12 SOA、ESB、SCA之間的聯繫

SOA是一種服務集成的架構思想，超越具體的技術和架構，又涵蓋具體的技術和架構。SOA的最常見的解決方案是SCA，其次還有JBI，BPEL、SDO也勉強可以算做SOA的解決方案之一，因為後兩者也是為了系統解耦和集成提供了支持。

SCA是服務組件架構，是SOA思想的最流行的一種實現方式，SOA思想的實現除了SCA外，還要JBI等。

ESB是SCA思想實現的基礎設施。ESB主要作用是集中註冊發布服務，為服務與傳輸協議之間解耦。並不是所有的SOA架構都需要ESB，ESB是SCA特有的。當然任何符合ESB特徵的解決方式都可以稱之為ESB，也不僅僅是SCA內部的。

綜上所述，以上概念都是一個理念、一種思想，並非特指代某個現有的實現或解決方案，這是起初接觸SOA 容易犯的概念上的錯誤。

12.1 ESB與SOA的關係

這兩個詞包含的內涵太豐富了，無法用一兩句話說清楚，並且，這個詞在不同的地方含義也有所不同。

SOA—-面向服務架構，實際上強調的是軟體的一種架構，一種支撐軟體運行的相對穩定的結構，表面含義如此，其實SOA是一種通過服務整合來解決系統集成的一種思想。不是具體的技術，本質上是一種策略、思想。

ESB—-企業服務匯流排，像一根「聰明」的管道，用來連接各個「愚笨」的節點。為了集成不同系統，不同協議的服務，ESB做了消息的轉換解釋與路由等工作，讓不同的服務互聯互通。

目前ESB與SOA的確切概念依然沒有。但可以明確的說SOA就是一種服務集成思想，它的不同實現方式可能差別很大，目前SOA最常見的實現方式是SCA和JBI。

12.2 ESB究竟是什麼

這個問題在個大廠商之間，認識和觀點也存在很大差異。

IBM、Oracle等認為ESB是連接服務的一種模式，但一些開源組織和其他廠商認為ESB是一種產品，並且提供了ESB連接解決方案的實現，這種實現可以認為是中間件，也可以認為是組件工具。

對此，我個人的觀點更偏向前者，ESB是一種模式，ESB的實現方式也很多，可以稱之為ESB產品。當然在不同場合ESB的含義也不同，需要鑒別。

12.3 為什麼ESB總和SOA黏在一塊

通常，這兩個名詞總不分家，談論的話題中「你中有我，我中有你」。

為什麼是這樣的呢？

ESB是SOA嗎？

兩者之間究竟有什麼微妙的關係呢？

帶著疑問，繼續往下看：

首先，ESB不是SOA。SOA的最常見的實現方式方式是SCA和JBI，而SCA的實現需要ESB，相反JBI則不需要ESB，可以參看本人對JBI和SCA分析解讀的文章。

其次，因為IBM和Oracle（收購了BEA和SUN的牛X公司）都推崇SCA模式的SOA，因此SCA實際上已經成為SOA的事實標準，說道SOA，最先想到的就是SCA模式了。

最後，ESB是SCA架構實現不可缺少的一部分，ESB產品脫離了具體的應用外，沒有任何意義。ESB的作用在於實現服務間智能化集成與管理的中介。通過ESB可以訪問所集成系統的所有已註冊服務。

12.4 ESB的特點

ESB是一種在鬆散耦合的服務和應用之間標準的集成方式。它可以作用於：

面向服務的架構 – 分布式的應用由可重用的服務組成；

面向消息的架構 – 應用之間通過ESB發送和接受消息；

事件驅動的架構 – 應用之間非同步地產生和接收消息；

ESB就是在SOA架構中實現服務間智能化集成與管理的中介。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！

本站內容充實豐富，博大精深，小編精選每日熱門資訊，隨時更新，點擊「搶先收到最新資訊」瀏覽吧！

請您繼續閱讀更多來自 程序源 的精彩文章: