What looks like a simple method invocation but actually talks to another process for you?

Over the last 20 years or so, object-oriented programming techniques have matured from a curiosity to a major component of almost every software engineer's programming toolbox. The reason for this growth is easy to understand: object-oriented programming techniques help software engineers solve real problems, that is, constructing and maintaining software products.

In the Linux world, one can find object-oriented programming techniques realized in a variety of programming languages, including Perl, Python, Java and C++. Even though these programming languages utilize different programming constructs to realize object-oriented techniques, they all have one thing in common: the mechanism they employ to invoke an object's method. In all of these languages, an object's method is invoked by treating the method as if it were a regular function/procedure, providing a special reference to the object with which the method is associated. For example, C++ uses the keyword “this” while Python uses the keyword “self” to refer to the object.

The designers of these various programming languages have chosen to use this mechanism because it works and because it provides the best performance as compared to alternative mechanisms—an excellent design trade-off, but there is a problem. For those who construct applications that use multiple processes, this mechanism prevents them from using object-oriented techniques between processes. Simply stated, it is not possible to invoke an object's method in one process from an object in another process.

CORBA (Common Object Request Broker Architecture) is a specification for an architecture that provides support for invoking methods in objects that may exist in a different process. The CORBA architecture is based on the concept of a common object. Figure 1 shows how common objects interact. This figure shows how a request from one object, the left-most object in the figure, can be sent to an object existing within the same process, within another process running on the same processor or within another process running on a different processor. From the viewpoint of the requesting object, it does not matter where the object to which the request is being sent exists. It is the responsibility of a component of the CORBA architecture known as the ORB (Object Request Broker) to ensure that the request is delivered to the correct object.

Figure 1. Method Invocation in CORBA

In order to better understand and appreciate what CORBA is, we are going to construct a simple CORBA application. This application consists of two objects, a server that can handle requests to get the current processor load and a client that makes requests for this information. These two objects are created in different processes.

The first thing to do in constructing a COBRA application is specify the interface for the object that will handle the requests. This interface is visualized in Figure 1 as a ring that surrounds the core of the object. One makes this specification using CORBA's Interface Definition Language (IDL). This IDL is formally known as the OMG IDL, OMG being the Object Management Group responsible for the CORBA specification. The specification for this interface specifies the methods (functions) supported by that interface.

The server we are constructing supports only a single method that can be invoked to determine the current CPU load. Listing 1 shows the specification for the CPULoad interface. This interface declares the method getLoadAvgs, which has three parameters: oneMinAvg, fiveMinAvg and tenMinAvg. These three parameters are all of the type float. CORBA's float data type is the same as the C/C++ float data type. In fact, the CORBA IDL supports most but not all C/C++ data types. The out keyword is used to specify that this parameter is an output parameter—a parameter used to return data to the method's invoker. The keywords in and inout can be used in place of out; in informs that the parameter is an input parameter, and inout indicates that the parameter is used as both an input and an output parameter.

Now that the interface has been specified, it needs to be processed so it can be used to build the required executables. IDL specification are processes using IDL compilers (Figure 2).

Figure 2. Creating the Client and Server Programs

The IDL compiler takes the specification and processes it to produce two header files, a client and a server header file, and two source files, a stub source file for the client and a skeleton source file for the server. The header and source files contain the declarations and code necessary to build a working CORBA program. Once the header and source files are produced, they are compiled and linked with either the client or source object files to produce a working executable.

The source and header files produced by the IDL compiler are language-specific. This is a strong feature of the CORBA specification, because it means you probably can use CORBA with your favorite programming language. If you have a favorite programming language, you need to find an IDL compiler that supports your language of choice. However, before rushing off to select an IDL compiler, we need to mention one other caveat of IDL compilers—they are targeted at a specific ORB. If you select an IDL compiler, you must use the ORB that the compiler targets. Conversely, if you choose an ORB, you need to use one of the IDL compilers targeted for that ORB. Given that the ORB has the biggest impact on performance and supported features, one usually selects an ORB and then the IDL compiler.

Another important aspect of ORBs and IDL compilers needs to be mentioned here. The ORB and IDL compiler used to build a CORBA executable—for example, the server program—do not have to be the same ORB and IDL compiler used to build a different CORBA executable, say, the client program. This is true even if the executables need to interoperate. The only information that needs to be shared is the IDL specification.

In this article, we use the DOC Group's TAO ORB, which was selected for three reasons: it is open-source, it is ported to a large variety of platforms, including Linux, and it is an efficient, full-featured ORB. The drawback to choosing TAO, from some developers' viewpoint, is it supports only C++.

Now that the IDL specification has been written, and an ORB and IDL compiler have been chosen, we can process the IDL specification. The Makefile shown in Listing 2 explains how to invoke the TAO IDL compiler, tao_idl, to process the IDL specification.



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Re: CORBA, Part I

iplayfast's picture

The artical is interesting. I've seen this option in my Borland compiler for years without exploring it. After reading the artical I thought I would explore it. Then I read the comments. Yes, it is old tech.

Now I'm not sure if it's worth while learning yet another technology.

Is it?

Re: CORBA, Part I

Anonymous's picture

There are still people building new systems on CORBA. There are many, many older systems being maintained with CORBA.

CORBA is a strong, robust technology. It works well. In fact, chances are, if you've played any MMORPGs, you've used a system built with CORBA.

CORBA is easy. Some of the C++ bindings are fairly obtuse. In turn, people often think C++ bindings = CORBA = obtuse. Simple fact is, these are the people that show their ignorance. There are some parts of CORBA, wihch need to be improved. Guess what, the standards have been marching on. Some of the original specifications have been obsoleted or depricated. The biggest problem with CORBA, is the very slow nature that it's specifications evolve and the speed at which the revised specifications can be implemented by vendors. Having said that, however, most modern CORBA implementations are robust, powerful and fairly full featured.

If you are a C++ coder and are using CORBA in C++, it's fairly easy to abstract away most of the obtuseness of CORBA C++ bindings. As such, take a look at ACE/TAO. It's a C++ only CORBA implementation, however, those guys know what they are doing. Take a peek if you get a chance.

Re: CORBA, Part I

Anonymous's picture

"What looks like a simple method invocation but actually talks to another process for you?"

CORBA! And in the white paper below you can read why that is a rather bad idea.

"We look at a number of distributed systems that have attempted to paper over the distinction between local and remote objects, and show that such systems fail to support basic requirements of robustness and reliability."

Re: CORBA, Part I

Anonymous's picture


I have a bridge to sale you too. Just let me know when you want to complete the purchase.

Right off the bat, the number of exceedingly poor assumptions that paper makes invalidates the entire paper. Feel free to ignore it.

Re: CORBA, Part I

Anonymous's picture

CORBA is a great idea and sounds very nice.
I have done a lot of evaluations, experimentations and implementations using CORBA, so I do know what I'm talking about, and here are my griefs:

  • slow standard: the standard evolves very slowly, which is what one has to expect with over 700 vendors in the OMG
  • implementations: the vendors don't implement all features or are too slow to implement (rather) new features (e.g. CorbaMessaging, CORBA 3.x)
  • RMI/IIOP is great but.. don't count on it: RMI/IIOP is really cool but is very limited and is rather tough to set up with various EJB containers and ORBs
  • overhead: yes, but... CORBA is very efficient and fast, and the initialization (naming service, resolve names, ...) isn't more overhead than EJB
  • more of a distributed agent architecture than messaging-oriented: you almost can't do asynchronous/decoupled communication, which is badly needed for high-performance applications with a pipeline architecture - those features are covered quite well by the CorbaMessaging standard in CORBA 3.0, but I'm not aware of any vendor having implemented it yet (some vendors have implemented some parts of it)
  • quite complex to use: you do have to dig quite deep into CORBA to be able to really use it as you need and there are some rather complex things in there - but, once you have, it isn't that complex any more; the least I can say, though, is that it's far from being straightforward to use; that's also because CORBA is much more low-level compared to, say, EJB - but in return it is much more flexible (especially on the server side)
  • SOAP/XML-RPC/...: those web services messaging techniques are much easier to use; keep in mind that they are far from achieving CORBA's features but for rather simple things (e.g. simple calls between Java and C++), go for SOAP
  • COSS Notification Service sucks: too bad that the Notification Service is too complex (that's its tradeoff for being extremely flexible) and slo-o-ow... really too slow for using it as an asynchronous/decoupled messaging channel; that's kind of sad, especially when you see that JMS (Java Messaging Service) is fast as hell

I'd say: before you bet on CORBA, do try it out very carefully and don't just count on the nice things you hear/read about it, because you might be disappointed.
Then again, if it works for you, it can be a really slick framework to build your application on :)

KDE dropped CORBA, use DCOP instead

Anonymous's picture

In a desktop environment, does CORBA make sense ?

I'm no programmer but I ask this question because of KDE & GNOME history.

At the beginning KDE tried it out but dropped it since it complicated a lot the programming & as a side effect, refrain new progammers to enter the project (because of the learning curve). Today, they use DCOP instead which is a success (but doesn't have all the features of CORBA) and has inspired D-Bus.

On the other hand, GNOME opted for CORBA with their own (fast, light but incomplete) implementation called ORBIT. Today, it's a failure.

To me, it seems that CORBA is theoritically perfect (and that's why professors love it) but has failed to have an impact in real life programming.

Any comments ?

Re: KDE dropped CORBA, use DCOP instead

Anonymous's picture

Not really fair to take Orbit as an example. At the time, Orbit was not very mature and the gnome folks couldn't decide what direction they were going. Furthermore, most had no CORBA experience and had no idea how to leverage it. The Gnome/Orbit example is a good example or poor design, inexperience, lack of direction, and poor execution.

You can argue all day long how much sense CORBA on the desktop makes, but in the end, you can't knowingly and successful argue with the orbit/gnome example, as there were far, far too many other issues at play.

Now then, I'll attempt to tackle the CORBA on the desktop debate. If we take ACE/TAO, as an example, I find it odd that they can create a RT CORBA driven avionics (as in, fly by wire for military jets) implementation, but people are still willing to claim that CORBA is unfit for the desktop. Worth noting, the CORBA avionics implementation was considered a big success. That's the difference between having a good, quality ORB and developers that know what they are doing and half-thought out interfaces and a second rate, incomplete ORB, not to mention inexperienced developers. Had the Gnome guys had a clue, and used a quality ORB, they would of been far, far better off. Instead, they decided they needed to grow their own solution. I can't argue if that decision made sense at the time. I simply don't remember. Just the same, chances are high, they should of looked elsewhere. If memory serves, there was OmniORB as an option, which was and still is, a very high performance ORB (much faster than ORBIT) and very complete. Plus, it had/has many language bindings available for it. Also, if you bother to look as the speed of many high quality ORBs today, I think you'll agree that performance should not be a concern. However, it was a major issue for the Gnome guys. Read into that what you will, however, to me it says several things. Bad interfaces, bad code, bad ORB, bad developers. Take your pick or one or more.

Had KDE gone with CORBA and Gnome done it right, I think it's safe to say, the state of the Linux desktop would be much, much better than where we are today.

Re: KDE dropped CORBA, use DCOP instead

Anonymous's picture

It is true there is aditional complexity when using CORBA but it is a standard arquitecture. If KDE, GNOME, Mozilla and OpenOffice had agreed to a standard communication protocol we could be much closer to have interoperability on the desktop than we are now. If they had used CORBA a unified object model would still be required, but it would be much easier get there.

Re: KDE dropped CORBA, use DCOP instead

Anonymous's picture

GNOMEs ORBit2 became (after all) a relatively good CORBA implementation, but it took too long. For the desktop you don't need the "distributed and remote" features of CORBA, so a simpler technology might make sense. OTOH, if you ever used CORBA with Python (either PyORBit or omniORBpy), you can't imagine a simpler technology! CORBA is difficult, because the language bindings for C and C++ are crazy. With Python (and to some extend Java) it's much easier.

Re: KDE dropped CORBA, use DCOP instead

Anonymous's picture

The KDE tutorial about DCOP goes something like:
    DCOPRef("kdesktop", "KScreensaverIface").call("lock");

And from the command line:
    dcop kdesktop KScreensaverIface lock

If you compare that with the article above then I think the difference in ease of use is very clear.

Does CORBA make sense? Yes, for a distributed air traffic controlling system it probably does. But on the desktop it's just not the right tool for the job.

Re: KDE dropped CORBA, use DCOP instead

Anonymous's picture

DCOP has a main drawback, it depends on Qt library, If you plan to use dcop in your develop you must use Qt too, at least a part of Qt.
Despite this drawback, dcop is much more simple than corba, but for RMI purposes it does its work fine.

Re: CORBA, Part I

Anonymous's picture

Don't you think that Corba is just too much overhead? One can argue that Object oriented programming is also a large overhead and that it tends to add a certain degree of obscurity and complexity. I myself am not a big CORBA fan, nor am I an advocate of Java. I feel that they both provide a tremendous amount of overhead to an already complex problem you're trying to solve. You can do anything with C and System specific programming. Ok, CORBA and Java might provide some type of homogeneous interface between architectures, but is all this complexity really necessary?


Re: CORBA, Part I

Anonymous's picture

Most large, distributed applications will _eventually_ need

* an easy method to define remote APIs
* a way to handle distributed transactions
* a standard set of distributed services
* a standard method of handling remote object references
* a standard method of activating objects that are referenced, but not currently alive (i.e. - object has been sync'd back to database, and is no longer in memory)
* a standard method of handling errors

When projects get big, they NEED this stuff. It's easier if it's already been done for you by people who have spent a lot of time thinking about the issue.

Homogeneous interfaces between architectures is more or less a side issue compared to what CORBA actually gives you.

Re: CORBA, Part I

Anonymous's picture

Don't you think that Corba is just too much overhead?

As with most things, it's only overhead if you don't use it. CORBA is a mature solution to the issues encountered when creating robust & distributed platform- and language-neutral systems, and as such it has *a lot* of what you call overhead (e.g. in a simplistic system, you could ask "why do I need an ORB? I can just make a config file that has the IP address of the server app I'm connecting to").
In an analogy, I read a posting recently on re-inventing the X-Window system because it "has too much overhead". One would think that any replacement that aimed to accomplish the same things would end up much the same way.

Re: CORBA, Part I

Anonymous's picture

Right, and RMI is built on top of CORBA (well... RMI/IIOP is). CORBA is cross-language, and cross-platform.

Of course, this article shouts "Welcome to 1996!" pretty loudly to me... seems rather dated ;-)

Re: CORBA, Part I

Anonymous's picture

As is your comment. Welcome to 2004. CORBA has evolved. You might want to educate your self more before you comment further.

Not any more

Anonymous's picture

Hello, it's now 2009. CORBA seems to be pretty much dead on the desktop now.

Re: CORBA, Part I

shpxnvz's picture

"Simply stated, it is not possible to invoke an object's method in one process from an object in another process."

You cannot mention Java and make this claim. RMI provides this functionality for Java.

Re: CORBA, Part I

Anonymous's picture

Is RMI not a library ?

Geek Guide
The DevOps Toolbox

Tools and Technologies for Scale and Reliability
by Linux Journal Editor Bill Childers

Get your free copy today

Sponsored by IBM

8 Signs You're Beyond Cron

Scheduling Crontabs With an Enterprise Scheduler
On Demand
Moderated by Linux Journal Contributor Mike Diehl

Sign up and watch now

Sponsored by Skybot