为RMI实现类Jini的发现机制

　　如果你从事过Jini开发，你会知道Jini客户端是不需要知道服务的位置的；它们简单地通过发现机制来获得一个代理以访问它们需要的服务。相反，在RMI（远程方法调用）中，你必须知道你想访问的服务器的URL。  在中，我们将向你展示怎样为RMI实现一个类Jini的发现机制，这将使得一些客户端从必须知道RMI服务器URL的麻烦中解脱出来。
主要是针对没有用过Jini的RMI开发者。通过深入观察Jini内部的运作，我们希望你能开始了解Jini的机制有多么强大。我们当然不是希望你重新实现Jini，但这篇文章能帮助你理解这些机制是怎样运作的。甚至可能帮助你说服你的经理或部门头头，该考虑将Jini作为一项可行的分布式系统技术。

在RMI中，客户端必须知道它所要连接的服务器的位置。RMI服务器的地址是URI的形式rmi://:/，其中端口号是rmiregistry用来侦听请求的端口。例如：
=(Translator)Naming.lookup("rmi://theHost/SpanishTranslator");
Class classes=new Class{Translator.class};


Translator service=serviceItem.service;
比较两种查找机制，你会注意到在Jini版本中没有指定服务的位置。值得一提的是，如果必要，你也可以指定一个查找服务的位置，但不是你想要访问的实际服务的位置。Jini模型的强大之处是，我们不需要知道或关心服务位于何处。

理想地，我们考虑查找Translator所发现的第一个匹配的实例。
=(Translator)RMIDiscovery.lookup(clazz,id); 
Class clazz=Translator.class;
现在我们对如何使用RMI发现机制有了一个更好的主意，我们来研究一下怎样实现它。在我们尝试实现我们"简陋的"RMI发现机制以前，先来看看Jini是怎样做的，再把这些原理/概念适用到RMI服务器和客户端上。
发现机制
发现机制实际上比这要复杂得多，但我们只对其中多播UDP和单播TCP/IP的关键概念感兴趣。


服务器端　　　　　　　　客户端
建立ServerSocket以监听来自服务器的单播响应。
解析收到的UDP数据包。如果有效，通过单播TCP/IP连回客户端。 
从流中读取远程对象。
开始使用服务。

前面我们已经大致勾勒了客户端怎样发现服务器：它会指定一个接口类和一个唯一名字来确认一个服务器实例。这是因为多个实现相同接口的服务器可以同时运行。
下面是我们将使用的发现请求消息的格式：
现在我们看看一个消息数据包的例子，这个数据包是客户端发送来发现Translator服务器的Spanish实例的。RMI-DISCOVERY是协议头。5000是客户端将监听响应的端口号：
我们没有在请求中包括客户机的名字，因为这个信息可以从服务器收到的UDP包中获得。定义了我们的消息格式，现在我们可以开始实现发现类了。
实现服务器端的类
//初始化RMI服务器

RMILookup.bind(server,"Spanish")
在继续之前，我们扼要重述一下服务器端的类的职责：
6. 如果步骤4和5匹配，将服务器的远程代理（remote stub）通过单播TCP/IP socket串行化到客户端
建立多播UDP监听器
int port=6789; 

InetAddress address=InetAddress.getByName(multicastAddress); 

DatagramPacket packet=new DatagramPacket(buf, buf.length);
//parse packet etc
从上面的例子可以看出，你要建立一个多播监听器并在此地址/端口联合上接收数据包有多么简单。在上面的例子中，只能处理单个数据包，所以我们必须在创建DatagramPacket和socket.receive()处建立循环；否则只有一个客户端能够发现这个服务器。
byte buf=new byte[512];
socket.receive(packet);
} 
1. 每请求线程：为每个请求创建一个新的线程来处理 来自线程池的线程：使用来自（可能固定的）资源线程池的预初始化的一个线程(见 "Java Tip 78: Recycle Broken Objects in Resource Pools，http://www.javaworld.com/javaworld/javatips/jw-javatip78.html";) 阻塞：在同一时间只处理一个请求，其他请求必须等待