JAVA 遠程通信機制

在分佈式服務框架中，一個最基礎的問題就是遠程服務是怎麼通信的，在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、同步請求、異步請求等等請求方式，按照網絡通訊原理，須要實現這個須要作的就是將請求轉換成流，經過傳輸協議傳輸至遠端，遠端計算機在接收到請求的流後進行處理，處理完畢後將結果轉化爲流，並經過傳輸協議返回給調用端。 
原理是這樣的，但爲了應用的方便，業界推出了不少基於此原理之上的應用級的協議，使得你們能夠不用去直接操做這麼底層的東西，一般應用級的遠程通訊協議會提供： 
一、爲了不直接作流操做這麼麻煩，提供一種更加易用或貼合語言的標準傳輸格式； 
二、網絡通訊機制的實現，就是替你完成了將傳輸格式轉化爲流，經過某種傳輸協議傳輸至遠端計算機，遠端計算機在接收到流後轉化爲傳輸格式，並進行存儲或以某種方式通知遠端計算機。 
因此在學習應用級的遠程通訊協議時，咱們能夠帶着這幾個問題進行學習： 
一、傳輸的標準格式是什麼？ 
二、怎麼樣將請求轉化爲傳輸的流？ 
三、怎麼接收和處理流？ 
四、傳輸協議是？ 
不過應用級的遠程通訊協議並不會在傳輸協議上作什麼多大的改進，主要是在流操做方面，讓應用層生成流和處理流的這個過程更加的貼合所使用的語言或標準，至於傳輸協議則一般都是可選的，在java領域中知名的有：RMI、XML-RPC、Binary-RPC、SOAP、CORBA、JMS，來具體的看看這些遠程通訊的應用級協議： 
-------------------------------------------------------------------------------------------------------------------------------------------------- 
RMI 
RMI是個典型的爲java定製的遠程通訊協議，咱們都知道，在single vm中，咱們能夠經過直接調用java object instance來實現通訊，那麼在遠程通訊時，若是也能按照這種方式固然是最好了，這種遠程通訊的機制成爲RPC（Remote Procedure Call），RMI正是朝着這個目標而誕生的。 
來看下基於RMI的一次完整的遠程通訊過程的原理： 
一、客戶端發起請求，請求轉交至RMI客戶端的stub類； 
二、stub類將請求的接口、方法、參數等信息進行序列化； 
三、基於socket將序列化後的流傳輸至服務器端； 
四、服務器端接收到流後轉發至相應的skelton類； 
五、skelton類將請求的信息反序列化後調用實際的處理類； 
六、處理類處理完畢後將結果返回給skelton類； 
七、Skelton類將結果序列化，經過socket將流傳送給客戶端的stub； 
八、stub在接收到流後反序列化，將反序列化後的Java Object返回給調用者。 
來看jboss-remoting對於此過程的一個更好的圖示： 

根據原理來回答下以前學習應用級協議帶着的幾個問題： 
一、傳輸的標準格式是什麼？ 
是Java ObjectStream。 
二、怎麼樣將請求轉化爲傳輸的流？ 
基於Java串行化機制將請求的java object信息轉化爲流。 
三、怎麼接收和處理流？ 
根據採用的協議啓動相應的監聽端口，當有流進入後基於Java串行化機制將流進行反序列化，並根據RMI協議獲取到相應的處理對象信息，進行調用並處理，處理完畢後的結果一樣基於java串行化機制進行返回。 
四、傳輸協議是？ 
Socket。 
-------------------------------------------------------------------------------------------------------------------------------------------------- 
XML-RPC 
XML-RPC也是一種和RMI相似的遠程調用的協議，它和RMI的不一樣之處在於它以標準的xml格式來定義請求的信息(請求的對象、方法、參數等)，這樣的好處是什麼呢，就是在跨語言通信的時候也可使用。 
來看下XML-RPC協議的一次遠程通訊過程： 
一、客戶端發起請求，按照XML-RPC協議將請求信息進行填充； 
二、填充完畢後將xml轉化爲流，經過傳輸協議進行傳輸； 
三、接收到在接收到流後轉換爲xml，按照XML-RPC協議獲取請求的信息並進行處理； 
四、處理完畢後將結果按照XML-RPC協議寫入xml中並返回。 
圖示以上過程： 

一樣來回答問題： 
一、傳輸的標準格式是？ 
標準格式的XML。 
二、怎麼樣將請求轉化爲傳輸的流？ 
將XML轉化爲流。 
三、怎麼接收和處理流？ 
經過監聽的端口獲取到請求的流，轉化爲XML，並根據協議獲取請求的信息，進行處理並將結果寫入XML中返回。
四、傳輸協議是？ 
Http。 
-------------------------------------------------------------------------------------------------------------------------------------------------- 
Binary-RPC 
Binary-RPC看名字就知道和XML-RPC是差很少的了，不一樣之處僅在於傳輸的標準格式由XML轉爲了二進制的格式。 
一樣來回答問題： 
一、傳輸的標準格式是？ 
標準格式的二進制文件。 
二、怎麼樣將請求轉化爲傳輸的流？ 
將二進制格式文件轉化爲流。 
三、怎麼接收和處理流？ 
經過監聽的端口獲取到請求的流，轉化爲二進制文件，根據協議獲取請求的信息，進行處理並將結果寫入XML中返回。 
四、傳輸協議是？ 
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中的一次遠程通訊的過程： 
一、客戶端將請求轉化爲符合JMS規定的Message； 
二、經過JMS API將Message放入JMS Queue或Topic中； 
三、如爲JMS Queue，則發送中相應的目標Queue中，如爲Topic，則發送給訂閱了此Topic的JMS Queue。 
四、處理端則經過輪訓JMS Queue，來獲取消息，接收到消息後根據JMS協議來解析Message並處理。 
回答問題： 
一、傳輸的標準格式是？ 
JMS規定的Message。 
二、怎麼樣將請求轉化爲傳輸的流？ 
將參數信息放入Message中便可。 
三、怎麼接收和處理流？ 
輪訓JMS Queue來接收Message，接收到後進行處理，處理完畢後仍然是以Message的方式放入Queue中發送或Multicast。 
四、傳輸協議是？ 
不限。 
基於JMS也是經常使用的實現遠程異步調用的方法之一。