Help with Designing or Debugging CORBA Applications

How to add CORBA GIOP/IIOP decoding capabilities to an open-source protocol analyzer.
OMG IDL Overview

OMG IDL is a declarative language used to describe one or more interfaces that CORBA object implementations provide. You don't write applications using OMG IDL, but you describe interfaces that objects support. The syntax of OMG IDL is not too difficult to understand. Here is a simple example:

module example{
   interface demo {
      short getSize();

This says an object that supports the demo interface from the module example provides an operation called getSize. It takes no arguments and returns a value of type "short". OMG defines the integer data type short as a 2 octet value (see CORBA ref Chap 15).

A slightly more detailed example would be:

module example {
   interface Penguins {
      enum Food {squid, krill, fish, rock_crab};
      typedef Food Food_t;
      Food_t favouriteFood();

This says that an object supporting the Penguins interface from the module "example" provides an operation called favouriteFood(). It takes no arguments and returns a value of type Food_t. Of course Food_t is a typedef of Food, which is an enumeration. Typedef and enum may be familiar to you already from other language implementations (C, C++, etc.).

IDL files for real-world applications will be far more complex than this and may include structs, sequences, exceptions and a host of other IDL types. I urge readers to visit the OMG site ( and grab a copy of the CORBA specification. It is available in a number of different formats.

So what can you do with all this OMG IDL? Here's where IDL compilers enter the picture.

IDL Compilers

There are a variety of IDL compilers in existence today. They normally include a particular ORB implementation. You can see a reasonable list of them by doing a Google search using "linux corba".

Some examples of IDL compilers are listed below. This list represents just a small percentage of the ever-growing IDL compiler family: omniidl from the omniORB distribution, idl2java from Visibroker, idlj from Sun's J2SE v1.3 release and tao_idl from TAO distribution. There are many more of course, as you can see by doing a quick Google search.

IDL compilers can do a lot of useful things. Some of the more important tasks include verifying correct syntax of the IDL file(s) being read, generating target code for a variety of languages (Java, C, C++, Lisp, Python, etc.), producing client stubs and producing object skeletons.

The one that interested me was omniidl. It consists of the compiler front end and allows you to write compiler back ends to suit your particular task.

One of the things I liked with omniidl was that you write the back end in Python and access tree data structures (representing the parsed IDL) via a nice API. With this in mind, let's see how CORBA GIOP messages are structured so we know how to decode them.


Thankfully there are just a handful of GIOP messages used to allow client/server interaction. They also are defined using OMG IDL and belong to the GIOP module. You can see them described in detail in Chapter 15 "General Inter-ORB Protocol" of the CORBA specification:

  • Request: used for attribute accessor operations and for CORBA object invocations.

  • Reply: the response to a Request message, if the response expected flag is TRUE in the Request message.

  • LocateRequest: used to determine if the current server can handle requests directly or to find out where the client should send requests for a given object reference.

  • LocateReply: the response to the Locate Request message.

  • CancelRequest: tells the server that the client is no longer expecting a reply to a specific Request or LocateRequest message.

  • MessageError: sent when the recipient does not recognize the version number or message type of the specified message, or that the message header is not correctly formed.

  • Fragment: used to support fragmentation of Request and Reply messages (e.g., when a Reply message carries a lot of data that could not be sent in the original Reply message).

How Do OMG IDL Types Get Marshaled?

To find out how OMG IDL types get formatted on an octet stream, there are detailed rules defined in CDR transfer syntax and also in the CORBA specification. I will not delve too deeply into this other than to say that alignment of data types are, on their natural boundaries, relative to the beginning of the octet stream or start of an encapsulation.

Table 1 shows these alignment restrictions for some of the more commonly used types. Note, there are a lot more types defined in the CORBA specification than are shown here.



Comment viewing options

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

Re: Help with Designing or Debugging CORBA Applications

Anonymous's picture

There's a young project hosted by

called CorbaTrace that aimed to trace Corba calls

on the corba bus. It's written in Java

It's quite younger, but could be interresting with some help

Find more information here:

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 now

Sponsored by Skybot