Obtaining the remote object

Several methods exist by which the client can get a reference for the remote object.

Typically, this reference is a string, called an Interoperable Object Reference (IOR). For example:
IOR:000000000000001d524d493a5......

This reference contains all the information required to find the remote object. It also contains some details of the server settings to which the object belongs.

The client ORB does not have to understand the details of the IOR. The IOR is used as a reference to the remote object, like a key. However, when client and server are both using an IBM® ORB, extra features are coded in the IOR. For example, the IBM ORB adds a proprietary field into the IOR, called IBM_PARTNER_VERSION. This field holds a value like the following example:
49424d0a 00000008 00000000 1400 0005
In the example:
  • The first three bytes are the ASCII code for IBM
  • The next byte is 0x0A, which specifies that the following bytes provide information about the partner version.
  • The next 4 bytes encode the length of the remaining data. In this example, the remaining data is 8 bytes long.
  • The next 4 null bytes are reserved for future use.
  • The next 2 bytes are for the Partner Version Major field. In this example, the value is 0x1400, which means that release 1.4.0 of the ORB is being used.
  • The final 2 bytes in this example have the value 0x0005 and represent the Minor field. This field is used to distinguish maintenance updates within the same release. The updates contain changes that affect compatibility with earlier versions.
The final step is called the bootstrap process. This step is where the client application tells the ORB where the remote object reference is located. The step is necessary for two reasons:
  • The IOR is not visible to application-level ORB programmers.
  • The client ORB does not know where to look for the IOR.

A typical example of the bootstrap process takes place when you use a naming service. First, the client calls the ORB method resolve_initial_references("NameService"). The method which returns a reference to the name server. The reference is in the form of a NamingContext object. The ORB then looks for a corresponding name server in the local system at the default port 2809. If no name server exists, or the name server cannot be found because it is listening on another port, the ORB returns an exception. The client application can specify a different host, a different port, or both, by using the -ORBInitRef and -ORBInitPort options.

Using the NamingContext and the name with which the Remote Object has been bound in the name service, the client can retrieve a reference to the remote object. The reference to the remote object that the client holds is always an instance of a Stub object; for example _Sample_Stub.

Using ORB.resolve_initial_references() causes much system activity. The ORB starts by creating a remote communication with the name server. This communication might include several requests and replies. Typically, the client ORB first checks whether a name server is listening. Next, the client ORB asks for the specified remote reference. In an application where performance is important, caching the remote reference is preferable to repetitive use of the naming service. However, because the naming service implementation is a transient type, the validity of the cached reference is limited to the time in which the naming service is running.

The IBM ORB implements an Interoperable Naming Service as described in the CORBA 2.3 specification. This service includes a new string format that can be passed as a parameter to the ORB methods string_to_object() and resolve_initial_references(). The methods are called with a string parameter that has a corbaloc (or corbaname) format. For example:
corbaloc:iiop:1.0@aserver.aworld.aorg:1050/AService

In this example, the client ORB uses GIOP 1.0 to send a request with a simple object key of AService to port 1050 at host aserver.aworld.aorg. There, the client ORB expects to find a server for the requested Aservice. The server replies by returning a reference to itself. You can then use this reference to look for the remote object.

This naming service is transient. It means that the validity of the contained references expires when the name service or the server for the remote object is stopped.