Lesson 6

Interoperability is CORBA's biggest advantage over competing technologies. This module discussed a high-level view of how CORBA achieves interoperability, even down to the protocol level. This level of interoperability did not exist prior to CORBA, and the OMG is continually searching for ways to improve interoperability, effectively raising the bar and changing what the industry may realistically expect vendors to support. The momentum generated by this drive in the marketplace is surely the primary reason that so many vendors are adding CORBA support to their products. It is a trend that will continue for the foreseeable future.

At a high-level, CORBA (Common Object Request Broker Architecture) achieved interoperability through several key mechanisms:

1. Interface Definition Language (IDL):
   • CORBA uses IDL, a language-independent specification for describing interfaces to services. IDL allows developers to define the interface of an object in a way that is independent of programming language, operating system, or hardware architecture. This means that clients and servers can be written in different programming languages but still communicate seamlessly if they adhere to the same IDL.
2. Object Request Broker (ORB):
   • The ORB is the core component that enables communication between objects. It acts as a middleware layer that manages the communication, location transparency, and execution of requests between clients and servers. The ORB translates client calls into requests that can be understood by the server object, facilitating the interaction across different networks and platforms.
3. IIOP (Internet Inter-ORB Protocol):
   • IIOP is the primary protocol used by CORBA for communication between ORBs over the Internet or any IP-based network. It is based on TCP/IP and defines how requests and responses are encoded and transmitted. IIOP ensures that different ORBs from different vendors can interoperate by providing a standardized way to marshal and unmarshal data across the network. This includes:
   • GIOP (General Inter-ORB Protocol): The abstract protocol from which IIOP is derived. GIOP specifies the message formats, data representation, and transport mechanisms.
   • CDR (Common Data Representation): A standard for encoding data that includes rules for marshaling and unmarshaling data types, ensuring that data sent from one system can be correctly interpreted by another.
4. Dynamic Invocation Interface (DII) and Dynamic Skeleton Interface (DSI):
   • These interfaces allow for runtime invocation of operations on objects without prior knowledge of their exact interface. DII allows clients to dynamically construct requests to any CORBA object, while DSI allows servers to receive requests dynamically, enhancing flexibility in system design.
5. Interoperability with Non-CORBA Systems:
   • CORBA also supports bridges and gateways for interoperability with other systems not natively using CORBA. This can include adapters for different middleware or protocols, although these solutions might not be as seamless as native CORBA to CORBA communication.
6. Standardized Services and Facilities:
   • The Object Management Group (OMG) defined a set of standard services like Naming Service, Event Service, etc., which helped in achieving consistent behavior across different implementations of CORBA. These services provide additional layers of abstraction and functionality that ensure interoperability at a higher level.

Through these mechanisms, CORBA provided a framework where objects could interact regardless of where they were located or how they were implemented, significantly enhancing interoperability across heterogeneous environments. This was a pioneering approach in the era before web services and modern microservices architectures became prevalent.

Before CORBA 2.0, one of the most common complaints lodged against CORBA was its lack of standard protocol specifications. To allow remote ORB applications to communicate, every ORB vendor had to develop its own network protocol or borrow one from another distributed system technology. This resulted in "ORB application islands", where each one was built over a particular vendor's ORB, and thus they were unable to communicate with one another. CORBA 2.0 introduced a general ORB interoperability architecture called the (GIOP) General Inter-ORB Protocol. GIOP is an abstract protocol that specifies transfer syntax and a standard set of message formats to allow independently developed ORBs to communicate over any connection-oriented transport. The (IIOP) Internet Inter-ORB Protocol specifies how GIOP is implemented over (TCP/IP) Transmission Control Protocol/Internet Protocol. All ORBs claiming CORBA 2.0 interoperability conformance must implement GIOP and IIOP, and almost all contemporary ORBs do so.
ORB interoperability also requires standardized object reference formats. Object references are vague to applications, but they contain information that ORBs need in order to establish communications between clients and target objects. The standard object reference format, called the Interoperable Object Reference (IOR), is flexible enough to store information for almost any inter-ORB protocol imaginable. An IOR identifies one or more supported protocols and, for each protocol, contains information specific to that protocol. This arrangement allows new protocols to be added to CORBA without breaking existing applications. For IIOP, an IOR contains a host name, a TCP/IP port number, and an object key that identifies the target object at the given host name and port combination.

In the next module, we will focus on CORBA interfaces.
We will learn how to use CORBA Interface Definition Language, what functionality IDL supports, as well as what is not supported.

Before we move on, take this short quiz about the material we have just covered.
Corba Interoperability IIOP - Quiz