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.