1. 程式人生 > >遠端通訊的幾種選擇(RPC,Webservice,RMI,JMS,SOAP,REST,CORBA的區別)

遠端通訊的幾種選擇(RPC,Webservice,RMI,JMS,SOAP,REST,CORBA的區別)

RPCRemote Procedure Call Protocol遠端過程呼叫

RPC使用C/S方式,採用http協議,傳送請求到伺服器,等待伺服器返回結果。這個請求包括一個引數集和一個文字集,通常形成“classname.methodname”形式。優點是跨語言跨平臺C端、S端有更大的獨立性,缺點是不支援物件,無法在編譯器檢查錯誤,只能在執行期檢查。

Web Service

Web Service提供的服務是基於web容器的,底層使用http協議,類似一個遠端的服務提供者,比如天氣預報服務,對各地客戶端提供天氣預報,是一種請求應答的機制,是跨系統跨平臺的。就是通過一個servlet

,提供服務出去。

首先客戶端從伺服器的到WebServiceWSDL,同時在客戶端聲稱一個代理類(Proxy Class) 這個代理類負責與WebService

伺服器進行RequestResponse當一個數據(XML格式的)被封裝成SOAP格式的資料流傳送到伺服器端的時候,就會生成一個程序物件並且把接收到這個RequestSOAP包進行解析,然後對事物進行處理,處理結束以後再對這個計算結果進行SOAP

包裝,然後把這個包作為一個Response傳送給客戶端的代理類(Proxy Class),同樣地,這個代理類也對這個SOAP包進行解析處理,繼而進行後續操作。這就是WebService

的一個執行過程。

Web Service大體上分為5個層次:

 1. Http傳輸通道

 2. XML的資料格式

 3. SOAP封裝格式

 4. WSDL的描述方式

 5. UDDI  UDDI是一種目錄服務,企業可以使用它對Webservices進行註冊和搜尋

RMI Remote Method Invocation面向物件的遠端方法呼叫)

RMI採用stubs skeletons 來進行遠端物件(remote object)的通訊。stub充當遠端物件的客戶端代理,有著和遠端物件相同的遠端介面,遠端物件的呼叫實際是通過呼叫該物件的客戶端代理物件stub來完成的,通過該機制

RMI就好比它是本地工作,採用tcp/ip協議,客戶端直接呼叫服務端上的一些方法。優點是強型別,編譯期可檢查錯誤,缺點是隻能基於JAVA語言,客戶機與伺服器緊耦合。

JMSJava Messaging Service

JMSJava的訊息服務,JMS的客戶端之間可以通過JMS服務進行非同步的訊息傳輸。JMS支援兩種訊息模型:Point-to-PointP2P)和Publish/SubscribePub/Sub),即點對點和釋出訂閱模型。

SOAP(simple object access protoal,簡單物件訪問協議)REST(representational state transfer,表達性狀態轉移)

CORBA

通用物件請求代理架構,支援任何程式語言編寫的物件之間的方法電泳。corba使用二進位制的IIOP來實現物件間的通訊。​

幾者的區別與聯絡

1RPCRMI

1RPC跨語言,而 RMI只支援Java

2RMI呼叫遠端物件方法,允許方法返回 Java物件以及基本資料型別,而RPC不支援物件的概念,傳送到 RPC服務的訊息由外部資料表示 (External Data Representation, XDR)語言表示,這種語言抽象了位元組序類和資料型別結構之間的差異。只有由 XDR定義的資料型別才能被傳遞, 可以說 RMI是面向物件方式的 Java RPC

3)在方法呼叫上,RMI中,遠端介面使每個遠端方法都具有方法簽名。如果一個方法在伺服器上執行,但是沒有相匹配的簽名被新增到這個遠端介面上,那麼這個新方法就不能被RMI客戶方所呼叫。

RPC中,當一個請求到達RPC伺服器時,這個請求就包含了一個引數集和一個文字值,通常形成“classname.methodname”的形式。這就向RPC伺服器表明,被請求的方法在為“classname”的類中,名叫“methodname”。然後RPC伺服器就去搜索與之相匹配的類和方法,並把它作為那種方法引數型別的輸入。這裡的引數型別是與RPC請求中的型別是匹配的。一旦匹配成功,這個方法就被呼叫了,其結果被編碼後返回客戶方。

2JMSRMI

採用JMS服務,物件是在物理上被非同步從網路的某個JVM上直接移動到另一個JVM上(是訊息通知機制)

RMI物件是繫結在本地JVM中,只有函式引數和返回值是通過網路傳送的(是請求應答機制)。

RMI一般都是同步的,也就是說,當client呼叫Server的一個方法的時候,需要等到對方的返回,才能繼續執行client端,這個過程呼叫本地方法感覺上是一樣的,這也是RMI的一個特點。

JMS 一般只是一個點發出一個MessageMessage Server,發出之後一般不會關心誰用了這個message

所以,一般RMI的應用是緊耦合,JMS的應用相對來說是鬆散耦合應用。

3WebserviceRMI

RMI是在tcp協議上傳遞可序列化的java物件,只能用在java虛擬機器上,繫結語言,客戶端和服務端都必須是java

webservice沒有這個限制,webservice是在http協議上傳遞xml文字檔案,與語言和平臺無關

4WebserviceJMS

Webservice專注於遠端服務呼叫,jms專注於資訊交換。

大多數情況下Webservice是兩系統間的直接互動(Consumer <--> Producer),而大多數情況下jms是三方系統互動(Consumer <- Broker -> Producer)。當然,JMS也可以實現request-response模式的通訊,只要ConsumerProducer其中一方兼任broker即可。

JMS可以做到非同步呼叫完全隔離了客戶端和服務提供者,能夠抵禦流量洪峰;WebService服務通常為同步呼叫,需要有複雜的物件轉換,相比SOAP,現在JSONrest都是很好的http架構方案;(舉一個例子,電子商務的分散式系統中,有支付系統和業務系統,支付系統負責使用者付款,在使用者在銀行付款後需要通知各個業務系統,那麼這個時候,既可以用同步也可以用非同步,使用非同步的好處就能抵禦網站暫時的流量高峰,或者能應對慢消費者。)

JMSjava平臺上的訊息規範。一般jms訊息不是一個xml,而是一個java物件,很明顯,jms沒考慮異構系統,說白了,JMS就沒考慮非java的東西。但是好在現在大多數的jms provider(就是JMS的各種實現產品)都解決了異構問題。相比WebService的跨平臺各有千秋吧。