Re: Replacing JRMP with JERI

What I'm particularly interested in is replacing JRMP with JERI with the
only changes being to use NIO, SSL, and export to not use DGC. I'm not
interested in the reggie LUS or any of that.  

-----Original Message-----
From: Gregg Wonderly [mailto:[email protected]] 
Sent: Wednesday, July 06, 2005 10:01 AM
To: [email protected]
Subject: 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

===========================================================================
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