前言

在上一期中，我们说明了是因为什么样的因缘际会，导致目前的分布式计算环境，同时也因为软硬件的演进潮流，引领了目前的网络发展方向。在本期中，我们将详细说明Jini系统的运作，包括每个系统中的成员要如何告知自己的存在，以及如何去寻找到适当的服务等等，且听笔者娓娓道来。

Jini系统概观

在本文中，笔者将对Jini系统做一个完整的介绍，但是在这之前，我们必须了解一些Jini架构中所定义的一些概念。以下就针对这些基本概念逐一解释：

服务(Services)

在Jini架构中最重要的部份就是所谓的「服务」。所谓的服务，就是指任何一个人、程序、或是其他服务可以使用的单元。而一个服务，可以是一种运算，也可以是一种储存媒介，甚至可以是一种和别人沟通的管道，或是软件过滤程序、硬设备、或是另一个用户。举例来说，我们打印文件的动作可以称之为服务，而将文件由某种格式转换成另一种格式，也可以称之为一种服务。

所有在Jini系统中的用户都可以共享系统所提供的服务，如果我们只将一群服务器与客户端视为一个Jini系统的话，这样的想法并不适当。相反地，我们应该将Jini系统视为由一群服务所构成的环境，它们共同合作来提供某种特定的功能。所有的服务都可以供其他服务来使用，而某些服务的客户端本身也可能拥有自己的客户端。而Jini具有动态组织的天性更允许任何服务根据其需求，在任何时间加入或是退出整个系统，以提供适当的服务组合。

Jini系统提供了在分布式系统的环境中建构、找寻服务，同时也提供了服务之间的通讯管道。这类服务的例子有：设备部份包括打印机、显示器、磁盘驱动器，软件部份包括应用程序以及工具程序，信息的部份则包括数据库以及档案。其他如系统中的用户等等。在Jini系统中，服务间的沟通是透过使用服务协议(service protocol)来完成的，而所谓的服务协议，是由Java程序语言所开发出来的一群程序界面，且这样的一群协议是开放使用的。一个基本的Jini系统定义了一小组这样的服务协议来提供服务间最重要的互动功能。

查询服务(Lookup Services)

上节中所有的服务都是透过所谓的查询服务来找寻及定位。查询服务是Jini系统中最核心的起始功能，因为它建立了用户和系统之间的桥梁。更精确的说，一个查询服务的工作，就是将特定功能的服务所提供出来的接口，对应到系统中实际提供服务的伺服对象上。除此之外，服务中具有进一步叙述的属性更可以提供专业的人仔细的选择出更适合他们的服务。

在查询服务中的对象也可以包含其他的查询服务，也就是说，这提供了阶层式的查询模式。此外，一个查询服务也可以包括其他的命名或目录服务对象，藉此提供了和其他Jini查询服务之间的桥梁，甚至对其他系统的查询服务也可以达到相同的桥接能力。当然了，一个Jini的查询服务的参考(reference)是可以放在这些其他的命名或是目录服务中，以提供所服务的客户端获得另一个Jini系统中所提供的资源。一个服务可以透过一组发觉(discovery)以及加入(join)的协议来加入到一个查询服务之中，其动作顺序为：首先该服务会利用发觉协议来找出适当的查询服务，其次便利用加入协议来将自己放入该查询服务之中。

Java的远程程序启动(RMI)

在Jini系统中，服务之间的通讯都是透过Java的远程程序启动(也就是RMI)来完成。这样的基础架构不单只是提供服务之间的沟通方法而已，它更是整个Jini技术基础架构的一部份。Java RMI提供了找寻以及启动对象的方法，同时也提供了分布式的对象垃圾回收(Garbage Collection)功能。基本上，RMI是在Java程序语言环境中对传统的远程过程调用(Remote Procedure Call, RPC)所作的一种功能性的延伸。RMI不但允许数据在网络环境中由某对象传送给另一个对象，同时更允许整个对象在网络中移动，其中当然包括了程序代码的部份。在Jini系统中这类的简便性便是以RMI的能力为基础，将程序代码以对象的形式在网络环境中传递。

安全性(Security)

在Jini技术中，安全模型的设计是由两个方面角色来完成：一是当事人(principal)，另一个则是访问控制名单(access control list)。Jini的服务是由所谓的当事人来存取，其中系统可以用当事人来回溯出系统中特定的用户，而服务本身则是透过实作该服务的伺服对象来对外提供存取。至于是否具有存取服务的权限，则是由该对象本身所关连到的访问控制名单来予以决定。

租约(Leasing)

在Jini系统环境中，服务的存取是以租约(lease)为基础的模式来提供。所谓的租约，是指在某段时间内，允许存取特定服务的特性。每一个租约都必须经过用户、服务、以及服务提供商之间的协调，成为服务协议之中的一部份。用户可能会需要在某段特定时间内使用某种服务，但真正允许存取的时间则不尽相同，服务本身需将请求的时间考虑在内后做出回应。如果某个租约到期，却没有做解约的动作的话，则用户以及服务的提供者都可以假设租约已经终止，不论是因为该项资源已经不在需要使用，或是客户端抑或网络发生了问题，甚至是租约不允许延续的情形都是如此。租约是可以有独占性的，但也可以不是，端看资源本身的特性来决定。所谓独占性的租约(exclusive lease)，是指确保在使用资源的期间，没有其他人可以租用这项资源(如打印服务)。而非独占性租约(non-exclusive lease)则允许多个用户同时分享这项资源。

交易(Transactions)

所谓的交易，就是指一系列的运作(operation)，不论这些运作是使用单一的服务，或是使用多个服务，都可以视为一项交易。Jini系统中的交易接口(Jini Transaction interface)提供了一个服务协议，用来执行一种两阶段式的运作(two-phase commit)。而交易本身的实作，包括交易本身所内含的意义，则留给使用交易接口的服务来予以规划。

事件(Events)

Jini架构提供了分布式的事件模型(distributed event model)。一个对象可以允许其他对象针对特定的事件做登记，以便在稍后的运作中可以收到该事件发生的通知。这样一来，便可以让以分布式事件模型为基础的程序拥有更具保障的可靠性以及扩展性。

Jini系统组件概观

在Jini架构中，我们可以大略的将系统分成三大类组件，分别是基础架构类、服务类、以及设计模型类。所谓的基础架构类组件，就是指建立Jini系统环境所必需的建构单元。所谓的服务类组件，是指在系统环境中运作的单元，而设计模型类组件，则是指建立具有可靠性服务所需要的接口集合，其中包括属于基础架构的部份，以及在系统环境中运作的部份。虽然这三类组件具有相互独立且各部相同的特性，但由于它们在系统中相互纠结，所以它们之间的差异也显得有些模糊。此外，要建立一个Jini系统环境也不一定需要这三个部份同时存在。即使如此，一个Jini系统仍然可以发挥它的能力，因为它是由特殊的基础架构和设计模型所构成，也就是我们所提到的“服务”。而在这样的架构下区分出这三类组件，可以使得传统的程序代码更动减至最低，进而顺利的加入Jini系统的运作环境之中。但是，要Jini系统发挥它最大的能耐，还是必须要建立新的服务，并运用整合模式来建立时才会呈现。

我们可以将个完整的Jini系统，视为一个在单机上执行Java运作，并赋予在网络部份做上述的基础架构、设计模型、以及服务的延伸。这几类组件相对于原来的Java应用程序环境，我们可以由(表一)看出其中的差异之处。

《表一 Jini架构的组件区分》

基础架构部份

在Jini的基础架构下，定义了Jini技术最基本的核心功能。其基础架构包含了以下几个方面：

1. 一个分布式的安全模型，这些都已经整合在RMI之中，且延伸了原先Java平台的安全模型，使其在分布式系统的环境中运作。

2. 包含了发觉(discovery)以及加入(join)协议，服务协议允许各种服务(包含硬件以及软件)去发掘其他服务，或是成为运作环境中的一员，甚至是通知其他成员自己所能提供的服务。

3. 内含查询服务，也就是扮演了所有服务的仓库管理，其中每个查询服务的记录(entry)都是由Java程序语言所设计出来的对象，这些对象是允许被下载的，成为查询运作中的一部份，并同时担任客户端的代理者，负责与放在查询服务处的程序代码进行沟通。

所谓的发觉及加入协议，就是用来定义将服务变为Jini系统中的一部份的方法，其中RMI是在Jini服务间担任双向沟通的角色。而分布式的安全模型以及其实作部份，则定义了系统中各组成份子该如何取得自己以及别人的权限。最后，查询服务则反映了目前系统环境中所有成员的状况，同时也扮演者为成员提供以及寻找服务的中央控制角色。

设计模型部份

Jini的基础架构部份不但使用了设计模型，同时也善加利用了它。在查询服务中的记录部份，则是使用租约的方式来运作，这使得查询服务得以正确地反映出目前所有可用的服务。而当有某些服务加入或是离开查询服务的时候，就会发生相对应的通知事件，此时，其他系统中的对象便可以根据这个事件来得知是否有新的服务可用，或是不再提供哪些原有的服务。此外，设计模型的部份也具有移动程序代码的能力，因为这是在基本的基础架构上就已经涵括的特点。

所有的基础架构及架构在其上的服务都是可以执行运算的单元，共同存在Jini的运算环境中。此外，服务也是由一群定义沟通协议的接口所组成，而这些接口也可以供基础架构或是其他服务来使用，提供相互之间的沟通管道。这些所谓的接口，共同组成了Java程序模型的分散是延伸版本，进而形成了Jini的程序设计环境。而这些形成Jini程序设计模型的接口有以下几类：

1.和租约(leasing)相关的接口，这类接口定义了在可重复使用及具时间性的模型上配置即释放资源的方法。

2.和事件(event)及通知(notifica- tion)相关的接口，这类接口是以JavaBeans组件的事件模型为基础，将之延伸到分布式的环境中，用以提供Jini系统中服务之间的事件沟通管道。

3.和交易(transaction)相关的接口，这类接口可以使系统中各单元所造成的改变都可以确实对其他成员发生影响，或是完全没有影响。

所谓和租约相关的接口，是将Java中有关持有对某些资源的参考模型，加上时间的因子，使得在网络发生问题时，这样的参考持有可以安全的予以处理。而事件及通知相关的接口则延伸了原先Java-Beans组件以及Java应用程序环境的事件模型，使之能够在分布式环境中运作，使得由其他对象所处理的事件可以确保递送成功，而该模型也应该考虑到分布式的通知是有延迟的特性。

而在交易有关的接口部份，则引进了轻量化(light-weight)并具有面向对象特性的协议，使得Jini应用程序得以自由地控制自身在交易过程中状态的变化。这种交易协议针对分布式对象的环境提供了一种协调期间动作的两步骤做法，第一个步骤称为投票阶段(voting phase)，在这期间每个对象均会根据本身是否完成自身工作的状况来投票，而第二个步骤，则是协调者针对每一个对象发出执行完成的讯息，以达到交易完成的目的。

Jini的交易协议，和大多数的交易接口设计并不相同，这是因为Jini并不能假设系统中的交易是发生在标准的事务处理系统中，也就是说，它并不是处在一个能够保证交易内容正确执行的环境中。相反地，Jini的交易协议采取了更接近传统面向对象概念的观点，将交易的正确内涵交付给涵括在交易中个别对象的实作方法，而整个交易协议的内容则是定义了这类对象在协调交易运作中所需的互动形式。

以上这些定义Jini设计模型的接口，都会用在基础架构组件上，建构出最基本的Jini服务。例如，查询服务使用了租约及事件相关的接口，租约协议能确保某些已登记服务的可用状况，而事件接口则能针对管理上的问题以及设备组态动作上提供协助。又如Jini服务中的JavaSpace服务，是利用了租约及事件相关的接口，同时也支持Jini交易协议，所以交易管理者便可以藉以协调投票阶段中所有参与其间的对象。请注意，并不是所有的服务都必须使用到Jini的设计模型，但是这样的服务仍必须使用和Jini基础架构互动的运作方法。例如，每个服务都必须使用设计模型和Jini的查询服务交谈，并且不论该服务所提供的资源是否需要使用到租约，它都必须和查询服务本身之间有租约存在，且必须定期更新。

服务部份

Jini技术的基础架构以及设计模型是共同用来在网络环境中提供以及找寻服务，而这些服务则是利用基础架构来和其他服务进行沟通，或是找寻对方，以及告知其他服务及用户自己的状态。这些服务都是以Java程序语言所设计出来的对象形式存在，也有可能是使用其他对象所组成。一个典型的服务会提供一个接口，其中定义了该服务对外所能执行的运作，其中部份的接口可能是程序本身会使用到，也有一部份可能是由客户端来执行，以达到服务和用户之间沟通的目的。以下是一个Jini服务所包含的内容范例：

1.一个打印服务，可以由Java或传统的应用程序执行打印的工作。

2.一个JavaSpace服务，这项服务是用来针对相关的Java对象，做简单的沟通以及储存数据之用。

3.一个交易管理程序，这个管理程序可以让一群对象共同在Jini交易协议的环境中运作。

服务架构(Service Architecture)

服务形成了Jini系统中的沟通基础，同时也是程序设计也是用户的接口。关于服务的架构，最好是透过以下的Jini发觉以及查询协议来进行了解。

发觉以及查询协议

Jini系统的核心部份，是由发觉、加入以及查询三个协议共同组成，其中发觉和加入协议是发生在设备要加入系统的时候。所谓的发觉动作，是当一个服务需要寻找欲登记的查询服务时发生，而加入动作则是当查询服务找到了以后所发生的行为。此外，查询动作则是发生在当用户需要符合某个接口型态的服务时发生。以下的运作步骤一(图一)描述了发觉步骤的运作。

《图一 服务提供商透过广播的方式寻找查询服务》

所谓的发觉以及加入运作，是将服务加入Jini系统的一个过程。而所谓服务的提供者，就是一个服务的起始点，如某个设备或是某个软件程序。首先，服务提供商会先在局域网络上广播一个请求，为的是找寻查询服务的所在(如步骤一所示)。接着，相对于该服务的伺服对象便会被加载查询服务之中(就是步骤二(图二)的「加入」动作)。这个伺服对象包含了相对于该服务的Java程序语言接口，其中包括了用户以及应用程序可以使用的方法，并伴随着其他叙述性的属性，藉以执行该项服务。此外，所有的服务，都必须有能力找到查询服务。不过，一个服务也可以将这样的事情委托给其他的服务来执行。无论如何，此时该服务就应该可以被其他人查询到，并且提供他人使用，如步骤三(图三)所示。在这样的情形下，客户端是根据服务的型态来定位该服务，也就是说，利用该服务所提供的Java定义接口，并伴随着查询服务所提供的其他叙述性属性来决定。到了这里，该伺服对象便可以加载客户端以供执行。最后的一个步骤则是启动该项服务，如步骤四(图四)所示。

《图二 服务提供商将伺服对象以及服务属性登记在查询服务中》

《图三 客户端根据型态以及其他属性发出请求藉此取得一份相对应的伺服对象》

《图四 客户端透过伺服对象直接和服务提供商进行沟通》

这样的伺服对象所内含的方法，其使用的通讯协议是可以自行定义的，因为所有通讯只在服务提供商及客户端之间沟通。所以，提供相同接口的服务也可以使用完全不同的交谈协议。

这种允许服务提供商透过查询服务，将伺服对象的程序代码传递给客户端的模式，提供了服务提供商绝大的弹性来设计自己的沟通模式。很熟悉吗？没错，这和目前applet由服务器传递到客户端浏览器的模式的确有几分神似。而这种移动程序代码的特性也可以确保伺服端所提供的服务可以正常的运作。因为在客户端所执行的程序代码就相当于伺服对象的代理人一般。客户端只需要了解到自身所使用的是由Java所撰写的接口实作即可，所以接口的实作部份可以是任何服务所需要执行的工作。且由于程序代码是由服务本身所致做出来的，因此程序代码本身可以善用这样的特性来予以发挥。

后记

本文介绍了在一个Jini系统中，服务是如何透过查询服务来对外公开，同时也说明了客户端如何透过查询服务来取得特定服务的伺服对象供本身使用。而其间所使用的方法，就如同Java applet的特性一般，把伺服对象的程序代码由服务的提供者传递到客户端本身，来做到所谓的服务代理人角色。这样的模式，不但可以简化主从式架构的设计，同时也可以因为伺服对象是由服务本身所撰写的原因，实作出更为复杂的沟通协议，藉以提供更强大且复杂的服务内涵。