Note: www.cdegroot.com is in rebuild. Please accept my apologies for broken links, missing stuff, etcetera - more
  Home

In the coming weeks, I'll give an overview of the basic service implementations that are part of the Jini 1.1 software kit. This week the kick-off is with two indispensable parts: RMID and a simple HTTP service.

RMID

RMID is not a part of Jini per se, it comes with the Java development kit. However, Sun's sample implementation of Jini relies heavily on this daemon, and for many people it is their first confrontation with "RMI Activation", a system for activating and suspending services.

The idea is (as usual) straightforward: if you have a lot of small services that may or may not be used at any given moment in time, you don't want them all sitting around and eating away memory. By making services "activatable", you can keep them out of memory without making them out of reach.

Most services are RMI-based and therefore you speak to them through an RMI stub (either directly, or through a proxy wrapper class that does something smart on the client machine before talking to the service). RMI activation provides a "faulting" stub, which starts out by assuming that the object is not available. If you invoke a method on the stub, the stub contacts the activation daemon it was created for and asks the daemon for a reference to the live object. The daemon activates the object if necessary, and returns the reference. The stub now uses this reference to talk to the service.

The registration of activatable services is also done with the RMI activation daemon, RMID. One of the nicer parts of the daemon is that all registrations are written to disk (lots of confusion has been caused by Sun using the switch "-log" to point to this location - technically, persistence of the registration is implemented through a transaction log, but for us mere mortals "-data" would have been a lot less confusing and not so many people would have wondered at why this "log file" doesn't log any human-readable output). When the RMI daemon is killed and restarted (for example, because of a machine reboot), it reads this database of activation registrations and registers them again. So, once you register a service (as you will do when you "start" the Jini standard services), you don't need to worry about service startup again until after you've erased RMID's data files.

HTTPD

Dynamic class loading is an integral part of RMI, and therefore of Jini. You will need to have an HTTP daemon servicing the RMI codebase, and because not everyone has Apache or IIS running on her box, there is a very primitive HTTP daemon included in the Jini software kit. The Jini documentation has details on how to start this extremely simple class server, although you are free to use a standard HTTP server.

With RMI activation up and an HTTP service to service dynamic class loading, we can start thinking about the other service we'll need - next week.


 
Copyright (C)2000-2011 Cees de Groot -- All rights reserved.