CORBA FAQ

CORBA is the acronym for Common Object Request Broker Architecture™, OMG®'s open, vendor-independent architecture and infrastructure that computer applications use to work together over networks. Using the standard protocol IIOP, a CORBA-based program from any vendor, on almost any computer, operating system, programming language, and network, can interoperate with a CORBA-based program from the same or another vendor, on almost any other computer, operating system, programming language, and network.

Some people think (or used to, when we originally wrote this page back in the early '90s) that CORBA is the only specification that OMG produces, or that the term "CORBA" covers all of the OMG specifications. Neither is true; for list with links to all the OMG specifications, click here. To continue with CORBA, read on.

CORBA is useful in many situations. Because of the easy way that CORBA integrates machines from so many vendors, with sizes ranging from mainframes through minis and desktops to hand-helds and embedded systems, it is the middleware of choice for large (and even not-so-large) enterprises. One of its most important, as well most frequent, uses is in servers that must handle large number of clients, at high hit rates, with high reliability. CORBA works behind the scenes in the computer rooms of many of the world's largest websites; ones that you probably use every day. Specializations for scalability and fault-tolerance support these systems. But it's not used just for large applications; specialized versions of CORBA run real-time systems, and small embedded systems.

The four keys to object orientation are:

CORBA applications are composed of objects, individual units of running software that combine functionality and data, and that frequently (but not always) represent something in the real world. Typically, there are many instances of an object of a single type - for example, an e-commerce website would have many shopping cart object instances, all identical in functionality but differing in that each is assigned to a different customer, and contains data representing the merchandise that its particular customer has selected. For other types, there may be only one instance. When a legacy application, such as an accounting system, is wrapped in code with CORBA interfaces and opened up to clients on the network, there is usually only one instance.

For each object type, such as the shopping cart that we just mentioned, you define an interface in OMG IDL. The interface is the syntax part of the contract that the server object offers to the clients that invoke it. Any client that wants to invoke an operation on the object must use this IDL interface to specify the operation it wants to perform, and to marshal the arguments that it sends. When the invocation reaches the target object, the same interface definition is used there to unmarshal the arguments so that the object can perform the requested operation with them. The interface definition is then used to marshal the results for their trip back, and to unmarshal them when they reach their destination.

The IDL interface definition is independent of programming language, but maps to all of the popular programming languages via OMG standards: OMG has standardized mappings from IDL to C, C++, C++11, Java, Ruby, COBOL, Smalltalk, Ada, Lisp, Python, and IDLscript. For more on OMG IDL, click here.

This separation of interface from implementation, enabled by OMG IDL, is the essence of CORBA - how it enables interoperability, with all of the transparencies we've claimed. The interface to each object is defined very strictly. In contrast, the implementation of an object - its running code, and its data - is hidden from the rest of the system (that is, encapsulated) behind a boundary that the client may not cross. Clients access objects only through their advertised interface, invoking only those operations that the object exposes through its IDL interface, with only those parameters (input and output) that are included in the invocation.

Figure 1 shows how everything fits together, at least within a single process: You compile your IDL into client stubs and object skeletons, and write your object (shown on the right) and a client for it (on the left). Stubs and skeletons serve as proxies for clients and servers, respectively. Because IDL defines interfaces so strictly, the stub on the client side has no trouble meshing perfectly with the skeleton on the server side, even if the two are compiled into different programming languages, or even running on different ORBs from different vendors.

In CORBA, every object instance has its own unique object reference, an identifying electronic token. Clients use the object references to direct their invocations, identifying to the ORB the exact instance they want to invoke (Ensuring, for example, that the books you select go into your own shopping cart, and not into your neighbor's.) The client acts as if it's invoking an operation on the object instance, but it's actually invoking on the IDL stub which acts as a proxy. Passing through the stub on the client side, the invocation continues through the ORB (Object Request Broker), and the skeleton on the implementation side, to get to the object where it is executed.

Figure 2 diagrams a remote invocation. In order to invoke the remote object instance, the client first obtains its object reference. (There are many ways to do this, but we won't detail any of them here. Easy ways include the Naming Service and the Trader Service.) To make the remote invocation, the client uses the same code that it used in the local invocation we just described, substituting the object reference for the remote instance. When the ORB examines the object reference and discovers that the target object is remote, it routes the invocation out over the network to the remote object's ORB. (Again we point out: for load balanced servers, this is an oversimplification.)

How does this work? OMG has standardized this process at two key levels: First, the client knows the type of object it's invoking (that it's a shopping cart object, for instance), and the client stub and object skeleton are generated from the same IDL. This means that the client knows exactly which operations it may invoke, what the input parameters are, and where they have to go in the invocation; when the invocation reaches the target, everything is there and in the right place. We've already seen how OMG IDL accomplishes this. Second, the client's ORB and object's ORB must agree on a common protocol - that is, a representation to specify the target object, operation, all parameters (input and output) of every type that they may use, and how all of this is represented over the wire. OMG has defined this also - it's the standard protocol IIOP. (ORBs may use other protocols besides IIOP, and many do for various reasons. But virtually all speak the standard protocol IIOP for reasons of interoperability, and because it's required by OMG for compliance.)

Although the ORB can tell from the object reference that the target object is remote, the client can not. (The user may know that this also, because of other knowledge - for instance, that all accounting objects run on the mainframe at the main office in Tulsa.) There is nothing in the object reference token that the client holds and uses at invocation time that identifies the location of the target object. This ensures location transparency - the CORBA principle that simplifies the design of distributed object computing applications.

Almost everything. Figure 1 doesn't show any of CORBA's mechanisms for load balancing, resource control, or fault tolerance on the server side. We deliberately kept the figure simple to demonstrate how CORBA interoperability works.

For technical details on the ORB, click here. This technical page includes more detail about how the ORB works, and the interfaces it bears, including resource control and load balancing.

This FAQ continues with a description of the CORBA specifications.

As we've already pointed out, CORBA is a suite of specifications issued by the OMG.

We've put details of the specification process in their own part of this tutorial. To jump to details about how OMG members work together to define new specifications, click here.

Formally, CORBA 2 and CORBA 3 refer to complete releases of the entire CORBA specification. However, because OMG increments the major release number only when they make a significant addition to the architecture, these phrases become a sort of shorthand for just the significant addition. So, "CORBA 2" sometimes refers to CORBA interoperability and the IIOP protocol, and "CORBA 3" sometimes refers to the CORBA Component Model (even though the term CORBA 3 really refers to a suite of ten specifications!). It's easy to tell, from the context, which meaning an author intends.

To learn about how to download specifications, click here. To skip the download tutorial and go straight to the download page, click here.

As we've already pointed out, CORBA is a suite of specifications issued by the OMG.

Data-Distribution Service™ (DDS™) and CORBA® are two independent connectivity standards that enable the exchange of information, distinct from location, hardware platform, programming language or operating system.

They both provide application portability (using standard language interfaces) and network interoperability. Both DDS and CORBA were developed by the Object Management Group® (OMG®). However, they were designed to support different use cases and integration patterns.

DDS primarily supports publish-subscribe data-distribution. It also supports remote procedure calls (RPC), an evolvable type system, Qos, and fine-grained security. DDS is transport independent: It can run over UDP/IP, TCP/IP, Shared-Memory or other transports.

The CORBA family of standards support remote method invocation on distributed objects. CORBA uses TCP/IP, SSL/TLS, or other transports. CORBA has support for real-time and embedded systems.

While the DDS and CORBA standards are independent, both leverage the OMG Interface Definition Language™ (IDL™) to specify data and service types. This allows applications to use the same data types for both DDS and CORBA interactions.