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