正如我们从例子中可以看到,servicediscoverymanager用lookup()方法来查找任何与servicetemplate匹配的可用的服务.你还可以在服务查找中使用任何数字或属性;在这里我们出于保持简单与精练的考虑而没有这样做.
【程序编程相关:球无线局域网设备收入增长10%】 【推荐阅读:和记黄埔与微软合作 用户3G手机将与MS】比较两种查找机制,你会注意到在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.简单来说,这意味着客户端发出一个多播的请求数据包,然后数据包被监听它的查找服务拾取.然后查找服务用单播连接连回客户端,并把查找服务的代理串行化成流通过此连接发送出去.此后客户端就可以与查找服务(的代理)交互以定位它需要的服务.发现机制实际上比这要复杂得多,但我们只对其中多播udp与单播tcp/ip的关键概念感兴趣.我们并不打算实现一个等同的独立运行的rmi查找服务.相反我们将实现一个简单的多播监听器/单播分发器(multicast listener/unicast dispatcher)供rmi服务器使用,实际上我们使得每个rmi服务器作为它自己的查找服务.在客户端,我们为服务器端socket写个配对物??一个多播分发器/单播监听器(multicast dispatcher/unicast listener).
下面的表更详细地说明了rmi客户端与rmi服务器端间的交互. rmi客户端与rmi服务器端的交互 服务器端客户端 在多播地址上开始监听 建立serversocket以监听来自服务器的单播响应. 开始向多播地址发送udp数据包 ... 下一页