Re: Replacing JRMP with JERI

George Ludwig wrote:
> There's the rub...if all you do is use JRMP and
> rmiregistry with JERI, then what you've really done is
> spent time to re-implement your RMI-based system to
> behave exactly the way it used to. No swappable
> transports, no (more convenient) dynamic code
> downloading, etc. And, if you recall from our
> conversation that got me in to the JINI pool in the
> first place, no additional control over the DGC.
>
> I see little point in moving to JERI unless you really
> move to JERI, rather then just a minor
> re-implementation of JRMP.

Some RMI applications use unicast sockets to serialize proxies between applications.  In that model, you don't need a
lookup service.  All you need to do is to use an Exporter to get a proxy, and then serialize that to another JVM.  I
know that's not a big number of applications, but that is the simple use of JERI without any of the Jini services.

>>The flexibility of the Configuration mechanism means
>>that there is not a canned API with a limited set of
>>methods to
>>learn.  Instead, you design your configuration
>>values and how your application uses them.  This is
>>no different than
>>using a properties file, or some other form of
>>configuration though, so this shouldn't be a foreign
>>concept to most Java
>>developers.
>
> I didn't go in to the configuration mechanism, because
> any existing RMI app has already got a way to
> configure the services. And in my own case, at least,
> it's so integral that just replacing it with the JINI
> config stuff is pretty much out of the question (at
> least until I get around to re-architecting the
> system).

There are of course many ways to get a Configuration.  The documented way is to just pass the String[] from your main
method into ConfigurationProvider.getInstance().  You can of course use a hardcoded file name, a filename from a
different configuration interface, a system property specified file name, or a different implementation of
Configuration.  In one of my applications that makes extensive use of the command line, I chose to use a system property
instead and just use

        Configuration config = ConfigurationProvider.getInstance( new String[] {
                System.getProperty("myapp.config.file") } );

This works fine.  Then I can get the Exporter, lusProxyPreparer etc from that Configuration...

>>Thanks for putting together your rundown on steps to
>>go through George.  Also, please spend some time
>>look at the
>>jini.org project, v2getsmart at
>>http://v2getsmart.jini.org.  This project has all
>>kinds of tutorial materials and links
>>related to learning more about JERI and the related
>>features in Jini2.0.
>
> I've been through that stuff, and there is lots of
> good info. But the caveat is that most of the info
> relates to JINI 2.0, rather than the 2.1 beta. And if
> you're on the beta and trying to get reggie to run
> based on a 2.0 tutorial, you will be pulling your hair
> out just as I did (hence my long section on reggie!).

All of my Jini 2.0 services run just fine using the Jini 2.1 jar files with absolutely no changes.  What is different
between 2.0.2 and 2.1beta is the layout of the JTSK directory tree.  There are some things in the tutorial that are
broken.  It's a beta!  Trying something new, using a beta, is a risky proposition.

> Plus, there is no actual tutorial from the point of
> view of an RMI programmer trying to move his system
> over.
>
> As a developer, I usually go for the beta (if it's a
> significant rev) because I don't want to have to
> re-learn anything once the beta is released.

For RMI programmers moving to Jini, there is no difference between Jini 2.0 and Jini 2.1 from an API perspective.  All
the Exporter, ProxyPreparer, ILFactory etc interfaces are backward compatible.  The Sun contributed Jini Technology
Starter kit is one implementation of the Jini specification.  Currently, it is the only complete implementation.
However, there are other implementations of various parts of the specification for specifically focused businesses.

If you use the com.sun.jini.start.ServiceStarter framework, and draw from the examples in the JTSK for creating your
implementation/startup, then you'll see the differences that Sun has chosen between how they packaged the APIs for 2.0
verses the 2.1beta.  This packaging is not part of the specification, and is not considered to be 'Jini' because of that
fact.

The key thing to remember about Jini is that it is based on a specification.  It's not a bunch of random code and
development that doesn't care about compatibility.  The Jini community demands compatibility where it makes sense.
There are very specific design decisions that have been made by the Sun team and from input from the rest of the
community through voting that are keeping things focused.

The packaging issue is something that the community discusses.  But, dictating a particular packaging would imply some
limitations on usage patterns.  So far, noone has made a proposal that we dictate how all the jar files in the JTSK are
layedout or managed.

In my installations, I always put the appropriate jars into a different directory structure than one the JTSK uses,
because I have specific needs.

People who are just starting need something that works.  Right now, the 2.1beta is broken from several directions.  If
you don't know anything about Jini, you'll fight it, as you discovered.

So, I'd still recommend using Jini 2.0.2 as a starting point for anyone just getting started.  It represents something
that is more stable.  Learning about Jini, can be very frustrating if you are also fighting how to use the JTSK tutorial
and associated files.

Gregg Wonderly

===========================================================================
To unsubscribe, send email to [email protected] and include in the body
of the message "signoff RMI-USERS".  For general help, send email to
[email protected] and include in the body of the message "help".

For a list of frequently asked RMI questions please refer to:
http://java.sun.com/j2se/1.3/docs/guide/rmi/faq.html

To view past RMI-USERS postings, please see:
http://archives.java.sun.com/archives/rmi-users.html