RPC、Webservice、RMI、JMS有什么區(qū)別

這篇文章主要介紹RPC、Webservice、RMI、JMS有什么區(qū)別，文中介紹的非常詳細，具有一定的參考價值，感興趣的小伙伴們一定要看完！

RPC（Remote Procedure Call Protocol）

RPC使用C/S方式，采用http協(xié)議,發(fā)送請求到服務(wù)器，等待服務(wù)器返回結(jié)果。這個請求包括一個參數(shù)集和一個文本集，通常形成“classname.methodname”形式。優(yōu)點是跨語言跨平臺，C端、S端有更大的獨立性，缺點是不支持對象，無法在編譯器檢查錯誤，只能在運行期檢查。

Web Service

Web Service提供的服務(wù)是基于web容器的，底層使用http協(xié)議，類似一個遠程的服務(wù)提供者，比如天氣預(yù)報服務(wù)，對各地客戶端提供天氣預(yù)報，是一種請求應(yīng)答的機制，是跨系統(tǒng)跨平臺的。就是通過一個servlet，提供服務(wù)出去。

首先客戶端從服務(wù)器的到WebService的WSDL，同時在客戶端聲稱一個代理類(Proxy Class) 這個代理類負責(zé)與WebService

服務(wù)器進行Request 和Response 當一個數(shù)據(jù)（XML格式的）被封裝成SOAP格式的數(shù)據(jù)流發(fā)送到服務(wù)器端的時候，就會生成一個進程對象并且把接收到這個Request的SOAP包進行解析，然后對事物進行處理，處理結(jié)束以后再對這個計算結(jié)果進行SOAP

包裝，然后把這個包作為一個Response發(fā)送給客戶端的代理類(Proxy Class)，同樣地，這個代理類也對這個SOAP包進行解析處理，繼而進行后續(xù)操作。這就是WebService的一個運行過程。

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

 1. Http傳輸信道

 2. XML的數(shù)據(jù)格式

 3. SOAP封裝格式

 4. WSDL的描述方式

 5. UDDI  UDDI是一種目錄服務(wù)，企業(yè)可以使用它對Webservices進行注冊和搜索

RMI （Remote Method Invocation）

RMI 采用stubs 和 skeletons 來進行遠程對象(remote object)的通訊。stub 充當遠程對象的客戶端代理，有著和遠程對象相同的遠程接口，遠程對象的調(diào)用實際是通過調(diào)用該對象的客戶端代理對象stub來完成的，通過該機制RMI就好比它是本地工作，采用tcp/ip協(xié)議，客戶端直接調(diào)用服務(wù)端上的一些方法。優(yōu)點是強類型，編譯期可檢查錯誤，缺點是只能基于JAVA語言，客戶機與服務(wù)器緊耦合。

JMS（Java Messaging Service）

JMS是Java的消息服務(wù)，JMS的客戶端之間可以通過JMS服務(wù)進行異步的消息傳輸。JMS支持兩種消息模型：Point-to-Point（P2P）和Publish/Subscribe（Pub/Sub），即點對點和發(fā)布訂閱模型。

幾者的區(qū)別與聯(lián)系

1、RPC與RMI

（1）RPC 跨語言，而 RMI只支持Java。

（2）RMI 調(diào)用遠程對象方法，允許方法返回 Java 對象以及基本數(shù)據(jù)類型，而RPC 不支持對象的概念，傳送到 RPC 服務(wù)的消息由外部數(shù)據(jù)表示 (External Data Representation, XDR) 語言表示，這種語言抽象了字節(jié)序類和數(shù)據(jù)類型結(jié)構(gòu)之間的差異。只有由 XDR 定義的數(shù)據(jù)類型才能被傳遞， 可以說 RMI 是面向?qū)ο蠓绞降?Java RPC 。

（3）在方法調(diào)用上，RMI中，遠程接口使每個遠程方法都具有方法簽名。如果一個方法在服務(wù)器上執(zhí)行，但是沒有相匹配的簽名被添加到這個遠程接口上，那么這個新方法就不能被RMI客戶方所調(diào)用。

在RPC中，當一個請求到達RPC服務(wù)器時，這個請求就包含了一個參數(shù)集和一個文本值，通常形成“classname.methodname”的形式。這就向RPC服務(wù)器表明，被請求的方法在為 “classname”的類中，名叫“methodname”。然后RPC服務(wù)器就去搜索與之相匹配的類和方法，并把它作為那種方法參數(shù)類型的輸入。這里的參數(shù)類型是與RPC請求中的類型是匹配的。一旦匹配成功，這個方法就被調(diào)用了，其結(jié)果被編碼后返回客戶方。

2、JMS和RMI

采用JMS 服務(wù)，對象是在物理上被異步從網(wǎng)絡(luò)的某個JVM 上直接移動到另一個JVM 上（是消息通知機制）

而RMI 對象是綁定在本地JVM 中，只有函數(shù)參數(shù)和返回值是通過網(wǎng)絡(luò)傳送的（是請求應(yīng)答機制）。

RMI一般都是同步的，也就是說，當client調(diào)用Server的一個方法的時候，需要等到對方的返回，才能繼續(xù)執(zhí)行client端，這個過程調(diào)用本地方法感覺上是一樣的，這也是RMI的一個特點。

JMS 一般只是一個點發(fā)出一個Message到Message Server,發(fā)出之后一般不會關(guān)心誰用了這個message。

所以，一般RMI的應(yīng)用是緊耦合，JMS的應(yīng)用相對來說是松散耦合應(yīng)用。

3、Webservice與RMI

RMI是在tcp協(xié)議上傳遞可序列化的java對象，只能用在java虛擬機上，綁定語言，客戶端和服務(wù)端都必須是java

webservice沒有這個限制，webservice是在http協(xié)議上傳遞xml文本文件，與語言和平臺無關(guān)

4、Webservice與JMS

Webservice專注于遠程服務(wù)調(diào)用，jms專注于信息交換。

大多數(shù)情況下Webservice是兩系統(tǒng)間的直接交互（Consumer <--> Producer），而大多數(shù)情況下jms是三方系統(tǒng)交互（Consumer <- Broker -> Producer）。當然，JMS也可以實現(xiàn)request-response模式的通信，只要Consumer或Producer其中一方兼任broker即可。

JMS可以做到異步調(diào)用完全隔離了客戶端和服務(wù)提供者，能夠抵御流量洪峰； WebService服務(wù)通常為同步調(diào)用，需要有復(fù)雜的對象轉(zhuǎn)換，相比SOAP，現(xiàn)在JSON，rest都是很好的http架構(gòu)方案；（舉一個例子，電子商務(wù)的分布式系統(tǒng)中，有支付系統(tǒng)和業(yè)務(wù)系統(tǒng)，支付系統(tǒng)負責(zé)用戶付款，在用戶在銀行付款后需要通知各個業(yè)務(wù)系統(tǒng)，那么這個時候，既可以用同步也可以用異步，使用異步的好處就能抵御網(wǎng)站暫時的流量高峰，或者能應(yīng)對慢消費者。）

JMS是java平臺上的消息規(guī)范。一般jms消息不是一個xml，而是一個java對象，很明顯，jms沒考慮異構(gòu)系統(tǒng)，說白了，JMS就沒考慮非java的東西。但是好在現(xiàn)在大多數(shù)的jms provider（就是JMS的各種實現(xiàn)產(chǎn)品）都解決了異構(gòu)問題。相比WebService的跨平臺各有千秋吧。

以上是“RPC、Webservice、RMI、JMS有什么區(qū)別”這篇文章的所有內(nèi)容，感謝各位的閱讀！希望分享的內(nèi)容對大家有幫助，更多相關(guān)知識，歡迎關(guān)注億速云行業(yè)資訊頻道！