This week's giveaway is in the EJB and other Java EE Technologies forum. We're giving away four copies of EJB 3 in Action and have Debu Panda, Reza Rahman, Ryan Cuprak, and Michael Remijan on-line! See this thread for details.
I have studied the concept of Distributed computing as well as RMI, I have not understood some things. From implementation point -
First we make a interface extending the Remote interface and then we make a class implementing this interface where we implement our business methods. In the interface the business methods throw the RemoteException but when we implement this method we neither throw this exception nor handle it in the body of the method. Whereas on the client side , when we call this method remotely we take of this exception, client has to handle or declare this exception. Why is it so?
Also Why we extends the class UnicastRemoteObject in our class? What do you mean by exporting logic? I have gone through some books but not able to find questions of these answers.
Implementing or extending a method and calling a method are two different things. In your server part you are implementing the methods, and as per the rule the implementing method can throw the same exception, any sub class of that exception or no exception at all, so nothing is wrong. But in the client part you are calling the method, so its completely a different issue.
Joined: Mar 19, 2009
ok. when we generate the stub and skeleton classes then we do:
The stub and skeleton classes are generated from the RemoteImp class. The client calls the method on the object of stub class. After marshalling and sending the method call over the network, the skeleton calls the method locally on the RemoteImp class. Here the method does not throw the checked exception. So why the client has to handle this exception? I mean, example:
when we will call this add() method then we have to either handle or throw this exception. But :
when calling the sub() method why will I bother about any exception. The sub() method is clearly not throwing any exception.
Same is the doubt here.
Client indirectly calls the method of the class RemoteImp and the method of this class does not throw any exception so why should the client bother handling this exception.
This means that client does not invoke the method on the RemoteImp but on the RemoteInterface?
I hope the following example might help you to understand why you need to handle that exception.
Joined: Mar 19, 2009
Thanks. So the client calls the method on the reference of the interface. And on the server side the method which is actually invoked is of the class which implements this interface.
What is exporting logic and why do we extend our server side class with UnicastRemoteObject? What is the purpose of extending?
By extending this class, the object will be automatically exported for RMI access. If you do not wish to extend this class another way is using the exportObject, static method of UnicastRemoteObject class.
I have not understood.
I have one more doubt regarding this.
When we bind the object of this class in the rmi registry on server side, we do:
This binds the remote object "stub" or simply the remote object with the name "stub_object" in the rmi registry ?
On client side when we do:
Here the client gets the stub to the remote object according to the spec.
The remote object is obj. We are binding the remote object and not the stub to the registry, so the client should also get the remote object upon lookup. Why it is said that the client gets the stub to the remote object, upon lookup?
By extending this class, the object will be automatically exported for RMI access
Are talking about the 'obj' object to be automatically exported for RMI access? But we are doing that explicitly using the registry.