The examples in this section and in the previous section have (for conve-
nience) made use of localhost to run all the components associated with a
CORBA application on the same machine. However, this need not have been
the case. The ORB, nameserver and object server program could have been
started on one host, whilst the client (or clients) could have been started on a
different host (or hosts). Each client would then have needed to use the com-
mand line option -ORBInitialHost to specify the host machine for the
ORB (and, if appropriate, the command line option -ORBInitialPort to
specify the port).
In commercial ORBs, object references persist . They can be saved by clients as
strings and subsequently be recreated from those strings. The methods required to
perform these operations are object_to_string and string_to_object respectively,
both of which are methods of class Orb . With the latter method, an object of
(CORBA) class Object is returned, which must then be 'downcast' into the original
class via method narrow of the appropriate 'helper' class.
Suppose that we have a reference to a StockItem object and that this reference is
called itemRef . Suppose also that the ORB on which the object is registered is iden-
tifi ed by the variable orb . The following Java statement would store this reference
in a String object called stockItemString :
String stockItemString =
The following statements could subsequently be used to convert this string back
into a StockItem object reference:
org.omg.CORBA.Object obj =
StockItem itemRef = StockItemHelper.narrow(obj);
Of course, the client would have needed to save the original string in some per-
sistent form (probably within a disc fi le).
Since Java IDL supports transient objects only (i.e., objects that disappear
when the server process closes down), the above technique is not possible.
However, it is possible to implement an object so that it stores its state in a disc
file, which may subsequently be used by the object's creation method to re-
initialise the object.