Lazy activation in RMI allows remote objects to begin execution only when they are first accessed, rather than all being activated upfront. A faulting remote reference contains both an activation ID and a potential live reference. When a method is first invoked, if the live reference is null, the activation ID is used to look up and activate the object. The activated object's live reference is then returned and used for subsequent invocations. Socket factories in RMI allow customizing how server and client sockets are created, such as for authentication or controlling which network interface is bound.

1. Unit – III Roy Antony Arnold G Sr. Lecturer Einstein College of Engineering Tirunelveli, Tamilnadu, India

2. In RMI, activation allows objects to begin execution on an as-needed basis . When an activatable remote object is accessed (via a method invocation) if that remote object is not currently executing, the system initiates the object's execution inside an appropriate JVM

3. An active object is a remote object that is instantiated and exported in a JVM on some system. A passive object is one that is not yet instantiated (or exported) in a JVM, but which can be brought into an active state. Transforming a passive object into an active object is a process known as activation . Activation requires that an object be associated with a JVM, which may entail loading the class for that object into a JVM and the object restoring its persistent state (if any). In the RMI system, we use lazy activation. Lazy activation defers activating an object until a client's first use (i.e., the first method invocation).

4. Lazy activation of remote objects is implemented using a faulting remote reference (sometimes referred to as a fault block). A faulting remote reference to a remote object “faults in” the active object’s reference upon the first method invocation to the object . Each faulting reference maintains both a persistent handle (an activation identifier) and a transient remote reference to the target remote object. The remote object’s activation identifier contains enough information to engage a third party in activating the object.

5. A remote object’s stub contains a “faulting” remote reference type that contains both: an activation identifier for a remote object, and a “live” reference (possibly null) containing the “active” remote reference type of the remote object

7. When a client receives a stub for an activatable server, the stub contains a special form of RemoteRef which initially contains a null "real" RemoteRef and an ActivationID for the remote object. When the stub is first used for a remote method invocation the RemoteRef is null, so the stub engages in a protocol interaction with the activation system daemon rmid in the remote host. The result of this protocol interaction is a live RemoteRef which the stub can then use to invoke the remote method. Behind the scenes, the activation system has taken the following steps: looked up the ActivationID found the ActivationGroup associated with it activated the group if necessary told the group to activate the activatable server if necessary obtained the activatable server's RemoteReffrom the group, and returned it to the client stub.

8. During a remote method invocation, if the “live” reference for a target object is unknown, the faulting reference engages in the activation protocol. The activation protocol involves several entities: the faulting reference, the activator, an activation group, and the remote object being activated . The activator (usually one per host) is the entity which supervises activation by being both: a database of information that maps activation identifiers to the information necessary to activate an object (the object's class, the location--a URL path-- from which the class can be loaded, specific data the object may need to bootstrap, etc.), and a manager of Java virtual machines, that starts up JVMs (when necessary) and forwards requests for object activation to the correct activation group inside a remote JVM.

9. A faulting reference uses an activation identifier and calls the activator (an internal RMI interface) to activate the object associated with the identifier. The activator looks up the object’s activation descriptor (registered previously). The object’s descriptor contains: the object’s group identifier, specifying the JVM in which it is activated, the object’s class name, a URL path from which to load the object’s class code, and object-specific initialization data in marshalled form. When the object is finished activating, the activation group passes back a marshalled object reference to the activator that then records the activation identifier and active reference pairing and returns the active (live) reference to the faulting reference. The faulting reference (inside the stub) then forwards method invocations via the live reference directly to the remote object.

10. Unit – 3

11. A socket factory is a class which enables you to provide your own Sockets or ServerSockets to RMI. Applications using RMI can provide their own socket factories, which RMI will use when constructing server and client sockets on behalf of RMI servers and clients. This facility has two principal uses: To superimpose a custom protocol, e.g. an authenticating or encrypting protocol, over the RMI transport protocol. To control the Socket or ServerSocket itself: e.g. to set a client timeout, or to use a specific serverside listening network interface in "multihomed” hosts.

12. Server socket factory classes must implement the interface java.rmi.server.RMIServerSocketFactory and therefore must provide an implementation of its createServerSocket method. import java.rmi.server.*; import java.net.*; import java.io.*; public class MyServerSocketFactory implements MIServerSocketFactory { public createServerSocket(int port) throws IOException { return new ServerSocket(port); } }

13. A client socket factory must implement the interface java.rmi.server.RMIClientSocketFactory and therefore provide an implementation of its createSocket method. import java.rmi.server.*; import java.net.*; import java.io.*; public class MyClientSocketFactory implements RMIClientSocketFactory, Serializable { public createSocket(String host,int port) throws IOException { return new Socket(host,port); } }

14. Secure sockets The Secure Sockets Layer (SSL) superimposes a measure of security over TCP. SSL can be enabled for an RMI service by defining SSL client and server socket factories. HTTP Tunnelling The default RMI socket factory, which is returned by the RMISocketFactory.getDefaultFactory method, implements a three stage Connection technique to penetrate clientside firewalls. (a) direct TCP connection; (b) direct HTTP tunnel; and (c) indirect HTTP tunnel, and that it may be desired to short-circuit this process and go straight to step (c). Multihoming A network host is said to be "multihomed” if it supports more than one network interface—more than one IP address. Such a host might be used at the junction of two IP subnets to act as a router between them, or to virtualize two or more "logical" hosts on a single physical host. By default, a server socket listens at—is bound to—all available network interfaces. You can force a server socket to listen at a specific network interface by using the constructor for ServerSocket which takes three arguments: a port, a backlog, and an InetAddress.

15. public class MultiHomedServerSocketFactory implements RMIServerSocketFactory { private InetAddressbindAddr; // Constructor public MultiHomedServerSocketFactory(InetAddress bindAddr) { this.bindAddr = bindAddr; } public ServerSocket createServerSocket(int port) throws IOException { return new ServerSocket(port,0,bindAddr); } }