隨著移動計算的普及和嵌入式可聯網微處理器的無處不在的應用
TCP/IP 終於顯露出它已經顯得過時
設計 Jxta 的初衷就是要突破當今基於 TCP/IP 的網絡的限制
從而擴展因特網所能觸及的范圍
在 developerWorks 的討論 Jxta 的系列的這最後一篇文章中
Sing Li 舉例說明了體現這種擴展的系統
並解決了一個實際問題
您將看到 Jxta 不受客戶機／服務器網絡的典型約束的限制
請單擊本文頂部或底部的討論
在討論論壇與作者及其他讀者共享關於本文的心得
到本系列文章的這裡為止
我們仔細考察了 Jxta
一個 Java 參考實現的新 P
P 平台
是如何工作的
在第一部分中
我們了解了 Jxta 的互操作特征
Jxta 被定義為一組互操作協議
可以跨硬件平台
操作系統和編程語言實現
我們也討論了 Jxta 的操作模型和包括對等機
對等組
服務和管道在內的許多重要概念
在第二部分中
我們的著眼點是建立和運行 Jxta
我們探討了一個 Jxta 應用程序 — Jxta shell — 並經歷了創建管道並從一個對等機發送消息到另一個對等機的情形
在我們編寫 Jxta shell 擴展時
我們第一次獲得了用 Jxta API 編程的經驗
迄今為止
我們討論 Jxta 的方式都是從下到上的
對於像我們這樣具有系統編程和網絡工程背景的人來說
這是再自然不過的
在本系列的這第三篇也即最後一篇文章中
我們要把事情顛倒過來
從那些從事應用級設計和體系結構的人的角度來說
本文是自上而下看待 Jxta 的
我們從一個特定的示例問題開始
對這個問題進行分析並設計出一個解決方案
從而展示 Jxta 是如何自然地解決該問題的
隨著本文的進行
我們討論 Jxta 如何通過並列（juxtaposition）改變聯網的前景展望
我們還提供一個 Jxta 服務和客戶機的設計和代碼
解決一個分布式數據收集問題
設想一下我們需要創建一個大規模的氣象數據收集和分析系統
在這個系統中
我們有數百個氣象數據收集點
每個收集點配備一個微型氣象站
這些氣象站將當前溫度（和其它大氣狀態）提供給一組數據集中器
收集器遍布世界各地
這些收集器並不是都直接連接到因特網
任何時候都可能有新的數據收集器連接上來或脫開連接
在這個項目中
參與進來的收集器的確切數量經常在變化
數據分析和處理基於區域平均值
開始時只有
個集中器
每個集中器監視來自許多個收集器的數據
這些數據被實時提供給關系數據庫
隨後
來自關系數據庫的數據被提供給運行氣象分析和預測的仿真模型的超級計算機並由它處理
集中器的數量和位置會發生變化
但它們的行為則大多更穩定
一旦安裝後
集中器就會保持運轉
除非碰到系統失效
我們必須解決的問題
我們的系統如何能夠持續運轉
並能考慮到在幾乎不影響整體性能的條件下
允許動態添加或除去收集器和集中器
初始分析
特定網絡的復雜性
系統中的某些收集器可直接訪問因特網
其它的通過無線電傳輸技術進行連接
它們處在惡劣的外部環境中
事實上
在這些基於無線電的收集器中
許多都被設計成了節能的
以延長電池壽命
收集器的有效范圍僅夠與下一個最近的收集器或基站聯系
這些收集器中許多都不支持 TCP/IP
而是使用基本的分組無線技術
一些更獨立的收集器僅僅靠其太陽能電池板獲得能量
並使用衛星傳輸進行通信
還有另外一些收集器則連接到標准蜂窩電話上
用 SMS（short message service
短消息服務）消息傳遞來發送消息
在項目的整個生命周期中
可用的收集器的數量會發生變化
在項目開始時
我們無法預測將會構建到未來收集器中的連接類型
也無法預測收集器將使用的技術
例如
在項目的某個階段
在一個超級計算機群集內使用軟件仿真來仿真數量巨大的收集器
我們的解決方案必須能適應所有收集器
不管是真正的還是仿真的
現在的還是將來的
解決方案
並列（Juxtaposition）
圖
顯示用來解決這個問題的高層次設計
圖
解決數據收集問題
請注意
並列 P
P 網絡用來適應網絡的多種不同情況
而集中器提供 P
P 網絡和傳統的客戶機／服務器網絡之間的連接
數據庫服務器和超級計算機駐留在客戶機／服務器網絡
集中器充當兩個網絡之間的網橋 — 每個集中器在 P
P 網絡上具有動態特性
在客戶機／服務器網絡具有靜態特性
這個體系結構反映了 Jxta 對傳統系統的補充作用和提供並行於這些傳統系統的增值的能力 — 通過並列（juxtaposition）
Jxta 的名稱就源於這個詞語
我們不想深入討論這裡的客戶機／服務器網絡的細節
因為其中並沒有什麼獨特之處
我們甚至可以使用 VPN 技術在因特網上運行它
有趣的部分在 P
P 網絡
圖
顯示了它的組成
它可隨將來的變化而變化
請注意其中用到的多種不同技術
圖
數據收集器網絡的組成
在實現這個 P
P 網絡時
我們可以利用 Jxta
從而獲得以下優點
容易地添加或除去新的收集器或集中器
這得益於 Jxta 的統一分散尋址
設計簡單性
這得益於 Jxta 的網絡虛擬化
持續運轉
這得益於 Jxta 支持故障彈性
免維護運轉
這得益於 Jxta 支持動態自我組織網絡
支持跨越許多硬件平台和編程語言的多種不同實現
支持所用的各種不同通信協議讓我們來更詳細地研究一下其中幾個益處
並看看 Jxta 如何為體系結構的各個方面作出獨特的貢獻
統一分散尋址
統一分散尋址的字面意思是
對等機可以為自己生成一個 ID 並立即加入到網絡
而不必與任何注冊人或中央認證機構聯系
而當今的 DNS 則必須這樣
這一特征使我們任何時候都可以向網絡添加收集器和集中器
在本文附帶的代碼包中（您可以從參考資料下載它）
我們提供了名為 mdidgen 的實用程序
它可以用來為新的 Jxta 服務和管道生成地址
（要更多了解 mdidgen
請參閱旁注 mdidgen 實用程序
）您可以閱讀本系列的第一篇文章
了解 Jxta ID 是如何用來對 Jxta 對象（例如
對等機
對等組
服務和管道）進行統一尋址的
請注意
Jxta 網絡中的對等機不一定要有一個獨立的物理存在
在我們的示例中
我們用一個超級計算機群集來仿真數量巨大的收集器
每個收集器有它自己的統一地址
這些仿真收集器的每一個在 P
P 網絡的其它部分看來都是一個與那些具有物理存在的對等機沒有什麼差別的對等機
網絡虛擬化
通過分散尋址為所有收集器和集中器賦予網絡中唯一的標識後
它們立即就成為網絡中的對等機並開始彼此通信
盡管它們可能通過許多種不同的消息傳遞機制進行相互聯系
但在 Jxta 級別上
它們都只是一個虛擬網狀網絡中的節點
如圖
所示
圖
網絡虛擬化
請注意
將收集器和對等機實際相互連接起來的所有不同的傳輸和尋址模式都被虛擬化了
只留下一個網狀網絡
其中的每個對等機都與其它每一個對等機相連接
Jxta 通過使用統一尋址模式和極遲綁定（very late binding）
在多個端點協議上添加一個智能消息路由層做到這一點
從本質上說
每一個端點協議或傳輸協議棧都成為虛擬 Jxta 網絡的一個驅動程序
將虛擬網絡映射到物理網絡上
圖
顯示了這種設置
圖
端點協議作為驅動程序
通信協議要成為合格的端點協議
只需要它能夠在兩個物理節點之間發送或接收 XML 消息
對傳輸可靠性或消息廣播支持沒有什麼要求
因而
最簡單的分組無線協議也可以用作端點協議驅動程序
與像 TCP/IP 這樣的復雜多層協議並列
這也解釋了為什麼 HTTP 和 TCP/IP 在 Jxta 協議棧內都是同一級別的端點協議
盡管它們的物理級別非常不同
HTTP 是一個受支持的端點協議
因為只要有必要
它就能夠穿越盡可能多的防火牆
從而獲取從一個 Jxta 對等機傳送到另一個的消息
Jxta 網絡中的每個對等機可以同時支持多個端點協議
Jxta 虛擬網絡機制會以一種盡可能遲的方式將虛擬化的統一網絡地址映射到物理網絡地址（在 Jxta 中稱為網絡端點）
從本質上說
一個對等機對應於一組物理端點
其中的每個物理端點可以在完全不同的物理通信協議上實現
較高級別的虛擬化和路由服務隱藏了這一點
許多人或許能看出這就是多協議路由器的一個非常高級的形式 — 正是這相同的設備使當今的因特網成為現實
這一概念的發展將把我們帶向一個更加普遍的因特網
這是再自然不過的了
讓我們更詳細地研究一下圖
所示的示例
對等機 A 是網絡中的一個收集器
它試圖通過一系列中介收集器（對等機 B
C 和 D）將其數據發送到集中器（對等機 E）
在圖中每個對等機的下面是該對等機所支持的一組協議
圖
Jxta 路由示例
因為對等機 A 不直接連接到對等機 E
所以它的消息必須通過中介對等機 B
C 和 D 進行路由
Jxta 將自動對消息進行路由
使用 TCP/IP 從對等機 A 到對等機 B
使用分組無線協議從對等機 B 到對等機 C
使用 SMS 從對等機 C 到對等機 D
使用 HTTP 從對等機 D 到對等機 E
對等機 E 將在它創建的管道上接收來自對等機 A 的消息
完全未覺察 Jxta 為它所執行的復雜工作
請注意
對等機 C 到對等機 D 的路徑是非
From:http://tw.wingwit.com/Article/program/Java/hx/201311/26481.html
