遠程調用的幾種方式

 

JAVA遠程調用的幾種實現方式簡析

2010-04-24 2:54

在分佈式服務框架中，一個最基礎的問題就是遠程服務是怎麼通訊的，在Java領域中有很多可實現遠程通訊的技術，例如：RMI、MINA、ESB、 Burlap、Hessian、SOAP、EJB和JMS 等，這些名詞之間到底是些什麼關係呢，它們背後到底是基於什麼原理實現的呢，瞭解這些是實現分佈式服務框架的基礎知識，而如果在性能上有高的要求的話，那 深入瞭解這些技術背後的機制就是必須的了，在這篇blog中我們將來一探究竟，拋磚引玉，歡迎大家提供更多的實現遠程通訊的技術和原理的介紹。

基本原理

要實現網絡機器間的通訊，首先得來看看計算機系統網絡通信的基本原理，在底層層面去看，網絡通信需要做的就是將流從一臺計算機傳輸到另外一臺計算 機，基於傳輸協議和網絡IO來實現，其中傳輸協議比較出名的有 http、tcp、udp等等，http、tcp、udp都是在基於Socket概念上爲某類應用場景而擴展出的傳輸協議，網絡IO，主要有bio、 nio、aio三種方式，所有的分佈式應用通訊都基於這個原理而實現，只是爲了應用的易用，各種語言通常都會提供一些更爲貼近應用易用的應用層協議。

應用級協議

遠程服務通訊，需要達到的目標是在一臺計算機發起請求，另外一臺機器在接收到請求後進行相應的處理並將結果返回給請求端，這其中又會有諸如one way request、同步請求、異步請求等等請求方式，按照網絡通信原理，需要實現這個需要做的就是將請求轉換成流，通過傳輸協議傳輸至遠端，遠端計算機在接 收到請求的流後進行處理，處理完畢後將結果轉化爲流，並通過傳輸協議返回給調用端。
原理是這樣的，但爲了應用的方便，業界推出了很多基於此原理之上的應用級的協議，使得大家可以不用去直接操作這麼底層的東西，通常應用級的遠程通信協議會 提供：

1. 爲了避免直接做流操作這麼麻煩，提供一種更加易用或貼合語言的標準傳輸格式；
2. 網絡通信機制的實現，就是替你完成了將傳輸格式轉化爲流，通過某種傳輸協議傳輸至遠端計算機，遠端計算機在接收到流後轉化爲傳輸格式，並進行存儲或以某種 方式通知遠端計算機。

所以在學習應用級的遠程通信協議時，我們可以帶着這幾個問題進行學習：

1. 傳輸的標準格式是什麼？
2. 怎麼樣將請求轉化爲傳輸的流？
3. 怎麼接收和處理流？
4. 傳輸協議是？

不過應用級的遠程通信協議並不會在傳輸協議上做什麼多大的改進，主要是在流操作方面，讓應用層生成流和處理流的這個過程更加的貼合所使用的語言或標 準，至於傳輸協議則通常都是可選的，在java領域中知名的有：RMI、XML-RPC、Binary-RPC、SOAP、CORBA、JMS，來具體的 看看這些遠程通信的應用級協議：

RMI

RMI是個典型的爲java定製的遠程通信協議，我們都知道，在single vm中，我們可以通過直接調用java object instance來實現通信，那麼在遠程通信時，如果也能按照這種方式當然是最好了，這種遠程通信的機制成爲RPC（Remote Procedure Call），RMI正是朝着這個目標而誕生的。

來看下基於RMI的一次完整的遠程通信過程的原理：

1. 客戶端發起請求，請求轉交至RMI客戶端的stub類；
2. stub類將請求的接口、方法、參數等信息進行序列化；
3. 基於socket將序列化後的流傳輸至服務器端；
4. 服務器端接收到流後轉發至相應的skelton類；
5. skelton類將請求的信息反序列化後調用實際的處理類；
6. 處理類處理完畢後將結果返回給skelton類；
7. Skelton類將結果序列化，通過socket將流傳送給客戶端的stub；
8. stub在接收到流後反序列化，將反序列化後的Java Object返回給調用者。

根據原理來回答下之前學習應用級協議帶着的幾個問題：

1. 傳輸的標準格式是什麼？
是Java ObjectStream。
2. 怎麼樣將請求轉化爲傳輸的流？
基於Java串行化機制將請求的java object信息轉化爲流。
3. 怎麼接收和處理流？
根據採用的協議啓動相應的監聽端口，當有流進入後基於Java串行化機制將流進行反序列化，並根據RMI協議獲取到相應的處理對象信息，進行調用並處理， 處理完畢後的結果同樣基於java串行化機制進行返回。
4. 傳輸協議是？
Socket。

XML-RPC

XML-RPC也是一種和RMI類似的遠程調用的協議，它和RMI的不同之處在於它以標準的xml格式來定義請求的信息(請求的對象、方法、參數 等)，這樣的好處是什麼呢，就是在跨語言通訊的時候也可以使用。

來看下XML-RPC協議的一次遠程通信過程：

1. 客戶端發起請求，按照XML-RPC協議將請求信息進行填充；
2. 填充完畢後將xml轉化爲流，通過傳輸協議進行傳輸；
3. 接收到在接收到流後轉換爲xml，按照XML-RPC協議獲取請求的信息並進行處理；
4. 處理完畢後將結果按照XML-RPC協議寫入xml中並返回。

同樣來回答問題：

1. 傳輸的標準格式是？
標準格式的XML。
2. 怎麼樣將請求轉化爲傳輸的流？
將XML轉化爲流。
3. 怎麼接收和處理流？
通過監聽的端口獲取到請求的流，轉化爲XML，並根據協議獲取請求的信息，進行處理並將結果寫入XML中返回。
4. 傳輸協議是？
Http。

Binary-RPC

Binary-RPC看名字就知道和XML-RPC是差不多的了，不同之處僅在於傳輸的標準格式由XML轉爲了二進制的格式。

同樣來回答問題：

1. 傳輸的標準格式是？
標準格式的二進制文件。
2. 怎麼樣將請求轉化爲傳輸的流？
將二進制格式文件轉化爲流。
3. 怎麼接收和處理流？
通過監聽的端口獲取到請求的流，轉化爲二進制文件，根據協議獲取請求的信息，進行處理並將結果寫入XML中返回。
4. 傳輸協議是？
Http。

SOAP

SOAP原意爲Simple Object Access Protocol，是一個用於分佈式環境的、輕量級的、基於XML進行信息交換的通信協議，可以認爲SOAP是XML RPC的高級版，兩者的原理完全相同，都是http+XML，不同的僅在於兩者定義的XML規範不同，SOAP也是Webservice採用的服務調用協 議標準，因此在此就不多加闡述了。

CORBA

Common Object Request Broker Architecture（公用對象請求代理[調度]程序體系結構），是一組用來定義“分佈式對象系統”的標準，由OMG(Object Menagement Group)作爲發起和標準制定單位。CORBA的目的是定義一套協議，符合這個協議的對象可以互相交互，不論它們是用什麼樣的語言寫的，不論它們運行於 什麼樣的機器和操作系統。
CORBA在我看來是個類似於SOA的體系架構，涵蓋可選的遠程通信協議，但其本身不能列入通信協議這裏來講，而且CORBA基本淘汰，再加上對 CORBA也不怎麼懂，在此就不進行闡述了。

JMS

JMS呢，是實現java領域遠程通信的一種手段和方法，基於JMS實現遠程通信時和RPC是不同的，雖然可以做到RPC的效果，但因爲不是從協議 級別定義的，因此我們不認爲JMS是個RPC協議，但它確實是個遠程通信協議，在其他的語言體系中也存在着類似JMS的東西，可以統一的將這類機制稱爲消 息機制，而消息機制呢，通常是高併發、分佈式領域推薦的一種通信機制，這裏的主要一個問題是容錯（詳細見ErLang論文）。

來看JMS中的一次遠程通信的過程：

1. 客戶端將請求轉化爲符合JMS規定的Message；
2. 通過JMS API將Message放入JMS Queue或Topic中；
3. 如爲JMS Queue，則發送中相應的目標Queue中，如爲Topic，則發送給訂閱了此Topic的JMS Queue。
4. 處理端則通過輪訓JMS Queue，來獲取消息，接收到消息後根據JMS協議來解析Message並處理。

回答問題：

1. 傳輸的標準格式是？
JMS規定的Message。
2. 怎麼樣將請求轉化爲傳輸的流？
將參數信息放入Message中即可。
3. 怎麼接收和處理流？
輪訓JMS Queue來接收Message，接收到後進行處理，處理完畢後仍然是以Message的方式放入Queue中發送或Multicast。
4. 傳輸協議是？
不限。

基於JMS也是常用的實現遠程異步調用的方法之一。