[Up: Object Request Broker]
[Previous: Object Request Broker] [Next: Addressing]

Interface Definition

The Interface Definition Language (IDL) is used to describe an object's interface. IDL solely consists of declarative constructs, foremost of the ``interface'' keyword used to describe the methods^3.1 exported by an object and available to the client.

Figure 3.2: Simple IDL File

Interfaces are strongly typed, i.e. methods have a specific number of typed parameters and a typed return value. Parameters also have a direction: ``in'' parameters are sent from the client to the server, ``out'' parameters are received by the client as a result of the invocation, and ``inout'' parameters first get passed to the server, where they are potentially modified and then again returned.

Figure 3.2 shows the IDL declaration for an ``Account'' interface that provides two modifiers to deposit and withdraw, and one accessor to query the balance.

As mandated by the object-oriented programming model, IDL also provides interface inheritance: an interface can inherit from one or more base interfaces and can later, in programming, be used instead of a base type object (polymorphism). Whether the object implementation of a derived object also inherits the base object's implementation or re-implements the base interface's methods is up to the object implementation itself and not addressed by IDL: interface and implementation are kept separate.

IDL provides a number of basic numeric and string types. Additional language constructs allow the declaration of user-specific structured types, like structures, unions and enumerations. Noteworthy are the two basic data types ``any,'' which contains a value of arbitrary type, and ``object,'' which transports an untyped object reference.

Interface declarations are independent of a programming language. IDL files are then processed by an IDL compiler to produce the required declarations for the target language. How this is done is specified by a CORBA language mapping. For C++, two classes are generated: one abstract ``skeleton'' class for the server side to which the programmer must add the object implementation, and one ``stub'' class for the client side.

Type information from IDL files can also be kept online in one or more Interface Repositories, either for the purpose of constructing requests dynamically, or also for introspection purposes. The interface of the Interface Repository is itself described in IDL; the contents of an Interface Repository can therefore be accessed through normal CORBA mechanisms.

[Previous: Object Request Broker] [Next: Addressing]
[Up: Object Request Broker]