topical media & game development

[] readme course(s) preface I 1 2 II 3 4 III 5 6 7 IV 8 9 10 V 11 12 afterthought(s) appendix reference(s) example(s) resource(s) _

object-oriented programming

[] readme course preface 1 2 3 4 5 6 7 8 9 10 11 12 appendix lectures resources

Interface Definition Language -- IDL

The Interface Definition Language (IDL) that accompanies CORBA-2.0 provides the constructs needed to specify interfaces only.

IDL allows for specifying modules, consisting of interfaces. An interface specification may contain (read only) attributes and operations. Operations are synchronous, unless annotated as oneway. Operations may raise exceptions upon failure.

Interface Definition Language

IDL

modules -- for clustering
interfaces -- correspond with objects
attributes -- may be read only
operations -- best effort invocation
exceptions -- for handling failure

Language bindings

C, Smalltalk, C++, Java

See www.infosys.tuwien.ac.at/Research/Corba/OMG

slide: Interface Definition Language -- IDL

Although IDL is syntactically very similar to C++ or Java, it completely lacks the algorithmic constructs of these languages. Objects specified in IDL must be realized in one of the languages for which an official IDL language binding exists, such as C, Smalltalk, C++ or Java, or an unofficial binding, such as Python, Perl and Prolog.

Example

As an example, look at the definition of a module universe below. It contains an interface named world which provides a method hello and two additional methods ask and tell.


  module universe {    universe  
  
  interface world {
      	void hello();
  
  	void ask(in string x);
  	string tell();
  
  	oneway void halt();
  	};
  };

slide: universe.idl

The ask method has a string input parameter and the tell method has a string result type.

All methods supported by the world interface are synchronous, except for the halt method, which is annotated as oneway.

The realization of the universe module is given in Appendix Universe.

Types and values

The operations specified in an interface may result in a value and may take particular values as arguments. The type of a value must either exist as a basic type or be specified in IDL.

Basic types

integers, reals, booleans, enum, string, any

Constructed types

struct, union, sequence, array, interface

Object references

interface + operations

slide: Types and values

Basic types encompass integers, reals, booleans, enumerations and strings. There is also a generic type, any, which allows for checking the actual type dynamically. Constructed types include record structures (struct), tagged unions, sequences and arrays.

Interfaces specify object types. However, a value that identifies an object is always a reference to the object. In CORBA 2.0 it is not possible to send objects by value. As a workaround, one may send records by value and then locally instantiate an object.

Operations and exceptions

An operation or method specifies a service that a client may request of an object. Operations may result in a value. Each parameter of an operation has a type and a modifier indicating whether it is an input, output, or combined inout parameter.

Operations

in, out, inout -- parameter attributes

Exceptions


  exception out_of_range { long count; }
  
  interface writer {
    void position(in long pos) raises(out_of_range);
    }

slide: Operations and exceptions

The signature or type of an operation may also include one or more exceptions that may be raised. Exceptions may contain data fields.

The signature of operations may also be assembled dynamically, through the dynamic invocation interface of the ORB. The semantics for such requests are the same as for requests via the operation stub generated from the interface specification.

Interfaces and inheritance

Interfaces define polymorphic object types. An interface may be realized by any object that supports the operations specified in the interface.

Interfaces and inheritance

no overriding, no overloading

Multiple (interface) inheritance

>
  interface A {  };
  interface B {  };
  interface C : A { };
  interface D : B, A { };

slide: Interfaces and inheritance

Interfaces can inherit from other interfaces. This results in augmenting the interfaces with the attributes and operations of the inherited interface. However, in contrast to class inheritance in C++, IDL does not allow for operations to be overridden, nor for overloading operations, that is different signatures for the same operation.

Multiple (interface) inheritance is supported however, provided that no clashes or overloading occurs.

The Object interface

Each object type defined in IDL may be assumed to be derived from the interface Object. For example, when defining an iterator type the interface may look as follows:


  interface iterator {    iterator  
          Object next();
          };

It is the responsibility of the implementation to downcast the object type to its actual type.

Language bindings

A language binding for IDL must satisfy a number of requirements. See CORBA Reference.

Language bindings

types, references, access, ORB and BOA support

The Object interface


  interface Object {    PIDL   
  	InterfaceDef get_interface();
  	Object duplicate();
  	...
  }

slide: Language bindings

Naturally, the mapping must support IDL basic and constructed types, references to objects and constants, and access to attributes and operations.

In addition it must provide the signatures for operations defined by the Object Request Broker (which transmits requests over the network) and the Basic Object Adaptor (which translates method requests to actual object method or function invocations).

Access to the ORB and BOA is usually provided by means of so-called pseudo-objects, objects described by interfaces in IDL which are not necessarily implemented as ordinary objects. As an example, the Object interface describes the functionality that each IDL-defined object has.

[] readme course(s) preface I 1 2 II 3 4 III 5 6 7 IV 8 9 10 V 11 12 afterthought(s) appendix reference(s) example(s) resource(s) _

You may not copy or print any of this material without explicit permission of the author or the publisher. In case of other copyright issues, contact the author.