Different Layers of CORBA Interoperability

This lesson will give an overview of CORBA interoperability. CORBA (Common Object Request Broker Architecture) provides a framework for distributed object-oriented systems. Interoperability is one of its core goals, allowing objects in different environments to communicate seamlessly. CORBA defines five types of interoperability to facilitate this communication:

1. Inter-ORB Protocol (IIOP)
   • Description:
     • The Internet Inter-ORB Protocol (IIOP) is the standard wire protocol for CORBA communication over TCP/IP networks.
   • Usage:
     • Enables ORBs (Object Request Brokers) from different vendors to communicate over the internet or other TCP/IP-based networks.
   • Key Feature:
     • Ensures communication between CORBA objects regardless of their underlying ORB implementation.
2. Object Adapter Interoperability
   • Description:
     • Object adapters act as intermediaries between the CORBA objects and the ORB. They manage requests to objects.
   • Usage:
     • Different adapters (e.g., Basic Object Adapter or Portable Object Adapter) are used to support various CORBA object lifecycles, activation policies, and invocation semantics.
   • Key Feature:
     • Provides portability and flexibility by enabling different object adapter implementations to interoperate.
3. Bridge Interoperability
   • Description:
     • Bridges facilitate communication between different middleware systems, such as CORBA and non-CORBA systems.
   • Usage:
     • Allows CORBA systems to communicate with systems using other technologies like DCOM or Java RMI.
   • Key Feature:
     • Acts as a gateway to enable interoperation between heterogeneous systems.
4. Domain Interoperability
   • Description:
     • Refers to interoperability within specific CORBA domains or verticals, such as telecommunications, finance, or healthcare.
   • Usage:
     • Defines standard interfaces and protocols tailored to particular industries.
   • Key Feature:
     • Provides consistency and seamless communication for CORBA applications within the same domain.
5. Federated Interoperability
   • Description:
     • Federation involves the integration of multiple CORBA systems to appear as a single cohesive system.
   • Usage:
     • Enables interoperability in large-scale distributed systems where different CORBA environments are interconnected.
   • Key Feature:
     • Facilitates unified operation and management across distributed CORBA environments.

Summary Table

Type	Description	Purpose
Inter-ORB Protocol (IIOP)	Standard wire protocol for CORBA over TCP/IP	Ensures seamless communication between ORBs
Object Adapter	Intermediary managing CORBA object requests	Flexibility and portability between different adapters
Bridge Interoperability	Gateway for CORBA and non-CORBA system communication	Integration of heterogeneous systems
Domain Interoperability	Industry-specific standardization for CORBA applications	Consistency within vertical domains
Federated Interoperability	Unified operation across interconnected CORBA systems	Scalability and unified management in distributed systems

These interoperability types collectively enable CORBA to function as a robust and versatile framework for building distributed systems.
The following series of images below outlines the five types 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