Modifying Activatable Servers Incorporating a Custom Socket into an Application

Ordinary servers that arent subclasses of UnicastRemoteObject are handled similarly. Recall that stubs for these types of servers are created using one of UnicastRemote - Object s static export methods: static RemoteStub exportObjectRemote obj static Remote exportObjectRemote obj, int port static Remote exportObjectRemote obj, int port, RMIClientSocketFactory csf, RMIServerSocketFactory ssf These methods are called from within the launch code, as in the following snippet from Chapt er 9 : private static void launchServerNameBalancePair serverDescription { try { Account_Impl2 newAccount = new Account_Impl2serverDescription.balance; RemoteStub stub = UnicastRemoteObject.exportObjectnewAccount; Naming.rebindserverDescription.name, stub; System.out.printlnAccount + serverDescription.name + successfully launched.; } catchException e{} } The change to the launch code is exactly parallel to our changes of the subclasses of UnicastRemoteObject . Instead of calling the one-argument version of export , we call the four-argument version. The preceding code becomes the following: private static void launchServerNameBalancePair serverDescription { try { Account_Impl2 newAccount = new Account_Impl2serverDescription.balance; RemoteStub stub = UnicastRemoteObject.exportObjectnewAccount, 0, new PropertyBasedMonitoringSocket_RMIClientSocketFactory , new PropertyBasedMonitoringSocket_RMIServerSocketFactory ; Naming.rebindserverDescription.name, stub; System.out.printlnAccount + serverDescription.name + successfully launched.; } catchException e{} }

18.2.2 Modifying Activatable Servers

Recall that one of the major changes in making a server activatable is switching from UnicastRemoteObject to Activatable . Servers that extended UnicastRemoteObject now extend Activatable , and servers that used one of the static exportObject methods defined in the UnicastRemoteObject class now use one of the static exportObject methods defined in the Activatable class. This parallelism continues when you modify an activatable server to use a custom socket factory. Here, for example, is the code for our activatable account server, modified to use a custom socket factory: public class Account_Impl extends Activatable implements Account { private Money _balance; public Account_ImplActivationID id, MarshalledObject data throws RemoteException { superid, 0, new PropertyBasedMonitoringSocket_RMIClientSocketFactory , new PropertyBasedMonitoringSocket_RMIServerSocketFactory ; try { _balance = Money data.get ; .... } That is, instead of calling the two-argument superclass constructor: protected ActivatableActivationID id, int port we need to call the four-argument superclass constructor: protected ActivatableActivationID id, int port, RMIClientSocketFactory csf, RMIServerSocketFactory ssf and pass in the socket factories we wish to use. Similarly, Activatable defines four static export methods: static Remote exportObjectRemote obj, ActivationID id, int port static Remote exportObjectRemote obj, ActivationID id, int port, RMIClientSocketFactory csf, RMIServerSocketFactory ssf static ActivationID exportObjectRemote obj, String location, MarshalledObject data, boolean restart, int port static ActivationID exportObjectRemote obj, String location, MarshalledObject data, boolean restart, int port, RMIClientSocketFactory csf, RMIServerSocketFactory ssf Making an activatable server that does not extend Activatable to use a custom socket factory is easy. Doing so consists entirely of switching the export method that is called to an export method that takes socket factories for arguments.

18.2.3 Modifying the Default Servers