幾種經常使用遠程通訊技術（RPC，Webservice，RMI，JMS）的區別

原文連接：http://blog.csdn.net/shan9liang/article/details/8995023

RPC（Remote Procedure Call Protocol）

RPC使用C/S方式，採用http協議,發送請求到服務器，等待服務器返回結果。這個請求包括一個參數集和一個文本集，一般造成「classname.methodname」形式。優勢是跨語言跨平臺，C端、S端有更大的獨立性，缺點是不支持對象，沒法在編譯器檢查錯誤，只能在運行期檢查。

 

Web Service

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

 

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

服務器進行Request 和Response 當一個數據（XML格式的）被封裝成SOAP格式的數據流發送到服務器端的時候，就會生成一個進程對象而且把接收到這個Request的SOAP包進行解析，而後對事物進行處理，處理結束之後再對這個計算結果進行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語言，客戶機與服務器緊耦合。

 

JMS（Java Messaging Service）

JMS是Java的消息服務，JMS的客戶端之間能夠經過JMS服務進行異步的消息傳輸。JMS支持兩種消息模型：Point-to-Point（P2P）和Publish/Subscribe（Pub/Sub），即點對點和發佈訂閱模型。

 

幾者的區別與聯繫

 

一、RPC與RMI

 

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

（2）RMI 調用遠程對象方法，容許方法返回 Java 對象以及基本數據類型，而RPC 不支持對象的概念，傳送到 RPC 服務的消息由外部數據表示 (External Data Representation, XDR) 語言表示，這種語言抽象了字節序類和數據類型結構之間的差別。只有由 XDR 定義的數據類型才能被傳遞， 能夠說 RMI 是面向對象方式的 Java RPC 。

（3）在方法調用上，RMI中，遠程接口使每一個遠程方法都具備方法簽名。若是一個方法在服務器上執行，可是沒有相匹配的簽名被添加到這個遠程接口上，那麼這個新方法就不能被RMI客戶方所調用。

在RPC中，當一個請求到達RPC服務器時，這個請求就包含了一個參數集和一個文本值，一般造成「classname.methodname」的形式。這就向RPC服務器代表，被請求的方法在爲 「classname」的類中，名叫「methodname」。而後RPC服務器就去搜索與之相匹配的類和方法，並把它做爲那種方法參數類型的輸入。這裏的參數類型是與RPC請求中的類型是匹配的。一旦匹配成功，這個方法就被調用了，其結果被編碼後返回客戶方。

  

二、JMS和RMI

 

採用JMS 服務，對象是在物理上被異步從網絡的某個JVM 上直接移動到另外一個JVM 上（是消息通知機制）

而RMI 對象是綁定在本地JVM 中，只有函數參數和返回值是經過網絡傳送的（是請求應答機制）。

 

RMI通常都是同步的，也就是說，當client調用Server的一個方法的時候，須要等到對方的返回，才能繼續執行client端，這個過程調用本地方法感受上是同樣的，這也是RMI的一個特色。

JMS 通常只是一個點發出一個Message到Message Server,發出以後通常不會關心誰用了這個message。

因此，通常RMI的應用是緊耦合，JMS的應用相對來講是鬆散耦合應用。

 

三、Webservice與RMI

 

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

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

 

四、Webservice與JMS

 

Webservice專一於遠程服務調用，jms專一於信息交換。

 

大多數狀況下Webservice是兩系統間的直接交互（Consumer <--> Producer），而大多數狀況下jms是三方系統交互（Consumer <- Broker -> Producer）。固然，JMS也能夠實現request-response模式的通訊，只要Consumer或Producer其中一方兼任broker便可。

 

JMS能夠作到異步調用徹底隔離了客戶端和服務提供者，可以抵禦流量洪峯； WebService服務一般爲同步調用，須要有複雜的對象轉換，相比SOAP，如今JSON，rest都是很好的http架構方案；（舉一個例子，電子商務的分佈式系統中，有支付系統和業務系統，支付系統負責用戶付款，在用戶在銀行付款後須要通知各個業務系統，那麼這個時候，既能夠用同步也能夠用異步，使用異步的好處就能抵禦網站暫時的流量高峯，或者能應對慢消費者。）

 

JMS是java平臺上的消息規範。通常jms消息不是一個xml，而是一個java對象，很明顯，jms沒考慮異構系統，說白了，JMS就沒考慮非java的東西。可是好在如今大多數的jms provider（就是JMS的各類實現產品）都解決了異構問題。相比WebService的跨平臺各有千秋吧。

---

小龍評論

---

關於RPC，有不少實現都是將對象轉換成通用的JSON對象，變通的地支持面向對象

關於Web Service，對於業務邏輯的事務處理不是特別清楚，更多地用於數據查詢 關於JMS，有不少MQ框架也都是基於JMS標準實現的，ActiveMQ貌似就很強大，有空必定要好好研究下！