前言

到目前为止，我们已经知道，Jini技术是一个以Java平台为基础的分散式系统架构，达到具简单、弹性以及合作的目的。在Jini的架构下，允许一群机器设备或是软体程式形成一种合作的模​​式，提供其他成员自己所拥有的资源，同时也可以索取自己所需要的资源。而这些所谓的资源，在客户端所呈现出来的是以Java程式语言所设计的物件，但是实作的部份可以是软体，也可以是硬体。在本期中我们将要探讨这些在硬体部份的实作，有​​哪些可能的方式，以及在功能及设备的复杂度上会有哪些可能的取舍问题。

基本的设备架构型态

Jini架构的主要概念，就是让分散式系统的运作弹性尽可能的单纯。所有的服务都是透过所谓的类别介面(interface)来定义，而代理人(proxy)的实作部份则必须支援这些介面。这个代理人可以让使用服务的客户端看见，而且是由服务提供者上载并登记在查询服务中，而这些实作部份最后可以下载到客户端。这种以服务导向为中心的设计方法，可以让代理人程式码到达客户端，又因为代理人完全了解服务端的实作(因为都是由服务端所撰写)，所以这简直就是专为服务端的硬体或软体所设计的服务，你要称它为网路层级的「驱动程式」也不为过，这样的驱动程式是由Java程式语言所设计，并透过网路来使用远端的硬体资源的方法。

接下来，我们就来看看在硬体上有哪些实作Jini服务的方式。这其中每一种方式，对使用服务的客户端来说都是一样的，只是不同的方式或使用不同的途径来和Jini查询服务沟通，同时也会使用不同的形式来提供使用服务的客户端Java的类别介面。在每一种方式中，都会针对设备的复杂度而有不同的设计取舍，对设备所具有的弹性、沟通形式的直接程度也都是如此。在此之前，我们要先了解所谓的位置关系(interposition)，也就是在服务提供者本身以及其客户端之间加入代理人的形式和能力。这个服务代理人可以用来当作Jini技术基础架构上的中介者，将服务本身要和Jini系统合作的部份分离出来。以下几种方式，只是给予服务设计者一些基本的建议，在设计硬体组件的服务上所能采取的几种基本方式。另外要强调一点，就是并没有所谓的单一Jini设备架构，相对的，应该是存在一个可以容纳不同服务的设备虚拟空间，而这些服务是由不同价格、效能、功能、以及弹性的硬体所实作构成的。以下便是这几种方式的描述：

1.使用现有Java虚拟机器的设备

首先，最简单的设计方法，就是将运算效能、记忆体以及储存媒体都涵括进来，并加入完整的JVM以及支援Jini基础架构所需的Java应用程式环境(也就是那些支援程式码载入、 RMI、以及特别的安全功能者)以加入Jini合作环境之中。这样的做法，设备便会成为一个很特别的运算单元，对外提供具有设备能力的Java API。在这样的方式下，硬体的实作都会被隐藏在设备的软体实作后面，而这样的软体实作又会隐藏在客户端所使用的服务代理人后面，这样两阶层式的架构如(图一)所示：

《图一 使用现有Java虚拟机设备的组态》

这样的设备可以使用到完整的Java以及Jini技术，来上载和设备沟通的程式码，以及下载该服务可能会用到的程式码。这样的设备可以使用基本的RMI协定来透过网路做沟通工作，并且在通讯协定及设备的软体协定间有一定的连结。在这样的形式下，设备便成了透过内嵌的Java平台来提供特定服务的网路应用。实际上，这样的方式使用了在硬体上实作RMI伺服器的方式，而将硬体独立在两阶层的间接沟通模式下。其中第一层是代理人程式码的部份，这部份被上载到Jini查询服务中，且由使用服务的客户端来下载。第二层则是本机上的JVM以及由Java所设计的程式码，这部份用来当作代理人和硬体之间的中介单元。

使用这种方式来实作的设备，可以视为在设备上实作多种服务，并透过JVM来对外提供。此外，这样的设备本身的进步也不会影响到客户端或是主从端之间的网路通讯协定，因为硬体上的任何改变都只有JVM以及伺服端和硬体直接沟通的程式码才会看见。这样的方式虽然简单且具有弹性，但却为设备本身带来了额外的成本，因为这个设备将会需要一个微处理器来执行JVM，以及一定数量的记忆体来建立并存放所撰写的类别程式，还需要一些储存媒介来提供所需载入的JVM以及JDK软体。这些部份对实作硬体设备所提供的Jini服务来说都是必要的，而这些额外的硬体需求的确会增加生产该设备所负担的成本。

要符合这些需求并不代表你需要一个专属的JVM，或是一个在设备上运作的完整JDK。因为JVM可以在任何形式的微核心程式上执行，甚至可以直接在硬体上执行。此外，JDK其中有一大部分对设备本身来说并不需要，如绘图以及和使用者介面相关的部份，这些都是目前JDK版本中的一大部份，其中也有另一些部份可以因应需求来进行删减，进而形成一个瘦身过后的JDK来提供Jini设备使用。这种将JDK真正所需的部份找出来的工作式相当值得的，因为这样可以显著的调整整个元件的大小，同时这样的技术也和内嵌式Java技术(Embedded Java)的定义很接近，只是要再加上对RMI的支援即可。

这样的做法重点是在设备可以下载任何由Java所撰写的程式码，并使用RMI来当作沟通的桥梁，以应付一个一般用途虚拟机器的需求。若是设备可以支援一个标准的JVM，则该设备便可以再Jini合作环境中发挥完整的功能，且在设备之间的相互合作沟通方面也可以具有完全的弹性。

2.使用自订虚拟机器的设备

如果生产设备的厂商愿意牺牲一些在Jini分散式架构下的弹性的话，要加入Jini合作环境的门槛就可以降低一些。也就是说，我们可以设计自己特殊用途的虚拟机器，使它只拥有加入Jini合作环境中最基本的发觉以及查询服务协定即可。这样一来，该设备仍然可以成为Jini系统中的一份子。要达到这样的目的，首先设备厂商必须为该设备实作出Jini发觉服务以及Jini查询服务的相关介面，包括和租约相关的部份，以及如何在Jini环境中更新租约等等。其次必须要有足够的方式来让其他成员下载并使用你所提供的服务代理人。举例来说，这样特殊的虚拟机器可能不需要使用到安全管理的功能(Security Manager)，但这在标准的JVM中却是必需的。 (图二)表示了这种方法的形式，和第一种方法的差别只在虚拟机器的部份。

《图二 使用自定义虚拟机设备的组态》

间单来说，这样的设备就是包含了特别用来在Jini环境中运作的JVM，其中允许了Jini的发觉以及查询服务运作，并设计了特别的租约形式以供使用。这样做法的缺点，就是它会限制了该设备的能力，不但将来的软体更新较为困难，同时对代理人在协定的修正上也会有诸多不​​便之处。而特别的租约形式也会对设备造成限制，因为只有特别实作出来的查询服务才能够使用到它。但是无论如何，这种在服务设计上的负担也不会比简化整个设备要来得复杂。

3.数种设备共用一个虚拟机器(实体连接形式)

第三种方法是使用一个完整的JVM，但是将该JVM的成本(包括硬体及软体部份)分散到数个不同的设备上。如果是使用这样的做法，则一群设备便可以共同使用一个JVM来当作在设备和Jini系统之间的值中介层。每个设备都可以把Java程式码载入到它们所属的虚拟机器中，并允许该虚拟机器和设备本身沟通，并将那些和Jini查询服务、发觉服务以及租约沟通的部份加入JVM中。这样的做法和第一种方式相当类似，不同之处在于JVM是由一群设备共同使用的。它仍然是个完整的JVM，也就是说，它允许程式码的下载，以及一切Java平台所应具有的功能。但无论如何，对这样的实作设备来说，必须要能够允许数个不同型态的实体设备连接到一个大的设备上，共同分享一个Java应用程式环境。

这样一个大的设备，我们可以想像成是一个Jini设备船坞(Jini device bay)。这个船坞可以提供电源、网路连接、以及执行JVM的微处理器，并包括一个合适版本的JDK。而那些提供特殊用途Jini服务的设​​备则可以连接到这个船坞上，并让设备船坞知道它们的存在。这部份的沟通可以使用自己的内部协定(也就是说，允许厂商生产自己的设备以及容纳那些设备的设备船坞)，或是其他工业标准来识别自己的设备。而由于有这样的关系，一个新加入的设备会告诉设备船坞如何针对特定的服务取出相对应的Java程式码，或是如何找出和该设备沟通的程式。这样一来，便允许设备本身携带自己的「驱动程式」，以利自己的机器或是网路来使用。

而当设备船坞侦测到一个新的设备时，它会运用Jini查询服务来注册该设备所提供的服务，在这里，设备船坞则是负担着在Jini查询服务中更新租约的责任，并处理任何已经移除的设备，就如同该设备的代理者一样。而设备船坞也会将设备的程式码提供给Jini查询服务，以便所有使用该服务的客户端能够下载执行。在使用设备服务的客户端眼中，它会相信它正和在Jini查询服务中所登记的设备做沟通，但是实际上它是透过了设备船坞来进行运作。而该设备船坞则是扮演这对不同服务所分派动作的角色，就如同代理者一般，将服务代理人的网路协定，经过转换之后，透果设备船坞和真正设备之间的协定来作通知。这样的架构我们以(图三)来表示其运作模式。

《图三 数种设备共享一个虚拟机「实体连接形式」的组态》

这样的做法对设备厂商来说，可以使用同一个设备船坞来连接许多个实体设备，的确可以降低成本，而这样的船坞也可以具备一些智慧、记忆、以及其他单元(如电源等)。而透过这样的方式在多个设备之间共享资源，和Jini系统环境沟通所需要的额外成本和工程负担就可以适当的分散到这些设备上。这样的方式对厂商来说，会负担的成本主要是在于让设备船坞扮演Jini设备的角色，并且实际运作的设备必须事先定义且无法更新。在这里必须要再强调一次，Jini设备船坞本身就是一个Jini设备，也就是说，它提供了它所包含在其中的设备所拥有的所有服务。也就是因为如此，它对于自身内部的控制就具有极大的弹性，包括内部沟通的协定，甚至是硬体汇流排得规格等等。

4.数种设备共用一个虚拟机器(网路连接形式)

另一个使用设备船坞的方法，就是透过网路来和设备进行沟通，而不是使用实体的连接方式。在这种方式下，一个让数种设备​​当作代理者的JVM就存在于网路环境中，提供服务的设备可以加入该网路，发觉现有的代理者设备，然后对该代理者进行注册。而这个注册动作除了是将自己所提供的服务的Java程式码做登录之外，还会将如何和设备本身沟通的程式码也一并做登录。而当一个设备替自己注册了之后，该代理者便会将这个设备所提供的服务，向Jini查询服务进行真正的注册动作。这样一来，设备所提供的服务便正式成为Jini合作环境中的一部份。而针对那些服务所发出的请求，则会先送到该服务的代理者，然后再将请求转交给实际负责的设备上。此外，该代理者必须要能够处理和Jini相关的工作，如租约的更新等等。这样的方式在(图四)中有清楚的说明。

《图四 数种设备共享一个虚拟机「网络连接形式」的组态》

这样的方式对个别设备来说，是需要一些额外硬体设备支援，也就是要有所谓的代理者。这样的代理者必须具有网路连线，并且具有自己的电源。但即使如此，各个设备仍不需要有自己的CPU、记忆体、或是储存媒介，因为这些都由在网路上的Jini设备代理者来提供了。

使用这种方式的设备，和网路代理者之间必须要有特定的通讯协定，也就是说，要有特别的网路程式码，以便提供该设备在网路上的识别功用，但这仍然只是代理者和设备之间的特殊沟通方式。而且，这样的协定一旦确定下来之后，也就不容易在进行修正了。此外，这样的方式和前一种Jini设备船坞比起来个别设备的设计上会比较复杂一些，但是设备的数量就不会因为硬体的限制而有所谓的上限，而且设备也不必一定要和代理者放在一起，这在前一种方式是不可能做到的。这样的方式也可以当成为Jini设备和其他网路设备之间建立所谓的闸道(Gateway)。针对那些原先使用特定通讯协定的设备，我们去建立Jini代理者来连接它们，进而加入Jini合作环境之中。这种做法可以用在消费性电子设备、工厂自动控制设备、以及其他家用控制设备上，来共同组成Jini系统运作环境。

后记

本文介绍了在一个Jini系统环境中，硬体的实作有哪些可能性，同时也说明了这些实作方式所会面临的取舍问题。这些取舍问题分别出现在各阶层的成本问题上，包括硬体设计、软体工程、网路组态等部份。本文也提供了有心发展Jini系统的读者可以采取的系统架构形态，希望能让读者在花费最少的精神，来达到进入Jini世界的大门之中。