[44] IIOP
(Part of the CORBA FAQ, Copyright © 1996-99)

[44.1] WHAT IS AN IOR?

An IOR is an Interoperable Object Reference. It is a specialized object reference. An IOR is used by an application in the exact same way that an object reference is used. An IOR allows an application to make remote method calls on a CORBA object. Once an application obtains an IOR, it can access the remote CORBA object via IIOP. The CORBA object can be implemented with any CORBA 2.0 compliant product that supports IIOP. The application that obtains the IOR can be developed with a different CORBA 2.0 product. The application constructs a GIOP message and sends it. The IOR contains all the information needed to route the message directly to the appropriate server.

[ Top | Bottom | Previous section | Next section ]

[44.2] ARE IORS OBTAINED IN THE SAME MANNER AS OBJECT REFERENCES?

Obtaining IORs is exactly the same as obtaining object references. The one caveat is that ORB::resolve_initial_references returns an IOR but it usually must be implemented within the same CORBA product environment.

[ Top | Bottom | Previous section | Next section ]

[44.3] CAN AN APPLICATION REFER TO OBJECTS IMPLEMENTED WITH MULTIPLE CORBA PRODUCTS?

Well, they’re sure supposed to be able to do so. Here’s how.

Let us assume that an application needs to access two objects. Object A is implemented with CORBA product Aa and object B is implemented with CORBA product Bb. Let us look at several scenarios:

1. The front-end application will be implemented with CORBA product Aa: The simplest approach is for the front-end application to obtain an object reference to A by calling ORB::resolve_initial_references(). Since the front-end application is implemented with product Aa it cannot obtain an object reference to B by calling ORB::resolve_inital_references(). It can acquire the stringified object reference to B and convert it to an IOR by calling ORB::string_to_object(). How does it obtain the stringified object reference? Object B’s constructor could be implement to stringify itself and write the string to a file that is accessible to the front end application (access might be provided by NFS). Every CORBA product that supports IIOP should be support ORB::string_to_object().
2. The front-end application will be implemented with CORBA product Cc: This scenario is very similar to the first. The application can not use ORB::resolve_initial_references() since neither object A or B are implemented with product Cc. The front end application will obtain an IOR to A and an IOR to B by first acquiring stringified object references. It will then converting the strings to IORs by calling to ORB::string_to_object(). Every CORBA product that supports IIOP should be support ORB::string_to_object().
3. The front-end application will be implemented with CORBA product Cc. It will obtain IORs A and B from product Cc’s implementation of the CORBA NameService. It will not need to acquire any stringified object references. The real question is how are IOR A and IOR B bound within product Cc’s CORBA NameService. The processes implementing object A and Object B must acquire an object reference to product Cc’s CORBA NameService. This can only occur by obtaining a stringified object reference to product Cc’s CORBA NameService. How is the stringified object reference to product Cc’s NameService initially created? A simple application implemented with product Cc obtains the NameService by calling ORB::resolve_inital_references(), it then stringifies it by calling ORB::object_to_string(), once this has been done it externalizes the string so that it can be accessed by the processes implementing object A and B.

Note: Stringified objects cannot be exchanged using CORBA based communication. This is your classic catch 22 situation

[ Top | Bottom | Previous section | Next section ]

[44.4] CAN CORBA VENDORS SIMPLIFY INTEROPERABILITY AND THE PROCESS OF OBTAINING OTHER VENDOR’S OBJECT REFERENCES?

CORBA vendors can simplify the process of obtaining external object references by providing small pieces of code designed only to create external IORs. This might be a function called ExternalORB::create_external_references(). Vendors could provide this code to the public or directly to other ORB vendors.

[ Top | Bottom | Previous section | Next section ]

 E-mail us