1. Local Objects vs. Distributed Objects
Local objects are those whose methods can only be invoked by a local
process, a process that runs on the same computer on which the object exists.
A distributed object is one whose methods can be invoked by a remote
process, a process running on a computer connected via a network to the
Distributed Object-Based Systems computer on which the object exists.
Tanenbaum, Ch. 10
remote local C
E
invocation invocation local
invocation remote
invocation F
A B local
invocation D
1 3
The Distributed Object Paradigm - 1 The Distributed Object Paradigm - 2
A process running in host A makes a method call to a
The distributed object paradigm is a paradigm that distributed object residing on host B, passing with the call
provides abstractions beyond those of the message- data for the parameters, if any.
passing model. The method call invokes an action performed by the
In object-oriented programming, objects are used to method on host A, and a return value, if any, is passed
represent an entity significant to an application. Each from host A to host B.
object encapsulates: A process which makes use of a distributed object is said
to be a client process of that object, and the methods of
the state or data of the entity: in Java, such data is contained the object are called remote methods (as opposed to local
in the instance variables of each object; methods, or methods belonging to a local object) to the
the operations of the entity, through which the state of the client process.
entity can be accessed or updated.
2 4
1

2. An Archetypal Distributed Objects System Distributed Object System - 2
A similar architecture is required on the server side, where the
object runtime support for the distributed object system handles the
registry
receiving of messages and the unmarshalling of data, and
forwards the call to a software component called the server
object client object server
proxy.
client server The server proxy interfaces with the distributed object to invoke
proxy proxy the method call locally, passing in the unmarshalled data for the
runtime runtime arguments.
support support
The method call results in the performance of some tasks on the
network network server host. The outcome of the execution of the method,
support support including the marshalled data for the return value, is forwarded
by the server proxy to the client proxy, via the runtime support
physical data path and network support on both sides.
logical data path
5 7
Distributed Object System Distributed Object System - 3
Logically, the object client makes a call directly to a remote
method.
In reality, the call is handled by a software component,
called a client proxy, which interacts which the software on
the client host that provides the runtime support for the 2-16
distributed object system. Common organization of a remote object with client-side
proxy.
The runtime support is responsible for the interprocess
communication needed to transmit the call to the remote
host, including the marshalling of the argument data that
needs to be transmitted to the remote object.
6 8
2

3. Distributed Object Systems/Protocols Static vs dynamic remote method invocations
The distributed object paradigm has been widely adopted Typical way for writing code that uses RMI is similar
in distributed applications, for which a large number to the process for writing RPC
declare the interface in IDL, compile the IDL file to generate
of mechanisms based on the paradigm are available. client and server stubs, link them with client and server side
Among the most well known of such mechanisms are: code to generate the client and the server executables
~ Java Remote Method Invocation (RMI), referred to as static invocation
~ the Common Object Request Broker Architecture (CORBA) requires the object interface to be known when the client is
being developed
systems,
Dynamic invocation
~ the Distributed Component Object Model (DCOM),
the method invocation is composed at run-time
~ mechanisms that support the Simple Object Access Protocol invoke(object, method, input_parameters, output_parameters)
(SOAP). useful for applications where object interfaces are
Of these, the most straightforward is the Java RMI discovered at run-time, e.g. object browser, batch processing
systems for object invocations, “agents”
9 11
Persistent vs transient objects
Persistent objects continue to exist even if they
are not contained in the address space of a server
process
The “state” of a persistent object has to be stored Java Remote Method Invocation
on a persistent store, i.e., secondary storage
Invocation requests result in an instance of the
object being created in the address space of a
running process
many policies possible for object instantiation and
(de)instantiation
Transient objects only exist as long as their
container server processes are running
10 12
3

4. Remote Method Invocation Object Registry
Remote Method Invocation (RMI) is an object-oriented The RMI API allows a number of directory services to be used
implementation of the Remote Procedure Call model. It is an for registering a distributed object. One such service is the
API for Java programs only. Java Naming and Directory Interface (JNDI), which is more
Using RMI, an object server exports a remote object and general than the RMI registry, in the sense that it can be used
registers it with a directory service. The object provides by applications that do not use the RMI API.
remote methods, which can be invoked in client programs. We will use a simple directory service called the RMI registry,
Syntactically: rmiregistry, which is provided with the Java Software
A remote object is declared with a remote interface, an extension of the Development Kit (SDK). The RMI Registry is a service whose
Java interface. server, when active, runs on the object server’s host
The remote interface is implemented by the object server. machine, by convention and by default on the TCP port 1099.
An object client accesses the object by invoking the remote methods
associated with the objects using syntax provided for remote method
invocations.
13 15
The Java RMI Architecture The interaction between the stub and the skeleton
Directory service A time-event diagram describing the interaction between
object object
the stub and the skeleton:
client server
supports the interface with stub skeleton Remote
the application program Method
time
marshal parameters;
send Request
maps the platform-independent stub/skeleton stub skeleton unmarshal parameters
layer to the platform-dependent transport Invoke method
layer; carries out remote reference protocols remote reference layer remote reference layer
execute code
transport layer transport layer and return a
sets up, maintains, and shuts down value
receive return value
connections; and carries out the
marshal reply
transport protocol
send reply
logical data path unmarshall reply;
return value
physical data path
(based on http://java.sun.com.marketing/collateral/javarim.html)
14 16
4

5. The API for the Java RMI A sample remote interface
// file: SomeInterface.java
The Remote Interface
// to be implemented by a Java RMI server class.
The Server-side Software import java.rmi.*
The Remote Interface Implementation public interface SomeInterface extends Remote {
// signature of first remote method
Stub and Skeleton Generations public String someMethod1( )
The Object Server throws java.rmi.RemoteException;
// signature of second remote method
The Client-side Software public int someMethod2( float ) throws
java.rmi.RemoteException;
// signature of other remote methods may follow
} // end interface
17 19
The Remote Interface A sample remote interface - 2
A Java interface is a class that serves as a template for The java.rmi.Remote exception must be listed in the
other classes: it contains declarations or signatures of throw clause of each method signature.
methods whose implementations are to be supplied by This exception is raised when errors occur during the
classes that implements the interface. processing of a remote method call, and the exception
A java remote interface is an interface that inherits is required to be caught in the method caller’s program.
from the Java Remote class, which allows the interface Causes of such exceptions include exceptions that may
to be implemented using RMI syntax. Other than the occur during interprocess communications, such as
Remote extension and the Remote exception that must access failures and connection failures, as well as
be specified with each method signature, a remote problems unique to remote method invocations,
interface has the same syntax as a regular or local Java including errors resulting from the object, the stub, or
interface. the skeleton not being found.
18 20
5

6. The Server-side Software UML diagram for the SomeImpl class
An object server is an object that provides the SomeInterface
methods of and the interface to a distributed object. UnicastRemoteObject Method1
Method2
Each object server must ...
implement each of the remote methods specified in the
interface,
register an object which contains the implementation with SomeImpl
a directory service. Method1
It is recommended that the two parts be provided as Method2
separate classes. ...
UMLDiagram for SomeImpl
21 23
The Remote Interface Implementation Stub and Skeleton Generations
A class which implements the remote interface should be provided. The syntax is
similar to a class that implements a local interface. In RMI, each distributed object requires a proxy each for the object server
and the object client, knowns as the object’s skeleton and stub respectively.
import java.rmi.*; These proxies are generated from the implementation of a remote interface
import java.rmi.server.*; using a tool provided with the Java SDK: the RMI compiler rmic.
/**
rmic <class name of the remote interface implementation>
* This class implements the remote interface SomeInterface.
*/ For example:
public class SomeImpl extends UnicastRemoteObject rmic SomeImpl
implements SomeInterface {
public SomeImpl() throws RemoteException { As a result of the compilation, two proxy files will be generated, each
super( ); prefixed with the implementation class name:
} SomeImpl_skel.class
public String someMethod1( ) throws RemoteException { SomeImpl_stub.class.
// code to be supplied
}
public int someMethod2( ) throws RemoteException {
// code to be supplied
}
} // end class 22 24
6

7. The stub file for the object The Object Server - 2
// This method starts a RMI registry on the local host, if it
The stub file for the object, as well as the remote // does not already exists at the specified port number.
private static void startRegistry(int RMIPortNum)
interface file, must be shared with each object client – throws RemoteException{
try {
these file are required for the client program to Registry registry= LocateRegistry.getRegistry(RMIPortNum);
registry.list( );
compile. // The above call will throw an exception
// if the registry does not already exist
A copy of each file may be provided to the object }
catch (RemoteException ex) {
client by hand. In addition, the Java RMI has a feature // No valid registry at that port.
System.out.println(
called “stub downloading” which allows a stub file to "RMI registry cannot be located at port " + RMIPortNum);
Registry registry= LocateRegistry.createRegistry(RMIPortNum);
be obtained by a client dynamically. System.out.println(
"RMI registry created at port " + RMIPortNum);
}
} // end startRegistry
25 27
The Object Server The Object Server - 3
The object server class is a class whose code instantiates and exports an In our object server template, the code for exporting an object is as follows:
object of the remote interface implementation. Figure 10 shows a template // register the object under the name “some”
for the object server class. registryURL = "rmi://localhost:" + portNum +
import java.rmi.*;
…… "/some";
public class SomeServer { Naming.rebind(registryURL, exportedObj);
public static void main(String args[]) { The Naming class provides methods for storing and obtaining references from the registry. In
try{ particular, the rebind method allow an object reference to be stored in the registry with a URL
// code for port number value to be supplied in the form of
SomeImpl exportedObj = new SomeImpl(); rmi://<host name>:<port number>/<reference name>
startRegistry(RMIPortNum);
The rebind method will overwrite any reference in the registry bound with the given reference
// register the object under the name “some”
name. If the overwriting is not desirable, there is also a bind method.
registryURL = "rmi://localhost:" + portNum + "/some";
Naming.rebind(registryURL, exportedObj);
The host name should be the name of the server, or simply “localhost”. The reference name is
a name of your choice, and should be unique in the registry.
System.out.println("Some Server ready.");
}// end try
} // end main
26 28
7

8. The RMI Registry The Object Server - 5
A server exports an object by registering it by a symbolic name with a server known as
the RMI registry. When an object server is executed, the exporting of the
// Create an object of the Interface distributed object causes the server process to begin to
SomeInterfacel obj = new SomeInterface(“Server1”);
// Register the object; rebind will overwrite existing
listen and wait for clients to connect and request the
// registration by same name – bind( ) will not. service of the object.
Naming.rebind(“Server1”, obj);
A server, called the RMI Registry, is required to run on the host of the server which
An RMI object server is a concurrent server: each
exports remote objects. request from an object client is serviced using a
The RMIRegistry is a server located at port 1099 by default
It can be invoked dynamically in the server class:
separate thread of the server. Note that if a client
import java.rmi.registry.LocateRegistry; process invokes multiple remote method calls, these
…
LocateRegistry.createRegistry ( 1099 );
calls will be executed concurrently unless provisions
… are made in the client process to synchronize the calls.
29 31
The RMI Registry - 2 The Client-side Software
Alternatively, an RMI registry can be activated by The program for the client class is like any other Java
hand using the rmiregistry utility which comes with the class.
Java Software Development Kit (SDK), as follows:
The syntax needed for RMI involves
rmiregistry <port number>
locating the RMI Registry in the server host,
where the port number is a TCP port number. If no and
port number is specified, port number 1099 is assumed.
looking up the remote reference for the server object; the
The registry will run continuously until it is shut down reference can then be cast to the remote interface class and
(via CTRL-C, for example) the remote methods invoked.
30 32
8

9. The Client-side Software - 2 Invoking the Remote Method
import java.rmi.*;
….
public class SomeClient {
The remote interface reference can be used to invoke
public static void main(String args[]) { any of the methods in the remote interface, as in the
try {
String registryURL = example:
"rmi://localhost:" + portNum + "/some";
SomeInterface h = String message = h.method1();
(SomeInterface)Naming.lookup(registryURL); System.out.println(message);
// invoke the remote method(s)
String message = h.method1(); Note that the syntax for the invocation of the remote
System.out.println(message);
// method2 can be invoked similarly
methods is the same as for local methods.
} // end try
catch (Exception e) {
It is a common mistake to cast the object retrieved
System.out.println("Exception in SomeClient: " + e); from the registry to the interface implementation class
}
} //end main or the server object class . Instead it should be cast as
// Definition for other methods of the class, if any.
}//end class
the interface class.
33 35
Looking up the remote object
The lookup method of the Naming class is used to
retrieve the object reference, if any, previously stored
in the registry by the object server. Note that the
retrieved reference must be cast to the remote
Steps for building an RMI application
interface (not its implementation) class.
String registryURL =
"rmi://localhost:" + portNum + "/some";
SomeInterface h =
(SomeInterface)Naming.lookup(registryURL);
34 36
9

10. Developing the server-side software Placement of files for a RMI application
1. Open a directory for all the files to be generated for this application.
2. Specify and compile the remote-server interface in SomeInterface.java
3. Implement and compile the interface in SomeImpl.java
Object Client host Object Server host
4. Use the RMI compiler rmic to process the implementation class and
generate the stub file and skelton file for the remote object: object server directory
rmic SomeImpl object client directory
SomeInterface.class
The files generated can be found in the directory as
SomeImpl_Skel.class and SomeImpl_Stub.class. SomeInterface.class SomeServer.class
Steps 3 and 4 must be repeated each time that a change is made to the SomeImpl.class
interface implementation. SomeClient.class
5. Create and compile the object server program SomeServer.java. SomeImpl_Skel.class
SomeImpl_Stub.class
6. Activate the object server
java SomeServer
37 39
Developing the client-side software Testing and Debugging an RMI Application
1. Open a directory for all the files to be generated for this application. 1. Build a template for a minimal RMI program. Start with a remote interface
2. Obtain a copy of the remote interface class file. Alternatively, obtain a with a single signature, its implementation using a stub, a server program
copy of the source file for the remote interface, and compile it using javac which exports the object, and a client program which invokes the remote
to generate the interface class file. method. Test the template programs on one host until the remote method can
3. Obtain a copy of the stub file for the implementation of the interface: be made successfully.
SomeImpl_Stub.class. 2. Add one signature at a time to the interface. With each addition, modify the
4. Develop the client program SomeClient.java, and compile it to generate client program to invoke the added method.
the client class. 3. Fill in the definition of each remote method, one at a time. Test and
5. Activate the client. thoroughly debug each newly added method before proceeding with the next
one.
java SomeClient 4. After all remote methods have been thoroughly tested, develop the client
application using an incremental approach. With each increment, test and
debug the programs.
38 40
10

11. Comparison of the RMI and the socket APIs Diagrams for the Hello application
The remote method invocation API is an efficient tool
for building network applications. It can be used in HelloInterface
lieu of the socket API in a network application. Some
of the tradeoffs between the RMI API and the socket UnicastRemoteObject
sayHello( )
API are as follows:
HelloServer HelloImpl
The socket API is closely related to the operating system, HelloClient
and hence has less execution overhead. For applications listRegistry( )
which require high performance, this may be a consideration. startRegistry( )
UML diagram
The RMI API provides the abstraction which eases the task client registry server
of software development. Programs developed with a higher rebind( )
level of abstraction are more comprehensible and hence look up( )
easier to debug. sayHello( )
sequence diagram
41 43
HelloInterface.java
import java.rmi.*;
public interface HelloInterface
The HelloWorld Sample extends Remote {
public String sayHello(String name)
throws java.rmi.RemoteException;
}
42 44
11

12. HelloImpl.java Running the Client
import java.rmi.*;
import java.rmi.server.*; % java HelloClient
Enter the RMIRegistry host number:
public class HelloImpl extends UnicastRemoteObject localhost
implements HelloInterface { Enter the RMIRegistry port number:
3232
public HelloImpl() throws RemoteException { Lookup completed
super();
HelloClient: Hello, World! Daffy Duck
}
%
public String sayHello(String name)
throws RemoteException {
return "Hello, World! " + name;
}
}
45 47
import java.io.*;
import java.rmi.*; HelloServer.java
import java.rmi.server.*;
import java.rmi.*;
HelloClient.java import java.rmi.registry.Registry; (overall structure)
public class HelloClient { import java.rmi.registry.LocateRegistry;
public static void main(String args[ ]) {
import java.net.*;
try {
int RMIPort; import java.io.*;
String hostName;
InputStreamReader is = new InputStreamReader(System.in); public class HelloServer {
BufferedReader br = new BufferedReader(is);
public static void main(String args[ ]) {
System.out.println("Enter the RMIRegistry host number: ");
hostName = br.readLine(); …
System.out.println("Enter the RMIRegistry port number: "); }
String portNum = br.readLine(); private static void startRegistry(int RMIPortNum)
RMIPort = Integer.parseInt(portNum); throws RemoteException {
String registryURL = "rmi://"+hostName+":"+portNum+"/hello";
…
HelloInterface h = (HelloInterface)Naming.lookup(registryURL);
System.out.println("Lookup completed "); }
String message = h.sayHello("Daffy Duck"); private static void listRegistry(String registryURL)
System.out.println("HelloClient: " + message); } throws RemoteException, MalformedURLException
catch (Exception e) { {
System.out.println("Exception in HelloClient: " + e);
…
}
} }
} }
46 48
12

13. public static void main(String args[ ]) {
InputStreamReader is = new InputStreamReader(System.in);
BufferedReader br = new BufferedReader(is);
String portNum, registryURL;
private static void listRegistry(String registryURL)
try{
System.out.println("Enter the RMIregistry port throws RemoteException, MalformedURLException
number:"); {
portNum = (br.readLine()).trim(); System.out.println("Registry " + registryURL + "
int RMIPortNum = Integer.parseInt(portNum); contains:");
startRegistry(RMIPortNum); String[] names = Naming.list(registryURL);
HelloImpl exportedObj = new HelloImpl();
for (int i =0;i< names.length;i++)
registryURL = "rmi://localhost:" + portNum + "/hello";
Naming.rebind(registryURL,exportedObj); System.out.println(names[i]);
System.out.println("Server registered. Registry }
currently contains:");
listRegistry(registryURL);
System.out.println("Hello Server ready.");
} //end try
catch (Exception re) { HelloServer.java
System.out.println("Exception in HelloServer.main: " +
re); (listRegistry)
}
}
HelloServer.java
(main) 49 51
// This method starts an RMI registry at port RMIPortNum if Running the Server
// it does not already exist.
private static void startRegistry(int RMIPortNum) throws
RemoteException { % java HelloServer
try {
Enter the RMIregistry port number:
Registry registry = LocateRegistry.getRegistry(RMIPortNum);
registry.list();
3232
} RMI registry cannot be located at port 3232
catch (RemoteException e) { RMI registry created at port 3232
System.out.println("RMI registry cannot be located at port Server registered. Registry currently contains:
" + RMIPortNum); Registry rmi://localhost:3232/hello contains:
Registry registry = //localhost:3232/hello
LocateRegistry.createRegistry(RMIPortNum);
Hello Server ready.
System.out.println("RMI registry created at port " +
RMIPortNum);
HelloServer.java
(startRegistry)
50 52
13

14. Polling vs. Callback
In the absence of callback, a client will have to poll a
passive server repeatedly if it needs to be notified that
an event has occurred at the server end.
RMI Callbacks Polling Callback
Server Server
...
Client Client
A client registers itself with the
A client issues a request to the
server, and wait until the server
server repeatedly until the
calls back.
desired response is obtained.
a remote method call
53 55
Introduction Two-way communications
Some applications require that both sides may initiate IPC.
In the client server model, the server is passive: the IPC Using sockets, duplex communication can be achieved by using
is initiated by the client; the server waits for the arrival two sockets on either side.
of requests and provides responses. With connection-oriented sockets, each side acts as both a
client and
Some applications require the server to initiate
communication upon certain events. Examples applications a server.
are: Process 1
Process 1
• monitoring
• games request
• auctioning response
• voting/polling
• chat-toom
• message/bulletin board request
• groupware
response
54 56
14

15. RMI Callbacks Callback application files
A callback client registers itself with an RMI server. Object client host Object server host
The server makes a callback to each registered client
upon the occurrence of a certain event. object client directory object server directory
Server
Clients Client.class Server.class
C1
ClientInterface.class S erverInterface.class
The callback list
S erverInterface.class ClientInterface.class
C2
ClientImpl.class ServerImpl.class
RMI calls
C3
callback
S erverImpl_S tub.class ClientImpl_S tub.class
C4
ClientImpl_skel.class S erverImpl_skel.class
C5
57 59
Callback Client-Server Interactions RMI Callback file placements
Server host
Client host
1
Client.class 2 RMI registry
Client host Server host
SomeInterface_stub.class
client directory server directory
3,4 SomeClient.class SomeServer.class
SomeInterface_skel.class
CallbackInterface_skel.class SomeInterface_stub.class
X
SomeServer.class SomeInterface.Skeleton.class
java.policy
CallbackInterface_skel.class
5 CallbackInterface_stub.class
CallbackInterface_stub.class
1. Client looks up the interface object in the RMIregistry on the server host. java.polcy
2. The RMIRegistry returns a remote reference to the interface object.
3. Via the server stub, the client process invokes a remote method to register itself for callback,
passing a remote reference to itself to the server. The server saves the reference in its callback list. HTTP Server
4. Via the server stub, the client process interacts with the skeleton of the interface object
to access the methods in the interface object.
SomeInterface_stub.class
5. When the anticipated event takes place, the server makes a callback to each registered
client via the callback interface stub on the server side and the callback interface skeleton on the
client side.
58 60
15

16. The Hello Application with Callback Remote Interface for Server
CallbackClient
HelloInterface
public interface HelloInterface extends Remote {
Interface
UnicastRemoteObject
sayHello( ) notifyMe( ) UnicastRemoteObject // remote method
public String sayHello() throws java.rmi.RemoteException;
HelloServer HelloImpl
C al lbackClie nt
C allbackC lie nt
mpl // method to be invoked by a client to add itself to the
callback list
public void addCallback(
listRegistry( )
startRegistry( )
UML diagram
HelloCallbackInterface CallbackObject)
client registry server throws java.rmi.RemoteException;
}
rebind( )
look up( )
sayHello( )
addCallback ( )
notifyMe( )
sequence diagram
61 63
Remote Interface for Callback
RMI Callback Interface
Client
The server provides a remote method which allows a // an interface specifying a callback method
client to register itself for callbacks. public interface HelloCallbackInterface extends java.rmi.Remote
A Remote interface for the callback is needed, in {
addition to the server-side interface. // method to be called by the server on callback
The interface specifies a method for accepting a callback public void callMe (
from the server. String message
The client program is a subclass of RemoteObject and ) throws java.rmi.RemoteException;
implements the callback interface, including the callback }
method.
The client registers itself for callback in its main
method.
The server invokes the client’s remote method upon the
occurrence of the anticipated event.
62 64
16

17. Alogorithm for building an RMI
HelloServer, with callback Callback Application
public class HelloServer extends UnicastRemoteObject implements Server side:
HelloInterface { 1. Open a directory for all the files to be generated for this
static int RMIPort; application.
// vector for store list of callback objects 2. Specify the remote-server interface, and compile it to generate
private static Vector callbackObjects; the interface class file.
3. Build the remote server class by implementing the interface, and
public HelloServer() throws RemoteException { compile it using javac.
super();
4. Use rmic to process the server class to generate a stub.class file
// instantiate a Vector object for storing callback objects and a skelton.class file: rmic SomeServer
callbackObjects = new Vector();
5. If stub downloading is desired, copy the stub file to an
}
appropriate directory on the HTTP host.
// method for client to call to add itself to its callback
6. Activate the RMIRegistry, if it has not already been activated.
public void addCallback( HelloCallbackInterface CallbackObject) {
// store the callback object into the vector 7. Set up a java.policy file.
System.out.println("Server got an 'addCallback' call."); 8. Activate the server, specifying (i) the codebase if stub
callbackObjects.addElement (CallbackObject); downloading is desired, (ii) the server host name, and (iii) the
}
security policy file.
9. Obtain the CallbackInterface. Compile it with javac, then use
65 rmic to generate the stub file for the callback. 67
Alogorithm for building an RMI
HelloServer, with callback - 2 Callback Application
public static void main(String args[]) { Client side:
…
1. Open a directory for all the files to be generated for
registry = LocateRegistry.createRegistry(RMIPort);
this application.
…
callback( ); 2. Implement the client program or applet, and compile it
… to generate the client class.
} // end main 3. If stub downloading is not in effect, copy the server
private static void callback( ) { interface stub class file by hand.
… 4. Implement the callback interface. Compile it using
for (int i = 0; i < callbackObjects.size(); i++) { javac, then using rmic to generate a stub class and a
System.out.println("Now performing the "+ i +"th callbackn"); skeleton class for it.
// convert the vector object to a callback object
5. Set up a java.policy file.
HelloCallbackInterface client =
(HelloCallbackInterface) callbackObjects.elementAt(i); 6. Activate the client, specifying (i) the server host
… name, and (ii) the security policy file.
client.callMe ( "Server calling back to client " + i);
…
66 68
17

18. HelloClient, with callback
HelloClient() { // constructor
System.setSecurityManager(new RMISecurityManager());
// export this object as a remote object
UnicastRemoteObject.exportObject(this);
// …
Registry registry = LocateRegistry.getRegistry("localhost", RMIPort);
h = (HelloInterface) registry.lookup("helloLiu");
h.addCallback(this); // … The Common Object
Request Broker
} // end constructor
// call back method - this displays the message sent by the server
public void callMe (String message) {
}
System.out.println( "Call back received: " + message );
public static void main(String args[]) { // …
Architecture (CORBA)
HelloClient client = new HelloClient(); // …
while (true){
; } // end while
} // end main
} // end HelloClient class
69 71
HelloServer, HelloClient CORBA
UnicastRemoteObject HelloInterface UnicastRemoteObject CallbackInterface
The Common Object Request Broker
Architecture (CORBA) is a standard
sayHello sayHello
HelloServer HelloClient
RMIPort
architecture for a distributed objects
system.
RMIPort
sayHello
sayHello
addCallback callMe
Class Diagram for HelloServer Class Diagram for HelloClient
CORBA is designed to allow distributed
HelloClient RMIregistry HelloServer
objects to interoperate in a heterogenous
getRegistry environment, where objects can be
sayHello
implemented in different programming
language and/or deployed on different
addCallback
platforms
callMe
Event diagram for the Hello application
70 72
18

19. CORBA vs. Java RMI The Basic Architecture
CORBA differs from the architecture of naming
lookup
Java RMI in one significant aspect:
object
naming service object client
implementation
RMI is a proprietary facility developed by Sun
MicroSystems, Inc., and supports objects stub skeleton
written in the Java programming langugage only.
ORB ORB
CORBA is an architecture that was developed
by the Object Management Group (OMG), an network network
industrial consortium.
operating operating
system system
logical data flow
physical data flow
73 75
CORBA CORBA Object Interface
A distributed object is defined using a software file similar to
CORBA is not in inself a distributed objects the remote interface file in Java RMI.
facility; instead, it is a set of protocols. Since CORBA is language independent, the interface is defined
using a universal language with a distinct syntax, known as the
A distributed object facility which adhere to CORBA Interface Definition Language (IDL).
these protocols is said to be CORBA-compliant, The syntax of CORBA IDL is similar to Java and C++. However,
and the distributed objects that the facility object defined in a CORBA IDL file can be implemented in a
large number of diverse programming languages, including C, C++,
support can interoperate with objects supported Java, COBOL, Smalltalk, Ada, Lisp, Python, and IDLScript.
by other CORBA-compliant facilities. For each of these languages, OMG has a standardized mapping
CORBA is a very rich set of protocols. We will from CORBA IDL to the programming language, so that a
compiler can be used to process a CORBA interface to generate
instead focus on the key concepts of CORBA the proxy files needed to interface with an object
related to the distributed objects paradigm. We implementation or an object client written in any of the CORBA-
will also study a facility based on CORBA: the Java compatible languages.
IDL.
74 76
19

20. Cross-language CORBA application Inter-ORB Protocols
The IIOP specification includes the following elements:
1. Transport management requirements: specifies the
connection and disconnection requirements, and the roles for
the object client and object server in making and unmaking
object implementation written
object client written in Java connections.
in C++
2. Definition of common data representation: a coding scheme
skeleton in C ++ ge ne rate d by
for marshalling and unmarshalling data of each IDL data type.
stub in Java generated by compiling
the C O RBA obje ct inte rface compiling the C O RBA obje ct 3. Message formats: different types of message format are
inte rface
defined. The messages allow clients to send requests to object
servers and receive replies. A client uses a Request message to
ORB written in Java ORB written in C++ invoke a method declared in a CORBA interface for an object
and receives a reply message from the server.
77 79
Inter-ORB Protocols Object Bus
An ORB which adheres to the specifications of the IIOP
To allow ORBs to be interoperable, the OMG may interoperate with any other IIOP-compliant ORBs over
the Internet. This gives rise to the term “object bus”,
specified a protocol known as the General where the Internet is seen as a bus that interconnects
Inter-ORB Protocol (GIOP), a specification CORBA objects
which “provides a general framework for
CORBA CORBA CORBA
protocols to be built on top of specific object object object
transport layers.”
A special case of the protocol is the Inter- ORB ORB ... ORB
ORB Protocol (IIOP), which is the GIOP
applied to the TCP/IP transport layer.
The Internet
78 80
20

21. ORB products CORBA Object References
There are a large number of proprietary as As in Java RMI, a CORBA distributed
well as experimental ORBs available: object is located using an object
(See CORBA Product Profiles, reference. Since CORBA is language-
http://www.puder.org/corba/matrix/) independent, a CORBA object reference is
Orbix IONA an abstract entity mapped to a language-
Borland Visibroker specific object reference by an ORB, in a
PrismTech’s OpenFusion representation chosen by the developer of
Web Logic Enterprise from BEA
the ORB.
Ada Broker from ENST For interoperability, OMG specifies a
Free ORBs protocol for the abstract CORBA object
reference object, known as the
Interoperable Object Reference (IOR)
81 protocol. 83
Object Servers and Object Interoperable Object Reference
Clients (IOR)
As in Java RMI, a CORBA distributed For interoperability, OMG specifies a
object is exported by an object server, protocol for the abstract CORBA object
similar to the object server in RMI. reference object, known as the
An object client retrieves a reference to a Interoperable Object Reference (IOR)
distributed object from a naming or protocol.
directory service, to be described, and An ORB compatible with the IOR protocol
invokes the methods of the distributed will allow an object reference to be
object. registered with and retrieved from any
IOR-compliant directory service. CORBA
object references represented in this
protocol are called Interoperable Object
82
References (IORs). 84
21

22. Interoperable Object Reference
CORBA Naming Service
(IOR)
An IOR is a string that contains encoding for CORBA specifies a generic directory service. The
the following information: Naming Service serves as a directory for CORBA
objects, and, as such, is platform independent and
The type of the object.
programming language independent.
The host where the object can be found.
The Naming Service permits ORB-based clients to
The port number of the server for that object. obtain references to objects they wish to use. It
An object key, a string of bytes identifying the allows names to be associated with object
object. references. Clients may query a naming service
The object key is used by an object server to using a predetermined name to obtain the associated
locate the object. object reference.
85 87
Interoperable Object Reference
CORBA Naming Service
(IOR)
The following is an example of the string To export a distributed object, a CORBA object
representation of an IOR [5]: server contacts a Naming Service to bind a
IOR:000000000000000d49444c3a677269643a312e3000000 symbolic name to the object The Naming Service
00000000001000000000000004c0001000000000015756c74 maintains a database of names and the objects
72612e6475626c696e2e696f6e612e6965000009630000002 associated with them.
83a5c756c7472612e6475626c696e2e696f6e612e69653a67 To obtain a reference to the object, an object
7269643a303a3a49523a67726964003a client requests the Naming Service to look up the
The representation consists of the character object associated with the name (This is known as
prefix “IOR:” followed by a series of resolving the object name.)
hexadecimal numeric characters, each The API for the Naming Service is specified in
character representing 4 bits of binary data in interfaces defined in IDL, and includes methods
that allow servers to bind names to objects and
the IOR. clients to resolve those names.
86 88
22

23. CORBA Naming Service A CORBA object name
To be as general as possible, the CORBA object naming
scheme is necessary complex. Since the name space is
universal, a standard naming hierarchy is defined in a manner
The syntax for an object name is as follows:
similar to the naming hierarchy in a file directory <naming context > …<naming context><object name>
naming context1 where the sequence of naming contexts leads
to the object name.
naming context1 ... naming context2
...
naming context1 ... naming context1
...
object object
name 1 name n
89 91
A Naming Context Example of a naming hierarchy
A naming context correspond to a folder or As shown, an object representing the
directory in a file hierarchy, while object names
corresponds to a file.
men’s clothing department is named
The full name of an object, including all the store.clothing.men, where store and
associated naming contexts, is known as a clothing are naming contexts, and men is an
compound name. The first component of a object name. store
compound name gives the name of a naming
context, in which the second component is
accessed. This process continues until the last ...
component of the compound name has been
clothing Appliances
reached.
Naming contexts and name bindings are created ...
using methods provided in the Naming Service women men television
interface.
90 92
23

24. Interoperable Naming Service Object Adapters
The Interoperable Naming Service (INS) is a In the basic architecture of CORBA, the implementation of
a distributed object interfaces with the skeleton to interact
URL-based naming system based on the CORBA with the stub on the object client side. As the architecture
Naming Service, it allows applications to share a evolved, a software component in addition to the skeleton
common initial naming context and provide a URL was needed on the server side: an object adapter.
to access a CORBA object.
distributed object
implementation
object adapter
ORB
93 95
CORBA Object Services Object Adapter
CORBA specify services commonly needed in distributed An object adapter simplifies the
applications, some of which are:
Naming Service:
responsibilities of an ORB by assisting an
Concurrency Service: ORB in delivering a client request to an
Event Service: for event synchronization; object implementation.
Logging Service: for event logging;
Scheduling Service: for event scheduling; When an ORB receives a client’s request, it
Security Service: for security management; locates the object adapter associated with
Trading Service: for locating a service by the type (instead of the object and forwards the request to
by name);
Time Service: a service for time-related events; the adapter.
Notification Service: for events notification; The adapter interacts with the object
Object Transaction Service: for transactional processing.
implementation’s skeleton, which performs
Each service is defined in a standard IDL that can be
implemented by a developer of the service object, and whose data marshalling and invoke the appropriate
methods can be invoked by a CORBA client. method in the object.
94 96
24

25. The Portable Object Adapter The CORBA Interface file Hello.idl
There are different types of CORBA 01. module HelloApp
object adapters. 02. {
The Portable Object Adapter, or POA, is a
03. interface Hello
particular type of object adapter that is 04. {
defined by the CORBA specification. An 05. string sayHello();
object adapter that is a POA allows an 06. oneway void shutdown();
object implementation to function with 07. };
different ORBs, hence the word portable. 08. };
97 99
Compiling the IDL file (using Java
1.4)
The IDL file should be placed in a directory dedicated to the
application. The file is compiled using the compiler idlj using
a command as follows:
A Java IDL application example
idlj -fall Hello.idl
The –fall command option is necessary for the compiler to
generate all the files needed.
In general, the files can be found in a subdirectory named
<some name>App when an interface file named <some
name>.idl is compiled.
If the compilation is successful, the following files can be
found in a HelloApp subdirectory:
HelloOperations.java Hello.java
HelloHelper.java HelloHolder.java
_HelloStub.java HelloPOA.java
These files require no modifications.
98 100
25