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.