多數(shù)網(wǎng)絡(luò)編程庫中（以JAVA為主來說明），在JAVA平臺中一樣的提供了這些元素。而作為面向連接協(xié)議來說使用的是套接字（Socket）進行了更進一步的抽象描述。一般我們在JAVA的網(wǎng)絡(luò)編程中都覺得在使用套接字這塊相對方便，它不需要你去更多的了解操作系統(tǒng)的細(xì)節(jié)以及硬件的傳遞處理方式。TCP/IP的所有細(xì)節(jié)之處都得到了套接字的封裝使用，讓程序員關(guān)注到業(yè)務(wù)層面的處理。

       對象是一種抽象思維物質(zhì)，對于計算機來說它只對數(shù)字電路的存儲方式能夠加以識別而且在網(wǎng)絡(luò)傳輸當(dāng)中也是一種信號量，而這一切只有使用字節(jié)流方式傳輸才是真正需要做到的。所以在本地主機與遠(yuǎn)程服務(wù)器的通訊傳輸就在對象與字節(jié)流之間不斷相互轉(zhuǎn)化才是我們真正需要的人性物質(zhì)與機器所需要的。（有點墨跡了，切入整體）總體來說就是需要兩種方式來認(rèn)定這種傳輸行為：編組（Marshalling）與反編組（Unmarshalling）。而這一切的手段方式才是通過：序列化（Serialiazable）與反序列化的方式不斷完成。如下圖所示：

圖：對象到字節(jié)再到對象的轉(zhuǎn)換

       對于數(shù)據(jù)的傳輸本質(zhì)就是上圖說明的。那我們一般是如何使用套接字來構(gòu)造我們這一行為呢？對于這里強調(diào)的主要是一種大致方法說明，所以只能以部分代碼來說明客戶端怎么來發(fā)送這個請求。

而作為服務(wù)器的接收方則把以上數(shù)據(jù)做一個逆轉(zhuǎn)相反處理就可以。即服務(wù)器需要讀取發(fā)送過來的對象數(shù)據(jù)，最終得到結(jié)果?，F(xiàn)在假設(shè)還是一個甚至更多這樣的對象處理，我們又要處理和以上代碼差不多的過程。好，到這里我們可曾想到難道沒有一種辦法把這些過多的重復(fù)過程做一個通用的方式來提供嗎？我如果不想去做這些繁雜的對象處理可以嗎？比如，我想直接得到：

這樣就能讓我們把底層的那些龐雜數(shù)據(jù)轉(zhuǎn)換能夠透明封裝起來呢？既然這個問題一經(jīng)提出，那就意味著肯定有很多類似的需求。技術(shù)永遠(yuǎn)都是在需求的提出應(yīng)運而生的。上面提出的需求就是我們要討論的，既然我們想把一些套接字的重復(fù)處理過程來個封裝清理，那需要面對的問題是什么呢？

1.      能夠把所有的相同處理過程全部都移入到服務(wù)端呢？

2.      對于客戶端來說能否只預(yù)留接口行為呢？

3.      把過多的復(fù)雜處理過程完善的做個封裝？

4.      如果以上過程能夠形成，那客戶端又是如何辦到可以連接到服務(wù)器端的組件行為呢？

既然能夠把遇到的問題提出然后總結(jié)出來也就意味著我們需要去解決它。不知道是否還

記得設(shè)計模式中有一個叫：代理模式？沒錯，就是這個代理模式開始我們的描述。代理是一個實現(xiàn)給定接口的對象，但是不直接去執(zhí)行代碼結(jié)果，而是代表其他一些對象執(zhí)行實際計算的對象。怎么理解這個話呢？舉例說，如今很多城市都有火車票或者飛機票的代售點，這里的代售點其實就是采用了一種代理機制。我們想買某天的火車或者飛機票有時候并不需要到火車站或者飛機票的總點去購買票，而是找一個你最近的代售點去購買。代售點就是起到一個中間橋梁的作用，至于買票人員無需關(guān)心他們?nèi)绾稳ビ嗁?，這些具體的動作都由他們內(nèi)部去處理，你只關(guān)心最終是否有你需要的票就行。知道這個原理接下來就好理解很多了，我們最好以類圖的方式來說明這個代理的機制，如圖所示：

    到這里如果還覺得抽象，沒關(guān)系接下來我以更加貼切的實例來結(jié)合類圖的方式給出對應(yīng)的參照說明。假如我們把上面的proxy模式再做個深入的探討剖析（結(jié)合上面說的客戶端發(fā)送參數(shù)作為請求和提出的問題綜述）。大家都知道一個接口是能夠在安全甚至在擴展上能夠幫助我們非常大的功能。作為客戶端最為希望的就是只關(guān)心我們需要的參數(shù)（或者變量）、返回值，而它如何而來，做了哪些具體工作這些都不是客戶端關(guān)心的。Ok,現(xiàn)在結(jié)合我們說的接口方式，確實可以解決這個問題（接口的簡單化，沒有具體實現(xiàn)），但是你可能會問：

1.      既然接口如此簡單，那參數(shù)又是如何傳遞過去的呢？

2.      服務(wù)端又如何知道我要的是什么呢？

帶著問題我們來解決這個問題，當(dāng)然也是大家所關(guān)心的問題了?，F(xiàn)在開始要對于上面的proxy模式做個深入剖析了。我們先來看一個proxy模式演變的過程的圖示：

圖：RMI核心結(jié)構(gòu)

    我們可以從圖示看出從傳統(tǒng)的proxy模式變化到一個變化的結(jié)構(gòu)有什么不同呢？對于先前我們提出的兩個問題就可以很好的做出解釋了：

n         既然接口如此簡單，那參數(shù)又是如何傳遞過去的呢？

A:既然是對客戶端只開接口暴露，那么我們是就需要一個后臺的socket來傳輸接口中已經(jīng)定義好的參數(shù)，通過參數(shù)的編組（序列化）方式請求到遠(yuǎn)程服務(wù)上去響應(yīng)處理。這當(dāng)中要求定義到對方服務(wù)的服務(wù)名稱和端口號。（這里也就是我們最先提到的那段代碼了）

n         服務(wù)端又如何知道我要的是什么呢？

A:ok,既然客戶端是通過socket來發(fā)送數(shù)據(jù)，那勢必一定需要ServerSocket來做這個響應(yīng)的接收處理了。問題是傳過來的參數(shù)如何與我們的業(yè)務(wù)實現(xiàn)類關(guān)聯(lián)上呢？所以這個也就是skeleton的職責(zé)所在了，在skeleton的封裝處理中（啟動中就把響應(yīng)實現(xiàn)類給嵌入，聚合實現(xiàn)類），然后通過類轉(zhuǎn)換處理和匹配處理來得到需要響應(yīng)的結(jié)果了。

    本來說到這想大概有個收尾，但是總覺得還沒有把一些問題說透徹。索性想再深入寫寫。
    從套接字衍生到RMI代碼思路