Help with Designing or Debugging CORBA Applications

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 (www.omg.org) 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.

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:

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.