If the client "bootstrapping" operation does not establish contact with a remote naming service, you can use the following alternative strategies to retrieve the Interoperable Object Reference (IOR) of a remote object:
You can obtain the remote ORB's root name context and store it as a string-modified IOR in a file. During ORB initialization, CORBA C++ clients and servers can set the com.ibm.CORBA.localObjrefFile ORB property to the path name of the file that contains the string-modified IOR of a root naming context. The root naming context is then returned by calling ORB::resolve_initial_references("NameService").
You can write an application to store the string-modified IOR of a remote ORB's root naming context into a file. You then can make the file available (for example, by copying) to the client environment. The client then can read the string-modified IOR from the supplied file and use the ORB::string_to_object interface to resolve the root naming context. Use this approach only once during initialization, even if the client is to access many different server objects registered with the same naming service. In addition, the IOR for the name server is typically fairly static, so it is relatively simple to manage in a distributed environment.
Similar to the preceding option, put a string-modified IOR for a remote object into a file, have the client read that IOR, and use the ORB::string_to_object interface to resolve the object reference. However, it does not use a Name Service at all.
The client can look up an entry in the name server of one ORB and then rebind the reference in the name server of a different ORB. For example, you can write a utility to look-up an EJB's home in the WebSphere name service, string-modify the object reference and write it to a file. You then can use another utility to read this file, remodify the object reference, and bind it into another ORB's naming service.
A client can make use of another co-existent ORB that supports "bootstrapping" with other ORBs from the same vendor.