对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的租用接口。
标签：
