3
CORBA and IDL

CORBA is the Common Object Request Broker Architecture of the Object Management Group (OMG). Basically this is a specification for distributed objects which is independent of manufacturers, platforms, and even programming languages. Simple values are transferred and objects are always represented by proxies. CORBA aims at the building of heterogeneous, distributed systems; language transparency of the distribution is not a goal.

IDL is CORBA's specification language. Classes ( interface ), constants ( const ), instance variables ( attribute ), methods and errors ( exception ) are declared using IDL. A compiler maps the specification to a programming language and generates code for the communication infrastructure. The OMG has specified mappings from IDL to Ada, C, C++, COBOL, Java, and SmallTalk, and RMI over IIOP depends on a mapping from Java/RMI back to IDL.

To support C++, IDL permits multiple inheritance, which is simulated in Java using aggregates ( tie , delegate pattern). C++ provides only rudimentary runtime type information ; therefore, an IDL compiler implements an extensive type code system.

CORBA's central feature is to always be able to map between strings and objects ( object_to_string , string_to_object ). This is supported by an Object Request Broker ( ORB ) in each application which communicates with the other applications. Object identities are supposed to be persistent, i.e., the strings can be stored in files to be used later and on other platforms.

 

Server objects are registered with the ORB ( connect ). Depending on the CORBA version, there can be a Basic Object Adapter ( BOA ) or a Portable Object Adapter ( POA ), which deliver requests and thus implement a thread model, on which it depends in turn if callbacks or asynchronous dialogs are possible.

CORBA has some predefined services. In particular there is a NameService , which implements a hierarchical name space which maps paths to NamingContext and other objects (as strings). Once the first NamingContext object is available as the root of a NameService , one can access registered objects and thus gain access to other services.

Objects are always passed across the net and stored in files as strings, either in the hexadecimal IOR notation (which can be decoded using iordump ) or as a URL for the Internet Inter ORB Protocol (IIOP), for a NameService for example

iioploc://host:port/NameService
corbaloc::host:port/NameService