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

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的結果。）

整體上，由於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？

ESB與EAI區別：

ESB是將全部的系統的交互都放在SOA統一服務總線上面來控制處理。

EAI只是將不一樣的系統集成起來（能夠採用ESB總線形式，也能夠採用點對點的形式）。

ESB能幫助解決什麼？

參考博客： http://blog.csdn.net/tantexian/article/details/48135907

附上開源使用量最大的ESB mule：

什麼是BPM：

BPM，即業務過程管理，是一種以規範化的構造端到端的卓越業務流程爲中心，以持續的提升組織業務 績效 爲目的的系統化方法，常見商業管理教育如 EMBA 、MBA等均將BPM包含在內。

用來審批，用來發送短信，發送郵件等業務流程編排。

兩大主流開源BPM對比：（Activiti與spring集成更好）

Activiti Demo：

國內bpm在線試用：

‘