« November 2009
Sun	Mon	Tue	Wed	Thu	Fri	Sat
1	2	3	4	5	6	7
8	9	10	11	12	13	14
15	16	17	18	19	20	21
22	23	24	25	26	27	28
29	30

Today

Bespoke services: network/rmi/registry

Gary and I were recently prototyping an application that uses Java RMI, and so I ended up searching around to see if anyone has done a service conversion for rmiregistry(1). (rmiregistry(1) is the daemon that lets RMI clients find the available remote objects being served by various virtual machines on a given system.) Turns out no one has (or no one's published it), which means it's time to rev up the convert-o-tron.

Since we're still developing our application and it's likely we'll change a definition or two, and since we need to restart the registry to cause the remote objects, we're going to make our prototype service restart automatically if we restart the registry. That means our prototype service has a dependency on network/rmi/registry with specific restart_on behaviour, meaning that its service description has a fragment like the following:

<!--
    As an RMI server application, we expect to be able to
    register our RMI classes with the registry server.
-->
<dependency
    name='rmi-registry'
    grouping='require_all'
    restart_on='restart'
    type='service'>
        <service_fmri value='svc:/network/rmi/registry' />
</dependency>

Inject that fragment into your various RMI servers' descriptions (or the equivalent property group into the repository) and you'll save a bit of time on application reinitializations.

So, if you're interested, please feel free to take a copy of network/rmi/registry; comments and corrections welcome.

[ T: OpenSolaris Solaris smf RMI ]

(2006-03-28 15:26:56.0) Permalink Comments [3]

Comments:

Since you're already in tune with RMI, you might want to have a look at Jini. In particular, Jini's lookup service (analogous to rmiregistry but distributed, inherently supports redundant deployment and is searchable by interface capability as well as name and other attributes) doesn't need to be restarted when your service evolves.

To be specific, it stores the registered proxies as MarshalledObjects rather than loading them, so it doesn't have to worry about "unloading". Also, service registrations are "leased" such that if the service crashes or is stopped harshly, the service registration will be removed after a reasonable amount of time.

As a matter of fact, Jini's design is much more resilient to network and service failure and evolution than plain RMI.

In addition, Jini's remote object implementation (JERI) has pluggable service endpoints that support secure transport using SSL or Kerberos, as well as JRMP. People have also done JXTA endpoints and you could roll your own.

Of course, with Jini being protocol-agnostic (see Jim Waldo's The End of Protocols), you don't need RMI at all if you have something else that works better.

If you do find Jini interesting, please also have a look at my project, the Harvester Application Container (harvester.jini.org), which provides a simple deployment environment for Jini services and clients.

Posted by Greg Trasuk on March 28, 2006 at 10:52 PM PST #

@Greg: Thanks for all the links. We're building something small, but if it gets any bigger, we'll definitely take a look at Jini and Harvester. — Stephen

Posted by Stephen on March 29, 2006 at 12:18 PM PST #

In the SMF XML it might be worth making Java Home a properties and that IMHO would complete the basic SMF definition. Remember to submit it to the OpenSolaris SMF community. Its the sort of thing that could be part of a future solaris release :-)

Posted by Peter on March 30, 2006 at 04:47 PM PST #