• Post Reply
  • Bookmark Topic Watch Topic
  • New Topic

Query on RMI functioning

 
adithya narayan
Ranch Hand
Posts: 79
Android Eclipse IDE Firefox Browser
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 2988
59
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 432
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
>>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
Posts: 2988
59
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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
Posts: 4678
7
Linux Mac OS X VI Editor
  • Likes 1
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
@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
Posts: 79
Android Eclipse IDE Firefox Browser
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
@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
Posts: 2988
59
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
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.
 
  • Post Reply
  • Bookmark Topic Watch Topic
  • New Topic