談談自己對REST、SOA、SOAP、RPC、ICE、ESB、BPM知識彙總及理解

Better_Mee發表於2015-09-03

SOA：

維基百科解釋：SOA:面向服務的軟體架構（Service Oriented Architecture）,是一種計算機軟體的設計模式，主要應用於不通應用元件中通過某種協議來互操作，例如典型的通過網路協議。因此SOA是獨立於任何廠商、產品與技術的。

SOA作為一種架構依賴於服務的方向，它的基本設計原理是：服務提供了一個簡單的介面，抽象了底層的複雜性，然後使用者可以訪問獨立的服務，而不需要去了解服務底層平臺實現。

基於SOA的解決方案，努力使經營目標而建立企業的質量體系。SOA架構是五層水平：

1. 使用者介面層–這些GUI的終端使用者或應用程式訪問的應用程式/服務介面。

2. 業務流程層–這些精心設計的代表在應用方面的業務用例服務。

3. 服務層–服務合併在一起，為整個企業提供實時服務。

4. 服務元件層–用來建造服務的元件，如功能庫和技術庫，技術介面等。

5. 作業系統–這層包含資料模型，企業資料倉儲，技術平臺等。

正因為SOA架構實現不依賴於技術，因此能夠被各種不同的技術實現。

例如：

SOAP, RPC

REST

DCOM

CORBA

OPC-UA

Web services

DDS

Java RMI

WCF (Microsoft's implementation of web services now forms a part of WCF)

Apache Thrift

SORCER

因此REST、SOAP、RPC、RMI、DCOM等都是SOA的一種實現而已。

Webservice：

Web services是建立可互操作的分散式應用程式的新平臺。

webservice是一種標準，他可以通過soap或rest的方式來實現。

傳統的soap-webservice，使用了soap協議（基於xml包裝）等。如果使用restful-webservice的話，則不需要soap與之相關的協議等，而是通過最簡單的 http 協議傳輸資料 ( 包括 xml 或 json) 。既簡化了設計，也減少了網路傳輸量（因為只傳輸代表資料的 xml 或 json ，沒有額外的 xml 包裝）。

與webservice相關的幾個概念：

wsdl：網路服務描述語言是Web Service的描述語言，它包含一系列描述某個web service的定義。

UDDI：是一種目錄服務，企業可以使用它對 Web services 進行註冊和搜尋。UDDI，英文為 "Universal Description, Discovery and Integration"，可譯為“通用描述、發現與整合服務”。

UDDI^[1] 是一種規範，它主要提供基於Web服務的註冊和發現機制，為Web服務提供三個重要的技術支援：①標準、透明、專門描述Web服務的機制；②呼叫Web服務的機制；③可以訪問的Web服務註冊中心。UDDI規範由OASIS（Organization for the Advancement of Structured Information Standards^[1] ）標準化組織制定。^[1]

其中RMI、RPC、SOAP比較：

普通的Web專案，一般是繫結了特定的渲染語言（jsp、velocity，freemark），當然也有原始的html。但是僅僅限定了特定的返回資料格式與之相對應。Webservice專案則是能夠被其他系統呼叫（約束了相關格式）。因此普通的利用ssh或者springmvc建立的web專案並沒有釋出webservice。普通的web專案可以使用一些技術將需要釋出的介面釋出出去，就成為了webservice了。

什麼是SOAP?

SOAP (Simple Object Access Protocol) 顧名思義，是一個嚴格定義的資訊交換協議，用於在Web Service中把遠端呼叫和返回封裝成機器可讀的格式化資料。事實上SOAP資料使用XML資料格式，定義了一整套複雜的標籤，以描述呼叫的遠端過程、引數、返回值和出錯資訊等等。而且隨著需要的增長，又不得增加協議以支援安全性，這使SOAP變得異常龐大，背離了簡單的初衷。另一方面，各個伺服器都可以基於這個協議推出自己的API，即使它們提供的服務及其相似，定義的API也不盡相同，這又導致了WSDL的誕生。WSDL (Web Service Description Language) 也遵循XML格式，用來描述哪個伺服器提供什麼服務，怎樣找到它，以及該服務使用怎樣的介面規範，簡言之，服務發現。現在，使用Web Service的過程變成，獲得該服務的WSDL描述，根據WSDL構造一條格式化的SOAP請求傳送給伺服器，然後接收一條同樣SOAP格式的應答，最後根據先前的WSDL解碼資料。絕大多數情況下，請求和應答使用HTTP協議傳輸，那麼傳送請求就使用HTTP的POST方法。

什麼是REST？

REST (REpresentational State Transfort) 形式上應該表述為客戶端通過申請資源來實現狀態的轉換，在這個角度系統可以看成一臺虛擬的狀態機。拋開R. T. Fielding博士論文裡晦澀的理論不說，REST應該滿足這樣的特點：1)客戶端和伺服器結構；2)連線協議具有無狀態性；3)能夠利用Cache機制增進效能；4)層次化的系統；說到底，REST只是一種架構風格，而不是協議或標準。但這種新的風格（也許已經歷史悠久？）對現有的以SOAP為代表的Web Service造成的衝擊也是革命性的，因為它面向資源，甚至連服務也抽象成資源，因為它和HTTP緊密結合，因為它伺服器無狀態。

目前知道的三種主流的Web服務實現方案為：
REST：表象化狀態轉變 (軟體架構風格）
SOAP：簡單物件訪問協議
XML-RPC：遠端過程呼叫協議（已經慢慢被SOAP取代）

其他理解：

REST：表徵狀態轉移（Representational State Transfer），採用Web 服務使用標準的 HTTP 方法 (GET/PUT/POST/DELETE) 將所有 Web 系統的服務抽象為資源，REST從資源的角度來觀察整個網路，分佈在各處的資源由URI確定，而客戶端的應用通過URI來獲取資源的表徵。Http協議所抽象的get,post,put,delete就好比資料庫中最基本的增刪改查，而網際網路上的各種資源就好比資料庫中的記錄（可能這麼比喻不是很好），對於各種資源的操作最後總是能抽象成為這四種基本操作，在定義了定位資源的規則以後，對於資源的操作通過標準的Http協議就可以實現，開發者也會受益於這種輕量級的協議。REST是一種軟體架構風格而非協議也非規範，是一種針對網路應用的開發方式，可以降低開發的複雜性，提高系統的可伸縮性。

SOAP：簡單物件訪問協議（Simple Object Access Protocol）是一種標準化的通訊規範，主要用於Web服務（web service）中。用一個簡單的例子來說明 SOAP 使用過程，一個 SOAP 訊息可以傳送到一個具有 Web Service 功能的 Web 站點，例如，一個含有房價資訊的資料庫，訊息的引數中標明這是一個查詢訊息，此站點將返回一個 XML 格式的資訊，其中包含了查詢結果（價格，位置，特點，或者其他資訊）。由於資料是用一種標準化的可分析的結構來傳遞的，所以可以直接被第三方站點所利用。

XML-RPC：一個遠端過程呼叫（remote procedure call，RPC)的分散式計算協議，通過XML將呼叫函式封裝，並使用HTTP協議作為傳送機制。後來在新的功能不斷被引入下，這個標準慢慢演變成為今日的SOAP協定。XML-RPC協定是已登記的專利專案。XML-RPC透過向裝置了這個協定的伺服器發出HTTP請求。發出請求的使用者端一般都是需要向遠端系統要求呼叫的軟體。

三種方案的簡單比較

XML-RPC已慢慢的被SOAP所取代，現在很少採用了，但它還是有版權的，我在此就不作多介紹。
成熟度上：SOAP在成熟度上優於REST

效率和易用性上：REST更勝一籌（REST效率更高的原因在於，僅僅是建議的Http協議之上的一種協議。而SOAP則需要對資料、xml封裝資訊頭，解封裝等）

安全性上：SOAP安全性高於REST，因為REST更關注的是效率和效能問題

分散式能力：REST更適合在分散式環境中使用、因為REST是基於原生Http協議的，而http協議是無狀態的。大型分散式環境都能夠對無狀態支援良好，無狀態增強了整個系統的擴充套件性。這也是為什麼越來越多的雲端計算，分散式專案選擇REST。

（注：SOAP也是基於HTTP協議的，但是卻提供了session、cookie等機制來使得SOAP有狀態，從而支援需要有狀態的業務。有狀態舉例：1、增加一個使用者2、獲取最新增加的使用者。那1的執行成功與否，及執行先後順序的狀態將會影響2的結果。）

總體上，因為REST模式的Web服務與複雜的SOAP和XML-RPC對比來講明顯的更加簡潔，越來越多的web服務開始採用REST風格設計和實現。例如，Amazon.com提供接近REST風格的Web服務進行圖書查詢；雅虎提供的Web服務也是REST風格的。REST對於資源型服務介面來說很合適，同時特別適合對於效率要求很高，但是對於安全要求不高的場景。而SOAP的成熟性可以給需要提供給多開發語言的，對於安全性要求較高的介面設計帶來便利。所以我覺得純粹說什麼設計模式將會佔據主導地位沒有什麼意義，關鍵還是看應用場景，正是那句老話：適合的才是最好的

同時很重要一點就是不要扭曲了REST現在很多網站都跟風去開發REST風格的介面，其實都是在學其形，不知其心，最後弄得不倫不類，效能上不去，安全又保證不了，徒有一個看似象摸象樣的皮囊。

SOAP在安全方面是通過使用XML-Security和XML-Signature兩個規範組成了WS-Security來實現安全控制的，當前已經得到了各個廠商的支援，.net ，php ，java 都已經對其有了很好的支援。REST沒有任何規範對於安全方面作說明。因此在考慮安全性上，SOAP要高於REST。

ICE：

ICE是分散式應用的一種比較好的解決方案，雖然現在也有一些比較流行的分散式應用解決方案，如微軟的.NET（以及原來的DCOM）、CORBA及WEB SERVICE等，但是這些物件導向的中介軟體都存在一些不足：
.NET是微軟產品，只面向WINDOWS系統，而實際的情況是在當前的網路環境下，不同的計算機會執行不同的系統，如LINUX上面就不可能使用.NET；
CORBA雖然在統一標準方面做了很多的工作，但是不同的供應商實現之間還是缺乏互操作性，並且目前還沒有一家供應商可以針對所有的異種環境提供所有的實現支援，且CORBA的實現比較複雜，學習及實施的成本都會比較高；
WEB SERVICE最要命的缺點就是他的效能問題，對於要求比較高的行業是很少會考慮WEB SERVICE的。
ICE的產生就是源於.NET、CORBA及WEB SERVICE這些中介軟體的不足，它可以支援不同的系統，如WINDOWS、LINUX等，也可以支援在多種開發語言上使用，如C++、C、JAVA、RUBY、PYTHON、VB等，服務端可以是上面提到的任何一種語言實現的，客戶端也可以根據自己的實際情況選擇不同的語言實現，如服務端採用C語言實現，而客戶端採用JAVA語言實現，底層的通訊邏輯通過ICE的封裝實現，我們只需要關注業務邏輯。

什麼是ESB？