RMI goes deep

[Arttu Arstila]

Hi! In my job I am starting a project where I should transform a
Java-based system into RMI platform. Even though I am somewhat familiar
with RMI principles, there are still some obscurities.

The system I'm working on has one Server application that is a normal
Java program. Then there are multiple instances of client applets
running on remote computers. The distribution is currently implemented
with ancient Voyager ORB. So although the architecture is fine, the
Voyager->RMI transition requires some rewriting.

Although I've done most of the rewriting, there is one thing that
puzzles me. There is a kind of remote event mechanism that allows server
and clients to communicate with each other. Some of the classes in
applet package implement some remote listener interfaces (those extend
java.rmi.Remote) in event package.

So in order to work with RMI, I should rewrite those client classes to
extend UnicastRemoteObject and make other adjustments for RMI
compliance. But how can it be that I have remote classes in client
package? Shouldn't client get all the remote objects as references from
the server over RMI? Where do this client-side remote objects register
themselves? My mental models just don't match, please clarify this to me
if you can.

Grateful for your help,
Arttu Arstila
Helsinki University of Technology, Finland

 

[Thomas Weidenfeller]

But how can it be that I have remote classes in client
package?

Without going into details, such a setup is common in CORBA systems. You
should make a distinction between your system architecture's view (a
server, and multiple clients), and what constitutes a server or client
from a CORBA or RMI point of view.

For the later, every entity which provides a method which can be invoked
from remote is a "server". Every entity which invokes remote methods is
a "client".

If you have to implement some callback mechanism, like some event
notification, your (in architecture terms) client, has to offer a method
which can be called from remote for notification purposes. This makes
that (in architecture and implementation terms) client a (in
implementation terms) server, too.

Where do this client-side remote objects register
themselves?

I would guess they register at the (architecture) server when the
callback mechanism is set up "Dear server, please call this remote
method when something happens".

/Thomas

 

[Arttu Arstila]

Without going into details, such a setup is common in CORBA systems. You
should make a distinction between your system architecture's view (a
server, and multiple clients), and what constitutes a server or client
from a CORBA or RMI point of view.

For the later, every entity which provides a method which can be invoked
from remote is a "server". Every entity which invokes remote methods is
a "client".

If you have to implement some callback mechanism, like some event
notification, your (in architecture terms) client, has to offer a method
which can be called from remote for notification purposes. This makes
that (in architecture and implementation terms) client a (in
implementation terms) server, too.



I would guess they register at the (architecture) server when the
callback mechanism is set up "Dear server, please call this remote
method when something happens".

Ok, I think I'm getting it. So would it be right to understand it like
this: my (architecture) server and clients share the same RMI
server/coneection/distribution/whatever mechanism, and they can equally
register objects for distributed computing in it.


Thanks a lot for your help,
Arttu Arstila / HUT Finland

 

[iksrazal]

So in order to work with RMI, I should rewrite those client classes to
extend UnicastRemoteObject and make other adjustments for RMI
compliance. But how can it be that I have remote classes in client
package? Shouldn't client get all the remote objects as references from
the server over RMI? Where do this client-side remote objects register
themselves? My mental models just don't match, please clarify this to me
if you can.

Its all done via marshalling Stubs and Skeletons. Sort of like:

1) Compile all your client classes, including your interfaces that
extends Remote.
2) Copy your compiled interfaces from the client to the server.
3) Compile your server classes with javac .
4) Using rmic , compile your server classes which 'extends
UnicastRemoteObject' and implements your client interfaces .
5) Copy from the server your *Stub*.class to the client.
6) Start rmiregistry on the server.
7) Invoke your client.

HTH

Outsource to an American programmer living in brazil!
http://www.braziloutsource.com/
iksrazal

 

[Derek Chen-Becker]

Its all done via marshalling Stubs and Skeletons. Sort of like:

1) Compile all your client classes, including your interfaces that
extends Remote.
2) Copy your compiled interfaces from the client to the server.
3) Compile your server classes with javac .
4) Using rmic , compile your server classes which 'extends
UnicastRemoteObject' and implements your client interfaces .
5) Copy from the server your *Stub*.class to the client.
6) Start rmiregistry on the server.
7) Invoke your client.

Or wait for 1.5, where not only can you skip steps for and 5, but the
new metadata interface may simplify marking methods as remote...

Derek

 

[Nigel Wade]

Ok, I think I'm getting it. So would it be right to understand it like
this: my (architecture) server and clients share the same RMI
server/coneection/distribution/whatever mechanism, and they can equally
register objects for distributed computing in it.

This link might shed some light:
http://www.javaworld.com/javaworld/javaqa/1999-04/05-rmicallback.html

google for "java rmi callback" for more links.

 

[Arttu Arstila]

This link might shed some light:
http://www.javaworld.com/javaworld/javaqa/1999-04/05-rmicallback.html

google for "java rmi callback" for more links.

Thanks a lot, those diagrams were especially helpful.


Arttu Arstila
Helsinki University of Technology, Finland

 

[Arttu Arstila]

Its all done via marshalling Stubs and Skeletons. Sort of like:

Thanks for answering, but 'been there, done that'. As you can see from
my message, I've gotten the basics Luckily Thomas and Nigel
understood my question, it is sometimes hard to express my thoughts in
foreign language.


Arttu Arstila
Helsinki University of Technology, Finland