Book Home Java Enterprise in a Nutshell Search this book

Chapter 10. IDL Reference

Contents:

IDL Keywords
Identifiers
Comments
Basic Data Types
Constants and Literals
Naming Scopes
User-Defined Data Types
Exceptions
Module Declarations
Interface Declarations

This chapter serves as a quick reference for CORBA's language-independent Interface Definition Language (IDL). It also provides 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 ("IDL Syntax and Semantics," Chapter 3 of The Common Object Request Broker: Architecture and Specification, published by the OMG and available at www.omg.org).

Since this reference combines an IDL reference with an overview of the Java mapping of IDL, I'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, I've stolen a convention from the CORBA standards documents, where a comment preceding the example code indicates the language that 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 IDL plays is to imagine that you already have a set of interacting objects defined and then think of IDL as a way to export a subset of those interfaces so that they can be accessed by remote entities. Any member variables or operations you define in the IDL interfaces are visible and accessible by remote entities, providing they can obtain a reference to instances of these interfaces (see Chapter 4, "Java IDL", 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 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. The next step is to write implementations of the interfaces 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 normally use middleware objects to interface directly with the legacy code.

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

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 that defines each of these, and, in each case, we'll see how the IDL is mapped into equivalent Java code. Before we do that, though, we need to cover some of the basics of IDL: keywords, identifiers, comments, and various types of literals.

10.1. IDL Keywords

Table 10-1 lists the reserved keywords in IDL. These keywords are case-sensitive, and they cannot be used as identifiers in any IDL constructs.

Table 10-1. IDL Reserved Keywords

any

default

in

oneway

struct

wchar

attribute

double

inout

out

switch

wstring

boolean

enum

interface

raises

TRUE

case

exception

long

readonly

typedef

char

FALSE

module

sequence

unsigned

const

fixed

Object

short

union

context

float

octet

string

void



Library Navigation Links

Copyright © 2001 O'Reilly & Associates. All rights reserved.