What is IDL?

IDL is an acronym for Interface Definition Language of which there are several variations depending on the vendor or standard group that defined the language. The goal of an IDL is to describe the interface for some service so that clients wanting to use the service will know what methods and properties, the interface, the service provides. IDL is normally used with binary interfaces and the IDL language file describes the data types used in the binary interface.

There are several different standards for binary components, typically COTS or Commercial Off The Shelf, and how a client communicates with the binary component can vary though traditionally some version of Remote Procedure Call or RPC is used. Two such standards are the Microsoft Common Object Model or COM standard and the Common Object Request Broker or CORBA standard. There are other standards for components such as Firefox plugins or plugins for other applications such as Visual Studio itself however these do not necessarily use some form of Interface Description Language using instead some kind of a Software Development Kit or SDK with standardized and well known interfaces to an API.

What an IDL allows is a greater degree of flexibility in being able to create components offering services of various kinds which, due to their binary nature, may be used with a variety of different programming languages and a variety of different environments.

Microsoft uses a dialect of IDL with COM objects and the Microsoft IDL is not the same as CORBA IDL though there are similarities since they share common language roots. The IDL file contains the description of the interfaces supported by a COM object. COM allows for the creation of In Process services (may use RPC, or direct DLL calls) or Out of Process services (uses RPC). The idea behind COM is that the client only needs to know the identifier for the component along with the interface to be able to use it. The client requests the COM object then requests a class object from the COM object's factory which supports the interface the client wants to use and then uses the COM object through that interface.

Microsoft provides the MIDL compiler which processes an IDL file to generate the type library, providing information to users of the COM object about the interface, and the necessary stubs for marshaling data across the interface between client and service.

Marshaling of data basically means the stub takes the data provided by the client, packages it up and sends it to the service which performs some action and sends data back. This sending and receiving of data may be through some RPC service or through direct DLL function calls. The response from the service is translated into a form suitable for the client and then provided to the client. So basically the marshaling functionality is an adapter (see the adapter design pattern) or bridge (see the bridge design pattern) between the client and the service.

Visual Studio, my experience is with C++, contains a number of wizards that can be used for generating an example so that you can play with this. If you are interested you can create a work space and then in the work space you can create an ATL project to generate a control and then a simple MFC dialog project to test it out. Using ATL for your COM control hides quite a few details that you can investigate later and the simple MFC dialog project provides an easy way to create a container. You can also use the ActiveX Control Test Container tool, available in Visual Studio, to do preliminary testing and to see how methods and properties work.

There are also a number of example projects on web sites such as codeproject.com. For instance here is one using C to expose all the ugly plumbing behind COM and here is one using C++ without ATL.


There is also Interactive Data Language which I had a job using for scientific data analysis, but perhaps from the context it's clear to you that's not what this IDL stands for.


An interface definition language (IDL) is used to set up communications between clients and servers in remote procedure calls (RPC). There have been many variations of this such as Sun RPC, ONC RPC, DCE RPC and so on.

Basically, you use an IDL to specify the interface between client and server so that the RPC mechanism can create the code stubs required to call functions across the network.

RPC needs to create stub functions for the client and a server, using the IDL information. It's very similar to a function prototype in C but the end result is slightly different, such as in the following graphic:

+----------------+
| Client         |
|  +----------+  |         +---------------+
|  |   main   |  |         | Server        |
|  |----------|  |         |  +----------+ |
|  | stub_cli |----(comms)--->| stub_svr | |
|  +----------+  |         |  |----------| |
+----------------+         |  | function | |
                           |  +----------+ |
                           +---------------+

In this example, instead of calling function in the same program, main calls a client stub function (with the same prototype as function) which is responsible for packaging up the information and getting it across the wire to another process, via the comms channel.

This can be the same machine or a different machine, it doesn't really matter - one of the advantages of RPC is to be able to move servers around at will.

In the server, there's a 'listener' process that will receive that information and pass it to the server. The server's stub receives the information, unpacks it and passes it to the real function.

The real function then does what it needs to and returns to the server stub which can package up the return information (both return code and any [out] or [in,out] variables) and pass it back to the client stub.

The client stub then unpacks that and passes it back to main.

The actual details may differ a little but that explanation should be good enough for a conceptual overview.

The actual IDL may look like:

[   uuid(f9f6be21-fd32-5577-8f2d-0800132bd567),
    version(0),
    endpoint("ncadg_ip_udp:[1234]", "dds:[19]")
] interface function_iface {
    [idempotent] void function(
        [in] int handle,
        [out] int *status
    );
}

All that information at the top (for example, uuid or endpoint) is basically networking information used for connecting client and server. The "meat" of it is inside the interface section where the prototype is shown. This allows the IDL compiler to build the function client and server stub functions for compiling and linking with your client and server code to get RPC working.

Microsoft does use IDL (I think they have a MIDL compiler) for COM stuff. I've also used third party products with MS operating systems, both DCE and ONC RPC.

Tags:

Idl

Recent Posts