大家都知道對于互聯網的世界網絡通訊是其本質特征。而對于一個分布式式計算來說更是如此。在它的環境中使用了客戶/
服務器結構特點，使用的一個核心技術就是網絡通訊層。在最早的OSI
的概念基礎上，建立了完善具體協議層。而客戶想要能夠與位于其他物理層主機上的服務器通訊，需要能夠想服務器發送數據，然后以某種方式獲得響應。這當中就牽涉到我們熟悉的協議層面了，在這里就不再復述這些協議概念了。對于網絡通訊來說我們所要了解的是最為常用的就是兩種連接方式：無連接協議（UDP
）、面向連接協議（TCP/IP
）。
多數網絡編程庫中（以JAVA為主來說明），在JAVA平臺中一樣的提供了這些元素。而作為面向連接協議來說使用的是套接字（Socket）進行了更進一步的抽象描述。一般我們在JAVA的網絡編程中都覺得在使用套接字這塊相對方便，它不需要你去更多的了解操作系統的細節以及硬件的傳遞處理方式。TCP/IP的所有細節之處都得到了套接字的封裝使用，讓程序員關注到業務層面的處理。
對象是一種抽象思維物質，對于計算機來說它只對數字電路的存儲方式能夠加以識別而且在網絡傳輸當中也是一種信號量，而這一切只有使用字節流方式傳輸才是真正需要做到的。所以在本地主機與遠程服務器的通訊傳輸就在對象與字節流之間不斷相互轉化才是我們真正需要的人性物質與機器所需要的。（有點墨跡了，切入整體）總體來說就是需要兩種方式來認定這種傳輸行為：編組（Marshalling）與反編組（Unmarshalling）。而這一切的手段方式才是通過：序列化（Serialiazable）與反序列化的方式不斷完成。如下圖所示：
圖：對象到字節再到對象的轉換
對于數據的傳輸本質就是上圖說明的。那我們一般是如何使用套接字來構造我們這一行為呢？對于這里強調的主要是一種大致方法說明，所以只能以部分代碼來說明客戶端怎么來發送這個請求。
Socket socket=new Socket("http://www.wgh.com.cn",8888);
OutputStream out=socket.getOutputStream();
ObjectOutputStream obj=new ObjectOutputStream(out);
obj.writeObject(object);
InputStream in=socket.getInputStream();
ObjectInputStream objIn=new ObjectInputStream(in);
Object objFoo=(Object)objIn.readObject();
//todo 這里就是具體進行操作的相關傳值參數處理了…
obj.close();
objIn.close();
socket.close();
而作為服務器的接收方則把以上數據做一個逆轉相反處理就可以。即服務器需要讀取發送過來的對象數據，最終得到結果。現在假設還是一個甚至更多這樣的對象處理，我們又要處理和以上代碼差不多的過程。好，到這里我們可曾想到難道沒有一種辦法把這些過多的重復過程做一個通用的方式來提供嗎？我如果不想去做這些繁雜的對象處理可以嗎？比如，我想直接得到：
//其中clientObjectji就是從客戶端傳輸過來的副本；
MyObject myObject=server.getFoo(clientObject);
這樣就能讓我們把底層的那些龐雜數據轉換能夠透明封裝起來呢？既然這個問題一經提出，那就意味著肯定有很多類似的需求。技術永遠都是在需求的提出應運而生的。上面提出的需求就是我們要討論的，既然我們想把一些套接字的重復處理過程來個封裝清理，那需要面對的問題是什么呢？
1. 能夠把所有的相同處理過程全部都移入到服務端呢？
2. 對于客戶端來說能否只預留接口行為呢？
3. 把過多的復雜處理過程完善的做個封裝？
4. 如果以上過程能夠形成，那客戶端又是如何辦到可以連接到服務器端的組件行為呢？
既然能夠把遇到的問題提出然后總結出來也就意味著我們需要去解決它。不知道是否還
記得設計模式中有一個叫：代理模式？沒錯，就是這個代理模式開始我們的描述。代理是一個實現給定接口的對象，但是不直接去執行代碼結果，而是代表其他一些對象執行實際計算的對象。怎么理解這個話呢？舉例說，如今很多城市都有火車票或者飛機票的代售點，這里的代售點其實就是采用了一種代理機制。我們想買某天的火車或者飛機票有時候并不需要到火車站或者飛機票的總點去購買票，而是找一個你最近的代售點去購買。代售點就是起到一個中間橋梁的作用，至于買票人員無需關心他們如何去訂購，這些具體的動作都由他們內部去處理，你只關心最終是否有你需要的票就行。知道這個原理接下來就好理解很多了，我們最好以類圖的方式來說明這個代理的機制，如圖所示：
到這里如果還覺得抽象，沒關系接下來我以更加貼切的實例來結合類圖的方式給出對應的參照說明。假如我們把上面的proxy模式再做個深入的探討剖析（結合上面說的客戶端發送參數作為請求和提出的問題綜述）。大家都知道一個接口是能夠在安全甚至在擴展上能夠幫助我們非常大的功能。作為客戶端最為希望的就是只關心我們需要的參數（或者變量）、返回值，而它如何而來，做了哪些具體工作這些都不是客戶端關心的。Ok,現在結合我們說的接口方式，確實可以解決這個問題（接口的簡單化，沒有具體實現），但是你可能會問：
1. 既然接口如此簡單，那參數又是如何傳遞過去的呢？
2. 服務端又如何知道我要的是什么呢？
帶著問題我們來解決這個問題，當然也是大家所關心的問題了。現在開始要對于上面的proxy模式做個深入剖析了。我們先來看一個proxy模式演變的過程的圖示：
圖：RMI核心結構
我們可以從圖示看出從傳統的proxy模式變化到一個變化的結構有什么不同呢？對于先前我們提出的兩個問題就可以很好的做出解釋了：
n 既然接口如此簡單，那參數又是如何傳遞過去的呢？
A:既然是對客戶端只開接口暴露，那么我們是就需要一個后臺的socket來傳輸接口中已經定義好的參數，通過參數的編組（序列化）方式請求到遠程服務上去響應處理。這當中要求定義到對方服務的服務名稱和端口號。（這里也就是我們最先提到的那段代碼了）
n 服務端又如何知道我要的是什么呢？
A:ok,既然客戶端是通過socket來發送數據，那勢必一定需要ServerSocket來做這個響應的接收處理了。問題是傳過來的參數如何與我們的業務實現類關聯上呢？所以這個也就是skeleton的職責所在了，在skeleton的封裝處理中（啟動中就把響應實現類給嵌入，聚合實現類），然后通過類轉換處理和匹配處理來得到需要響應的結果了。
本來說到這想大概有個收尾，但是總覺得還沒有把一些問題說透徹。索性想再深入寫寫。
從套接字衍生到RMI代碼思路
posted on 2009-02-02 11:57
葉澍成 閱讀(3584)
評論(1) 編輯 收藏 所屬分類:
java基礎 、
分布式