[31] INTERFACE DEFINITION LANGUAGE (IDL)
(Part of the CORBA FAQ, Copyright © 1996-99)

[31.1] WHAT IS THE PURPOSE OF IDL?

IDL stands for Interface Definition Language. Its purpose is to define the capabilities of a distributed service along with a common set of data types for interacting with those distributed services. IDL meets a number of objectives:

1. Language Independence:
2. Distributed service specification:
3. Definition of complex data types:
4. Hardware Independence:

[ Top | Bottom | Previous section | Next section ]

[31.2] DO I PROGRAM IN IDL?

No, it is an interface language. Applications are not programmed in IDL. IDL is used to define two basic types of entities:

1. Complex Data types shared between clients and servers: IDL supports 8 basic data types and allows complex data types to be composed of the basic types.
2. Capabilities of Distributed Objects (CORBA Interfaces):

[ Top | Bottom | Previous section | Next section ]

[31.3] IS IDL A SPECIFICATION LANGUAGE, AN IMPLEMENTATION LANGUAGE, OR BOTH?

A specification language.

IDL makes a strong separation between the specification of an object and the implementation of that object. Programmers who use the interface of an object have no idea whatsoever how that object is implemented. For example, the object doesn’t even need to be implemented using an OO programming language.

This is called “Separation of Interface from Implementation,” and is a very important concept in OO in general and in CORBA in particular.

[ Top | Bottom | Previous section | Next section ]

[31.4] DOES MY IMPLEMENTATION NEED TO USE INHERITANCE JUST BECAUSE MY IDL INTRERFACE USES INHERITANCE?

Nope.

Even though a CORBA interface might utilize inheritance, the object implementation is not required to utilize inheritance. For example, given the following two IDL interfaces:

    interface Base           { void f(); };
    interface Derived : Base { void g(); };

Suppose interface Base is implemented by class Base_impl and interface Derived is implemented by class Derived_impl. The key insight of this FAQ is that class Derived_impl does not need to inherit from class Base_impl. For example, Derived_impl could implement method f() directly, or it could contain a pointer to a Base_impl object and delegate f() to that object, or it could use some other technique.

This is an example of the separation of interface from implementation.

[ Top | Bottom | Previous section | Next section ]

[31.5] HOW DO I EXPRESS AGGREGATION IN IDL?

The aggregation of two objects is a very common OO design concept. Aggregation is also known as has-a and contains.

Since IDL doesn’t support “public data,” a programmer that is using an IDL interface cannot tell whether an aggregation is actually implemented using aggregation or by some other technique. In other words, IDL is a specification language that separates interface from implementation. In particular, IDL does not support implementation constructs such as aggregation.

However logical aggregation is supported by IDL: IDL lets you specify an operation that returns another interface, and this second interface could represent an object that is logically contained within the first object. Whether it’s actually implemented using aggregation or not is an implementation issue, not a specification issue, and the implementer can do it either way without requiring any changes to the IDL interface.

Note that DCOM directly supports aggregation since DCOM combines implementation issues with specification issues. The COM<->CORBA interworking specification actually maps aggregation to and from inheritance (CORBA IDL supports inheritance directly, and DCOM supports aggregation directly).

[ Top | Bottom | Previous section | Next section ]

[31.6] DOES CORBA HAVE SUPPORT FOR C++ VIRTUAL FUNCTIONS?

[Recently created (12/1998). Click here to go to the next FAQ in the “chain” of recent changes]

Yes.

CORBA IDL is a technology that lets you specify (“describe”) interfaces. It happens that each method of each CORBA interface is implicitly virtual, in the sense that the method will employ dynamic binding at runtime. However the implementation technique doesn’t have to have anything to do with the typical C++ technique (virtual pointers and virtual tables).

(See the C++ FAQ for more on the C++ use of the virtual keyword, and the typical C++ implementation of dynamic binding — virtual pointers and virtual tables.)

[ Top | Bottom | Previous section | Next section ]

[31.7] IS IT TRUE THAT CORBA IDL CAN SPECIFY INHERITANCE BUT NOT “VIRTUAL” METHODS?

[Recently created (12/1998). Click here to go to the next FAQ in the “chain” of recent changes]

Not really.

Technically speaking, you can’t specify “virtual” in CORBA IDL since “virtual” isn’t a CORBA IDL keyword. However the effect of the C++ keyword “virtual” is to cause dynamic binding to occur, and since all CORBA IDL methods are implicitly dynamically bound, CORBA IDL actually does support the “virtual” concept.

(See the C++ FAQ for more on the C++ use of the virtual keyword, and the typical C++ implementation of dynamic binding — virtual pointers and virtual tables.)

[ Top | Bottom | Previous section | Next section ]

[31.8] WHAT IS A GOOD IDL INTERFACE?

[Recently created (10/1999). Click here to go to the next FAQ in the “chain” of recent changes]

This is the $64,000 question. Obviously, there are a lot of application specifics that need to be considered. But there are also some rules of thumb:

• Recognize that the interface to an in-memory object and an interface to a distributed object are likely very different.
• Remote calls include network overhead. This puts a remote call in the “at least milliseconds” category, versus an in-memory call, which is in the “at least microseconds” category.
• As much as possible, a single IDL operation should coorespond to a single unit of work in the business system.
• IDL interfaces tend to be overly generous on the amount of information returned. This is because you don’t want a situation where clients have to make follow up calls to get supporting data.
• There are many different types of interfaces and design patterns. Some of the more common include:
  • Manipulation Interface - This is the interface used to manipulate a single object. E.g., a BankAccount.
  • Factory Interface - this is the interface used to create and delete objects. E.g., a Bank that creates and deletes BankAccounts. Or more explicitly, the interface could be named BankAccountFactory.
  • Search-To-Select Interface - This is the interface used to try to identify which object to manipulate. E.g., a BankAccountFinder that supports operations that take search data and return 0, 1, or more BankAccount object references or secondary keys.
  • Manager Interface - This is more a singleton, RPC style interface, whereby the object to manipulate is an argument in the operation rather than the object the call is made on. This style of interface can also be used to manipulate several objects in one call, and hence is used more in batch clients. E.g., BankAccountManager that has an operation taking a sequence of BankAccounts to run credit checks on.
• Distinguish conversational interfaces that are used by a client to represent a client-specific context versus entity interfaces that are used to represent a shared business object. The classic example is an order processing system, wherein the shopping cart is a conversational interface and the items being bought are entity interfaces.
• Consider where the transactions are in the system and how these map to the interface operations.
• Consider using the concept of idempotency. This helps with determining transaction completion status and recovery when asynchronous transactions are used or if the client is not a resource in the transaction.

There are some books on CORBA and IDL design patterns. Effective IDL design is probably one of the largest influences on the success of the system.

[ Top | Bottom | Previous section | Next section ]

 E-mail us