Java 版 (精华区)

发信人: rhine (静&&凉爽&&想念你), 信区: Java
标  题: jini核心技术4
发信站: 哈工大紫丁香 (2000年07月17日11:05:08 星期一), 站内信件

第4章   部 署 方 案
主要内容：
* 什么是Jini服务。
* 在桌面计算机和通用计算机上使用Jini。
* 在支持Java的设备上运行Jini。
* 使用Jini互连遗留的服务以及设备。
本章将完成对Jini技术的概括介绍，其主要内容是介绍对设备和服务部署与使用Jini的
通常方法， Jini模型的设计可适用于十分广泛的环境，可以是运行了Java虚拟机的通用
计算机，也可以是像电灯开关一样只有一位I/O而没有什么计算能力的简单设备。
4.1   成为Jini服务
我们已经大致知道了Jini是什么，那么"运用"Jini意味着什么呢？希望通过Jini结构进
行互操作的设备或者软件至少应该需要什么呢？
所需的内容非常少，下面看一下希望在Jini结构中可用的设备或服务需要做些什么。对
于希望在Jini中可用服务、设备或其他的软件，需要完成以下工作：
* 可以连接到TCP/IP网络，意味着设备或服务（或其他软件）要有一个IP地址并且配置
了TCP协议栈，可以发送和接收组播的消息。
* 参与到发现过程中，以找到至少一个查找服务。几乎所有的服务都使用组播发现，较
好的服务允许配置一组固定的查找服务通过单播发现连接。
* 通过提供一个代理对象在查找服务中注册，以使客户端可以下载，从而使用该服务。
此代理对象可以要回调后端处理器或设备，也可以自己实现全部服务功能。
* 保证其查找注册的租借能在服务可用时被续订。
实体必须做的至少是保证在一个查找服务中发布代理对象，以使其他实体可访问自己提
供的服务。而以上所列的任务可由实现服务的实体完成，也可以由其他软件代表实体来
完成。
以上列出的各条是参与到Jini中所必需的，服务的功能当然要在此基础上扩充以实现更
好的行为。例如，服务可以管理在生命周期中发现或丢弃的查找服务，可以管理自己的
事件注册和租借。不过代理发布机制是Jini的核心，其他内容只是可支持部分。
我已经多次提到，其他软件可以控制设备或服务，代表它参与到Jini群体中，这种使用
第三方的办法，是Jini能够控制像电灯开关和温度计这类没有嵌入JVM的设备以及遗留软
件服务的关键所在。
让我们看看Jini服务的使用者需要做到的：
* 服务的使用者（本身可能是服务，也可能不是）需要能使用发现过程找到一个或多个
查找服务。几乎所有使用者都要使用组播发现过程。在有些情况下，使用者针对特定的
查找服务需要有专门的URL，以使用单播发现协议直接连到该服务。
* 服务的使用者必须取到它希望使用的服务的代理对象。这个代理可以是"纯"RMI存根，
或"灵活的"代理，或非远程的序列化对象。使用者可以通过查寻在查找服务中注册的属
性或要使用的接口来找到代理，或者是在知道服务标识号的情况下直接根据ID号来查找
。
* 如果不能找到需要的服务，使用者希望能接收到相应查找服务的通告，以便在所需服
务注册到群体时能被通知到。这个功能是可选的，但Jini强力推荐。
这些同样十分简单，在找到服务代理之后，代理就自动被下载到客户端，客户程序就可
以像使用在编译时找到的类一样使用它了。
最简单的Jini服务和服务使用者不必理解远程事件或事务，对租借也只要很少的支持（
可简单地自动完成），不过它们必须能够使用发现协议并与查找服务交互操作。
4.2   如何为设备和服务使用Jini
接下来，将讨论一些使设备或网络中的服务参与到Jini中的通常方案。前面已提到，Ji
ni的设计支持十分广泛的硬件平台，可以把价格不一的各种设备（从少于1美元的设备到
超过百万的设备）集中到一起。
在决定使自己的产品支持Jini之前，理解各种可选的方案十分重要，因为对应每种选择
、功能和价格也各不相同。一般说来，有三种常见的部署方案可供选择，大多数情况下
总有一种方案与设备和服务类型最相适应。这些可选的方案是：
* 在通用计算机上使用Jini。这里"通用"的意思是，机器有自己的网络连接，有足够的
计算能力运行完整的Java虚拟机，并且倾向于长时间存在并连接到网络。
* 在有嵌入JVM的设备上使用Jini。这些设备与通用计算机不同，其计算能力要差许多（
通常也比较便宜）；并且只是偶尔连接到网络，网络带宽也要小得多。另外，这些设备
只能够运行一部分Java，一般是嵌入式Java（eJava）或个人Java（pJava）（见工具条
"Java变种"） 。
* 使用Jini控制无JVM的设备。在这种情况下，一个共享的支持Jini的计算机被用来控制
一组计算能力很有限，或干脆没有计算能力，但有少量I/O能力的设备。这种方案适用于
控制家庭中的开关这类情形，每个开关通过一位I/O"端口"（通常连出一条线）连到一个
集中的支持Jini的计算机，计算机负责处理开关间的通信，并将各开关作为Jini服务公
开。注意这里集中式计算机不需太强的计算能力，它可以像普通的墙式调温器一样简单
和小巧，或者是一个普通的桌面PC。
接下来将分别介绍一下各种方案，并分析一下各自的长处和弱点。
4.3   在通用计算机上运行Jini
尽管许多媒体都把报道重点集中于其连接小设备的能力上，其实Jini运行在通用计算机
上时同样十分优秀，在通用计算机上可以运行任意数量的服务，而Jini负责将这些服务
发布给Jini群体中的其他成员。例如，每个桌面PC都有磁盘，完全可以把这些存储空间
向其他设备公开，如数字相机（存储照片）、蜂窝式电话（备份电话号码簿）、应答设
备（提供更长的消息存储）、VCR（使视频直接数字化地存到硬盘）等。存储服务可直接
运行在PC上，使PC的硬盘对于参与到Jini中的任意服务都可访问。
更进一步，Jini可运行在大的服务器上，提供一种管理企业数据的便利、健壮的方式。
在企业中使用Jini，可使公司的网络更加可靠，面对网络故障有更大的弹性，而且还能
减少管理的时间。可以考虑这样一个Jini服务，它从企业上网的机器上收集统计数据，
因为它可以在很多查找服务上都冗余可用，所以十分可靠，这是系统管理必须的属性，
因为一般情况我们总希望网络诊断工具最后崩溃。这个服务还可能提供一个用户界面，
支持在任何带显示器的设备中查看统计数据；另外还可以轻松插到其他服务中，在磁盘
满或机器崩溃时通过通信服务发E-mail或呼叫信息。
通用计算机的这些特性使其特别适合于运行需要长时间连到网络的服务（包括"本地"的
Jini服务，如查找服务）的主机，而且价格性能比也较好。因为多个服务可运行在一台
计算机上。另外，因为可在最终要配置的机器上开发服务，它们还提供了方便的开发平
台。
另外，具有完整的JVM将带来很多好处。运行在这样的平台上的服务，可利用RMI与其被
下载到客户端的服务代理进行通信。另外，可利用RMI向服务器上载新的程序，使运行在
服务器上的服务得到及时的维护和升级。如果使用Java数据库连接（JDBC）软件，这些
服务还可以连接到公司的数据库。通过提供完整的JVM和完整的Java类库，可以保证所有
下载的代码都能够运行，而在使用Java的子集如eJava或pJava时，就不能提供这样的保
证。
图4-1的例子表示一个运行在通用计算机上的Jini服务使用RMI与其已嵌入客户端的服务
代理进行通信。注意在这个模型中，RMI、Jini和JDBC被表示为JVM之上平等的类库，这
些服务可以彼此使用。
显然这种方案的缺点是需要通用计算机。不过在很多情况下，使用通用计算机十分方便
，并不会增加负担。如果有可用的通用桌面计算机或服务器，在这样的机器上运行Jini
服务是十分理想的。
工具条：Java变种
被工业界承认的Java子集主要有两个，分别被称为个人Java（pJava）和嵌入式Java（e
Java），二者都是完整Java的精简版本，它们和完整的Java运行相同的字节码，具有相
同的语义，只是大量精减了可用的类库。
个人Java主要用于具有界面的可编程设备，比如蜂窝式电话和PDA等。这些设备一般可下
载Applet代码，至少具有AWT，有时也有支持用户界面的Java基本类。pJava去掉的最主
要的内容就是面向"企业"的API、数据连通性、CORBA通信（有时还有RMI）。在本书编写
过程中，pJava还只是基于JDK 1.1，而不是Java 2，因此缺少一些Jini中Java 2的RMI实
现的特征。Sun公司承诺在1999年把pJava升级到支持Java 2。
如果pJava被升级为可支持Java 2，那么pJava肯定是在Jini环境中最受欢迎的Java子集
，pJava平台与完整Java十分相近，而且工作于Jini的pJava设备当然支持RMI。
对于嵌入式Java设备，限制更加严格，所幸在Jini环境中eJava并不多见。嵌入式Java是
Java和个人Java更有限的子集，它使许多用户界面类都变为可选，还包括许多网络类（
显然，在参与到Jini的eJava设备中应该有这些内容）。这些设备可直接在ROM之外运行
Java字节码，而且许多不支持下载代码（尽管Jini环境中的eJava设备必须支持下载代码
）。一般说来，具有网络支持和下载并运行新程序能力的eJava设备，可以使用Jini服务
代理，但是那些具有用户界面构件的除外。
当然，如果有其他的软件作为代表使之在Jini中可见，eJava设备能彻底地参与到Jini中
。
图4-1   在通用计算机上使用Jini
4.4   在支持Java的设备上运行Jini
随着越来越多的设备支持Java，把Jini部署在具有嵌入式JVM的小设备上的做法也越来越
普遍。渐渐地，像蜂窝式电话、PDA、打印机、扫描仪和相机这样的设备都有了自己的J
VM。在很多方面，这种方案和上一种方案没有明显的区别，在两种方案中，设备都可连
接到网络，可执行自己包含的Java程序，而且通常要从网络上下载并运行Java字节码。

但在小设备上运行Jini和在通用计算机上运行Jini还是有些明显的差别。
* 小设备一般只运行全部Java平台的一部分。
* 小设备只是间或地连接到网络上。
* 小设备与通用计算机相比其计算能力和网络带宽一般都要低许多。
这几点中，只有第一点真正是个问题。尽管不希望运行Jini查找服务的设备不在网络上
的时间比在网络上的时间还长，或者是设备的计算能力十分有限，但你一般也不会只在
网络上运行一个查找服务，并将其运行在烤箱或微波炉上。
4.4.1   Jini和Java子集
对于小设备来说，应付不同版本的Java是个很大的问题。这样的设备由于通常比较便宜
，因此也只有全部Java平台的一个小子集可用。通常只有很有限的显示用户界面的能力
，在有些情况下，它们甚至根本就没有显示界面的能力。
考虑一下Jini工作的过程就会发现问题所在，Jini的核心就是服务具有把自己的一部分
，即服务代理嵌入到客户端的能力。在编写服务代理时，开发者必须清楚客户端的平台
上有哪些类库可用。例如若服务代理使用JFC，则开发者就假定了在运行代理的所有平台
上JFC都可用。但这种假定对于采用了更加有限的Java环境的Jini服务使用者来说并不一
定成立。
前面提到的两种主要的Java子集，即个人Java（pJava）和嵌入式Java（ejava），相对
于完整的Java，其可用类库都十分有限，因此某些服务代理运行在这样的环境时，可能
就会出问题。
更有限的Java环境
前面提到的问题主要原因在于使用能力有限的Java设备作为Jini服务的使用者，你可能
认为如果使用有限Java的设备只发布服务就可以了。不过要注意的是，服务提供者本身
也是查找服务的使用者，查找服务把自己的服务代理下载到服务提供者，因此至少pJav
a和eJava的设备要能够下载并运行查找服务的服务代理。
但还有其他选择，即使不下载程序，运行JVM一定子集的设备也可以工作于Jini。这种设
备将"硬编码"发现协议，并带有可与特定Jini查找服务交互的程序。不过这种设备将更
加受限制，在期望的环境外根本无法工作。如果查找服务的实现被改变（如厂家的兼并
，导致改用不同的协议与查找用户通信以提供更快的服务），设备也无法工作。
对这类设备比较好些的实现策略是定制针对自己实现的查找服务，此查找服务只拥有用
于此设备的代理。这将限制设备与Jini群体中其他部分的互操作，它只能为定制的查找
服务提供代理，客户端也只能从此查找服务取得设备的代理。
这种方案的好处就是可大大减少此设备所需的JVM内容和类库。因为没有下载代码，因此
也不需要字节码验证工具或安全管理程序，设备上的类库与参与到发现和查找需要的类
库相比也小得多。
此类设备将只能发布Jini服务，而不能使用Jini服务，因为使用Jini服务必须能下载其
代理。这种折衷是十分严重的，因此这种方法只在特定的环境中可用。
4.4.2   版本问题
eJava和pJava问题只是一个通用问题的缩影，这个问题就是如何保证主机平台的Java版
本与服务代理所期望的版本保持兼容。解决办法是达成一组协定，允许服务代理存储一
个属性用于指明它所需的最低Java功能，这个属性应该有所需类库、JVM版本等信息。在
试图使用一个服务代理前，使用者应检查服务的属性以确定是否可运行。
在编写本书时，Jini群体仍没有标准化这类属性。不过要想使开发的服务能用在尽可能
多的主机平台，还是有些步骤要注意。最重要的是，开发者要限制代理对象对主机平台
的依赖，这意味着代理对类库的明显依赖不要到处都是。如果服务可被分为多个功能块
，有些只依赖于核心库，其他依赖于不太常用的库，那么特殊的功能部分常可作为属性
附加到服务上。通过把有疑问的代码放置在代理之外，可以保证客户端一般都能下载并
使用服务代理。其他代码，如用户界面，可集中起来单独发送，允许客户端选择使用。

4.5   Jini使用设备代理
第三种方案会被大量设备采用，包括打印机、扫描仪以及连到主计算机上的其他设备，
还包括像家庭中的开关一样的微型设备。
在这种方案中，一个可运行JVM的机器物理上与一个或多个设备连接，这个机器作为Jin
i代理代表着这些设备运行，它可以参与到查找和发现协议中，处理其服务代理，并为设
备管理租借情况。运行JVM的机器和设备之间的连接通常不是普通网线，而是RS-232、U
SB、火线、或者X10"家庭自动化"等 。
运行JVM的机器可能是运行完整的Java （如前所述通用计算机的方案），或者是只运行
Java 的子集如eJava和pJava；这个机器实际上可能是通用计算机，如某人的PC，也可能
只是特别的Jini控制设备，比如可以把一个Jini控制器插入到音响设备中，使CD和DVD播
放机、调谐器、VCR以及电视机都可参与到家庭Jini群体中。更小的控制器设备可能只是
像墙挂式调温器一样，但可以提供Jini服务代表家庭中的报警系统、电灯开关、门锁等
功能。不管控制器形状如何，只要设备连接到控制器，就完全可以参与到家中的Jini群
体了。
比较简洁的方案是把代理应用运行在PC上，此应用程序的启动发生在引导机器、Window
s系统的即插即用数据库检查是否添加了新的硬件时。若是加入了可识别的设备，如打印
机或扫描仪，代理就发布这些设备相应的服务，使它们在网络上可用。在图4-2所示的例
子中，几个设备共享一个作为它们的Jini代理的JVM。
图4-2   多个设备共享Jini代理
这种方案有明显的优势。首先，它使"遗留的"硬件可参与到Jini中，现实生活中有大量
的打印机、扫描仪和其他旧设备不能运行Java，但只要在主机上安装一点软件，这些设
备就可以连入Jini世界了。甚至还有人想做Jini"转接"设备，连在主计算机和打印机之
间，使打印机可访问Jini。
其次，代理的方案使得十分便宜的设备也可以接入Jini群体中。如果必须使用嵌入了JV
M并有8M内存的开关，结果肯定是没有多少人能买得起；而如果大量的便宜设备可共享一
个Jini主机，并且与使用JVM的设备没有什么差别，那么就可以在家庭中使用越来越多的
廉价Jini设备了。
4.6   基本Jini服务的需求
前面各节讨论了运行Jini服务和服务使用者对平台的要求，但对于Jini结构的一些核心
内容，又有什么需求呢？我们知道Jini结构的许多关键部分就是Jini服务本身，运行这
些服务需要一定的条件。
Jini为自身的服务定义了接口，而非实现；因此Jini服务的实现不同，需求也不同了。
例如，一个查找服务可能建立在完整的商业数据库基础上，需要JDBC的支持；而另一个
查找服务可能要使用内存中的hash表。尽管我们不能统一确定这些基本服务到底需要什
么样的实现，但可以讨论所需的最少功能，这是构件接口所需的功能需要。
虽然Jini把两种服务定义为最基本的服务：查找服务和事务管理器，但查找服务相对更
加重要。除开特殊的事务管理器带来的一些特殊要求，查找服务可在任意环境中运行，
其情形和前面讨论的"普通"服务相同。
Sun目前提供的查找服务的参考实现，实际上是基于运行Java的通用计算机。但更精简的
查找服务完全可运行在功能低得多的平台。尽管你可能仍希望在服务器计算机上运行查
找服务以减少停机时间，但你完全可以简化查找服务使其不再基于Java。
最简单的查找服务对主机平台的基本需求是要求平台支持基于套接字的IP组播的网络传
输，发现协议使用此协议寻找查找服务，而查找服务可以响应。查找服务给出的响应是
一个序列化的Java对象，即客户端可用来连回查找服务的服务代理。这个对象可在运行
Java的机器上进行"预先序列化"，查找服务本身就没有必要运行序列化了。当这个预先
序列化了的对象被放置到查找客户端时，它可以使用任意协议，按需要的传输方式回调
查找服务。
作为Jini的"自引导"服务，查找服务对平台的需求很低，只要对连网的设备稍作扩充即
可。
4.7   适于使用Jini的情况
我们已经知道了一些使设备和服务参与到Jini中的常见方案，接下来从技术或市场的角
度来看一下，在哪些情形下使用Jini比较合适。可以归结为以下几种情况：
* 如果有了Jini服务（或计划中的），设备或软件服务会通过使用这些服务变得更加有
用，此时使用Jini比较合适。例如假设你出售扫描仪，你发现一些小的Jini软件服务可
提供图像到E-mail或图像到传真的网关，扫描仪可方便地使用这些服务增强自身功能，
使它看起来可以直接扫描e-mail消息或传真。通过使用Jini，你从创建这些服务的开发
者那里获益，或者从根本上说，你使那些开发者成为了你自己的开发者。
* 如果设备可使已有的其他Jini服务（或计划中的）增值，选用Jini比较合适。例如，
假设你在市场上出售打印机，同时你看到有数字相机进入了市场，选用Jini就可以使打
印机设备方便地成为数字像片的输出设备。
* 如果设备已有了嵌入式JVM，或一般是连接到通用计算机上，那么加入Jini应该是不必
犹豫的。一旦设备支持Java或连到计算机，支持Jini所需的其他工作就很少了，但潜在
的好处十分巨大。
* 如果软件服务运行在可运行Java虚拟机的通用计算机上，那么可以方便地为服务创建
一个Jini外壳使之在Jini中可用。这是Jini的一大好处：可以方便地编写小的粘合逻辑
（glue logic），使整个软件服务（甚至非Java的服务）对于其他的Jini设备和服务都
是可访问的。
* 如果软件服务可以方便地被分解为固定的多个部分，那么把各部分表示成一个Jini服
务是比较合理的。例如，企业级的文档管理系统可能具有文档存储仓库、文档服务引擎
、查询引擎等多个组成部分，通过为各个部分创建单独的Jini服务，可以获得很多好处
。首先，可以按需要把各部分方便地转移到其他机器。其次，系统具有了冗余特性，在
需要某个服务的备份时，只要再复制运行一份即可。第三，由于体系结构开放，使扩展
变得十分容易。
* 如果要创建一个通常要连到其他设备的设备，那么Jini可能是用于控制这些连接的可
用技术。例如，一组音响设备的各组成部分通常要用数据线进行连接，如果使用Jini是
前置放大器知道哪些设备是必需的、输入的各级是如何连接的，并能正确地配置各种控
制，岂不是很好？
* 最后，如果设备具有编程能力的好处，Jini也是比较好的方案。因为Jini支持程序下
载，可编程的设备在Jini中就可得到及时更新。更妙的是，它们可自动控制其Jini群体
中的其他设备，例如对于一个集中的MIDI控制面板，当有鼓设备被加入时，面板中可自
动增加一个控制鼓设备的用户界面。
随着越来越多的设备和计算机支持Java，越来越多的设备和软件系统彼此相连，Jini将
成为管理这些连通性的更符合逻辑的方案。而且，如果设备已支持Java或已连到通用计
算机系统，添加Jini只是小事一桩，这将大大鼓舞要采用Jini的用户。
4.8   不适于使用Jini的情况
因为Jini的设计可覆盖十分广泛的部署方案，包括从服务器到电灯开关的多种设备，因
此很少有Jini不适用的硬件环境，但也有一些因素会导致为设备添加Jini在价格上不合
算。
* 首先，如果设备确实是独立的，即没有连线连接设备，或者设备在网络上但根本不会
有其他实体会使用它，则Jini不太适用。但现在越来越少的设备是真正独立的了，这样
的设备令人无法忍受。
* 如果设备附近没有具有JVM的设备，而且此设备十分便宜不能嵌入JVM，则Jini不是可
选的方案。在设备参与到Jini的过程中，必须有Java的存在。
4.9   参考读物
如果你是家庭视听设备的发烧友，那么可以查看一下家庭视听互操作（HAVi）的Web站点
，这个是一些试图推出某些有意义标准的大A/V厂商的论坛。HAVi设备通过火线（FireW
ire）彼此连接。火线是一种高速的串行连接方式，也被标准委员会确定为IEEE 1394，
被Sony公司称为i.LINK，通过它不仅可传输控制信息，也可以在设备之间传送数字的音
频和视频内容。
Sun和HAVi厂商最近同意把Jini集成到HAVi技术中，因此很快就会看到使用和提供Jini服
务的"即插即用"的视听设备。
http://www.havi.org
4.10   后面的内容
本章结束了对Jini技术全面的概述，在下一部分将开始创建真正的Jini服务，并从深层
次分析一下Jini的核心技术。

--
           海纳百川，
                   有容乃大，
                           壁立千尺，
                                   无欲则刚。    

※ 来源:·哈工大紫丁香 bbs.hit.edu.cn·[FROM: dip.hit.edu.cn]