All About Object References

• Where to get the IOR

– As the result of a method call
• Callbacks
– Initialisation
• Stringified IOR
• Nameserver
• What is inside the IOR
– IIOP
 Callbacks

• During normal running object references are

normally obtained as return values from methods
• Distributed callbacks are a common design pattern
• Modify Counter example
• Also see example in JDK tutorial
 Distributed Callbacks

• Blocking calls are a problem when the remote

method takes a long time to complete
• Make one call to initiate the remote computation
• The remote object makes a second call -- back to
the client -- to notify that the computation is done
• The client is not blocked between the two calls
• Mixes Client and Server roles
 Counter with Callback IDL
module CounterPackage {
interface CounterCallback {
void callback( in long sum );
};

interface Counter {
void increment ( in CounterCallback
cbref );
};
};
 Servant
import CounterPackage.*;
public class Counter extends _CounterImplBase {
private int sum;
public Counter () {
sum = 0;
}
public void increment (CounterPackage.CounterCallback
cbref) {
sum ++;
cbref.callback (sum); // Notify client that
computation is complete
}
}
 Server Unchanged
import org.omg.CORBA.*;
import java.io.*;

public class CounterServer {

public static void main (String args[]) throws Exception {
ORB orb = ORB.init (args, null); // Initialise ORB.
Counter aCounter = new Counter (); // Create new counter.
orb.connect (aCounter); // Register counter with ORB.

String stringobjectref = orb.object_to_string(aCounter);

System.out.println (stringobjectref); // Orb ref.

java.lang.Object sync = new java.lang.Object ();

synchronized (sync) {
sync.wait();
}
}
}
 Counter Callback Client
• Client aspects as before
– Initialize ORB
– Get IOR of Servant (Counter Object)
– Narrow
– Make remote invocation
• Servant aspects of this callback client
– Implement CounterCallback Object
– Connect to ORB
– Pass the IOR
– No infinite event loop in this example
import CounterPackage.*;
import org.omg.CORBA.*;

public class CounterCallback extends _CounterCallbackImplBase{

public void callback (int sum) {
System.out.println ("Increment completed, sum = " + sum); }
}

public class CountTest {

public static void main (String args[]) {
ORB orb = ORB.init (args,null);

CounterCallback cbref = new CounterCallback();

orb.connect (cbref); // Connect the callback object

CounterPackage.Counter myCount =
CounterHelper.narrow (orb.string_to_object(args[0]));

myCount.increment(cbref);
}
}
 Real Callbacks need Threads

• Servant
– increment method starts a new thread to do the
computation and the original thread returns immediately
– alternatively declare method as oneway
oneway void increment(in CounterCallback cbref);

• Client
– create CounterCallback in a separate thread with an
event loop
 Initialisation

• Bootstrap: How do you get the first reference?

• Stringified Object References

– Safe and portable
– Inconvenient
• Naming Service
– Convenient to use meaningful names rather than IOR’s
– Just change IOR registered under a name for updates
• Trading service
 Using the CORBA Naming Service

• Allows you to obtain an IOR from a name

• Requires
– server to name an object
– client to know the name of the object
• One of the Services defined by CORBA
specification
– Java IDL implementation (tnameserv) is volatile
Client/Server Naming Scenario

Namespace
Name Server
<name_1, object_1>
2 <name_2, object_2>
…
<name_n, object_n>
ORB
Client Server
bind name
to object
resolve 1
name
ORB 3 ORB
4
invoke service
 Adding simple naming to the server
import org.omg.CosNaming.*;

public class CounterServer {

public static void main (String args[]) throws Exception {
ORB orb = ORB.init (args, null);
Counter aCounter = new Counter ();
orb.connect (aCounter);

org.omg.CORBA.Object objRef =
orb.resolve_initial_references ("NameService");
NamingContext ncRef = NamingContextHelper.narrow (objRef);

NameComponent nc1 = new NameComponent ("IncrementCounter", "");

NameComponent nc[] = {nc1};
ncRef.bind (nc, aCounter);
...
 Using the naming service in the client
import org.omg.CosNaming.*;

public class CountTest {

public static void main (String args[]) {
try {
ORB orb = ORB.init (args,null);

org.omg.CORBA.Object objRef =
orb.resolve_initial_references ("NameService");
NamingContext ncRef = NamingContextHelper.narrow (objRef);

NameComponent nc1 = new NameComponent ("IncrementCounter", "");

NameComponent nc[] = {nc1};
CounterPackage.Counter myCount =
CounterHelper.narrow (ncRef.resolve(nc));
 Where is the nameserver?
• Nameserver can run anywhere
– started with “tnameserv -ORBInitialPort portnumber”
– default portnumber is 900
• Server must be told where the nameserver is
– java servername -ORBInitialPort <portnumber>
-ORBInitialHost <hostname>
– This is how resolve_initial_references works, it is
ORB dependent
• Client must also be told where the name server is
 Adding a directory structure
• Can create directories (NamingContext) in name server
NameComponent comp1 = new NameComponent (“MyStuff”, “”);
Name Component [] name = {comp1};
NamingContext myhome = ncRef.bind_new_context (name);

• now add an object to this directory

NameComponent comp1 = new NameComponent (“IncrementCounter”, “”);
Name Component [] name = {comp1};
myhome.bind (name, myObject);

• to extract object on client

NameComponent comp1 = new NameComponent (“MyStuff”, “”);
NameComponent comp2 = new NameComponent (“IncrementCounter”, “”);
Name Component [] name = {comp1, comp2};
CounterPackage.Counter myCount =
CounterHelper.narrow (ncRef.resolve(name));
 Trading Service
• Yellow pages
• Dynamic lookup based on service
descriptions
• Example
– printers with different
• location
• bw/color
• size paper
 Object References
• The only way for the client to reach target
objects
• Can be null (eg to convey “not found”)
• Can dangle (not point to an active object)
• Opaque (to ensure portability only
manipulate through standard interfaces)
 Structure of IOR
Repository ID Endpoint Info Object Key

• Repository ID (standardized)
– Information about the interface the IOR represents (used by
DII and narrow)
• Endpoint Info (standardized)
– For the physical connection: IP and Port numbers
• Object Key (proprietary)
– Vendor dependent way the ORB (and OA) identify the
target object on the server
– Opaque to the client
 IIOP
• Allows interoperability between different
ORB’s
• Precise specification of the on-the-wire
representation of data and messages for
TCP/IP