New York University

Computer Science Department

Courant Institute of Mathematical Sciences

 

The Interface Definition Language (IDL)

 

Course Title: Application Servers                                           Course Number: g22.3033-011

Instructor: Jean-Claude Franchitti                                            Session: 4

 

 


The Interface Definition Language (IDL) provides a technology-independent syntax for describing object encapsulations. It defines interfaces, thus creating objects. The IDL is only a definition language; mappings (a.k.a., “bindings”) to programming languages are provided for invocation and manipulation. The interfaces have attributes and operation signatures. Each interface specified in the IDL, specifies the operation signatures through which requests are made. The IDL supports inheritance to promote reuse. Its specifications are compiled into header files, stub and skeleton programs.

An interface specification, myspec.idl is created using the Interface definition Language. The IDL input is then compiled (we are using a mapping to C++ as an example here), creating three files, myspecs.cpp, myspecc.cpp and myspec.hh. Myspecc.cpp and myspecs.cpp are implementation code for the declarations specified in myspecs.hh for the client and server respectively. Myspec.hh and myspecs.cpp are compiled with other server files to create the server or object implementation. Myspec.hh and myspecc.cpp are compiled with other client files to create the client. Myspecc.cpp is referred to as the stub and myspecs.cpp is referred to as the skeleton. Stub and skeleton programs are used to populate the Interface Repository. For the client, the stub program acts like a local function call. The stub performs encoding and decoding of parameters. The stub program is created within the native programming language.

 

For the object implementation (server) a skeleton program is created. The skeleton programs invoke the methods that are part of the object implementation. No implementation details are part of the 'skeleton', the developer adds the details. The IDL skeleton usually depends on an Object Adapter. Object adapters may create implementations 'on the fly', not making use of the skeleton program.

 

The Dynamic Invocation Interface allows dynamic creation of requests.

 

IDL Specifications

 

IDL specifications are module definitions, constant definitions, type definitions, interface or exception definitions. An IDL file may contain one or more specifications. Each specification forms a naming scope. A name can be used in an unqualified form within a particular scope. If it is unresolved within the scope, it is searched for in outer scopes. Names can also use the form :: to specifically resolve a name.

 

Names have global scope, thus the global qualified name:


module1::interface1::enumeration1::identifier1

would represent an identifier1, defined within an enumeration (enumeration1), defined within an interface(interface1) defined within a module (module1).

 

Interfaces are the main component in IDL specifications. They group attributes and operations. Interfaces are composed of a head and a body. The header specifies the header and any inheritance structure. Interfaces can inherit declarations from base interfaces. Multiple interface inheritance is supported. Ambiguities are resolved by qualifying identifiers.

 

Types in the IDL follow from the types defined in the CORBA Object Model.

 

Operations in the IDL follow from the operations defined in the CORBA Object Model.

 

Attributes of an interface are logically equivalent to a pair (set and get) of accessor functions. If an attribute is declared as read-only, no set function is defined.

 

Exception declarations take the form of structure definitions. They have identifier and member definitions. Standard runtime exceptions are defined for the ORB. Standard exceptions may be raised by any operation without an explicit raise clause. Each standard exception has a completion status (yes, no, maybe) which describes whether the method completed before the raising of the exception.

 

Dynamic Invocation Interface (DII)

 

The client can dynamically specify an object, operation and set of parameters. This information is usually retrieved from the Interface Repository. The client can name the type of object and operation to be performed. The client can build up call programmatically by issuing calls.

 

The client uses object references to issue requests. The semantics of the requests are identical to the IDL requests even though the process of building the request is different. The request has an operation name, object reference and parameters. The parameters are in a name-value list that is built at runtime. This list can handle a variable number of parameters so the DII can support any invocation.

 

Request are created using a Request pseudo-object (regular interface is provided but it may not be implemented as an object). Requests are first created and then sent out. A request is created by calling the create_request operation of the object to be invoked. The request interface has the following operations available: add_argument, invoke, delete, send and get_response. The parameter list is built up from successive calls to add_argument. The parameters to add_argument itself contain its name, data type, value, length and flags. Only value and length are required, the rest are used for type checking.

 

After created and built, the request can be invoked by using the invoke or send methods. The invoke method blocks the caller until the result comes back from the object implementation. The caller is not blocked when using a send operation. The get_response method can then be used to retrieve the response at a later time.

 

Repositories

 

Interface Repository (IR)

 

The Interface Repository maintains representations of the IDL definitions. It augments the DII by providing persistent objects, which represent information about a servers interface. A client can query about an object unknown at compile time, query about services of the implementation and build a request.

 

The interfaces are maintained as Persistent 'live' objects available at runtime. The DII uses it to invoke requests of objects whose interfaces were unknown when the program was compiled. The IR is also used by the Object Request Broker for the marshalling and unmarshalling of parameters.

 

IR operations are defined for retrieving information objects maintained in the IR. The IR maintains information about interfaces and each interface is represented as an interface object. Each object in the IR can be one of the following types:

 

·       AttributeDef - An object representing an attribute.

·       ParameterDef - An object representing a parameter of an operation.

·       ExceptionDef - An object representing an exception that may be raised.

·       TypeDef - An object that represents a type definition.

·       ConstantDef - An object representing a constant.

·       OperationDef- An object representing an operation.

·       InterfaceDef - Represents an interface definition. This object contains collection of object representing operations, types, attributes, constants and exceptions.

·       ModuleDef - Collection of objects (interfaces, types, constants, exceptions) corresponding to a module definition.

·       Repository - an object that maintains a collection of definitional objects.

 

Interfaces can be retrieved from the IR in three ways:

 

·       Using the object reference, the InterfaceDef object can be retrieved. The collection of objects can then be traversed.

·       Use the get_interface operation (part of the ORB interface).

·       Traversing the IR structures using the names of the individual substructures.

 

Implementation Repository

 

The Implementation Repository maintains information for the ORB to 'start-up' (and locate) an object implementation. The specification also envisions other information for an object such as debugging and versioning information. The makeup of the Implementation Repository is not specified in CORBA since it is platform independent.