5.4 CORBA

The Common Object Request Broker Architecture (CORBA) is a standard of the Object Management Group (OMG), one of the largest software consortia in the computer industry. It enables objects running on different platforms, on different machines and written in different programming languages to interoperate. The OMG does not create software per se; it creates specifications that are implemented by different vendors. There are a large number of CORBA implementations—some commercial, others open source—that to a fairly large degree can be substituted for one another (unless proprietary extensions are used). The primary focus of CORBA is on enterprise systems, and as such, CORBA standardizes a large number of services that are useful for such systems, handling aspects such as database transactions, concurrency, object persistence, licensing, event notification and security (Szyperski et al. 2002:240). CORBA’s naming service is especially important, as it allows clients to look up server objects by name (Aleksy et al. 2005:269). Despite CORBA’s early focus on the enterprise, there are also specifications that enable CORBA implementations on resource-constrained embedded systems (Schmidt and Vinoski 2001). CORBA’s strengths aside, there has been some concern lately that interest in CORBA is waning (Henning 2006).

The CORBA runtime system consists of an Object Request Broker (ORB), which routes calls from one object to another and returns potential return values. An ORB handles all invocation specifics, such as finding the target object and marshalling arguments. All object invocations, regardless of whether the receiving object runs in-process or out-of-process, go through the ORB. By mandating the use of runtime software for all object invocations, CORBA can effectively hide differences between communicating objects—what languages they are written in, on what machines they are running and the operating system used—without requiring that their interfaces all look the same in memory. Thus, CORBA is, unlike COM, not a binary standard.

All objects are accessed using interfaces, which are specified in a CORBA-specific IDL dialect. It is this language, in conjunction with formalized language bindings, that serves as the standardization mechanism of CORBA, not the memory representation of interfaces. The IDL dialect is incompatible with that used by COM, and provides a few features unsupported by COM IDL, such as support for exceptions, modules and multiple interface inheritance. Aside from an ORB, every CORBA implementation also ships with an IDL compiler. One of the primary uses of a CORBA IDL compiler is to generate language-specific client-side and server-side proxies (known as stubs and skeletons, respectively), which are used to issue and deliver object requests. Stubs are used by clients that can check invocations at compile-time, such as those written in C or C++.

Clients that invoke operations without having compile-time knowledge of them, and thus use very late binding, cannot use a stub. Rather, they must use the Dynamic Invocation Interface (DII) of CORBA. As this interface is provided by the ORB, the target object remains oblivious to the invocation mechanism used to communicate with it (this is in stark contrast to COM, which requires objects reachable through very late binding to implement the IDispatch interface themselves). Dynamic invocations can be both synchronous and asynchronous. CORBA also supports the Dynamic Skeleton Interface (DSI), which allows objects to receive requests without having compile-time knowledge of the interfaces they implement.¹ The runtime type information required by these interfaces is stored in CORBA’s Interface Repository, which is analogous to a set of COM type libraries. Like type libraries, the Interface Repository can be traversed programmatically (Vinoski 1997).

CORBA defines a number of standardized language bindings, which make it possible to access and implement CORBA objects in a given language.² (As a binary standard, COM does not have to define any language bindings—it simply defines a binary standard for interfaces, and expects compilers and script hosts to adapt to this standard.) Language bindings are implemented by an object adapter, leaving the ORB to focus on language-agnostic parts of the runtime system. An object is an abstract entity that clients refer to through object references, which as of CORBA 2.0 have been standardized as Interoperable Object References, or IORs. An IOR contains all the information necessary to contact the object, including the IP address and port number for a remote object. The implementation of an object is known as a servant (Aleksy et al. 2005:15). The object adapter is responsible for binding an object reference to a concrete servant, which can serve the request made on the object.

While CORBA does not define a binary standard for interfaces, it does standardize the wire format used over a network. Prior to CORBA 2.0, there was no standardized wire format. As a result, vendors used their own proprietary formats, meaning that two objects using ORBs from different vendors could not communicate. As of CORBA 2.0, all implementations must support the standardized Internet Inter-ORB Protocol (IIOP), which is an implementation of the General Inter-ORB Protocol (GIOP).

CORBA 3.0 introduces the CORBA Component Model (CCM), which formally defines components in the CORBA context. CCM defines an execution environment for hosting components in the form of an application server, thus removing the need for developers to build ad-hoc server solutions. In addition, CCM introduces standards for packaging, assembling, and deploying components, enabling CORBA implementations to activate components remotely (prior to CCM, there were no such standards, making users rely on non-standard solutions). CCM augments the standard IDL language with the Component IDL (CIDL) language, which enables developers to describe components and their interfaces (Schmidt and Vinoski 2004).

Footnotes

1. This is useful for solutions that act as bridges between CORBA and other component models.
2. CORBA language bindings are formally called “language mappings.”