• Post Reply Bookmark Topic Watch Topic
  • New Topic

The files location of RMI

 
Qunfeng Wang
Ranch Hand
Posts: 434
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Inorder to implement a RMI application. I should define an interface:AInterface, and an implemention:AInterfaceImpl. I'm not sure how to deploy these tow files. In the client:AInterface.java, in the server side:AInterfaceImpl.java? If that case, I don't know how the client look for the concrate implemention.

Or the files should be deployed in the both side? Also I don't know the stub and skeleton's location. I think I need some clarifycation about the RMI mechanism.
 
Nathan Pruett
Bartender
Posts: 4121
IntelliJ IDE Java Spring
  • Mark post as helpful
  • send pies
  • Quote
  • Report post to moderator
Both your client and server have the interface - because this tells the client what methods are available to call on the server, and tells the server what methods it needs to implement. The implementation only really needs to be deployed on the server - because the client talks to it through the stub - not directly to the implementation class. The stub needs to be provided to the client, and the skeleton needs to be provided to the server - however, in more modern JVMs (1.5+) this should happen automatically. Also, rather than providing classes to the client at deploy time - if you use the RMI codebase property, you can have the client download needed classes at runtime. Though that may be getting a little ahead of ourselves...

This is what is going on "under the hood" in RMI: You specify the interface that client and server will agree to talk through. You make an implementation of that interface to do all the processes you need to do on the server, but you ignore any details about how messages are going to be serialized and sent across the network between client and server. Then, rmic (or in JDK1.5, the RMI subsystem) produces the stub and skeleton (either up front, or on the fly) according to these specifications. The stub also implements the remote interface you wrote - but all it does is take the method calls called by the client, serializes them, and sends them across the network in an agreed upon way with the skeleton. The skeleton wraps your real implementation, it receives messages from the stub, and it translates and de-serializes those into local method calls on the implementation. This process is then reversed when the implementation's method call completes.
[ July 19, 2006: Message edited by: Nathan Pruett ]
 
It is sorta covered in the JavaRanch Style Guide.
  • Post Reply Bookmark Topic Watch Topic
  • New Topic
Boost this thread!