Re: 2-way RMI-Connection

Michael Tomuschat wrote:
> This works perfectly well, when client and server are on the same host.
> But when the client is on a remote machine it cannot bind the
> status-interface to the rmiregistry any more (Access Exception: registry
> rebind disallowed from non-local host)

RMI as delivered in the JDK is, for all intents and purposes, RMI 1.0.  It's
basic implementation details and improvements have stopped since JDK1.5 changes
to use dynamic proxies.  There wasn't much significantly change before that,
except for some SocketFactory work to allow SSL to be used instead of TCP.

The original RMI engineers, and others, tried to upgrade the RMI platform to
provide a plugable endpoint and invocation layer plus additional needed security
enhancements.  This work was proposed to the JCP as JSRs
(http://www.jcp.org/en/jsr/detail?id=76 and
http://www.jcp.org/en/jsr/detail?id=78).  Because of a number of issues,
including the desire of some enterprise software companies wanting to tie in
standards changes to CORBA so that it could have these features too, the JSRs
failed.

Subsequently, this work was brought into the Jini (http://www.jini.org)
community.  This work was refined and implemented in the Jini 2.0 release.  Jini
is currently at release 2.1, and has become an Apache Podling project as Apache
River.  There is progress being made to get the Jini 2.1 source into SVN at
apache so that work can continue on the next release.

That's the short story of where Jini is today.

Jini, provides a much more expansive toolset to those wishing to utilize simple
java programming paradigms to create remote communications/distributed systems.

> So, how can I bind the status-class on the non-local host, or if this is
> not possible, how can I make the server call the applet's status-class??
>
> Is RMI the right tool for this task??

Jini is the tool that makes it possible to do this, if you really want to.  But,
in then end, it's probably not what you need to do for an internet application.

Instead, you could create/use an HTTP endpoint implementation that provided the
ability for the client to maintain the connection to the server for the calls
comming from the server to the client.

Or, if the flow of data is slow, you could just call from the client to the
server and not return from that call until there is data.  If there is lots of
data, you could batch the data items when there wasn't a client call pending in
the server and then just send back what you have when the clients inbound call
arrives.

In this day and age, alot of people are just using web services technologies and
using tools that generate a lot of infrastructure for you.  The nice thing about
the RMI programming model, is that you are using native Java values.  The great
thing about the Jini Extensible Remote Invocation (JERI) implementation in Jini
2.0 and later, is that it allows you to plug in Web services, MODBUS, Http,
semaphores, handwaving or some other invocation layer and endpoint technology as
a configuration step.  It's all part of the API and specifications, so you don't
have to engineer this.  Other peoples work is those pluggable with spec
compliant technologies too.

You'll have to make the decision yourself on what to do.  The link to LipeRMI
illustrates that others have been frustrated with RMI for various reasons.  The
JERI work in Jini pretty much resolves the issues that I've seen illustrated by
such projects.  But, for some reason, they continue to miss that Jini exists and
can provide them solutions.

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