What is CORBA ?

A comparison : CORBA as generalized networking

Because CORBA has such a mist surrounding it, I would like to start by creating a parallel to a hopefully better understood concept : CORBA is analogous to computer networking.

We already know that it's possible to connect a bunch of computers together using a network. The requirements for networking computers are that we have one or more computers, and that each computer has an appropriate network interface card (NIC). Note the word interface in NIC : A NIC provides a common interface through which two computers on a network can communicate.

This hardware setup is parallel to the software concept of CORBA interfaces : Two CORBA components must share a common interface to be able to communicate. In the case of computer networking, the common interface is usually ethernet, which usually carries TCP/IP data packets. So we can think of the PCs as CORBA components and ethernet (carrying TCP/IP) as an interface specification.

Name lookups

Let's take this analogy a little further. Suppose a computer on a large network wants information from another computer on the network. For example, Marge might sit down at her home computer and type http://ambient.2y.net/ (one of her favorite addresses) in her web browser. Broadly speaking, her computer will then try to make a connection to another computer somehow identified by ambient.2y.net (if such a computer can be found), and then transfer information from that computer to Marge's computer.

Marge's computer needs to do some work behind the scenes to enable this feat of magic. Because computers deal more easily with numbers than with human–readable domain names, Marge's computer needs to find an IP address for a computer that is known by the name ambient.2y.net. To find this address, her computer will contact a domain name server (which provides a service called the domain name service, or DNS) to ask if there is an IP address associated with the given name. This is just like looking up a phone number in the telephone book. Assuming the name and address are found on the DNS server, Marge's computer will receive an IP address and be able to communicate directly with that IP address using the ethernet (plus TCP/IP) interface. The great thing about networking is that it doesn't really matter where the remote computer is located : it could be in Marge's house (indeed, it could even be the same computer that Marge is using), or it could be in a remote corner of the globe. The IP address is all that's necessary to communicate between Marge's computer and the remote computer.

Happily, this technology also has a parallel in CORBA. Suppose Marge sits down at her computer and fires up her email program. Her friend Dave sent her an email with a movie attachment, so her email program suddenly needs to use a CORBA component to display the embedded movie. Marge's email program will need to locate an appropriate component somewhere in the CORBA network environment and then embed the component in the local application. This ability is one of the best parts about CORBA : see below for more information.

There are actually two steps here—location and embedding—but they are parallel to the steps involved in the network example above. We'll take them one at a time (though in the real world they are somewhat intertwined).

Locating a component

Marge's email application needs to locate a component to do the work of decoding and displaying the movie. (There are many advantages to this approach ; some of them are described in detail below.) To locate a suitable component, the email application on Marge's computer will send a message to the CORBA object request broker (ORB) on the CORBA network environment asking for a suitable component.

The ORB behaves just like a domain name server, looking up components using any of various criteria (including name based lookup or lookup based on interfaces). Assuming the ORB can locate a suitable component, then, it will cause a suitable component to be created on a host machine somewhere in the network. Once that component is created, the ORB will return an address for the component to Marge's email application. This address is referred to in CORBA as an *object reference* : like an IP address, once Marge's application has an object reference, it can request information from the object without knowing where the component is located in the network. The ORB handles all communication between Marge's email application and the movie player component.

Embedding the component

But how do the ORB and Marge's email application know that a given component can handle the movie playing task ? Here's where interfaces become intensely useful. Just like in the networking example, the component and Marge's email application can communicate thanks to a common interface. In practice, however, there is one difference : Unlike the networking example, there are an unlimited number of CORBA interfaces that the movie player and the email application could possibly use to communicate. The only requirement is that the movie player must provide an interface that the email application can use. You can't plug your ethernet cable into a telephone modem jack because they don't use the same interface ; similarly, you can't plug a component that provides interface X into a component that uses interface Y.

In practice, there are two ways of developing interface compatibility. The first is the monolithic–application approach : A single application is developed that splits its respective parts into CORBA components. Because all the components are developed simultaneously, their interface specifications might evolve together during the life cycle of the project. Examples of this type of project might be applications that use CORBA components in embedded devices (for example, some newer PDA applications).

The second method is the embedded–component approach : A somewhat complex application is developed first, and specialized subtasks (for example, displaying email attachments of various types) might be delegated to other development teams. The complex application simply defines interfaces that the embedded components need to implement. Then, after sufficient time for independent developer teams to work, the embedded components follow. Examples of this type of application are web browsers and email applications—which have plugins for displaying various media types—and, on Linux, the GNOME panel and Nautilus, which can embed various CORBA components.

CORBA as its own technology

With that, the analogy seems to have lived out its usefulness. Now I will present a bit about CORBA itself, because any analogy is not a 100 % match—though I reserve the right to refer back to the networking concept. So, as mentioned before, CORBA is an acronym for the Common Object Request Broker Architecture, an interprocess communications standard defined by the Object Management Group. The CORBA 3.0 specification is a massive document that I can't even begin to claim I understand even on a low level ; however, the basic concepts are straightforward enough and have already been presented in the above analogy. CORBA, then, includes the core concepts of interfaces, components and homes, and the object request broker (ORB). I'll try to present a little about these concepts individually.

Interfaces

CORBA requires developers to define interfaces (using the Interface Definition Language, which looks quite like Java) for software components. Unlike the networking example, interfaces in CORBA are (to date) purely software, so they can be altered quite easily ... in theory.

These components, which are essentially like very large C++ or Java classes, can then communicate with other CORBA components through an ORB (Object Request Broker), but only if the components involved have some interfaces in common. Components communicate with other components by passing an object reference (a void pointer, more or less, though it can point outside of the component's address space) to and from the ORB. The ORB maintains a list of where the different components are located and passes messages among them.

Components and homes

Components ...

The object request broker (ORB)

ORB ...

Advantages of CORBA

CORBA has many advantages that simply outweigh its disadvantages. These are the primary reason I started writing this document : I want more people to start trying out CORBA so it will become more central to the software development industry.

Component reuse

The nice thing about CORBA is that as an application developer you can reuse already existing components like a mad dog (just connect to the ORB and request an object reference of a certain type), and the components don't have to be running in the same process or even on the same physical machine (ORBs can manage interprocess communication automatically even over networks, which is way cool (tm)).

Distributed design, implementation, and verification

CORBA is fantastically advantageous for the email application because the developers of the application do not need to learn how to decode movies to be able to play movie attachments.

Distributed computation

One of the best things about CORBA is that Marge doesn't need to care where the movie player component actually lives : Just like in a network, a component could come from the local computer or a computer on some remote corner of the globe. This technology will permit, for example, mobile phones to embed movie player components that require more computer resources than a mobile phone can provide.

Drawbacks of CORBA

The not so nice thing about CORBA is that it is crazy complicated (includes a lot of complicated argument marshaling and demarshaling stuff for out of process function calls), so if you have an application that's going to run all in one process, using CORBA components entails a lot of unnecessary overhead, in terms of both runtime and programming time. Just getting a handle on the terminology and programming style took me about 6 months ...

Although CORBA is platform independent, the only platforms that have really embraced it are flavors of Unix. For example, the GNOME panel uses bonobo (a lightweight CORBA implementation) for its interprocess communication, which includes panel apps and the embedded nautilus stuff. CORBA is also what allows, for example, the ghostview component to be embedded in any other application (i.e. ggv or nautilus). In this way CORBA is a bit like OLE from the old Windows days.