Appendix G. IDL Reference

This chapter serves as a quick reference for CORBA's language-independent Interface Definition Language (IDL). It also gives a summary of the Java mapping of IDL (i.e., how IDL interface definitions are mapped by an IDL-to-Java compiler into equivalent Java interfaces.) For a complete, definitive reference on IDL and the Java mapping of IDL, consult the IDL specification issued by the OMG.

Since this reference combines an IDL reference with an overview of the Java mapping of IDL, we'll be using a combination of IDL and Java examples throughout. In order to make it clear which language is being used in each example, we've stolen a convention from the CORBA standards documents: a comment preceding the example code indicates which language is in use.

IDL, as the name implies, is a language for defining object interfaces. IDL is language-neutral, so interfaces defined in IDL can be converted to objects implemented in any language with an IDL mapping. One way to think of the role that IDL plays is to imagine that you already have a set of interacting objects defined, and IDL is a way to export a subset of those interfaces so that they can be accessed by remote entities. Any member variables or operations that you define in the IDL interfaces will be visible and accessible by remote entities, providing they can obtain a reference to instances of these interfaces (refer to Chapter 14 for more details on the use of CORBA objects). If you proceed this way, the definitions of the variables and operations on the IDL interfaces would have to match those on the actual implementations you are exporting, according to the rules of the IDL mapping to the language they are written in.

Of course, this is not the typical way that you use IDL in practice.^[1] You usually want to do an abstract design of a distributed application and its set of objects first, define the IDL interfaces for the objects that need to be used remotely, then compile these IDL interfaces into language-specific interfaces. Then implementations of the interfaces can be written in whatever programming language you are using. You are free to add additional operations and member variables to your language-specific implementations, but these features won't be accessible remotely unless you add them to the corresponding IDL interface.

^[1] One notable exception is the task of wrapping legacy code with a CORBA frontend, but even here you would normally use middleware objects to interface directly to the legacy code.

The five high-level entities that you can define in an IDL specification are:

• Modules, which act as namespaces

• Interfaces to objects (with their operations and data attributes)

• Data types

• Constants

• Exceptions

These high-level entities are listed here in roughly hierarchical order. Modules contain other modules, interfaces, data types, constants, and exceptions. Interfaces contain data types, constants, and exceptions that are specific to that interface, along with the operations and attributes for the interface. We'll look at the IDL syntax used to define each of these, and in each case we'll see how the IDL is mapped into equivalent Java code. Before we do that, let's go over some of the basics of IDL: the keywords , identifiers, comments, and various types of literals.