SEC. 9.1 CORBA 515
same interface repository, or at least use the same identifier to identify interfaces.
The most important part of each IOR is formed by what are called tagged profiles. Each such profile contains the complete information to invoke an object. If the object server supports several protocols, information on each protocol can be included in a separate tagged profile. Details on the profile used for IIOP are also shown in Fig. 9-14.
The IIOP profile is identified by a ProfileID field in the tagged profile. Its body consists of five fields. The IIOP version field identifies the version of IIOP that is used in this profile.
The Host field is a string identifying exactly on which host the object is located. The host can be specified either by means of a complete DNS domain name( such as soling. cs. vu. nl, or by using the string representation of that host’ s IP address, such as 130.37.24.11.
The Port field contains the port number to which the object’ s server is listening for incoming requests.
The Object key field contains server-specific information for demultiplexing incoming requests to the appropriate object. For example, a POA-generated object identifier will generally be part of such an object key. Also, this key will identify the POA.
Finally, there is a Components field that optionally contains additional information needed for properly invoking the referenced object. For example, the components field may contain security information indicating how the reference should be handled, or what to do in the case the referenced server is( temporarily) unavailable. We return to these matters below.
Now that we have explained the details of an object reference, it is not difficult to see how a client binds to an object to subsequently invoke a method. Recall from Chap. 2 that binding a client to an object is the process by which a connection is set up to an object so that the client can invoke that object’ s methods. Binding is possible only if the client has a reference to that object.
Anticipating our discussion on the CORBA naming service, assume a client has requested the naming service to resolve a human-readable name. The naming service will return a language-dependent implementation of the IOR as stored in the naming service. Such an implementation can be returned only if the client’ s ORB has carried out the complete binding process. It does so as follows.
The client ORB takes the IOR returned to it by the naming service, and by inspecting the repository ID contained in the IOR, it can place a proxy at the client and return a pointer p to that proxy. Internally, the ORB will store the fact that p is associated with the object’ s IOR.
Different ORBs have different implementations, but one typical scenario is as follows. Before passing p to the client, the client’ s ORB inspects the tagged profiles contained in the IOR. Assume that the object can be invoked using IIOP. In that case, the client ORB may set up a TCP connection with the object’ s server, using the host address and port number found in the IOR. At that point, it can pass