Hello IDL

The OMG Interface Definition Language (IDL) doesn't get much simpler (or less useful) than this! But for the purposes of this tutorial, a simple example will serve. Rather than focusing on the syntax of IDL here, we will instead concentrate on what it takes to implement an IDL interface (and interact with that implementation) using C++ and Java. There are plenty of good IDL references out there, including this one. The main things to remember about IDL are these: It is from IDL, and only from IDL, that all CORBA things flow. You can't do anything in CORBA without an IDL file. Let's take a closer look at ours:
	interface World
	{
	    string hello();
	};
We've defined an interface called World that contains one method called hello. It returns a string.

An interface is sometimes referred to as a CORBA object. But it's not an object in the way a C++/Java programmer might think of an object. It's more abstract. A CORBA object requires a programming language object (a servant) to incarnate it. This is a subtle, but important distinction.

The return value for the hello method is a string. A string is a basic CORBA datatype, along with short, long, char, float, double, boolean, octet, and any, each guaranteed by the CORBA standard to be of a specific size. All of the CORBA datatypes are mapped to language-specific types for each standard language mapping. For example, the C++ mapping maps a CORBA string to a char *, while the Java mapping maps it to a String.

So what good is an IDL file? Well, except for a language-independent way of describing the components of your system, not much... until you compile it. Language-specific IDL compilers take an IDL file as input and generate source code for "stub" and "skeleton" classes that represent your IDL interfaces.

The terms, stub and skeleton, are used to refer to the proxies on either side of a client-server relationship. These classes help to provide the illusion of location transparency in CORBA. The client application never knows for sure whether it is invoking methods on a local or remote CORBA object: it's simply invoking methods on its stub[s]. A stub acts as a proxy for a remote object. It forwards the local request (function name and parameters) to the remote object and awaits the return value. On the remote (server) side, the skeleton receives the request from its ORB and then invokes the appropriate (local) method on the servant -- the piece of software you write that implements the CORBA object. It's not crucial that you understand all of this right now: only that client objects need -- they invoke methods on -- stub objects, and server objects need -- their methods are invoked by -- skeleton objects. Got it? Good!

Let's continue by compiling our IDL file with the TAO compiler.

Back to... [ Corba Tutorials ]


Jim Crossley
Last modified: Mon Mar 22 11:52:58 EST 1999