RMI is designed to be extensible at runtime, and in particular it supports the notion of socket factories, which are pluggable objects with a responsibility for manufacturing network socket connections. A default socket factory is installed when RMI starts up, which simply uses regular unencrypted TCP connections to communicate RMI method calls and their results. However, other socket factories can be optionally installed. Socket factories control how RMI endpoints communicate at the raw byte-stream level. They have no effect on the higher-level operation of RMI, such as method calls and thread usage.

You can use Dynamo to designate a Java class that is instantiated and used as RMI’s socket factory. This permits third party vendors’ implementations of socket factories to be used transparently by RMI, and thus by Dynamo’s client/server RMI communication as used by the ATG Control Center. This supports such features as:

RMI-over-SSL can be useful in cases where a secure server needs to be contacted by authorized entities outside the firewall, or where security behind the firewall is an issue.

Configuring an Alternate Socket Factory

The component /atg/dynamo/server/RmiInitialization (of class atg.server.rmi.RmiInitialization) is responsible for performing RMI configuration prior to starting the Dynamo RMI server. It provides two ways to specify the socket factory class to be used:

In general, specifying a Nucleus component is preferable, because you can easily configure the component through a properties file. Specifying a class directly is a useful alternative, if, for example, you are using a preconfigured RMI socket factory implementation obtained from a 3rd-party vendor.

To configure an alternate socket factory:

To debug a socket factory at runtime, use vendor-supplied debugging switches if available. You can also use the Java argument Djava.rmi.server.logCalls=true to force all RMI method calls to be logged to the console.

loading table of contents...