aspose file tools*
The moose likes Distributed Java and the fly likes Query on RMI functioning Big Moose Saloon
  Search | Java FAQ | Recent Topics | Flagged Topics | Hot Topics | Zero Replies
Register / Login
JavaRanch » Java Forums » Java » Distributed Java
Bookmark "Query on RMI functioning" Watch "Query on RMI functioning" New topic
Author

Query on RMI functioning

adithya narayan
Ranch Hand

Joined: Jan 05, 2009
Posts: 79

I don't get one thing in RMI. It's a bit confusing actually.

On client side, we have the business interface (Hello.class), the client code (HelloClient.class) and the remote stub (probably Hello_stub.class) and on server side we have the server code (HelloImpl.class), the business interface (Hello.class) and the skeleton .

For Java 5 onwards, we don't create stubs but still they are c=in picture i believe.

So, how does the communication happen ?

The client calls method on Hello.class which then calls Hello_stub.class for all n/w operations. The Hello_stub.class calls the skeleton which then calls Hello.class and then calls methods on HelloImpl.class ?

I am a bit confused after reading Head first EJB .It would be glad if someone clarified it.
Tony Docherty
Bartender

Joined: Aug 07, 2007
Posts: 2286
    
  49
I don't get one thing in RMI. It's a bit confusing actually.

Don't worry, you're doing well if there's only one thing that you find confusing about RMI.

Try reading this article http://www.sce.carleton.ca/netmanage/simulator/rmi/RMIExplanation.htm
sai rama krishna
Ranch Hand

Joined: May 29, 2009
Posts: 246
>>we don't create stubs but still they are c=in picture i believe.


I have not understood what you mean by above line
Tony Docherty
Bartender

Joined: Aug 07, 2007
Posts: 2286
    
  49
we don't create stubs but still they are c=in picture i believe.

I think what the OP means is before Java 5 you had to run rmic to generate the stubs but since then they have been generated for you.
Pat Farrell
Rancher

Joined: Aug 11, 2007
Posts: 4655
    
    5

@adithya narayan, you will find that most of us have so many questions about RMI that we simply don't use it. For 99% of the time, RMI is the wrong answer. RMI was the only solution back in the 1990s, but now, there are many better solutions. So don't use it and the confusion goes away.
adithya narayan
Ranch Hand

Joined: Jan 05, 2009
Posts: 79

@Pat Farrell : i will definitely keep your suggestion in my mind, but i just wanted to understand the functionality
as we have EJB's in our project (which again is not used so often nowadays )

@Tony Docherty : nice article..i have few questions though

1) The remote object actually never comes in picture whenever remote method invocations are being done.
I mean only stubs and skeletons are stealing the show (at least till Java 5). As far as i understand ,Stubs are
implementations of the Remote interface . Not sure on skeletons though. What is the advantage or reason of
providing the client with the Remote interface's stubs ? What are skeletons ? In the link mentioned they haven't
mentioned what exactly are skeletons.

2) Since, JAVA 2 skeletons were eliminated
(referenced from : http://docs.oracle.com/javase/1.5.0/docs/guide/rmi/spec/rmi-arch2.html ).
If there are no skeletons to handle the incoming client requests, what is actually in place ?
It would be great if you could point me to a document link or something else.

3) Can a single registry running on a single different JVM bind to multiple remote objects running on their
respective JVM's ?
Tony Docherty
Bartender

Joined: Aug 07, 2007
Posts: 2286
    
  49
First of all I should point out that whilst I've used RMI on a few projects and know a bit about it I'm no RMI expert.

1) The remote object actually never comes in picture whenever remote method invocations are being done.
I mean only stubs and skeletons are stealing the show (at least till Java 5). As far as i understand ,Stubs are
implementations of the Remote interface . Not sure on skeletons though. What is the advantage or reason of
providing the client with the Remote interface's stubs ? What are skeletons ? In the link mentioned they haven't
mentioned what exactly are skeletons.

The remote object is the object with the code that is run when an RMI call is made. The stub and skeleton just provide the underlying mechanism to enable you to make a remote method call and optionally to return a value.
The stub provides a local object with the same interface as the remote object. When your local code calls one of stub's methods the stub handles the communication with the remote object (possibly via a skeleton) marshaling all the parameters and unmarshaling the return value if there is one.
The skeleton is on the remote machine and provides the other end of the RMI communication. ie it unmarshals the parameters passing them to the remote object, then marshals the return value if there is one passing it to the stub.

2) Since, JAVA 2 skeletons were eliminated
(referenced from : http://docs.oracle.com/javase/1.5.0/docs/guide/rmi/spec/rmi-arch2.html ).
If there are no skeletons to handle the incoming client requests, what is actually in place ?
It would be great if you could point me to a document link or something else.

I'm not sure of the reason as to why the skeleton is no longer needed other than the communication protocol was changed in Java 1.2.

3) Can a single registry running on a single different JVM bind to multiple remote objects running on their
respective JVM's ?

I assume you mean can remote objects on multiple JVM's all register themselves with one registry.
The simple answer is I don't know. I would have thought you could do this, the danger is though that if the JVM that created the Registry terminates then so does the Registry so you would lose RMI communication with all the remote objects in the other JVM's even though they are still running. Also you would have to make sure every attempt to bind a remote object used a unique name.
 
I agree. Here's the link: http://aspose.com/file-tools
 
subject: Query on RMI functioning