Presentation 13: RMI continued – more advanced issues: Activation & RMI over IIOP

Ingeniørhøjskolen i Århus Slide 2 af 18 Goals of this lesson After this 1x35 lessons you will be –Introduced to Activation framework and rmid –Introduced to RMI over IIOP

Ingeniørhøjskolen i Århus Slide 3 af 18 Outline Theory: (35 min.) –The Java RMI Activation framework (UDGÅR!) –Java RMI over IIOP

Ingeniørhøjskolen i Århus Slide 4 af 18 Architecture ServerClient Stub Registry Interfaces Skeleton Activation Interfaces RMI Runtime (rmid,rmiregistry) coded manually rmic generated bind lookup

Ingeniørhøjskolen i Århus Slide 5 af 18 Experience from the HelloWorld tutorial What happens after we create the server implementation object and bind it to the registry? –For how long does this object remain in memory? –When is this a clever approach? –When is this not the case What is our options? –=>RMI Activation

Ingeniørhøjskolen i Århus Slide 6 af 18 Activation Smart for objects that are rarely used And in systems with MANY object Solves problem running a large number of idle RMI services Allows for registering without getting instantiated Not smart for objects with frequent use –Needs to save and load state on persistent storage = performance degrading

Ingeniørhøjskolen i Århus Slide 7 af 18 How it works Remote method invocation activation system daemon (rmid) – listening for request Services lie dormant until invoked then activated Faulting reference from rmiregistry instead of service – has two –ActivationID: identifies the service –Liveref: when service is activated, a life reference Faulting reference via rmid invokes service by first call ActivationGroup ties the class with the rmid daemon – more ActivationID’s per group. 1 Group = 1 JVM

Ingeniørhøjskolen i Århus Slide 8 af 18 Architecture ServerClient Stub Registry Interfaces Skeleton Activation Interfaces RMI Runtime (rmid,rmiregistry) coded manually rmic generated bind lookup NEW: register

Ingeniørhøjskolen i Århus Slide 9 af 18 Activation in Java Client Host Stub Faulting Reference Live ref Hostwww.bvb.de Activa- tion ID Activator Activation Descriptors: ActGroup ClassName URL Init AG 1 Teamwww.bvb.de/… AG 2 Playerwww.bvb.de/… AG 2 Playerwww.bvb.de/… AG 2 Playerwww.bvb.de/… Java VM 1 2 AG 1 2 1: activate 2: create object in VM 3: pass object ref 4: update live ref

Ingeniørhøjskolen i Århus Slide 10 af 18 package examples.hello; import java.rmi.*; import java.rmi.activation.*; public class HelloImpl extends Activatable implements Hello { public HelloImpl (ActivationID id, MarshalledObject data) throws RemoteException { super(id, o); } public String sayHello() { return "Hello World! ; } Server object (HelloImpl.java) Register the object with the activation system then export it on an anonymous port Register the object with the activation system then export it on an anonymous port Client and interface Hello does not change!!! Client and interface Hello does not change!!!

Ingeniørhøjskolen i Århus Slide 11 af 18 package examples.hello; import java.rmi.*; import java.rmi.activation.*; import java.util.Properties; public class Setup { public static void main(String[] args) throws Exception { System.setSecurityManager(new RMISecurityManager()); Properties props = new Properties(); props.put("java.security.policy", "policy"); ActivationGroupDesc.CommandEnvironment ace = null; ActivationGroupDesc exampleGroup = new ActivationGroupDesc(props, ace); ActivationGroupID agi = ActivationGroup.getSystem().registerGroup(exampleGroup); String location = "file:/C:/dev/examples/activation/"; MarshalledObject data = null; ActivationDesc desc = new ActivationDesc(agi, "examples.activation.HelloImpl",location, data); MyRemoteInterface mri = (MyRemoteInterface) Activatable.register(desc); Naming.rebind(“HelloImpl", mri); System.exit(0); } Setup.java – contact with rmid & registry Once the ActivationGroupDesc has been created, register it with the activation system to obtain its ID Once the ActivationGroupDesc has been created, register it with the activation system to obtain its ID Because of the 1.2 security model, a security policy must be specified for the ActivationGroup VM. Register the class (bind it) in the ”rmiregistry” BUT DO NOT INSTANTIATE! Register the class (bind it) in the ”rmiregistry” BUT DO NOT INSTANTIATE! Register with the rmid daemon Register with the rmid daemon HelloImpl obj = new HelloImpl(); // Bind this object instance to the name "HelloServer" Naming.rebind("rmi:// /HelloServer", obj); HelloImpl obj = new HelloImpl(); // Bind this object instance to the name "HelloServer" Naming.rebind("rmi:// /HelloServer", obj); grant { // Allow everything for now permission java.security.AllPermission; }; grant { // Allow everything for now permission java.security.AllPermission; };

Ingeniørhøjskolen i Århus Slide 12 af 18 RMI over IIOP – RMI på CORBA 2.3-> Sun’s traditionel Java RMI uses the Java Remote Method Protocol (JRMP) This protocol is open – but not supported by many Using the Interoperable Inter-ORB protocol (IIOP) makes RMI compatible with other IIOP technologies – like CORBA over IIOP (with some restrictions) –This is done in the J2EE EJB technology (uses RMI over IIOP) IIOP comes with a price – not as many features –+ need to use Narrow call for stub loading and type casting Allows for using CORBA services – like the orbd Naming Service

Ingeniørhøjskolen i Århus Slide 13 af 18 RMI over IIOP – implementation //HelloInterface.java import java.rmi.Remote; public interface HelloInterface extends java.rmi.Remote { public void sayHello( String from ) throws java.rmi.RemoteException; } //HelloImpl.java import javax.rmi.PortableRemoteObject; public class HelloImpl extends PortableRemoteObject implements HelloInterface { public HelloImpl() throws java.rmi.RemoteException { super(); // invoke rmi linking and remote object initialization } public void sayHello( String from ) throws java.rmi.RemoteException { System.out.println( "Hello from " + from + "!!" ); System.out.flush(); } Interface – no changes Implementation a bit foreign

Ingeniørhøjskolen i Århus Slide 14 af 18 RMI over IIOP – Name binding //HelloServer.java import javax.naming.InitialContext; import javax.naming.Context; public class HelloServer { public static void main(String[] args) { try { // Step 1: Instantiate the Hello servant HelloImpl helloRef = new HelloImpl(); // Step 2: Publish the reference in the Naming Service // using JNDI API Context initialNamingContext = new InitialContext(); initialNamingContext.rebind("HelloService", helloRef ); System.out.println("Hello Server: Ready..."); } catch (Exception e) { System.out.println("Trouble: " + e); e.printStackTrace(); } This should be done in a separate class e.g. HelloImpl This should be done in a separate class e.g. HelloImpl JNDI: Java Naming and Directory Service – decoupling of Naming Service (e.g. orbd) InitialContext -> contact to server JNDI: Java Naming and Directory Service – decoupling of Naming Service (e.g. orbd) InitialContext -> contact to server

Ingeniørhøjskolen i Århus Slide 15 af 18 //HelloClient.java import java.rmi.RemoteException; import java.net.MalformedURLException; import java.rmi.NotBoundException; import javax.rmi.*; import java.util.Vector; import javax.naming.NamingException; import javax.naming.InitialContext; import javax.naming.Context; public class HelloClient { public static void main( String args[] ) { Context ic; Object objref; HelloInterface hi; try { ic = new InitialContext(); // STEP 1: Get the Object reference from the Name Service // using JNDI call. objref = ic.lookup("HelloService"); System.out.println("Client: Obtained a ref. to Hello server."); // STEP 2: Narrow the object reference to the concrete type and // invoke the method. hi = (HelloInterface) PortableRemoteObject.narrow( objref, HelloInterface.class); hi.sayHello( " MARS " ); } catch( Exception e ) { System.err.println( "Exception " + e + "Caught" ); e.printStackTrace( ); return; } We still use “lookup” but now we Use the ”initial context” from the Naming services (ORB) We still use “lookup” but now we Use the ”initial context” from the Naming services (ORB) We call narrow because this Object is only valid in the server VM – ”narrow” one to this VM We call narrow because this Object is only valid in the server VM – ”narrow” one to this VM

Ingeniørhøjskolen i Århus Slide 16 af 18 Getting it up and Running Compile with javac Run rmic –rmic –iiop HelloImpl Run Naming Service –E.g. use orbd tool (persistent naming) –start orbd -ORBInitialPort 1050 Start the HelloServer –java -classpath. - Djava.naming.factory.initial=com.sun.jndi.cosnaming.CNCtxFactor y -Djava.naming.provider.url=iiop://localhost:1050 HelloServer Start the Client –java -classpath. - Djava.naming.factory.initial=com.sun.jndi.cosnaming.CNCtxFactor y -Djava.naming.provider.url=iiop://localhost:1050 HelloClient

Ingeniørhøjskolen i Århus Slide 17 af 18 Restrictions in RMI over IIOP To make existing RMI programs run over IIOP, you need to observe the following restrictions. –Make sure all constant definitions in remote interfaces are of primitive types or String and evaluated at compile time. –Don't use Java names that conflict with IDL mangled names generated by the Java to IDL mapping rules. See section of the Java Language to IDL Mapping specification for the Java to IDL name mapping rules.Java Language to IDL Mapping –Don't inherit the same method name into a remote interface more than once from different base remote interfaces. –Be careful when using names that differ only in case. The use of a type name and a variable of that type whose name differs from the type name only in case is supported. Most other combinations of names that differ only in case are not supported. –Don't depend on runtime sharing of object references to be preserved exactly when transmitting object references across IIOP. Runtime sharing of other objects is preserved correctly. –It is not possible to use the following RMI features when using IIOP: RMISocketFactory UnicastRemoteObject Unreferenced The Distributed Garbage Collector (DGC) interfaces Dynamic class loading via the network

Ingeniørhøjskolen i Århus Slide 18 af 18 How do I interoperate between an RMI-IIOP app and an existing CORBA object? If the existing CORBA object has its remote interfaces defined originally in CORBA IDL, then interoperability is not possible. RMI- IIOP applications can interoperate with other CORBA objects only when their remote interfaces are originally defined as Java RMI interfaces. Also: Objects-by-value must be supported by all involved ORB’s For example, to interoperate between an RMI-IIOP client and a C++ object you would need to: –define the remote interface of the object in Java as an RMI Interface –run rmic -iiop against the interface to produce the stub for your RMI-IIOP client –run rmic -idl against the interface to produce IDL compatible with the RMI interface –run a C++ stub compiler against the IDL file to produce the C++ skeleton for your C++ server object.