remote method requirements.
Rajendra Deshpande
Ranch Hand
Posts: 40
posted 16 years ago
Hi friends,
Browsing thru a RMI documentation i came across the following....
****************
Each method declaration in a remote interface or its super-interfaces must satisfy the requirements of a remote method declaration as follows:
- A remote method declaration must include the exception java.rmi.RemoteException (or one of its superclasses such as java.io.IOException or java.lang.Exception) in its throws clause, in addition to any application-specific exceptions (note that application specific exceptions do not have to extend java.rmi.RemoteException).
- In a remote method declaration, a remote object declared as a parameter or return value (either declared directly in the parameter list or embedded within a non-remote object in a parameter) must be declared as the remote interface, not the implementation class of that interface.
****************
Could someone kindly explain to me the latter requirement in detail. Thanking you in anticipation of a helpful reply.
-Rajendra.
Browsing thru a RMI documentation i came across the following....
****************
Each method declaration in a remote interface or its super-interfaces must satisfy the requirements of a remote method declaration as follows:
- A remote method declaration must include the exception java.rmi.RemoteException (or one of its superclasses such as java.io.IOException or java.lang.Exception) in its throws clause, in addition to any application-specific exceptions (note that application specific exceptions do not have to extend java.rmi.RemoteException).
- In a remote method declaration, a remote object declared as a parameter or return value (either declared directly in the parameter list or embedded within a non-remote object in a parameter) must be declared as the remote interface, not the implementation class of that interface.
****************
Could someone kindly explain to me the latter requirement in detail. Thanking you in anticipation of a helpful reply.
-Rajendra.
Ashwin Desai
Ranch Hand
Posts: 124
posted 16 years ago
Hi,
A RMI Client needs to know about the methods that the RMI server supports. Thus, it needs to know about the interface that the server class implements.
When the client makes a Naming.lookup() to lookup the server on the remote machine, it gets a remote stub object that is a proxy/local representative of the server object. The Proxy and the Server objects share the same interface (about which the client knows already) and thus, the client does not have any problems invoking the methods.
Also, Java uses late binding (i.e. dynamic binding). So, you can subsititute one class for the other if they share the common ancestor.
to make this clear. Consider the following example.
public interface Server implements Remote
{
public void something() throws R...Ex...
}
public class ServerImpl extends Unicast.... implements Server
{
// register the server with the registry.
}
Client
------
public class Client
{
public static void main(String argv[])
{
Server server = (Server) Naming.lookup("//host/SERVER");
}
}
In the above call to Naming, say if I replace it by
ServerImpl server = (ServerImpl) Naming.lookup("//host/SERVER");
and assuming that we have the ServerImpl class on the client side. The code would compile just fine but you would get a run-time exception (mostly ClassCastException) because
Naming.lookup returns the Stub class that is different from the ServerImpl class.
Thus for this arrangement to work, we need to program to interfaces and use late binding.
Hope this helps.
Ashwin.
A RMI Client needs to know about the methods that the RMI server supports. Thus, it needs to know about the interface that the server class implements.
When the client makes a Naming.lookup() to lookup the server on the remote machine, it gets a remote stub object that is a proxy/local representative of the server object. The Proxy and the Server objects share the same interface (about which the client knows already) and thus, the client does not have any problems invoking the methods.
Also, Java uses late binding (i.e. dynamic binding). So, you can subsititute one class for the other if they share the common ancestor.
to make this clear. Consider the following example.
public interface Server implements Remote
{
public void something() throws R...Ex...
}
public class ServerImpl extends Unicast.... implements Server
{
// register the server with the registry.
}
Client
------
public class Client
{
public static void main(String argv[])
{
Server server = (Server) Naming.lookup("//host/SERVER");
}
}
In the above call to Naming, say if I replace it by
ServerImpl server = (ServerImpl) Naming.lookup("//host/SERVER");
and assuming that we have the ServerImpl class on the client side. The code would compile just fine but you would get a run-time exception (mostly ClassCastException) because
Naming.lookup returns the Stub class that is different from the ServerImpl class.
Thus for this arrangement to work, we need to program to interfaces and use late binding.
Hope this helps.
Ashwin.
Rajendra Deshpande
Ranch Hand
Posts: 40
Ashwin Desai
Ranch Hand
Posts: 124
posted 16 years ago
Hi,
rmic produces two files *_stub.class & *_skel.class. The stub class is an implementation of your Interface (that extends remote) and not ServerImpl class and carries out the communication with the server. It hides all the network level complexities from the user.
The stub is in charge of marshalling arguments for transport i.e. checking if the arguments are primitive types/Remote Objects/Serializable objects and converting them to the proper forms and sending them across the network. Also, the stub demarshalls the return arguments of the method calls to the server.
Hope this helps.
Ashwin.
rmic produces two files *_stub.class & *_skel.class. The stub class is an implementation of your Interface (that extends remote) and not ServerImpl class and carries out the communication with the server. It hides all the network level complexities from the user.
The stub is in charge of marshalling arguments for transport i.e. checking if the arguments are primitive types/Remote Objects/Serializable objects and converting them to the proper forms and sending them across the network. Also, the stub demarshalls the return arguments of the method calls to the server.
Hope this helps.
Ashwin.
Rajendra Deshpande
Ranch Hand
Posts: 40
posted 16 years ago
Ashwin,
Thanks for the reply. Things have become reasonably clear. Excuse me if my following query sounds silly....but I cannot hold back.
With respect to your first post...Stub belongs to class Server which in turn implments Remote.right? I presume that stubs by their nature of being server-proxy have to be of the same class as server obj. That makes me wonder why ServerImpl is used.
thanks,
raj.
Thanks for the reply. Things have become reasonably clear. Excuse me if my following query sounds silly....but I cannot hold back.
With respect to your first post...Stub belongs to class Server which in turn implments Remote.right? I presume that stubs by their nature of being server-proxy have to be of the same class as server obj. That makes me wonder why ServerImpl is used.
thanks,
raj.
Ashwin Desai
Ranch Hand
Posts: 124
posted 16 years ago
Hi,
No, the stub does not belong to the class Server, but it is an implementation of the Server INTERFACE just as the class ServerImpl is.
ServerImpl is the concrete class that provides the implementation to the methods that the interface Server defines. The User programs this class.
ServerImpl_stub.class is generated by the rmic compiler that also implements Server interface. This class implements all the methods of Server interface handling the Marshalling/Demarshalling of params and ret values and also communication across the n/w. The RMIC compiler generates this class from your own ServerImpl.java implementation. It is a proxy.
Also, stubs are not ServerSide proxies, but client side proxies.
Ashwin.
No, the stub does not belong to the class Server, but it is an implementation of the Server INTERFACE just as the class ServerImpl is.
ServerImpl is the concrete class that provides the implementation to the methods that the interface Server defines. The User programs this class.
ServerImpl_stub.class is generated by the rmic compiler that also implements Server interface. This class implements all the methods of Server interface handling the Marshalling/Demarshalling of params and ret values and also communication across the n/w. The RMIC compiler generates this class from your own ServerImpl.java implementation. It is a proxy.
Also, stubs are not ServerSide proxies, but client side proxies.
Ashwin.
Rajendra Deshpande
Ranch Hand
Posts: 40
posted 16 years ago
Ashwin,
Thanks for all your replies. I shall preserve a copy of this discussion on my PC. Btw when I said server-proxy I did not mean to say server side proxy but server's proxy(representative) for the client. Its been a fruitful exchange for me. Thanks yet again.
regards,
Rajendra.
Thanks for all your replies. I shall preserve a copy of this discussion on my PC. Btw when I said server-proxy I did not mean to say server side proxy but server's proxy(representative) for the client. Its been a fruitful exchange for me. Thanks yet again.
regards,
Rajendra.
