Notes Revisited

...

If this is the first time that the client's RMI runtime has seen this particular implementation of the policy, RMI will ask the server for a copy of the implementation. Should the implementation change tomorrow, a new kind of policy object will be returned to the client, and the RMI runtime will then ask for that new implementation.

...

This means that policy is always dynamic. You can change the policy by simply writing a new implementation of the general Policy interface, installing it on the server, and configuring the server to return objects of this new type. From that point on, any new expense reports will be checked against the new policy by every client.

This is a better approach than any static approach because:

• All clients don't need to be halted and updated with new software-software is updated on the fly as needed.
• The server is not burdened with entry checking that can be done locally.
• Allows dynamic constraints because object implementations, not just data, are passed between client and server.
• Lets users know immediately about errors.

If the entry is a valid one-one that matches current policy-the method returns normally. Otherwise it throws an exception that describes the error. The Policy interface is local (not remote), and so will be implemented by an object local to the client-one that runs in the client's virtual machine, not across the network. A client would operate something like this:

Policy curPolicy = server.getPolicy();
start a new expense report
show the GUI to the user
while (user keeps adding entries) {
    try {
        curPolicy.checkValid(entry); // throws exception if not OK
        add the entry to the expense report
    } catch (PolicyViolationException e) {
        show the error to the user
    }
}
server.submitReport(report);

Here's the Policy interface

public interface Policy {
    void checkValid(ExpenseEntry entry)
        throws PolicyViolationException;
}

import java.rmi.*;
public interface ExpenseServer extends Remote {
    Policy getPolicy() throws RemoteException;
    void submitReport(ExpenseReport report)
        throws RemoteException, InvalidReportException;
}

AND, The server looks like this:

import java.rmi.*;
import java.rmi.server.*;
class ExpenseServerImpl
    extends UnicastRemoteObject
    implements ExpenseServer
{
    ExpenseServerImpl() throws RemoteException {
        // ...set up server state...
    }
    public Policy getPolicy() {
        return new TodaysPolicy();
    }
    public void submitReport(ExpenseReport report) {
        // ...write the report into the db...
    }
}

This is why I thought (when made the tape...) that the serialization must have somehow captured the methods too. But then, that really doesn't make sense, does it...

What it sounds like is really happening is that they say it is passed, but really an instance is passed and the classLoader then dynamically finds the .class via the RMIClassLoader. then it loads it on the client side, so now they can legally say that it is running on the client side.

The problems are/were that they keep saying

1. that it is classes serialized (as opposed to instances)
2. that code is then at the client side
3. "In addition to class loaders, dynamic class loading employs two other mechanisms: the object serialization system to transmit classes over the wire, and a security manager to check the classes that are loaded."

Two things

1. a remote object has an interface that is on both the client and server. When the remote object is "passed" at runtime, the stub is passed, but when a method is called, the method runs on the server (hence RMI)
2. or, say a remote method brings back a non-remote class. What it really brings back is an instance and then dynamically the class is loaded.

OK, back.

I looked at the Serialization Specification page and can see nowhere where anything is saved other than object state

"The key to storing and retreiving objects is representing the state state of objects in a serialized form sufficient to reconstruct the object(s).
...
For java objects, the serialized form must be able to identify and verify the Java class from which the object's contents were saved and to restore the contents to a new instance.
...
Object serialization can automatically save and restore fields of each class of an object ..."

So, here is what I figure. The server can pass back either remote objects (which must have an interface on the client side) or non-remote objects (where it sends the copy) ... and possibly might use the remoteloader.

Since the remote objects are instantiated as the interfaces there is no problem at client compilation time since the interfaces are there (at the client side too).
What about client compilation and not having the non-remote .classes present (since they are dynamically loaded at run time.) In this example they (conveniently) had the non-remote objects interface there as well. Is this a pre-requisite? No, another nice trick is that one might have a super of the class locally. So in your code, you can declare it as the super...so when it actually dynamically loads a sub, the declaration still works fine.