Jini技术的出现，使得Java在成功地为网络设备的计算提供了合适的平台之后，更为网络设备，尤其是家庭网络下的消费类电子设备提供了一个全新的网络计算结构，从而实现了人们期待已久的网络设备的即插即用。
对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 成为Jini系统联邦一部分的一个明显的设计方案就是让其包含计算能力、内存和稳定的存储空间，这些是拥有一完全的JVM以及支持Jini基础结构所需的Java应用环境的那些部分所需的（尤其是那些部分包括代码载入、RMI和任何所需安全机制）。这将使设备进入专门的计算入口，设备的一部分将专门为Jini结构所需的部分Java API服务。在这种途径下，硬件抽象实现在了一设备局部软件抽象之后，该软件抽象了在客户与服务连接的的代理代码之后。
这样的设备可以对Jini和Java技术有完全的支持，包括上载与设备通信的的代码和下载可能为设备提供服务所需的代码。这样的设备在网络通信上使用本机RMI协议，并在通信协议和特定的控制设备自己运行的软件协议之间有一个宽松的联系。用这种途径，设备成为一通过嵌入式Jini平台提供特定服务（或服务集）的专门网络应用。
实际上，这种途径以RMI服务器的实现使用了硬件解决方案，在两个方向上隔离了硬件：先上载到Jini查找服务后下载到服务客户的本地代理代码来提供；在服务设备上的本地JVM和由Jini程序写的代码允许客户代理和硬件自身的调解。
通过设备上的JVM中介，一个使用这种途径的设备可以简单地在设备上实现多种服务。这样的设备可以在对客户和客户与服务之间的网络协议无影响的情况下自身发展。尽管简单、灵活，这种途径会增加设备的成本。设备需要一可运行JVM的微处理器，产生存储类所需的内存和一些存储JVM和JDK软件类的常驻存储（如磁盘或NVRAM）。所有这些都加到了那些执行设备提供的Jini服务所需的硬件之上。
满足这些需要不要调用JVM的主机版本，或一个在设备上运行的完全的JDK。JVM可以在任何形式的微内核或设备的硬件上直接运行。并且JDK的大部分不为一设备所需要，占用当前版本JDK相当大部分的如图形和UI（User Interface）类不被需要。版本的其它部分同样可抛弃，“被剥皮”的JDK足以满足Jini设备的需要。确定这样一个JDK子集的大小和部件是值得一做的；这与EmbeddedJava技术加上额外的RMI类的规模类似。
对于这种途径来说，重要的是可以下载用Java语言写的任何代码，并可以使用RMI通信系统和处理一个虚拟机一般的需要。通过一标准JVM，设备在Jini系统联邦中有一完全的成员资格，且在它提供给联邦的其它成员的代理与它自身通信方式上有足够的弹性。
使用专门JVM的设备 假如制造商愿意放弃Jini分布式结构提供的某些灵活性，我们可以降低对其进入（Jini设备生产）的要求。为此，设备生产商需在设备中实现对Jini发现与查找服务的接口，包括对某种租用专门的处理和对这种租用直接续租的能力，该租用由查找服务分发。并且设备还应有下载对服务有用代码的能力。这是一专门的功能集，比整个JVM需要的少得多，可由小得多的代码来实现。
这样的设备将包括一Jini环境专门设计的JVM，允许访问Jini发现和查找服务以及续租一特别顺序的租用。它限制了这样一个设备的灵活性，因为设备不可以变化软件。对由查找服务分发的租用的专门认知也使得这样的设备只能与专门的查找服务打交道。但是，这种服务功能上的欠缺可由简化设备总体得以弥补。
多个设备 1 2 您可能对 [Java] 的这些文章也感兴趣：