Different Layers of CORBA Interoperability

For interoperability, OMG specifies a protocol for the abstract CORBA object reference object, known as the Interoperable Object Reference (IOR) protocol. One obvious requirement for interoperability between different CORBA products is that they must be able to speak the same on-the-wire protocol (IIOP). However, that by itself it not sufficient. Another, less obvious requirement for interoperability is for one CORBA product to be able to find, say, the Naming Service or the Notification Service of another CORBA product. For example, how can an Orbix client find (connect to) the Naming Service of an Orbacus installation. This is often called a bootstrapping problem. The corbaloc and corbaname URLs were invented to address such bootstrapping issues, as I now discuss.
A CORBA application connects to a CORBA Service. For example, the Naming Service, Transaction Service and Notification Service by calling resolve initial references() and passing the name of the desired service as a parameter. The CORBA specification does not specify how resolve initial references() works (that is an implementation detail), but in most CORBA products this operation looks in a configuration file to find a name-of-CORBA-service!stringified-IOR mapping1 and then passes the stringified IOR as a parameter to string to object(). These mappings are normally set up during the installation and configuration of a CORBA product. To configure, say, Orbix to use an Orbacus Naming Service is a matter of obtaining a stringified IOR of the Orbacus Naming Service (typically from the Orbacus configuration file) and copying this into the Orbix configuration file. Then the next time an Orbix client calls resolve initial references ("NameService"), the client will be directed towards the Orbacus Naming Service. This technique works fine, but it is a bit cumbersome because stringified IORs are not human readable. However, with the introduction of corbaloc URLs, the technique becomes much easier. Now, instead of copying a stringified IOR of the Orbacus Naming Service into the Orbix configuration file, it is sufficient to copy a corbaloc URL into the Orbix configuration file. The fact that corbaloc URLs are easy to read (and edit) by humans makes it more feasible for an organization to use several different CORBA products.

Let us take a look back to our SmartParts application and note the places where CORBA's interoperability is paying off for us. The following exercise identifies interoperability in SmartParts.
Corba Interoperability Levels - Exercise