CORBA Connectivity: Welcome to CORBA

The CORBA Architecture

The name CORBA is an acronym standing for Common Object Request Broker Architecture. It is not software, but rather a specification defined by the Object Managment Group (OMG) - the world's biggest consortium within the software industry made up of around 700 members (including Microsoft). CORBA is a comprehensive, non-proprietary reference model for the development of distributed applications. At its core is the concept the Object Request Broker (ORB). Inside a CORBA application, the ORB plays the role of a software bus connecting several modules whose interfaces are defined using a standardized Interface Definition Language (IDL). The IDL, although strongly resembling C++, is nevertheless a language of its own to describe interfaces (i.e. types and signatures) independently of any specific implementation language. The clue to any concrete programming language is provided by using an equally standardized mapping of the IDL into the data types and signatures of the target language.

Besides the definition of the IDL and its mapping into several target languages (currently, there are standardized mappings into C, C++, Java, Smalltalk, Cobol, CommonLisp, Python and CorbaScript available, with a C# mapping pending), all the formal CORBA specifications are written in IDL - including even the interfaces of the ORB and its several Object Adaptors (which will be explained later). Based on an independent interface definition of its modules, a CORBA application is:

• Distributed - insofar as every module may reside within its own process, on a remote computer, or even located within another network.
• Heterogeneous - insofar as every module may be implemented in a different programming language, running within a different operating system, and even on different hardware.
• Object Oriented - insofar as CORBA IDL defines "objects" to be called using its operations (i.e. CORBA term for "methods")
• Modular - insofar as every interface implemented by a specific module can (and should) be designed to be as simple and atomic as possible so that a flexible infrastructure (even for highly volatile business processes) can be provided.

The CORBA specification is embedded in another embracing architecture, the Object Management Architecture (OMA).

The basic components of OMA are:

• Common Object Services (COS) - contain standardized interfaces for building a sound technical infrastructure. These services span from the simple hierarchical Naming Service (which should be delivered as a basic service with every ORB implementation), to useful services like the Event & Notification Service (a distributed version of the well known "Observer" pattern), up to advanced services like the Transaction Service (a distributed 2-phase-commit) and the Security Service (embracing all aspects of secure distributed computing).
• Common Facilities - contain so-called "horizontal" component interfaces for building a business infrastructure, which are useful within every specific business domain. Examples are the Printing Facility (standardized access to distributed print services), Internationalization & Time Facilities, the Mobile Agent Facilities, and the Meta Object Facility (for building all kinds of repositories based on IDL).
• Domain Facilities - contain so-called "vertical" component interfaces which are useful (if not necessary) in specific business domains. Examples are the General Ledger, Currency, and Party Management Facilities from CORBAfinance, or the Audio/Video Stream Facilities from CORBAtelecom.
• Application Objects - the application-specific component interfaces.
• ORB - the communication medium between all these components.

Common Object Services as well as the several Facilities and Application Objects are, like the ORB itself, defined in terms of IDL. This means that most of the services & facilities are implemented as CORBA objects (there are rare exceptions, such as the Security Service, as far as there are internal features of the ORB implementation specified). Because of this, the services should be (like all CORBA objects) compatible with all ORB implementations.

Inside CORBA

The basic idea behind CORBA is the concept of locational transparency. It should make no difference whether an object is called within the same process or on a remote process.

To realize this feature, CORBA uses the Proxy Pattern. A CORBA implementation will use the component's IDL description to generate two proxies:

• The Stub, which encapsulates all the communication codes on the client side. The client will locally instantiate the stub instead of the real object.
• The Skeleton, which provides the same functionality on the server side. The object implementation will usually be within a class derived from the skeleton, or will be attached as a delegate to another generated object implementation (which in turn is derived from the skeleton).

Before an object implementation can be called, the client (as well as the server) have to connect to the communication infrastructure (the ORB). Therefore, both have to make use of the standardized ORB interface provided by the ORB implementation.

There is some functionality not used by a client (e.g. special policies with regard to the creation of object references or activation modes) - in particular, one generic interface (the Object Adaptor) which is only used on the server side.

At present, most ORB implementations use the Portable Object Adaptor (POA), which is the only mandatory Object Adaptor (older applications may depend on the former Basic Object Adaptor which has been deprecated). In the future, additional Object Adaptors may be specified.

The scenario for establishing communication between the client and object implementation is pretty straight forward:

1. The server process instantiates an object implementation and attaches it to the Object Adaptor.
2. The Object Adaptor generates a globally unique ID for this object, an Interoperable Object Reference (IOR). The IOR encodes:
   • the physical address of the server process
   • the relative address of the object implementation within the address room of the server process
   • the interface type and version
3. The server process publishes the IOR (using the Naming Service, a flat file, or any other appropriate way).
4. The client retrieves the IOR and creates a new object from it using operations from the ORB interface. Up to this moment, the new object is of type CORBA::Object. In order to use the proper interface the object has to be downcasted ("narrowed") using some generated helper operations. At this time, the stub is instantiated and returned. During this procedure, a handshake protocol between the client stub and object implementation ensures a typesafe downcast.
5. The client calls the object implementation via its local stub.

Dynamic Invocation Interface (DII) and Dynamic Skeleton Interface (DSI) are alternatives to the statically generated stubs and skeletons. Before a DII call can be excecuted, the IDL description of a specific interface has to be loaded into an Interface Repository (another CORBA Object Service). A client can then retrieve the object's interface type (encoded within the IOR) using the generic CORBA::Object interface and access all necessary meta information to compose a generic request using the DII to the object implementation (without a generated static stub).

The analogous server side's mechanism is defined by the DSI. It provides a way for delivering requests from an ORB to an object implementation that does not have compile-time knowledge of the type of object it is implementing. This is primarily of use within dynamically typed languages like CommonLisp or Smalltalk.

CORBA interoperability (IIOP)

The interoperability and flexibility of CORBA makes it a perfect integration solution to bridge the gaps between different programming languages, operating systems, and computer hardware. The assumption, of course, is that the interoperability of different ORB implementations is guaranteed.

Every CORBA implementation uses the standardized General Inter-ORB Protocol (GIOP) for communication with other ORBs. The GIOP specifies the marshalling (serializing) and unmarshalling of CORBA requests and replies. The most common specialization of the GIOP is the Internet Inter-ORB Protocol (IIOP) for CORBA communication over TCP/IP.