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