RMI Architecture server client RMI Tra skeleton Sample Client Code remote object stub o.myMethod () To achieve location transparency,RMI introduces two special kinds of objects known as stubs and skeletons. The stub is a client-side object that represents the remote object.The stub has the same interface,or list of methods,as the remote object,but when the client calls a stub method,the stub forwards the request via the RMI infrastructure to the remote object,which actually executes it. On the server side,the skeleton object takes care of all of the details of "remoteness"so that the actual remote object doesn't need to worry about them.In other words,you can pretty much code a remote object the same way as if it were local--the skeleton insulates the remote object from the RMI infrastructure.During remote method requests,the RMI infrastructure automatically invokes the skeleton object so it can do its magic. The best news about this setup is that you don't have to write the code for the stubs and skeletons yourself!The JDK contains a tool,rmic,that creates the class files for the stubs and skeletons for you
RMI Architecture - skeleton - remote object client - stub server RMI Transport RMI Transport MyRemoteObject o = ...; o.myMethod (); Sample Client Code To achieve location transparency, RMI introduces two special kinds of objects known as stubs and skeletons. The stub is a client-side object that represents the remote object. The stub has the same interface, or list of methods, as the remote object, but when the client calls a stub method, the stub forwards the request via the RMI infrastructure to the remote object, which actually executes it. On the server side, the skeleton object takes care of all of the details of "remoteness" so that the actual remote object doesn't need to worry about them. In other words, you can pretty much code a remote object the same way as if it were local -- the skeleton insulates the remote object from the RMI infrastructure. During remote method requests, the RMI infrastructure automatically invokes the skeleton object so it can do its magic. The best news about this setup is that you don't have to write the code for the stubs and skeletons yourself! The JDK contains a tool, rmic, that creates the class files for the stubs and skeletons for you
Remote Exceptions server client java.rmi.RemoteException Under the covers,RMI uses TCP/IP sockets to communicate remote method requests.While sockets are a fairly reliable transport,there are many things that could go wrong.For example,suppose the server computer crashes during a method request.Or,suppose that the client and server computers are connected via the Internet,and the client's 'net connection drops. The point is that there are more things that can go wrong with remote objects than there is for local objects.And it's important that the client program be able to gracefully recover from errors. So that the client knows about such errors,every method that will be called remotely must throw RemoteException,which is defined in the java.rmi package
Remote Exceptions client server RMI Transport RMI Transport java.rmi.RemoteException Under the covers, RMI uses TCP/IP sockets to communicate remote method requests. While sockets are a fairly reliable transport, there are many things that could go wrong. For example, suppose the server computer crashes during a method request. Or, suppose that the client and server computers are connected via the Internet, and the client's 'net connection drops. The point is that there are more things that can go wrong with remote objects than there is for local objects. And it's important that the client program be able to gracefully recover from errors. So that the client knows about such errors, every method that will be called remotely must throw RemoteException, which is defined in the java.rmi package
Server Development Steps Overview o define a remotable interface Write a class that implements the remotable interface Write a server main program that creates an instance of the implementation object and assigns the object a name o Run the rmic compiler to generate the code for the stubs and skeletons Now let's take a look at the steps involved in writing the object server.We will look at the client side in a few moments. The first thing you need to do is define an interface for the remote object.This interface defines the methods that the client can call remotely.The big difference between a remoteable interface and local interface is that remote methods must throw the exception described on the last page Next,you must write a class that implements the interface Next,you need to write a main program that runs on the server.This program must instantiate one or more of the server objects and then typically registers the remote objects into the RMI name registry so that clients can find the objects. Finally,you need to generate the code for the stubs and skeletons.The JDK provides the rmic tool,which reads the remote object's class file and creates class files for the stubs and skeletons
Server Development Steps Overview Define a remotable interface Write a class that implements the remotable interface Write a server main program that creates an instance of the implementation object and assigns the object a name Run the rmic compiler to generate the code for the stubs and skeletons Now let's take a look at the steps involved in writing the object server. We will look at the client side in a few moments. The first thing you need to do is define an interface for the remote object. This interface defines the methods that the client can call remotely. The big difference between a remoteable interface and local interface is that remote methods must throw the exception described on the last page. Next, you must write a class that implements the interface. Next, you need to write a main program that runs on the server. This program must instantiate one or more of the server objects and then typically registers the remote objects into the RMI name registry so that clients can find the objects. Finally, you need to generate the code for the stubs and skeletons. The JDK provides the rmic tool, which reads the remote object's class file and creates class files for the stubs and skeletons
Writing a Remote Interface import java.rmi.*; public interface Meeting extends Remote public String getDate ( throws RemoteException; public void setDate string date throws RemoteException public void scheduleIt() throws RemoteException; Here's the interface definition for a simple remote interface.Objects that implement this interface provide a three methods:one that returns a string. one that accepts a string as an argument,and one that accepts no arguments and returns nothing.As mentioned earlier,these methods must throw the RemoteException,which clients will catch if something goes wrong with the communication between the client and server. Note that the interface itself extends the Remote interface that's defined in the java.rmi package.The Remote interface itself defines no methods,but by extending it,we indicate that the interface can be called remotely
Writing a Remote Interface import java.rmi.*; public interface Meeting extends Remote { public String getDate () throws RemoteException; public void setDate ( String date ) throws RemoteException; public void scheduleIt() throws RemoteException; } Here's the interface definition for a simple remote interface. Objects that implement this interface provide a three methods: one that returns a string, one that accepts a string as an argument, and one that accepts no arguments and returns nothing. As mentioned earlier, these methods must throw the RemoteException, which clients will catch if something goes wrong with the communication between the client and server. Note that the interface itself extends the Remote interface that's defined in the java.rmi package. The Remote interface itself defines no methods, but by extending it, we indicate that the interface can be called remotely
Implementing the Remote Interface java.lang.Object public class teobject java.mi.Server.RemoteObject implements Meeting private string ivDate java.rmi.Server.RemoteServer new String "1/1/2000"); throws RemoteException java.rmil se public String getDate()throws RemoteException return ivDate: 1 Now let's look at a class that implements the remote Meeting interface.As is typical. MeetingServer extends the UnicastRemoteObject class,which provides the basic behavior required of remote objects.The phrase"Unicast"refers to the fact that each client stub references a single remote object.In the future,RMI may allow for "Multicasting",where a stub could refer to a number of equivalent remote objects.With multicasting,the RMI infrastructure could balance the load between the set of remote objects. Here we show the implementation of two methods:the"getDate"method defined in the Meeting interface,and a no-argument constructor.Notice that both throw the RemoteException;this is required for constructors and all methods that the client calls remotely.In this case,the constructor has no useful work to do,but we still need to define it so it can throw the remote exception. The"getDate"method is the interesting one,though.It returns a string's reference back to the caller.While this may look simple,the RMI infrastructure and the skeletons and stubs actually have a lot of work to do here.They all must conspire so that a copy of the string is passed back to the client and then recreated as an object in the client's virtual machine
Implementing the Remote Interface import java.rmi.*; import java.rmi.server.*; public class MeetingServer extends UnicastRemoteObject implements Meeting { private String ivDate = new String ( "1/1/2000" ); public MeetingServer() throws RemoteException { } public String getDate() throws RemoteException { return ivDate; } . . . } java.lang.Object java.rmi.Server.RemoteObject java.rmi.Server.RemoteServer java.rmi.server.UnicastRemoteObject Now let's look at a class that implements the remote Meeting interface. As is typical, MeetingServer extends the UnicastRemoteObject class, which provides the basic behavior required of remote objects. The phrase "Unicast" refers to the fact that each client stub references a single remote object. In the future, RMI may allow for "Multicasting", where a stub could refer to a number of equivalent remote objects. With multicasting, the RMI infrastructure could balance the load between the set of remote objects. Here we show the implementation of two methods: the "getDate" method defined in the Meeting interface, and a no-argument constructor. Notice that both throw the RemoteException; this is required for constructors and all methods that the client calls remotely. In this case, the constructor has no useful work to do, but we still need to define it so it can throw the remote exception. The "getDate" method is the interesting one, though. It returns a string's reference back to the caller. While this may look simple, the RMI infrastructure and the skeletons and stubs actually have a lot of work to do here. They all must conspire so that a copy of the string is passed back to the client and then recreated as an object in the client's virtual machine