深刻淺出SOA思想

#0 系列目錄#

• 聊聊服務架構
• 深刻淺出SOA思想
• 微服務、SOA 和 API對比與分析

#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須要從軟件開發的技術發展史談起。真正的軟件開發從開始到如今經歷了四個階段，也能夠說成是四代：

1. 彙編語言開發；

2. 面向過程的軟件；

3. 面向對象的組件開發；

4. 面向服務的架構開發，也是今天要談論的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火起來的真正緣由#

1. 軟件開發技術的不斷提升。

2. 硬件性能的提高，價格降低，投出SOA所消耗的成本爲企業所能忍受。

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

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

5. 不少企業的軟件應用系統已經知足不了信息高度集成化的要求，爲了提升企業的核心競爭力，企業不惜重金，上SOA。

6. SOA的招牌很響亮，超越了一切，兼容了一切。它不摒棄舊系統，而是將不少舊系統繼承起來，就能夠實現。-----實際上，我我的認爲這是一個騙局。

#4 SOA最有前景的舞臺#

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

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

3. 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 服務組件##

1. 概念

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

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

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

b) 多個組件能夠用同一個實現（思考：一個Java的對象能夠同時實現多個接口）。

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

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

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

2. 服務組件的組成部分

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

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

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

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的異同#

1. 相同點

目的是同樣的：都是爲了集成。

大體方向同樣：都是爲了將服務和傳輸協議解耦。

2. 不一樣點

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嗎？

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

帶着疑問，繼續往下看：

1. 首先，ESB不是SOA。SOA的最多見的實現方式方式是SCA和JBI，而SCA的實現須要ESB，相反JBI則不須要ESB，能夠參看本人對JBI和SCA分析解讀的文章。

2. 其次，由於IBM和Oracle（收購了BEA和SUN的牛X公司）都推崇SCA模式的SOA，所以SCA實際上已經成爲SOA的事實標準，說道SOA，最早想到的就是SCA模式了。

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

##12.4 ESB的特色## ESB是一種在鬆散耦合的服務和應用之間標準的集成方式。它能夠做用於：

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

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

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

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