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。
4. 傳輸協議是?
不限。
基於JMS也是常用的實現遠端非同步呼叫的方法之一。
