• What's Needed:
  • Stubs/Skeletons for marshalling and unmarshalling
  • A way to locate remote objects
• What Java Provides:
  • Dynamic generation of stubs
  • Skeleton functionality within the class
  • Tools (i.e., rmiregistry and rmid) that provide registry services

• "Newer" Versions of Java:
  • A remote interface normally does not include a suffix (e.g., Server)
  • A class that implements a remote interface normally includes the Impl suffix (e.g., ServerImpl)
• "Older" Versions of Java:
  • A stub class that was generated by the rmic tool normally included the _Stub suffix (e.g., Server_Stub)
  • A skeleton class that was generated by the rmic tool normally included the _Skel suffix (e.g., Server_Skel).

• The Remote Interface:
  • Any object that wants to be available remotely must directly or indirectly implement the Remote interface
  • The Remote interface has no methods or fields and serves only to identify the semantics of being remotely available
• The RemoteException Class:
  • It is the common superclass for a number of communication-related exceptions that may occur during the execution of a remote method call
  • All methods in an interface/class that extends/implements the Remote interface must list RemoteException in its throws clause

• An Observation:
  • Most methods are either passed parameters or return something
  • The parameters/returns are often objects
• Classes to be Passed/Returned:
  • Must be serializable
  • Hence, normally implement the Serializable interface

• Comparing "Normal" Objects:
  • Use the equals() method
• Comparing "Remote" Objects:
  • The equals method in the Object class does not work correctly
  • One remedy is to extend the UnicastRemoteObject class (which also implements the hashCode() and toString() methods)

• The Naming Class:
  • Look up a remote object
  • Bind/rebind a name to a remote object
  • Unbind a name from a remote object
  • List the names that are bound bound in the registry
• The Names:
  • The names in the registry are URL formatted

1. Compile the source files using the javac command.
2. Start the registry using the rmiregistry command (which uses port 1099 by default).
3. Run the application that adds the necessary remote objects to the registry (using the java command).
4. Run the applications/applets that use the remote objects.

History:

• Prior to version 1.2, the rmic tool was used to create stubs and skeletons.
• In versions 1.2-1.4, the rmic tool was used to create stubs but explicit skeletons were not needed.
• Starting in version 1.5, stub classes are generated at runtime. Hence, the rmic tool is no longer needed. (The rmic tool can be used for IIOP and IDL.)

• The Activatable Class:
  • Provides support for persistent remote objects that can be activated into "live" objects by the system when needed
• Notes:
  • The "invoker" does not need to know whether the activation system is being used or not, and, hence does, not need to change
  • What does need to change is the way that the "invoked" object is registered
• The rmid Tool:
  • Starts the activation system daemon (which must be started before activatable objects can be either registered or activated)