Relation of this effort to Java RMI

Our stated goals and those behind the RMI package are more or less identical. Thus, it is not surprising that from the outside, the structure of the resulting distributed applications looks more or less identical to that of the structure used by the RMI package.

The differences lie in the implementation. The primary difference is that the complete communication infrastructure is contained within the client (CI) implementation and server (SI) implementation classes. In Java RMI the communications structure is broken down into several components. (As described in [] this was in an effort to provide the capablity for having differnt mechanisms for object communications).

Secondary differences

No extra security measures are invoked in the NetApp wrappers implementation. One inherits the standard Java security measures.

Multiple instances of the server class are used to service multiple clients. Also, there is no registry mechanism; the ServerManager dynamically loads classes by name.

All methods of the remote interface class must throw RMIExceptions. In the NetApp wrappers implementation this is not a necessity. (If a server class specifies that
NetAppexceptions are thrown, then the code creator will cause any communication code to throw the excpetion rather than print it to system.out.)

RMI has a specific set of security procedures Net App wrappers has the default Java security. In particular the remote class has the privilidges held by the user who started the ServerManger possesses. If one uses callbacks, then the server acquires the privalges that the client posseses; e.g. if it is a java Application, then it can modify ones user files.
RMI has point-to-point applications, with only a single instance of server classes running. NetApp wrappers, point-to-point communication. Multiple instance server classes.
RMI requires that the remote class be "running" NetApp wrappers invokes a remote class dynamically. Once the remote connection is terminated, then standard Java garbage collection takes care of removing it.

NetApp wrappers

In addition, all of the support code for the communication layer is exposed.

Allow the interface of the remote class to be identical to the local class. No introduction of additional exceptions. Depending on your point of view this could be desirable. I've put a switch in the CreateNetApp wrappers so that the interface code also throws expections with network errors. However, the existence of execptions doesn't help when the socket halts because of a read problem. So, I made the decision to just print out all the messasge to the screen.