【把P2P進行到底：講述Jxta的故事(2)】

在 Jxta 1.0 規範中，一個運行中的服務實例老是和一個對等機聯繫在一塊兒（您能夠把它想象成是由一個對等「服務器」主管的）。在一個對等組內，只能有一個服務實例和指定的對等機聯繫在一塊兒。這種類型的服務被視爲對等服務；若是主管該對等服務的對等機當機了，那麼將沒法得到該服務。另外一方面，同一服務的多個實例被冗餘地安裝在一個對等組內的多個對等機上，這被稱爲對等組服務。對等組服務是 Jxta 網絡的高可用性和容錯性的關鍵。Jxta 應用的實現者能夠自由地把任意 Jxta 服務做爲對等服務或對等組服務進行安裝。管道服務，即爲對等通訊提供邏輯管道抽象的核心 Jxta 服務，經常被做爲對等組服務來實現，以確保其老是可用。
　　
　　管道正如 Jxta 規範定義，在對等機之間傳輸數據、文件、信息、代碼或多媒體內容的一種方式是經過邏輯管道。Jxta 管道用於在對等機之間發送消息（可帶任意內容）。
　　
　　一個管道實例，從邏輯上講，是對等組內的一個資源。管道實例的實際實現一般狀況下是經過管道服務完成的。與傳統（相似 UNIX 的）的系統不一樣，Jxta 管道是單向的、異步的。須要雙向通訊的兩個對等機將不得不建立兩個獨立的管道實例。也跟傳統機制如 UNIX 管道或 TCP/IP 套接字不一樣，Jxta 管道的末端能夠在不一樣的時間鏈接到不一樣的對等機上，或者根本不鏈接。在爲 P2P 網絡上的服務提供冗餘實現方面，只此一個單一律念就是革命性的一步。對等機能夠在任一點及時邏輯地「拾起」管道。例如，設想一個想使用拼寫檢查器服務的對等機。它能夠鏈接到一個對等組的拼寫檢查器管道（該管道是被做爲冗餘對等組服務實現的）上。在這種狀況下，只要至少有一個拼寫檢查器的實例還在該對等組內的某個地方運行，該對等機就還能獲得服務。
　　
　　Jxta 1.0 規範提供了兩種通常類型的管道：點對點和廣播（propagate）。
　　
　　對等機可使用點對點管道鏈接到另外一個對等機並單向傳輸消息。對等機可使用廣播管道鏈接到一個或多個其它對等機並向它們全體傳輸消息。從本質上講，點對點管道是一對一的消息傳輸機制，廣播管道則是一對多的消息傳輸機制。Jxta 社區目前正在多對多消息傳輸機制方面努力；這個機制已經被命名爲 Jxta 導線（wire）。不論是什麼類型的管道，經過管道載送的信息塊都稱爲 Jxta 消息。那麼，這些消息的確切格式是什麼樣子呢？
　　
　　消息 Jxta 消息是經過管道從一個對等機傳送到另外一個對等機的數據束。這裏，Jxta 規範再一次儘量地使本身廣泛適應，以避免不經意間在消息的定義中引入任何依賴於實現的策略。消息被定義爲由信封和正文組成的任意大小的束。信封是標準格式，它包括：
　　
　　報頭
　　源端點信息（URI 格式）
　　目的地端點信息（URI 格式）
　　消息摘要（可選的出於安全性目的）
　　消息正文的長度是任意的，能夠包含一個可選的信任狀（出於安全性目的）和內容。
　　
　　請注意，Jxta 消息的定義很是鬆散。考慮到咱們平常通常都是在可靠的、寬帶的 TCP/IP 網絡上操做，這樣作的必要性並非當即能夠明瞭的。但 Jxta 消息的格式必須是靈活的、善於適應新環境的，由於它可能要在全部種類的網絡上實現，而不僅是在 TCP/IP 上。設想在一個支持 256 字節數據包的不可靠傳輸的網絡（象傳統的基於數據包的無線網絡）上的一個 Jxta 實現，您就會對 Jxta 消息的簡單定義如何使本身適應諸如這樣的不利環境表示讚揚。
　　
　　爲了提供一個標準的、語法上易分析的、通用的編碼機制，Jxta 消息目前採用 XML 文檔格式。Jxta 利用了 XML 的廣泛可訪問性和易使用、易編程的特色，這意味着 Jxta 能夠用大多數編程語言在大多數平臺上很容易地實現。只要 XML 語法分析器和生成庫在那裏是可用的。然而，Jxta 自己的設計卻使其消息代碼的編寫不依賴於 XML 的使用。雖然如今不太可能，但 Jxta 社區在規範的將來版本中包含（或要求）基於非 XML 的消息是徹底可能的。
　　
　　關於 Jxta 標識符從潛力上講，對等組或許能夠跟整個聯繫着的宇宙同樣大。在這麼大的名稱空間中爲任何事物進行惟一的命名都是一個挑戰。爲了應對這個問題，Jxta 給 Jxta 組件的每一個可設定地址的實例都分配了一個內部標識符。這種標識是經過一個 UUID 進行的，UUID 是使用可以確保在時間和空間上都有很高几率的惟一性的算法產生的 64 字節的數字。Jxta 標識符是 URN（統一資源名稱）格式的，並被嵌入到廣告中供內部使用。目前定義了四種標識符類型，用於標識對等組、對等機、管道和代碼／數據（code/data）（簡寫爲 codat）。
　　
　　廣告
　　廣告有點像是消息的「堂兄弟」。Jxta 廣告也採用 XML 文檔格式。廣告的內容描述了諸如對等機、對等組、管道或服務等 Jxta 組件實例的屬性。例如，能夠訪問另外一個對等機的廣告的對等機能夠設法直接連到該對等機上；能夠訪問一個對等組的廣告的對等機能夠經過廣告加入對等組。目前的因特網中與廣告類似的東西是域名和 Web 站點的 DNS 紀錄。Jxta 規範沒有規定如何建立、傳播或銷燬廣告。
　　
　　互操做性的基礎：Jxta 協議互操做性的另外一個關鍵是這樣一個事實：核心 Jxta 對等交互操做模型被徹底表示爲在底層網絡上傳輸的一套簡單協議。換句話說，既然協議和消息格式是定義無缺的，那麼基於 Jxta 的系統間的互操做性徹底能夠在導線一級上達到。
　　
　　例如，一個簡單的 PDA（8 位處理器，基於 C 語言編程）就能夠是一個運行在基於數據包的無線網絡上的 Jxta 對等機，它可與同一對等組內的各類系統，從 PC 服務器到大型機，進行交互。若是這些對等機共享一個公共網絡（傳送）並正使用 Jxta 協議和消息格式進行通訊，這是能夠作到的。
　　
　　Sun 已爲 Jxta 提供了初步的 Java 語言實現。Jxta 社區如今擁有這個參考實現。這個參考實現爲那些想馬上使用 Jxta 的 Java 程序員把事情變簡單了。而若是您正在非 Java 平臺上實現 Jxta，那麼理解這些協議就是很是重要的。表 2 簡要描述了 Jxta 協議的核心集，涵蓋了發現（對等機如何找到對方）、廣告（對等機如何讓別的對等機瞭解對等組、管道等信息）、經過管道進行的通訊和對等組成員資格的處理。下面的全部協議都是創建在傳送器上的 XML 消息交換的基礎上的。一樣地，它們能夠用幾乎全部的編程語言在幾乎全部平臺上實現。
　　
　　表 2. Jxta 核心協議
　　
　　Jxta 規範不要求對等機實現上述全部協議。任一特定的對等機只須實現那些實際要用到的協議。
　　
　　基於 Jxta 的系統的一些有趣的屬性
　　既然您已經對 Jxta 平臺理論上的構件有了一個基本理解，咱們就來討論一下做爲 Jxta 設計結果的一些有趣的屬性。
　　
　　有「電子心跳」的任何東西均可以成爲一個 Jxta 對等機，從理論上說，有文本字符串生成能力的最簡設備均可以加入（雖然並非在每一個 P2P 應用中都有必要）到 Jxta 網絡中。這是怎麼成爲可能的呢？
　　
　　在 P2P 網絡上，過度簡化的設備須要對等代理人。這個代理人能夠表明該簡化設備（或多個簡化設備）執行發現、廣告和通訊。代理人的位置能夠被硬性固定在簡化設備。這樣，在代理人的幫助下，簡化設備就能夠成爲 Jxta 網絡上徹底合格的對等機。例如，一個被綁在一隻海龜身上並以無線方式發送出帶有位置信息的 Jxta 消息的 GPS 定位器，就能夠成爲 Jxta 網絡上的一個對等機。
　　
　　不肯定拓撲結構的網絡中的順序
　　典型 Jxta 網絡另外一個迷人的方面是它固有的不肯定的拓撲／響應結構。計算機用戶一般都習慣於本質上肯定的、同步的計算機系統，並認爲這是一種標準結構。例如，當咱們的瀏覽器發出 Web 頁面的 一個 URL 請求時，咱們指望輸出馬上就會出現。咱們還指望世界上的每一個人均可以使用同一個 URL 從同一個 Web 服務器檢索同一個頁面。
　　
　　在 Jxta 世界裏，一個特定的資源請求不會在幾分鐘、幾小時或甚至幾天內返回；事實上，它可能根本就不會返回。另外，請求同一資源的世界各地的人們極可能獲得的是來自徹底不一樣的服務器的資源副本。這就引發了一個問題：不肯定性系統有什麼好處呢？
　　
　　來自 grassroots 軟件革命的靈感
　　咱們只要看看象 Napster 和 Gnutella 這樣的流行 P2P 系統就能夠找到答案。下面是它們的一些額外的優點特徵（它們使同步性和肯定性的喪失變得值得）：
　　
　　內容的高可用性。
　　對等機能夠從多個服務器上獲取內容，理想狀況下可從附近開機運行着的一臺服務器上得到。原始源對等機沒必要爲每個資源請求服務；事實上，它甚至能夠不開機運行。網絡帶寬的最優化使用。
　　現今 Web 上典型的局部流量集中致使的擁塞不會影響 P2P 網絡。
　　
　　更低的內容分發成本。
　　P2P 網絡能吸納內容並複製它以使它易於存取。
　　
　　來自網絡中各個節點的計算能力的均衡。
　　經過異步操做，您能夠同時發出許多資源或服務請求，而後讓網絡爲您完成這些工做。
　　
　　無限的可伸縮性。
　　一個設計良好的 P2P 應用能夠在不影響可伸縮性限制的狀況下橫越整個已知的鏈接着的宇宙；而這在任何集中式模式中是徹底不可能的。
　　
　　在完美的 Jxta 世界中，咱們將在不肯定性網絡上執行異步請求。您以爲這個概念古怪嗎？讓咱們用一個示例來闡明。設想一個在基於 Jxta 的 P2P 網絡上運行的基於網絡的音樂請求服務。對等機提交了幾個對音樂文件的請求並在一段時間後覈查對等組中的音樂請求服務是否找到了這些文件。當咱們在一段時間後去覈查音樂請求服務時，所請求的一些文件已經被找到，但其它的卻沒法定位。服務對那些文件的響應是：音樂的選擇和可用性在不斷地變化；請稍後重試您的請求。這是一個可接受的不肯定的結果：雖然服務未能找到一個文件