Download Object Models for Distributed Systems

Presentation 13:
RMI continued – more advanced issues: Activation &
RMI over IIOP
Goals of this lesson
• After this 1x35 lessons you will be
• Introduced to Activation framework and rmid
• Introduced to RMI over IIOP
Outline
• Theory: (35 min.)
• The Java RMI Activation framework (UDGÅR!)
• Java RMI over IIOP
Architecture
Client
lookup
Stub
rmic generated
Server
coded manually
Registry
Interfaces
bind
Skeleton
rmic generated
Activation
Interfaces
RMI Runtime (rmid,rmiregistry)
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
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
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
Architecture
Client
lookup
Stub
rmic generated
Server
coded manually
Registry
Interfaces
bind
NEW: register
Skeleton
rmic generated
Activation
Interfaces
RMI Runtime (rmid,rmiregistry)
Activation in Java
Java VM1
Stub
Faulting
Reference
2: create object
in VM
Live Activaref tion ID
Java VM2
3: pass
object ref
AG1
AG2
Activator
1: activate
4: update
live ref
Client Host
Activation Descriptors:
ActGroup ClassName URL
Init
AG1
Team
www.bvb.de/…
AG2
Player
www.bvb.de/…
AG2
Player
www.bvb.de/…
AG2
Player
www.bvb.de/…
Host www.bvb.de
package examples.hello;
import java.rmi.*;
import java.rmi.activation.*;
Server object
(HelloImpl.java)
public class HelloImpl extends Activatable implements Hello {
public HelloImpl (ActivationID id, MarshalledObject data) throws
RemoteException {
super(id, o);
Register the object with the activation system
}
then export it on an anonymous port
public String sayHello() {
return "Hello World! ;
}
}
Client and interface Hello
does not change!!!
package examples.hello;
import java.rmi.*;
import java.rmi.activation.*;
import java.util.Properties;
Setup.java – contact
with rmid & registry
public class Setup {
public static void main(String[] args) throws Exception {
System.setSecurityManager(new RMISecurityManager());
Because of the 1.2 security model,
a security policy must be
specified for the ActivationGroup VM.
grant {
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);
}
// Allow everything for now
permission java.security.AllPermission;
Once the ActivationGroupDesc
has been created, register
it with the activation
system to obtain its ID
Register with the rmid
daemon
Register the class
(bind it) in the ”rmiregistry”
BUT DO NOT INSTANTIATE!
}
HelloImpl obj = new HelloImpl();
// Bind this object instance to the name "HelloServer"
Naming.rebind("rmi://192.168.1.101/HelloServer", obj);
RMI over IIOP - CORBA 2.3->
• 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 - IIOP
• With some restrictions
• This is done in the J2EE EJB technology (IIOP comes with a
price – not as many features + narrow needed)
• Allows for using CORBA services – like the orbd Naming Service
RMI over IIOP – implementation
• http://java.sun.com/j2se/1.4.2/docs/guide/rmi-iiop/
//HelloInterface.java
import java.rmi.Remote;
public interface HelloInterface extends java.rmi.Remote {
public void sayHello( String from ) throws java.rmi.RemoteException;
}
Interface – no changes
//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();
}
}
Implementation a bit foreign
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();
}
}
}
JNDI: Java Naming and Directory Service
– decoupling of Naming Service (e.g. orbd)
InitialContext -> contact to server
//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.");
We still use “lookup” but now we
Use the ”initial context” from
the Naming services (ORB)
// STEP 2: Narrow the object reference to the concrete type and
// invoke the method.
hi = (HelloInterface) PortableRemoteObject.narrow(
We call narrow because this
objref, HelloInterface.class);
hi.sayHello( " MARS " );
Object is only valid in the server
} catch( Exception e ) {
System.err.println( "Exception " + e + "Caught" );
e.printStackTrace( );
return;
}
}
}
VM – ”narrow” one to this VM
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.CNCtxF
actory -Djava.naming.provider.url=iiop://localhost:1050
HelloServer
• Start the Client
• java -classpath . Djava.naming.factory.initial=com.sun.jndi.cosnaming.CNCtxF
actory -Djava.naming.provider.url=iiop://localhost:1050
HelloClient
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 28.3.2 of the Java Language to IDL Mapping specification for
the Java to IDL name mapping rules.
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
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 RMIIIOP 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.
Alignment med læringsmål
Når kurset er færdigt forventes den studerende at kunne:
• redegøre for de grundlæggende principper og teknikker omkring
interproceskommunikation over såvel lokalnetværk som Internettet
• redegøre for teknikker for distribuerede objektorienterede løsninger,
herunder serialisering, marshalling, stub/skeleton, proxy, brug af
At kunne afgøre
hvilken teknologi forskellige Interface Definition Language sprog som udviklingskontrakt
der skal vælges
• redegøre for principperne omkring transparens og heterogenitet
(platforms og programmeringssprogs uafhængighed)
• redegøre for anvendelsen af Java RMI, XML/SOAP (Webservices),
herunder forskelle/ligheder, fordele/ulemper teknologierne imellem.
Samt på overordnet niveau have kendskab til forskelle og ligheder med
CORBA og .NET Remoting teknologierne
• anvende socket programmering til at lave et mindre distribueret system
baseret på objektorienterede principper
• anvende objektorienterede teknikker og arkitekturer til at designe og
Java RMI er ikke kun
JRMP baseret. programmere netværksforbindelser ved brug af middleware, og bevise
dette ved at konstruere og dokumentere to distribuerede systemer der
Det bliver helt anderledes
heterogent ved brug
IIOP. af ovenstående teknologier
gørafbrug
MEN – prisen er access transparency
der falder lidt, mens location stiger en
smule pga. mulighed for COS Naming.
Her må .NET Remotings strategy siges at være bedre