Activation
Upcoming SlideShare
Loading in...5
×
 

Activation

on

  • 940 views

Advanced Java Programming - III CSE Anna University Syllabus

Advanced Java Programming - III CSE Anna University Syllabus

Statistics

Views

Total Views
940
Views on SlideShare
940
Embed Views
0

Actions

Likes
0
Downloads
12
Comments
0

0 Embeds 0

No embeds

Accessibility

Upload Details

Uploaded via as Microsoft PowerPoint

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Activation Activation Presentation Transcript

  • Unit – III Roy Antony Arnold G Sr. Lecturer Einstein College of Engineering Tirunelveli, Tamilnadu, India
    • 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
    • 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).
    • 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.
    • 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
  •  
    • 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.
    • 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.
    • 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.
    • Unit – 3
    • 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.
    • 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); } }
    • 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); } }
    • 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.
    • 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);
    • }
    • }