談談自己對REST、SOA、SOAP、RPC、ICE、ESB、BPM知識彙總及理解
SOA:
維基百科解釋:SOA:面向服務的軟件架構(Service Oriented Architecture),是一種計算機軟件的設計模式,主要應用於不通應用組件中通過某種協議來互操作,例如典型的通過網絡協議。因此SOA是獨立於任何廠商、產品與技術的。
SOA作爲一種架構依賴於服務的方向,它的基本設計原理是:服務提供了一個簡單的接口,抽象了底層的複雜性,然後用戶可以訪問獨立的服務,而不需要去了解服務底層平臺實現。
基於SOA的解決方案,努力使經營目標而建立企業的質量體系。SOA架構是五層水平:
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了。
目前知道的三種主流的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風格的接口,其實都是在學其形,不知其心,最後弄得不倫不類,性能上不去,安全又保證不了,徒有一個看似象摸象樣的皮囊。
.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?