這篇文章主要介紹“REST、SOA、SOAP、RPC、ICE、ESB、BPM概念是什么”，在日常操作中，相信很多人在REST、SOA、SOAP、RPC、ICE、ESB、BPM概念是什么問題上存在疑惑，小編查閱了各式資料，整理出簡單好用的操作方法，希望對大家解答”REST、SOA、SOAP、RPC、ICE、ESB、BPM概念是什么”的疑惑有所幫助！接下來，請跟著小編一起來學(xué)習(xí)吧！

站在用戶的角度思考問題，與客戶深入溝通，找到海拉爾網(wǎng)站設(shè)計與海拉爾網(wǎng)站推廣的解決方案，憑借多年的經(jīng)驗，讓設(shè)計與互聯(lián)網(wǎng)技術(shù)結(jié)合，創(chuàng)造個性化、用戶體驗好的作品，建站類型包括：成都網(wǎng)站設(shè)計、做網(wǎng)站、企業(yè)官網(wǎng)、英文網(wǎng)站、手機端網(wǎng)站、網(wǎng)站推廣、域名注冊、網(wǎng)絡(luò)空間、企業(yè)郵箱。業(yè)務(wù)覆蓋海拉爾地區(qū)。

SOA：

維基百科解釋：SOA:面向服務(wù)的軟件架構(gòu)（Service Oriented Architecture）,是一種計算機軟件的設(shè)計模式，主要應(yīng)用于不通應(yīng)用組件中通過某種協(xié)議來互操作，例如典型的通過網(wǎng)絡(luò)協(xié)議。因此SOA是獨立于任何廠商、產(chǎn)品與技術(shù)的。

SOA作為一種架構(gòu)依賴于服務(wù)的方向，它的基本設(shè)計原理是：服務(wù)提供了一個簡單的接口，抽象了底層的復(fù)雜性，然后用戶可以訪問獨立的服務(wù)，而不需要去了解服務(wù)底層平臺實現(xiàn)。

基于SOA的解決方案，努力使經(jīng)營目標(biāo)而建立企業(yè)的質(zhì)量體系。SOA架構(gòu)是五層水平：

    1.   用戶界面層–這些GUI的最終用戶或應(yīng)用程序訪問的應(yīng)用程序/服務(wù)接口。

    2.   業(yè)務(wù)流程  層–這些精心設(shè)計的代表在應(yīng)用方面的業(yè)務(wù)用例服務(wù)。

    3.   服務(wù)層–服務(wù)合并在一起，為整個企業(yè)提供實時服務(wù)。

    4.   服務(wù)組件層  –用來建造服務(wù)的組件，如功能庫和技術(shù)庫，技術(shù)接口等。

    5.   操作系統(tǒng)–這層包含數(shù)據(jù)模型，企業(yè)數(shù)據(jù)倉庫，技術(shù)平臺等。

正因為SOA架構(gòu)實現(xiàn)不依賴于技術(shù)，因此能夠被各種不同的技術(shù)實現(xiàn)。

例如：

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的一種實現(xiàn)而已。

Webservice：

Web services是建立可互操作的分布式應(yīng)用程序的新平臺。

webservice是一種標(biāo)準(zhǔn)，他可以通過soap或rest的方式來實現(xiàn)。

傳統(tǒng)的soap-webservice，使用了soap協(xié)議（基于xml包裝）等。如果使用restful-webservice的話，則不需要soap與之相關(guān)的協(xié)議等，而是通過最簡單的 http 協(xié)議傳輸數(shù)據(jù) ( 包括 xml 或 json) 。既簡化了設(shè)計，也減少了網(wǎng)絡(luò)傳輸量（因為只傳輸代表數(shù)據(jù)的 xml 或 json ，沒有額外的 xml 包裝）。

與webservice相關(guān)的幾個概念：

wsdl：網(wǎng)絡(luò)服務(wù)描述語言是Web Service的描述語言，它包含一系列描述某個web service的定義。

UDDI： 是一種目錄服務(wù)，企業(yè)可以使用它對 Web services 進行注冊和搜索。UDDI，英文為 "Universal Description, Discovery and Integration"，可譯為“通用描述、發(fā)現(xiàn)與集成服務(wù)”。

UDDI^[1]  是一種規(guī)范，它主要提供基于Web服務(wù)的注冊和發(fā)現(xiàn)機制，為Web服務(wù)提供三個重要的技術(shù)支持：①標(biāo)準(zhǔn)、透明、專門描述Web服務(wù)的機制；②調(diào)用Web服務(wù)的機制；③可以訪問的Web服務(wù)注冊中心。UDDI規(guī)范由OASIS（Organization for the Advancement of Structured Information Standards^[1]  ）標(biāo)準(zhǔn)化組織制定。^[1] 

其中RMI、RPC、SOAP比較：

普通的Web項目，一般是綁定了特定的渲染語言（jsp、velocity，freemark），當(dāng)然也有原始的html。但是僅僅限定了特定的返回數(shù)據(jù)格式與之相對應(yīng)。Webservice項目則是能夠被其他系統(tǒng)調(diào)用（約束了相關(guān)格式）。因此普通的利用ssh或者springmvc建立的web項目并沒有發(fā)布webservice。普通的web項目可以使用一些技術(shù)將需要發(fā)布的接口發(fā)布出去，就成為了webservice了。

什么是SOAP?

SOAP (Simple Object Access Protocol) 顧名思義，是一個嚴(yán)格定義的信息交換協(xié)議，用于在Web Service中把遠程調(diào)用和返回封裝成機器可讀的格式化數(shù)據(jù)。事實上SOAP數(shù)據(jù)使用XML數(shù)據(jù)格式，定義了一整套復(fù)雜的標(biāo)簽，以描述調(diào)用的遠程過程、參數(shù)、返回值和出錯信息等等。而且隨著需要的增長，又不得增加協(xié)議以支持安全性，這使SOAP變得異常龐大，背離了簡單的初衷。另一方面，各個服務(wù)器都可以基于這個協(xié)議推出自己的API，即使它們提供的服務(wù)及其相似，定義的API也不盡相同，這又導(dǎo)致了WSDL的誕生。WSDL (Web Service Description Language) 也遵循XML格式，用來描述哪個服務(wù)器提供什么服務(wù)，怎樣找到它，以及該服務(wù)使用怎樣的接口規(guī)范，簡言之，服務(wù)發(fā)現(xiàn)?，F(xiàn)在，使用Web Service的過程變成，獲得該服務(wù)的WSDL描述，根據(jù)WSDL構(gòu)造一條格式化的SOAP請求發(fā)送給服務(wù)器，然后接收一條同樣SOAP格式的應(yīng)答，最后根據(jù)先前的WSDL解碼數(shù)據(jù)。絕大多數(shù)情況下，請求和應(yīng)答使用HTTP協(xié)議傳輸，那么發(fā)送請求就使用HTTP的POST方法。

什么是REST？

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

目前知道的三種主流的Web服務(wù)實現(xiàn)方案為：
REST：表象化狀態(tài)轉(zhuǎn)變 (軟件架構(gòu)風(fēng)格）
SOAP：簡單對象訪問協(xié)議 
XML-RPC：遠程過程調(diào)用協(xié)議 （已經(jīng)慢慢被SOAP取代）

其他理解：

REST：表征狀態(tài)轉(zhuǎn)移（Representational State Transfer），采用Web 服務(wù)使用標(biāo)準(zhǔn)的 HTTP 方法 (GET/PUT/POST/DELETE) 將所有 Web 系統(tǒng)的服務(wù)抽象為資源，REST從資源的角度來觀察整個網(wǎng)絡(luò)，分布在各處的資源由URI確定，而客戶端的應(yīng)用通過URI來獲取資源的表征。Http協(xié)議所抽象的get,post,put,delete就好比數(shù)據(jù)庫中最基本的增刪改查，而互聯(lián)網(wǎng)上的各種資源就好比數(shù)據(jù)庫中的記錄（可能這么比喻不是很好），對于各種資源的操作最后總是能抽象成為這四種基本操作，在定義了定位資源的規(guī)則以后，對于資源的操作通過標(biāo)準(zhǔn)的Http協(xié)議就可以實現(xiàn)，開發(fā)者也會受益于這種輕量級的協(xié)議。REST是一種軟件架構(gòu)風(fēng)格而非協(xié)議也非規(guī)范，是一種針對網(wǎng)絡(luò)應(yīng)用的開發(fā)方式，可以降低開發(fā)的復(fù)雜性，提高系統(tǒng)的可伸縮性。

SOAP：簡單對象訪問協(xié)議（Simple Object Access Protocol）是一種標(biāo)準(zhǔn)化的通訊規(guī)范，主要用于Web服務(wù)（web service）中。用一個簡單的例子來說明 SOAP 使用過程，一個 SOAP 消息可以發(fā)送到一個具有 Web Service 功能的 Web 站點，例如，一個含有房價信息的數(shù)據(jù)庫，消息的參數(shù)中標(biāo)明這是一個查詢消息，此站點將返回一個 XML 格式的信息，其中包含了查詢結(jié)果（價格，位置，特點，或者其他信息）。由于數(shù)據(jù)是用一種標(biāo)準(zhǔn)化的可分析的結(jié)構(gòu)來傳遞的，所以可以直接被第三方站點所利用。

XML-RPC：一個遠程過程調(diào)用（remote procedure call，RPC)的分布式計算協(xié)議，通過XML將調(diào)用函數(shù)封裝，并使用HTTP協(xié)議作為傳送機制。后來在新的功能不斷被引入下，這個標(biāo)準(zhǔn)慢慢演變成為今日的SOAP協(xié)定。XML-RPC協(xié)定是已登記的專利項目。XML-RPC透過向裝置了這個協(xié)定的服務(wù)器發(fā)出HTTP請求。發(fā)出請求的用戶端一般都是需要向遠端系統(tǒng)要求呼叫的軟件。

三種方案的簡單比較

XML-RPC已慢慢的被SOAP所取代，現(xiàn)在很少采用了，但它還是有版權(quán)的，我在此就不作多介紹。
成熟度上：SOAP在成熟度上優(yōu)于REST

效率和易用性上：REST更勝一籌（REST效率更高的原因在于，僅僅是建議的Http協(xié)議之上的一種協(xié)議。而SOAP則需要對數(shù)據(jù)、xml封裝信息頭，解封裝等）

安全性上：SOAP安全性高于REST，因為REST更關(guān)注的是效率和性能問題

分布式能力：REST更適合在分布式環(huán)境中使用、因為REST是基于原生Http協(xié)議的，而http協(xié)議是無狀態(tài)的。大型分布式環(huán)境都能夠?qū)o狀態(tài)支持良好，無狀態(tài)增強了整個系統(tǒng)的擴展性。這也是為什么越來越多的云計算，分布式項目選擇REST。

（注：SOAP也是基于HTTP協(xié)議的，但是卻提供了session、cookie等機制來使得SOAP有狀態(tài)，從而支持需要有狀態(tài)的業(yè)務(wù)。有狀態(tài)舉例：1、增加一個用戶2、獲取最新增加的用戶。那1的執(zhí)行成功與否，及執(zhí)行先后順序的狀態(tài)將會影響2的結(jié)果。）

總體上，因為REST模式的Web服務(wù)與復(fù)雜的SOAP和XML-RPC對比來講明顯的更加簡潔，越來越多的web服務(wù)開始采用REST風(fēng)格設(shè)計和實現(xiàn)。例如，Amazon.com提供接近REST風(fēng)格的Web服務(wù)進行圖書查找；雅虎提供的Web服務(wù)也是REST風(fēng)格的。REST對于資源型服務(wù)接口來說很合適，同時特別適合對于效率要求很高，但是對于安全要求不高的場景。而SOAP的成熟性可以給需要提供給多開發(fā)語言的，對于安全性要求較高的接口設(shè)計帶來便利。所以我覺得純粹說什么設(shè)計模式將會占據(jù)主導(dǎo)地位沒有什么意義，關(guān)鍵還是看應(yīng)用場景，正是那句老話：適合的才是最好的

同時很重要一點就是不要扭曲了REST現(xiàn)在很多網(wǎng)站都跟風(fēng)去開發(fā)REST風(fēng)格的接口，其實都是在學(xué)其形，不知其心，最后弄得不倫不類，性能上不去，安全又保證不了，徒有一個看似象摸象樣的皮囊。

SOAP在安全方面是通過使用XML-Security和XML-Signature兩個規(guī)范組成了WS-Security來實現(xiàn)安全控制的，當(dāng)前已經(jīng)得到了各個廠商的支持，.net ，php ，java 都已經(jīng)對其有了很好的支持。REST沒有任何規(guī)范對于安全方面作說明。因此在考慮安全性上，SOAP要高于REST。

ICE：

ICE是分布式應(yīng)用的一種比較好的解決方案，雖然現(xiàn)在也有一些比較流行的分布式應(yīng)用解決方案，如微軟的.NET（以及原來的DCOM）、CORBA及WEB SERVICE等，但是這些面向?qū)ο蟮闹虚g件都存在一些不足：
 .NET是微軟產(chǎn)品，只面向WINDOWS系統(tǒng)，而實際的情況是在當(dāng)前的網(wǎng)絡(luò)環(huán)境下，不同的計算機會運行不同的系統(tǒng)，如LINUX上面就不可能使用.NET；
 CORBA雖然在統(tǒng)一標(biāo)準(zhǔn)方面做了很多的工作，但是不同的供應(yīng)商實現(xiàn)之間還是缺乏互操作性，并且目前還沒有一家供應(yīng)商可以針對所有的異種環(huán)境提供所有的實現(xiàn)支持，且CORBA的實現(xiàn)比較復(fù)雜，學(xué)習(xí)及實施的成本都會比較高；
 WEB SERVICE最要命的缺點就是他的性能問題，對于要求比較高的行業(yè)是很少會考慮WEB SERVICE的。
 ICE的產(chǎn)生就是源于.NET、CORBA及WEB SERVICE這些中間件的不足，它可以支持不同的系統(tǒng)，如WINDOWS、LINUX等，也可以支持在多種開發(fā)語言上使用，如C++、C、JAVA、RUBY、PYTHON、VB等，服務(wù)端可以是上面提到的任何一種語言實現(xiàn)的，客戶端也可以根據(jù)自己的實際情況選擇不同的語言實現(xiàn)，如服務(wù)端采用C語言實現(xiàn)，而客戶端采用JAVA語言實現(xiàn)，底層的通訊邏輯通過ICE的封裝實現(xiàn)，我們只需要關(guān)注業(yè)務(wù)邏輯。

什么是ESB？

ESB與EAI區(qū)別：

ESB是將所有的系統(tǒng)的交互都放在SOA統(tǒng)一服務(wù)總線上面來控制處理。

EAI只是將不同的系統(tǒng)集成起來（可以采用ESB總線形式，也可以采用點對點的形式）。

ESB能幫助解決什么？

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

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

什么是BPM：

BPM，即業(yè)務(wù)過程管理，是一種以規(guī)范化的構(gòu)造端到端的卓越業(yè)務(wù)流程為中心，以持續(xù)的提高組織業(yè)務(wù) 績效 為目的的系統(tǒng)化方法，常見商業(yè)管理教育如 EMBA 、MBA等均將BPM包含在內(nèi)。

用來審批，用來發(fā)送短信，發(fā)送郵件等業(yè)務(wù)流程編排。

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

Activiti Demo：

國內(nèi)bpm在線試用：

‘

到此，關(guān)于“REST、SOA、SOAP、RPC、ICE、ESB、BPM概念是什么”的學(xué)習(xí)就結(jié)束了，希望能夠解決大家的疑惑。理論與實踐的搭配能更好的幫助大家學(xué)習(xí)，快去試試吧！若想繼續(xù)學(xué)習(xí)更多相關(guān)知識，請繼續(xù)關(guān)注創(chuàng)新互聯(lián)網(wǎng)站，小編會繼續(xù)努力為大家?guī)砀鄬嵱玫奈恼拢?/p>
分享名稱：REST、SOA、SOAP、RPC、ICE、ESB、BPM概念是什么
路徑分享：http://weahome.cn/article/pedoss.html