Java遠程通訊可選技術及原理

時間：2024-09-14 05:09:59 JAVA認證

Java遠程通訊可選技術及原理

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

　　基本原理

　　要實現網絡機器間的通訊，首先得來看看計算機系統網絡通信的基本原理，在底層層面去看，網絡通信需要做的就是將流從一臺計算機傳輸到另外一臺計算機，基于傳輸協議和網絡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。