Most read:
Popular archives:
JavaWorld's new look is here!
We've upgraded the site with a fresh look-and-feel, improved topical navigation, better search, new features, and expanded
community platform. Learn more about the changes to JavaWorld.
| Oracle Compatibility Developer's Guide |
| The Explosion in DBMS Choice |
Your first thought may be, Why bother to do this in the first place; why not just use Jini? We would agree with this logic, especially for new systems. However, many RMI-based systems still exist, and until Jini is accepted into mainstream Java development, we need to provide more elegant RMI solutions. In fact, the work described here is the result of such a requirement: to develop a Jini service that can also run as a standalone RMI server, but uses Jini-like discovery.
This article is primarily targeted at RMI developers who haven't adopted Jini. By giving insight into what occurs under the Jini hood, we hope you begin to understand how powerful Jini mechanisms are. We certainly don't encourage you to reimplement Jini, but this article may help you understand how these mechanisms work. It may even help you convince your managers or department heads that they should consider Jini as a viable technology for distributed systems.
We won't go into depth about the Jini discovery mechanism, so if you are not familiar with it, we recommend you quickly review Bill Venners's "Locate Services with the Jini Lookup Service."
In RMI, a client must know the location of the server to which it wants to connect. An RMI server's address is in the URL
form rmi://<host>:<port>/<servername>, where the port number is the port on which the rmiregistry listens for requests. For example:
Translator service
=(Translator)Naming.lookup("rmi://theHost/SpanishTranslator");
In Jini, a client finds a service using a Jini utility class, such as ServiceDiscoveryManager. In the example below, we create a ServiceTemplate instance with a list of classes; or in our case, the class we want to match -- the 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;
As you can see from the example, the ServiceDiscoveryManager uses the lookup() method to find any available services that match the ServiceTemplate. You may also associate any number of attributes with a service lookup; we didn't here in order to keep things simple and
essential.
Comparing both lookup mechanisms, you will notice that the service location isn't specified in the Jini version. It's worth pointing out that you can specify a lookup service location if required, but not the location of the actual service you want. The Jini model's power is that we don't have to know or care where a service is located.