對Jini設備的硬件要求
雖然Jini本身是一個軟件系統，但是一個真正投入使用的Jini系統則由一系列軟件和相應的硬件組成。顯然，以往一般的電子設備是不可能直接加入到Jini系統中來的。我們只有全面了解支持Jini技術的硬件規范，才會對Jini技術的未來有一個更深入的了解。
Jini結構需要以Java語言中的數據類型定義服務，且以服務的不同實例來以不同方法實現該數據類型。一個服務可以是不同類型的成員，答應了一個服務實例可以為客戶提供不同功能。這是一個標准的面向對象軟件的方法。Jini系統分布式的特點答應了Java語言的數據類型可以以一個軟件和硬件的結構來唯一地實現。
實現這種功能的思想核心十分簡單。服務以一個接口定義，支持接口的代理對服務客戶是可見的，代理的功能模塊由服務提供者上載到查找服務上，隨後以客戶所發現的服務的一部分被下載到客戶方。這種服務相關的功能模塊需要用Java語言編寫以保證可移植性。但是，既然這代碼來自被使用服務的個體實例，它的代理就可以具體地知道特定服務功能模塊的細節。下載的代碼不但知道實現這種服務的軟件，還可知道服務所在的硬件。在極端情況下，硬件就是服務的全部，下載的軟件是一個網絡級的設備驅動程序，在得到來自客戶方的Java語言的方法調用後，在網絡連線的另一端產生了對硬件的特定硬件代碼調用。
對查找服務（Lookup Service）的要求
一個服務提供的實際功能對提供這個功能的實體要求很少，實際上，Jini軟件服務可以用這樣一種方式來運行設備：客戶方下載的Jini程序直接向硬件發送相應的二進制代碼直接執行。在這種情況下，Jini設備所需的智能是最少的。Java程序與設備控制器交互的方式與設備在一局部計算機總路線下的交互是十分類似的（當然，還須在通信方面對網絡中心做一些修改）。
但是，提供服務僅是對Jini服務要求的一部分。要成為Jini系統的一個部件，服務還必須參加到Jini的發現協議中來，並向Jini查找服務注冊其自身信息。
這兩方面的需要是密切聯系的。Jini發現協議的主要目標是使得設備、服務或獲得本地Jini查找服務的一Jini遠程方法調用（RMI）的引用。一旦這個引用被得到，服務需在Jini查找服務中注冊，答應Jini系統中的其它成員發現和使用這個服務。
Jini查找服務的接口是一個完全的RMI接口，服務的實現使用了RMI所有的機制，包括分布的垃圾回收和代碼的動態下載。因此，服務被假定有一個對Jini查找服務的引用，該查找服務運行在一個完全的或是至少支持RMI的Java虛擬機之上。
當我們考慮到Jini查找服務的另一個實現方案，即除Jini查找服務自已定義的接口之外還支持其它遠程接口，（net．jini．core．lookup．ServiceRegistrar）因為這種方案有一個不同的RMI代理而不是像現在的方案那樣：一個有完全JVM和RMI的設備可以下載它。一個沒有完全JVM和RMI的設備需要一個處理這種服務實現的不同方法。
除此之外，服務的注冊還需要net．jini．core．lookup．ServiceItem對象的產生，這個對象由一系列的Jini對象組成。在查找服務包含這些入口則需要net．jini．core．entry．Entry的Jini對象的產生，所有這些對象最簡單的產生方式就是由一JVM構造。
最後，Jini查找服務的注冊被租用，返回的租用需要續租以使服務繼續在查找服務中顯示。查找服務規范沒有包括由注冊返回的租用對象。所有這些被定義成Jini語言中的接口，必須被以租用返回的（本地）對象支持。因而查找服務的設計需要那些類代碼下載到注冊的服務中以使租用可以被續租，實現了net．jini．core．lease的租用接口。
進入討論組討論。 實現Jini服務的三種不同途徑設備擁有常駐的JVM
