CORBA BASICS

• I’m totally new to CORBA.
• What is CORBA? What does it do?
• What is CORBA good for?
• How about a high-level technical overview?
• How do remote invocations work?
• That ORB/Skeleton Architecture on the Server Side doesn't look very scalable. What did you leave out?
• What is CORBA 2? CORBA 3? What does the version number mean, anyhow?
• Who is using CORBA already?

Does your company have a networking strategy, to ensure interoperability and control costs?

I’m totally new to CORBA.

This page will get you started. We haven't assumed that you know anything about CORBA. We did, however, assume that you know something about computing in general, and distributed (that is, networked) computing in particular - at least what you want to use it for, although not necessarily what you have to do to get it to work.

Some of the points in our discussion are aimed at management, while others are aimed at technical folks, but it's too soon to diverge. Don't worry about point of view; by clicking on the topics that look interesting, you'll pick the path that's best for you.

UML, another OMG standard, may be even more widely used than CORBA.

What is CORBA? What does it do?

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 that CORBA is the only specification that OMG produces, or that the term "CORBA" covers all of the OMG specifications. Neither is true; for an overview of all the OMG specifications and how they work together, click here. To continue with CORBA, read on.

Some large companies are embedding CORBA in networked devices for finance and medical applications.

What is CORBA good for?

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

* Encapsulation
* Polymorphism
* Inheritance
* Instantiation

In CORBA, client and object may be written in different programming languages!

How about a high-level technical overview?

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++, Java, 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 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.

The CORBAservices provide standard ways of passing object references around your network of CORBA objects.

Location Transparency keeps your applications flexible.

How do remote invocations work?

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.

OMG's best support for server-side scalability comes from the CORBA Component Model.

That ORB/Skeleton Architecture on the Server side doesn't look very scalable. What did you leave out?

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. 

The over 500 attendees at each OMG meeting make it a happening as well as an occasion to advance the OMG specification suite.

What is CORBA 2? CORBA 3? What does the version number mean, anyhow?

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.

Do you have a CORBA success story? Email us: mailto:majel@omg.org

Who is using CORBA already?

Thousands of sites rely on CORBA for enterprise, internet, and other computing. The Object Management Group maintains an entire website devoted to user design wins and success stories. At last count, there were over 300 stories on the site. Click here and we'll take you there for a look.