|
|
为RMI实现类Jini的发现机制
--使RMI开发从Jini的发现机制中得益
摘要
还没赶Jini的时髦吗？尽管Jini的机制十分强大，但它还没被Java开发的主流所接受。在这之前，开发者需要找到更好的远程方法调用（RMI）解决方案。这篇文章引导你为你的RMI开发实现一个类Jini的发现机制。(2,800 words; November 21, 2001)
作者 Philip Bishop and Nigel Warren
翻译 FooSleeper
原文来自JavaWorld，见http://www.javaworld.com/javaworld/jw-11-2001/jw-1121-jinirmi_p.html
如果你从事过Jini开发，你会知道Jini客户端是不需要知道服务的位置的；它们简单地通过发现机制来获得一个代理以访问它们需要的服务。相反，在RMI（远程方法调用）中，你必须知道你想访问的服务器的URL。在本文中，我们将向你展示怎样为RMI实现一个类Jini的发现机制，这将使得一些客户端从必须知道RMI服务器URL的麻烦中解脱出来。
你可能首先会想，为什么要这么麻烦；为什么不干脆用Jini？我们也同意这样的逻辑，特别是对新的系统来说。不管怎样，已经有许多基于RMI的系统存在，并且在Jini被Java开发的主流接受以前，我们仍然要提供更优雅的RMI解决方案。事实上，我们在这儿描述的工作，是这样的需求的结果：开发一项Jini服务使它同时可以作为一个独立的RMI服务器运行，但使用类Jini的发现机制。
本文主要是针对没有用过Jini的RMI开发者。通过深入观察Jini内部的运作，我们希望你能开始了解Jini的机制有多么强大。我们当然不是希望你重新实现Jini，但这篇文章能帮助你理解这些机制是怎样运作的。甚至可能帮助你说服你的经理或部门头头，该考虑将Jini作为一项可行的分布式系统技术。
我们不会太深入Jini的发现机制，所以如果你对此不是很熟悉，我们建议你快速浏览一下Bill Venners的"Locate Services with the Jini Lookup Service."（ http://www.javaworld.com/javaworld/jw-02-2000/jw-02-jiniology.html）
RMI基础和Jini查找
在RMI中，客户端必须知道它所要连接的服务器的位置。RMI服务器的地址是URI的形式rmi://<主机>:<端口>/<服务名>，其中端口号是rmiregistry用来侦听请求的端口。例如：
Translator service
=(Translator)Naming.lookup("rmi://theHost/SpanishTranslator");
在Jini中，客户端通过一个Jini工具类来找到服务，比如ServiceDiscoveryManager。在下面的例子中，我们创建了一个ServiceTemplate的实例，该实例包含一个类列表；在我们的例子中，是我们要匹配的类——Translator.class：
Class [] classes=new Class[]{Translator.class};
ServiceTemplate tmpl=new ServiceTemplate(null,classes,null);
ServiceDiscoveryManager lmgr=new ServiceDiscoveryManager(null,null);
ServiceItem serviceItem =lmgr.lookup(tmpl,null);
Translator service=serviceItem.service;
正如我们从例子中可以看到，ServiceDiscoveryManager用lookup()方法来查找任何与ServiceTemplate匹配的可用的服务。你还可以在服务查找中使用任何数字或属性；在这里我们出于保持简单和精练的考虑而没有这样做。
比较两种查找机制，你会注意到在Jini版本中没有指定服务的位置。值得一提的是，如果必要，你也可以指定一个查找服务的位置，但不是你想要访问的实际服务的位置。Jini模型的强大之处是，我们不需要知道或关心服务位于何处。
比较了RMI和Jini的发现机制之后，现在我们可以考虑怎样用类Jini的风格来访问一个RMI服务器。
位置中立的RMI查找
理想地，我们考虑查找Translator所发现的第一个匹配的实例。
Translator service
=(Translator)RMIDiscovery.lookup(clazz,id);
在这里clazz是RMI服务的接口，id是区分实现clazz接口的不同服务器实例的唯一字符串标识。例如，要找到一个西班牙语翻译器，我们用下面的代码：
Class clazz=Translator.class;
String id="Spanish";
现在我们对如何使用RMI发现机制有了一个更好的主意，我们来研究一下怎样实现它。在我们尝试实现我们“简陋的”RMI发现机制以前，先来看看Jini是怎样做的，再把这些原理/概念适用到RMI服务器和客户端上。
发现机制
Jini的基本发现机制联合使用多播UDP（用户数据报协议）（multicast UDP 见文后的Resources）和单播TCP/IP。简单来说，这意味着客户端发出一个多播的请求数据包，然后数据包被监听它的查找服务拾取。然后查找服务用单播连接连回客户端，并把查找服务的代理串行化成流通过此连接发送出去。此后客户端就可以和查找服务（的代理）交互以定位它需要的服务。图1图示了这个过程。
图1 Jini多播发现
发现机制实际上比这要复杂得多，但我们只对其中多播UDP和单播TCP/IP的关键概念感兴趣。
我们并不打算实现一个等同的独立运行的RMI查找服务。相反我们将实现一个简单的多播监听器/单播分发器（multicast listener/unicast dispatcher）供RMI服务器使用，实际上我们使得每个RMI服务器作为它自己的查找服务。在客户端，我们为服务器端socket写个配对物——一个多播分发器/单播监听器（multicast dispatcher/unicast listener）。也就是说图1中的两部分成了RMI客户端和RMI服务器端，如下面的图2所示。
图2 RMI多播发现
下面的表更详细地说明了RMI客户端和RMI服务器端间的交互。
RMI客户端和RMI服务器端的交互
服务器端 客户端
在多播地址上开始监听
建立ServerSocket以监听来自服务器的单播响应。
开始向多播地址发送UDP数据包
解析收到的UDP数据包。如果有效，通
过单播TCP/IP连回客户端。
向客户端发送远程代理（remote stub）。
从流中读取远程对象。
关闭ServerSocket。停止发送UDP多播数据包
开始使用服务。
发现协议
前面我们已经大致勾勒了客户端怎样发现服务器：它会指定一个接口类和一个唯一名字来确认一个服务器实例。这是因为多个实现相同接口的服务器可以同时运行。
在实现我们的RMI发现机制之前，我们必须为在参与者之间传递的消息定义一个协议。简单起见，我们用含定界符的字符串来包含RMI服务器对匹配的请求作出响应所需的全部信息。首先，我们定义一个协议头。这防止了服务器类尝试解析其他来源的数据包。消息数据包的剩余部分将包含一个单播响应端口，服务器的接口类名字，和服务器实例的唯一标识符。
下面是我们将使用的发现请求消息的格式：
<protocol>,<unicast port>,<interface class>,<unique id>
现在我们看看一个消息数据包的例子，这个数据包是客户端发送来发现Translator服务器的Spanish实例的。RMI-DISCOVERY是协议头。5000是客户端将监听响应的端口号：
RMI-DISCOVERY,5000,Translator,Spanish
我们没有在请求中包括客户机的名字，因为这个信息可以从服务器收到的UDP包中获得。定义了我们的消息格式，现在我们可以开始实现发现类了。
实现服务器端的类
我们的美好计划是写一个工具类，好让RMI服务器用它来实现它们自己的查找服务：
//初始化RMI服务器
Remote server=new SpanishTranslator();
//初始化发现监听器
RMILookup.bind(server,"Spanish")
Remote参数用于检查服务器是否是实现了客户端所要访问的接口，和哪一个RMI stub将最终被串行化返回给客户端。String参数用于比较服务器的名字和请求包中指定的名字。
在继续之前，我们扼要重述一下服务器端的类的职责：
1. 建立一个多播UDP socket以监听请求
2. 当数据包到达时检查协议头
3. 解析消息数据包
4. 匹配唯一服务器名字参数
5. 匹配接口参数
6. 如果步骤4和5匹配，将服务器的远程代理（remote stub）通过单播TCP/IP socket串行化到客户端
建立多播UDP监听器
要建立一个多播监听器，你必须使用一个确定的多播地址和端口；它的范围在224.0.0.1到239.255.255.255之间（包括224.0.0.1和239.255.255.255）。有些厂商保留了一些地址/端口的联合；例如，Sun为Jini保留了联合224.0.1.85:4160。（被保留地址的列表可以在http://www.iana.org/assignments/multicast-addresses找到。）不推荐在和别的厂商相同的地址/端口联合上运行，所以我们选择了和MulticastSocket Javadoc（见文后Resources）例子相同的联合：
int port=6789;
String multicastAddress="228.5.6.7";
MulticastSocket socket=new MulticastSocket(port);
InetAddress address=InetAddress.getByName(multicastAddress);
socket.joinGroup(address);
byte[] buf = new byte[512];
DatagramPacket packet=new DatagramPacket(buf, buf.length);
socket.receive(packet);
//parse packet etc
socket.leaveGroup(address);
从上面的例子可以看出，你要建立一个多播监听器并在此地址/端口联合上接收数据包有多么简单。在上面的例子中，只能处理单个数据包，所以我们必须在创建DatagramPacket和socket.receive()处建立循环；否则只有一个客户端能够发现这个服务器。
while(active){
byte[] buf=new byte[512];
DatagramPacket packet=new DatagramPacket(buf,buf.length);
socket.receive(packet);
//process packet
}
我们可以用一些策略来处理收到的数据包：
1. 每请求线程：为每个请求创建一个新的线程来处理
2. 来自线程池的线程：使用来自（可能固定的）资源线程池的预初始化的一个线程(见 "Java Tip 78: Recycle Broken Objects in Resource Pools，http://www.javaworld.com/javaworld/javatips/jw-javatip78.html")
3. 阻塞：在同一时间只处理一个请求，其他请求必须等待
由于我们从客户端发起一次发现，自然地，阻塞策略在这里是可行的。这是因为我们的客户端会以一定时间间隔持续发送发现消息，直到服务被定位或者请求失败达到了预定的次数——后面再详述。
检查协议头
收到一个数据包后，我们接着检查所包含的消息是否我们想要的。要完成这项工作，我们用startsWith()方法将byte []转换成String。虽然我们将协议头RMI-DISCOVERY硬编码到了下面的例子中，不过在实际的源码中它是作为一个常量来存取的。
String msg=new String(packet.getData()).trim();
boolean validPacket=msg.startsWith("RMI-DISCOVERY");
解析消息
假设我们得到一个有效的数据包，我们可以从中解析出消息来。由于消息是用定界符划分的，我们可以用StringTokenizer来分开它：
private String [] parseMsg(String msg,String delim){
//符合格式的请求
//<header><delim><port><delim><interface><delim><serviceName>
StringTokenizer tok=
new StringTokenizer(msg,delim);
tok.nextToken(); //protocol header
String [] strArray=new String[3];
strArray[0]=tok.nextToken();//回复端口
strArray[1]=tok.nextToken();//接口名
strArray[2]=tok.nextToken();//服务名
return strArray;
}
我们将消息数据包转换成了参数以后，就可以对照服务器的名字检查接口名和唯一服务器名。
匹配接口和服务器名
要用参数来匹配服务器的唯一名字，你只需简单地比较两个String对象。如果你下载了全部源码（见文后Resources），你可以看到RMILookup类有两个参数：一个指明了它的唯一名字，另一个是Remote对象。
你可以对存储服务器实现的所有接口的整个数组比较接口名字：
//在启动时完成
Class c=_service.getClass();
_serviceInterface=c.getInterfaces();
//进行匹配的部分代码
//interfaceName是请求的一部分
boolean match=false;
for(int i=0;!match && i<_serviceInterface.length;i++){
match=_serviceInterface[i].getName().equals(interfaceName);
}
返回到发现者的单播连接
如果唯一服务器名和接口类都匹配，我们就尝试连回客户端，并把服务器的stub串行化：
//repAddress已从进入的DatagramPacket中获得
//repPort已从消息数据包中解析出来
//_service 是RMI服务器的Remote ref（stub）
Socket sock=new Socket(repAddress,repPort);
ObjectOutputStream oos=new ObjectOutputStream(sock.getOutputStream());
oos.writeObject(new MarshalledObject(_service));
oos.flush();
oos.close();
值得注意的一点的是上面的例子中使用MarshalledObject。如果我们简单地串行化Remote对象到流，在客户端会发生一个ClassNotFoundException，除非客户端已经访问了服务器的stub（在大多数情况下这是糟糕的）。客户端会得到ClassNotFoundException是因为，不同于通过RMI传递对象，codebase会被附加到流中，在这儿我们是透过一个socket使用串行化，不会包含codebase。
MarshalledObject在Java 2中加入，提供了一个方便的途径来传递串行化的对象及其codebase。在内部，MarshalledObject将对象串行化到字节数组，这意味着当MarshalledObject被解串行化时，内部的对象不会解串行化。这对Jini服务，如查找服务，是极其有用的，因为它们不再被迫去下载注册的代理所代表的类。
要访问内部的对象，你要在客户端调用MarshalledObject的get()方法。
实现客户端的类
前面我们说明了RMI客户端怎样通过指定接口类名字和服务器的唯一名字来发现RMI服务器，如下所示：
Class clazz=Translator.class;
String id="Spanish";
Translator service
=(Translator)RMIDiscovery.lookup(clazz,id);
在考虑怎样实现我们的RMIDiscovery类以前，让我们先扼要重述一下它的职责：
1. 监听来自服务器的RMILookup的单播响应
2. 向多播地址发送UDP包
3. 从流中读取远程对象
4. 停止发送多播数据包
5. 停止在单播socket上监听
6. 使用服务器
建立单播TCP/IP监听器
要建立一个单播TCP/IP socket，我们必须选择一个监听的端口。不过，我们不能简单地将一个固定的端口号定义成常量，因为其他进程可能在使用这个端口。我们因此需要指定一个使用的端口号的范围：
private ServerSocket startListener(int port,int range){
ServerSocket listener=null;
for(int i=port;listener==null && i<(port+range+1);i++){
try{
listener =new ServerSocket(i);
}catch(IOException ex){
//端口（可能）已经被使用
//处理违例
}
}
return listener;
}
上面的startListener()方法尝试在指定范围内的一个端口上创建ServerSocket。此方法的调用者可以检查返回值是否为null（null意味着ServerSocket不能被创建）并获得使用的端口。另一个选择是在ServerSocket不能被创建时抛出一个违例：
ServerSocket listener=startListener(START_PORT,RANGE);
if(listener!=null){
int port=listener.getLocalPort();
//format message to include port number格式化消息以包含端口号
//start the multicast message dispatcher 启动多播消息分发器
Socket sock=listener.accept();
//read remote stub from stream 从流中读取remote stub
}
当我们成功地建立了单播监听器，我们就可以格式化消息数据包并启动多播消息分发器。
建立多播UDP分发器
如同多播监听器，我们必须使用一个已知的多播地址/端口联合。我们可以通过System属性或者通过一个常量来获取这项数据：
int port=6789;
String multicastAddress="228.5.6.7";
MulticastSocket socket=new MulticastSocket(port);
InetAddress address=InetAddress.getByName(multicastAddress);
socket.joinGroup(address);
//outMsg是用定界符划分的请求
byte [] buf=outMsg.getBytes();
//循环n次或一直到单播监听器收到响应为止
DatagramPacket packet=new DatagramPacket(buf,
buf.length,address,multicastPort);
socket.send(packet);
//结束循环
socket.leaveGroup(address);
socket.close();
一步一步察看上面的代码，你可以看到当我们配置好MulticastSocket之后，outMsg字符串被转换成一个字节数组以便从socket发送出去。注释说明了然后我们将发送消息预先指定的次数或者直到单播监听器收到响应为止。为了使例子简明，我们从中省略了与单播监听器的线程间的协调工作；你可以下载整个源码（见文后Resources）来看看这是怎样完成的。
读取服务器的stub
前面我们已经看到了怎样建立一个单播ServerSocket。现在我们要看看读取服务器的stub的代码。方法ServerSocket.accept()是阻塞的，所以它不会返回一个Socket对象，除非进入的连接已经完成：
Socket sock=listener.accept();
ObjectInputStream ois=new ObjectInputStream(sock.getInputStream());
MarshalledObject mo=(MarshalledObject)ois.readObject();
sock.close();
//server是一个成员域
server=(Remote)mo.get();
当我们获得了服务器的一个引用，我们接着可以唤醒调用RMIDiscovery.lookup()而被阻塞的线程，它将给客户端返回一个Remote对象。
采用Jini
在这篇文章中，我们向你展示了怎样为普通的RMI客户端和服务器应用一项类似Jini的发现概念的技术。虽然我们建议在新的项目中使用Jini，你还是能够用类似发现的机制来增强现有的RMI系统从而获得好处。
前面说明的RMI发现机制有一些Jini能够克服的局限。例如，多播UDP有受限制的范围，通常是一个子网内。这意味着使用我们的多播机制的客户端不能发现在多播范围以外运行的RMI服务器。然而，Jini有联合查找服务的概念可以“加入”不同的子网以使跨越WAN（广域网）的发现过程对客户端透明。
我们鼓励读者下载全部源码（见文后Resources）来进行试验。用一个RMI服务器为许多在多播范围以外运行的服务器的远程引用做委托或代理，并在其中使用RMILookup工具类，会是一个有趣的试验。
根本来说，Jini是一个更好更优雅的解决方案，所以我们强烈建议还没有体验过Jini的读者尽快体验一下。
最后，要指出的是，一般来说多播UDP在没有连接到集线器的独立的机器上不能工作。使用loopback适配器是可选的方案；不过，我们在基于Windows的机器上使用这种方法时遇到了错误。
Many thanks to Dan Creswell at IntaMission for suggesting the RMI discovery-like solution.
About the author
Philip Bishop is an independent Java consultant specializing in the design and implementation of distributed Java systems.
Nigel Warren is director of technology at IntaMission, creators of IntaSpaces, the evolvable JavaSpace. Nigel Warren and Philip Bishop are coauthors of Java in Practice (Addison Wesley, January 1999; ISBN: 0201360659).
Resources
•Download the source code for this article:
http://www.javaworld.com/javaworld/jw-11-2001/jinirmi/jinirmi.zip
•More material by Philip Bishop and Nigel Warren; plus future code updates for this article:
http://javainpractice.net
•Complete listing of JavaWorld's Jiniology column:
http://www.javaworld.com/columns/jw-jiniology-index.shtml
•"Locate Services with the Jini Lookup Service," Bill Venners (JavaWorld, February 2000):
http://www.javaworld.com/javaworld/jw-02-2000/jw-02-jiniology.html?
•Multicast UDP primer: Core Jini, Second Edition, W. Keith Edwards (Prentice Hall, December 2000; ISBN: 0130894087):
http://www.amazon.com/exec/obidos/ASIN/0130894087/javaworld
•MulticastSocket Javadoc:
http://java.sun.com/j2se/1.4/docs/api/java/net/MulticastSocket.html
•Sun's Jini homepage:
http://java.sun.com/products/jini/index.html
•The Jini Specification:
http://java.sun.com/products/jini/specs/index.html
•Bill Venners maintains a Jini FAQ here:
http://www.artima.com
•The Jini community Website has pointers to all things related to Jini:
http://www.jini.org
•"Jini-Talk with Jim Waldo," Frank Sommers with Bill Venners (JavaWorld, November 21, 2001) is an in-depth interview with Jini's creator:
http://www.javaworld.com/javaworld/jw-11-2001/jw-1121-jiniology.html
•For more articles on RMI, browse our RMI/RMI-IIOP Index:
http://www.javaworld.com/channel_content/jw-rmi-index.shtml
•For more articles on Jini, browse our Jini Index:
http://www.javaworld.com/channel_content/jw-jini-index.shtml
•Subscribe to JavaWorld's free weekly email newsletters:
http://www.idg.net/jw-subscribe
•Speak out in our Java Forum:
http://forums.devworld.com/webx?13@@.ee6b802
•You'll find a wealth of IT-related articles from our sister publications at IDG.net |
|
