Jini 為分散式計算環境中的網路互相操作性問題提供了開放解決方案。這意味著 Jini 做到了以下幾點：

Jini 的具體細節

正如上面提到的那樣，Jini 旨在提供自發的網路連結，允許用戶將幾乎任何支援Java 的設備（也就是說，其作業系統支援 Java 應用程式的任何設備）直接插入到網路，並且網路的所有元件可以立即識別這個新的設備及其能力。例如，如果新設備是一台印表機，則Jini 網路中的其他電腦將立即能夠找到並使用這台印表機。

透過使用在網路中行動的物件，Jini 架構意味著整個網路（連同其中每個單獨的服務）將可適應於變化。Jini 架構為客戶端和服務在網路上相互找到對方並共同工作以完成任務指定了一種方法。服務提供程式為客戶端提供可移植的基於 Java 技術的物件，這些物件能給予客戶端對該服務的訪問權。這種網路交互可使用任何類型的網路連結技術（如 RMI、CORBA 或 SOAP），因為客戶端只看到基於 Java 的物件，而且所有隨後發生的網路通信都限制在該物件以及發出該物件的服務。

當服務加入到具有支援 Jini 的服務和∕或設備的網路中時，它會透過發佈一個實作該服務 API 的 Java 對象來宣傳自己。這個物件的實現能夠以該服務選擇的任何方式工作。客戶端透過尋找支援該 API 的對象來找到服務。當它得到服務的已發佈對象時，它將下載與該服務通信所需的任何程式碼，從而學習如何透過這個 API 與特定的服務實作進行通信。實現該服務的程式師選擇如何使用 RMI、CORBA、XML 或專用協定將 API 請求轉換成線路上的位元。請參考(圖一與圖二)。

Jini在普及運算中面臨的挑戰

現在讓我們研究一下在無線設備中使用 Jini 所引發的問題，特別是那些在行動設備中嵌入Jini技術所引起的問題。首先，Jini 技術要求設備安裝了完整的 Java 2 標準版（J2SE）虛擬機（VM），缺少用於這些設備的標準無線網路連結技術更增加了這一困難。

為了幫助克服這些問題，已經建立了代理 Jini 架構。在代理 Jini 模型中，行動設備將程式碼傳遞到代理主機，代理主機隨後執行正常的 Jini 連接活動，如代表該設備註冊和使用服務。例如，印表機可以定位代理主機並傳遞程式碼以便為該印表機註冊列印服務。類似地，無線數位相機會用同一代理主機作為定位印表機和列印圖片的方法。

Jini 代理解決方案

Jini 代理專案定義了一種架構，它允許原本不能加入 Jini 網路的設備能夠加入網路。大多數行動和無線設備都屬於這一類，特別是那些用於普及運算（Pervasive Computig,PvC）的設備。它需要使用一個能夠與 Jini 網路交互的物件來連接設備及其環境。為做到這一點，需建立一個物件（或代理）來代表設備。透過向代理主機提供 JAR 檔或 JAR 檔的位置，設備在其“本地”網路環境找到代理主機然後用它註冊。代理主機實例化一個代理物件，該物件是從該 JAR 檔獲得的。這個代理物件隨即成為該設備在 Jini 網路上的代表。

無線連接不是因其穩定性而出名的。對於代理架構，不管連接建立或中斷，代理物件都可以保持活動，維持關於當前會話的資訊並代表 Jini 網路中的設備發揮積極作用。隨著可以使用不同的 CDC 設備，也可以對特定於設備的代理編譯。

下面是使用代理 Jini 架構的一些優點：

所有這些優點使 Jini 代理架構非常適合於 PvC 計算，其中該架構所針對的硬體或軟體元件的共同屬性是不能下載程式碼，其原因是設備的資源限制或網路連接性限制（比如在無線網路中）。以下是無線 PvC 中 Jini 代理架構的基本特點。

從 Jini 衍生的其他適合 PvC 的架構

下面將介紹一些針對特殊實作需求對 Jini 規範進行定制所產生的最新 Jini 項目：

Jump 專案（處理 P2P 網路連結）

Jump 專案的目標是為 P2P（或稱為點對點通信）建立新的發現和解析方法。這需要根據規範使用“自然語言定址”系統的名稱伺服器（已被 JXTA採納），並需要提供代理專用位址的方法的應用程式閘道。該專案沒有取得解決方案就停止了，這可能是由於 JXTA 專案的引入。有關使用基於 J2ME 的 JXTA 的詳細資訊可以在其網站找到。

Edge Networking（允許設備進行通信而不管使用什麼協定）

Edge Networking 允許將位於網路邊緣的所有設備（不管在NAT∕Internet∕xDSL 連接）連接在一起。Edge Networking 允許您輕鬆地使用自然語言發現這些設備，並且允許跨傳統網路邊界對這些設備進行入站連接。Edge Networking 獨立於傳輸協定，這給予應用程式開發人員使用 JXTA、HTTP、SIP 或任何其他協議進行通信的靈活性。

Davis 專案（處理 Jini 架構中安全性）

Jini Davis 專案主要關注對與安全性架構有關的幾個方面的支援，包括非統一網路安全性（涉及到客戶端、伺服器、遠端方法和參數的變化）和各種使用不同協定、演算法、機制和策略的安全性實現。

Edge Zucotto Xpresso（商用 Jini 解決方案）

Jini 代理架構的這個商業版本旨在使即便是簡單的設備也能利用和提供 Jini 服務，但當使用能夠運行 Java 應用程式的設備（例如一部嵌入 Zucotto Xpresso Java 本機處理器的手機）時能獲得最大的好處。

藍芽（消除協定差異和設備識別）

藍芽（Bluetooth）無線技術為行動設備發現其他鄰近設備並與其通信提供了一種方法。隨著新設備的加入以及已建立設備的移除，每台設備都始終可以被其附近的其他設備識別。這樣的動態、臨時網路連結是對 Jini 連接技術的極佳補充，它被設計成在符合 Jini 代理架構要求的情形下能很好地執行。

基於 J2ME 的 Jini（透過將設備視為物件來克服限制）

當前，在 CLDC 無線設備中使用 Jini 存在限制。隨著 Jini 代理專案的實現，Jini 正明確地向 J2ME 擴展。例如，想像使用您的 J2ME 設備參與線上交易。當您從一個地點移到另一個地點時，您會遇到不同的人並發現不同的事項（客戶端）。所有這些交互都發生在您自己的交易物件上，該物件實際上是您與這個世界的介面，一個從您的 J2ME 設備進行控制的物件。當交易執行時，會向您提供記帳服務，確認您何時開始了交易並據此開始對您收費。

將設備作為 Jini 網路中唯一物件的好處是擴大了交互作用語義集合。在門戶模型中，從設備的角度來看設備登錄和註冊可能相同，但其他服務看到的是門戶而不是單個對象。

Jini-RMI 方法（克服設備差異的另一種方法）

客戶端 A 向尋找服務（Lookup Service）發送一個請求；服務 B 以同樣的方式向尋找服務發送一個請求。尋找服務用編組的尋找服務代理物件響應客戶端 A 和服務 B；服務 B 向尋找服務發送一個 ServiceRegistrar.register（） 請求。尋找服務用註冊回應。客戶端 A 發出針對服務 B 的 ServiceRegistrar.lookup（），尋找服務用服務 B 代理物件響應。客戶端 A 直接將方法發送至服務 B，服務 B 從而對客戶端 A 作出回應。

當在小設備上使用 Jini 時，駐留在小設備上的服務 B 就會面臨一個問題，因為它不能解組尋找服務代理物件。這會產生一個“假裝的”尋找服務與客戶端 A 交互。客戶端 A 使用 ServiceRegistrar.register（），該方法返回服務 B 代理物件。這意味著設備執行自己的尋找服務以及所有 Jini 發現協議；設備服務尋找服務代理物件完全在本地客戶端上運行。

Jini 與未來

如您所見，Jini 網路連結的所有特殊實現都試圖提供滿足特定解決方案需要的服務，尤其要解決那些與參與 Jini 網路交互的設備限制有關的問題。

當然，設備限制是行動世界一個特殊的問題。目前的標準不能實現完整的 Jini，因此在各種項目中建立了變通方法。Jini 架構的許多變體，從 Jini-RMI 實現、到滿足代理 Jini 架構需求的藍芽，以及 Davis 項目的安全性增強、還有 Jini 架構，告訴我們 Jini 不是曇花一現，而有可能證明是 PvC 一直需要的無線連接的關鍵。有了 Jini，我們在網路上支援各種設備以建立真正的用戶社區的目標將能夠實現。

＜本文資料由台灣IBM提供，由陳玠錳整理，更多資料請參考IBM Taiwan開發者網站：http://www2.tw.ibm.com/developerWorks/tutorial/SelectTutorial.do?tutorialId=134＞