Plan B

RMI sans the rmiregistry

Eamonn McManus recently blogged about ways of securing the RMI registry from local modifications by malicious clients. If you must use the registry, those are effective (if slightly hacky) techniques to secure the RMI registry. (On a related note, a number of RMI-newbies tend to wrongly assume that the rmiregistry is somehow responsible for routing every method invocation and must be used all the time.) But RMI separates the "discovery" of a server object from the actual invocation upon it. (Notice that I said server object and not service - with all the SOA buzz and self-proclaimed "experts" criminally equating SOA to WS-* standards, I hesitate to use the word "service" and have readers make faulty assumptions based on jargon. Anyways...) When you initialize the RMI server implementation and export it through UnicastRemoteObject.exportObject, the returned java.lang.reflect.Proxy object implements Serializable as well (The proxy mechanism became the default instead of rmic generated client stubs in Java SE 5). As a result, you're free to share it with potential clients as you please: write it to a directory server that allows RBAC, persist to a DB, serialize it over a socket, put it up for clients to download from a web/ftp server and so forth.

In fact, such flexible service discovery is one of the key features of Jini: while you're welcome to use the default lookup implementation ("Reggie"), the Jini API makes no assumption of the discovery service implementation. In fact, any host can run a Lookup service and lookup services themselves can be dynamically discovered. No, that was not a circular definition - you can use multicast to lookup a discovery service. How cool is that?

 
In summary, if you're planning to build a system using RMI, you're free to use your own lookup service if rmiregistry doesn't serve the purpose. You must, however, evaluate the merits/demerits of one approach over another before deciding upon the actual implementation.

(And by the way, wish you a peaceful, healthy and prosperous 2007 :-))

Posted at 01:38PM Jan 01, 2007 by Bharath Ravikumar in Java  |  Comments[1]