Common Object Request Broker Architecture (CORBA).
A Specification for Invisibly Accessing Objects Across Processes and Networks.

Introduction

What CORBA provides to software developers is an easy way to separate out components of a program into small, self contained, "mini" programs. These mini programs can run anywhere on a network and communicate via a well defined interface. What this means to end users is a software solution that is considerably more fault tolerant than anything they are used to and a lot more flexible in terms of scalability and adding new functionality.

Using CORBA the software developer can decouple the different parts of the program and have these parts communicate using the well defined interface. These software components can communicate across a network if desired. In terms of speed this means that a particularly CPU intensive aspect of the program may be run on another computer on the network which is better suited to the task while a graphical output of data could run on the users desktop. In terms of fault tolerance this means that the software could very simply build redundancy into the system. Take, for example, a system where multiple databases are running on the network, each mirroring one another. If one database were to go down another could take its place without the end user knowing about it at all. In terms of functional flexibility CORBA architecture means that if a particular software component requires enhancement, only that part of the program need be modified and could then be slotted into place when completed. It would communicate with the other parts of the program via the well defined interface and the end user would not even have to stop running their application. In terms of scalability CORBA allows different software components to be moved around the network as required.

This is not new technology as such. What CORBA offers is a very easy way for the software developer to access other software components across networks at a level of resolution far finer than has ever been available. Furthermore, simple "mini" programs could be developed which only do single tasks but would advertise the fact across, say, the Internet for all who wish to use.

For example, consider the average web browser. This could be split up into a graphics engine, an FTP client, a mail client, a newsreader etc. Using CORBA technology such an application could be made up of several discreet programs all defining their interface. As an example of such an interface, an FTP client may have methods such as "getFile" or "putFile". A mail client may have methods such as "sendMessage". In an organisation there may be a single computer dedicated to mail and another dedicated to FTP. The end user would have the graphics engine program running on their desktop computer and this would communicate with the FTP client program and the mail client program. The user would see faster graphics, as only one part of the program is running on their desktop, and if the mail client needed to be upgraded then it could be without affecting anyone. No software would have to be replaced on any users desktop. Furthermore, this sort of software architecture saves space by avoiding replication. In this example the mail client software exists on only one computer.

Background

As software systems become larger, in terms of data and functionality, they must either become huge monolithic programs which do everything or be split into smaller, more manageable, components. For example it is common for systems to have multiple displays on many monitors possibly offering different views of the same data. In most cases it is a simpler, more elegant, solution to have separate processes for the display programs and a single server program processing the data.

With many systems, especially data critical systems, the responsibility of data integrity and data maintenance cannot be left to a single process or even a single computer. With, for example, automatic teller machines in banking systems, the knowledge of the withdrawal one makes at one machine must be passed around to all the other machines, or at least a central machine. Otherwise one could simply overdraw their bank account by withdrawing from several different machines.

Client Server Architecture and Distributed Systems

In a Client Server Architecture system there is one main repository of data, say a database program, and many client programs which read and write data from this server program. Once again, in the banking example, the automatic teller machine software would be a client of the main banking database server. A distributed system could be described as an extension of the client server model. There may be more than a single server, yet each server must somehow communicate with the others in order to maintain data integrity.

Distributing a software system across multiple processes and multiple machines has been popular for some time. Typically, data sharing has been done using techniques such as IPC (Inter Process Communication) or via raw sockets.

In comparison, CORBA offers the ability for the class designer to define a simple interface to their class. The class user can use that interface whether the class is in the same process, another process or even on another computer on the network.

More simply put, one is able to communicate between processes and across networks transparently at the class level. It is irrelevant where the data lies, all that needs to be known is that it is accessible.

Why Is CORBA Useful?

Changing the Implementation

Once the interface to a class has been finalised and the implementation of that class resides in another process then the clients of that class can be completed. Then if that class needs to be modified it will have no impact on the client. The client need not be recompiled, relinked or even restarted. A new implementation can be slipped in underneath the client without any repercussions. Taking this to an extreme, in an object oriented software system where each class implementation resides in a separate process, any class implementation could be modified without any impact to the rest of the system.

For example if a particular third party database was used by a software system and it needed to be replaced then a different database could be put in place without touching the source code for the rest of the system. The rest of the system would not notice that the details of the database had changed, they would not even have to restart.

Defining the Interface First

In a large software development project some of the major issues are; the interface between the various software components, when this interface becomes available, and the stability of this interface. If the project decides upon using a CORBA implementation then, as a matter of course, they must define the interface to their components very early in the development cycle. Having the interfaces to components defined early on means that the details of a component can be worked on without affecting the work on any other component. This generally means a quicker software development cycle.

Invisible Access

As mentioned before, CORBA allows clients and servers to bind to each other across not only processes but also networks. The client and server need not know where the other is, it is completely invisible. If a computer running a client or server is taken out of service it is feasible to move the location of the client or server without impact to the system as a whole.

The Interface

A class to print a string may have an interface as follows: 

          //
          // This is file Print.idl
          //
          #define PRINT_SERVER_NAME "PrintServer"
          interface Print 
          {
          attribute   string  stringToPrint;
          void        doPrint(in string outputString);
          };
Using the IDL compiler on the file Print.idl the following files are generated:
  • Print.hh this is the header file containing both the client code and the implementation code.
  • PrintS.cc a source file containing implementation (server) code.
  • PrintC.cc. a source file containing client code.

To the end user this means that certain parts of the software system could be running on computers which are best suited to performing the task, freeing up other computers for things like graphical displays. Furthermore, if at a later date it is decided that some components should be moved around to other computers this can then be done without changing any software.

Object Resolution Access

Normal inter process communication cannot provide the level of resolution of CORBA. Having access to a process - on the same machine or across the entire Internet - on a per object basis allows greater flexibility for program design and implementation as well as greater efficiency. Clients are oblivious to the fact that any sort of inter process communication is happening at all. The software developer is unable to achieve this level of resolution using other system architectures.

What Is CORBA?

The Common Object Request Broker Architecture (CORBA) is a specification which allows objects to be transparently accessed across processes and networks. CORBA was specified by the Object Management Group, Inc. (OMG). OMG is an international organisation made up of many software system vendors. It was founded in 1989 with the main purpose of establishing industry guidelines and specifications which provide a common framework for application software development.

Very simply, the CORBA specification is broken up into the Object Request Broker and the Interface Definition Language.

The Object Request Broker (ORB)

The Object Request Broker is a program running on a network that accepts connections from clients and servers and coordinates messages between them. Typically the client makes requests to the server which pass through the ORB. In a software system using CORBA a client would simply call a function in the server as if it would be in the same process as itself. The function call goes via the ORB which passes it to the server and then passes the return value back to the client. The ORB is responsible for all of the mechanisms involved in finding the correct object in the server and passing all the data to the server making up the request.

The Interface Definition Language (IDL)

The IDL provides the class designer with a way of defining the interface to a class in a completely independent manner. That is, this interface is free of any constraints to do with location and programming language. There are currently mappings available from IDL to C, C++, Smalltalk and Java. IDL allows the class designer to inform the class users of available operations and how they should be invoked.

The Implementation or Server Side

The IDL compiler creates two classes. Print and PrintBoaImpl. The class implementor derives from the class PrintBoaImpl simply filling the functionality of the class. For example: 

          //
          // Header file PrintImpl.hh
          //
          #include "Print.hh"

          class PrintImpl : public PrintBoaImpl
          {
          public: 
          void doPrint(const char* outputString)
          };
          

          //
          // Source file PrintImpl.cc
          //
          #include <iostream.h>
          #include "PrintImpl.hh"
          PrintImpl::doPrint(const char* outputString)
          { 
          cout << outputString << endl;
          }

The server executable would be made up of the source files PrintS.cc and PrintImpl.cc.

Using IDL

The class implementor creates an interface to their class using IDL. The IDL defines which attributes and methods are available to anyone wishing to use that class. IDL is very similar to C++ class headers and class interfaces in other object oriented languages. In the ORBIX implementation of CORBA the IDL is compiled to C++ source. Source code is generated for the client and the implementation (server). The class implementor writes a class that is derived from the server generated code.

How it works

An ORB knows about networks and about requests. Any program can register themselves with an ORB, that is tell an ORB that it is available to the network at large with a defined interface. The defined interface indicates which services are available and how they can be used. Any program can also connect to an ORB and use any of the services which are on offer. It doesn't matter where on the network the ORB or any of the programs attaching to the ORB are located.

The Client Side

The client implementor would bind to the Print class as follows: 

          //
          // Source file Client.cc
          //
          #include "Print.hh"
          //
          // Bind to the Print class.
          //
          Print* myPrintObject = Print::_bind(PRINT_SERVER_NAME);
          myPrintObject->doPrint("hello world");

The client executable would be made up of the source files PrintC.cc and Client.cc.

Behind the scenes the scenes the object request broker would process the _bind call and open a connection to the server. It would then process the doPrint call and pass the string "hello world" to the server. The fact that the server may be in another process or on another machine is completely invisible to the client.

CORBA Implementations

There are many implementations of CORBA which run on most operating systems including Windows 95, Windows 3.x, NT, OS/2, Macintosh and Unix platforms including Solaris, AIX, OSF/1 and Linux. Some Windows and NT implementations include support for OLE enabled applications. For more information see www.acl.lanl.gov/CORBA

In Conclusion

To the end user CORBA provides the following:

  • Scalability: Different software components can be moved around the network as required.
  • Fault tolerance: Software components which manage data can be replicated across a network and can replace one another invisibly if there is some sort of failure.
  • Process serving: Processes can be run on those computers best suited to the task. Graphics, for example, could run on the local machine whereas more CPU intensive tasks could be run on a larger computer elsewhere on the network.
  • Invisible enhancements: Components can be upgraded without interfering with any other running components.
  • Space saving: Software components need not be replicated.

To the software developer CORBA provides the following:

  • A faster software development cycle: The interface to a software component must be defined before anything else is done. Software developers can then program to this interface without interfering with any other development taking place in the system.
  • Object Level Resolution: Software developers can bind to object instances across a process or network giving them greater control than is possible using other system architectures.
  • Flexibility: Developers have a level of abstraction from processes and computers. They need not be aware that any sort of interprocess or network activity is going on at all.

Copyright © 1997, 1998 Robi Karp. Robi is a software consultant specialising in the areas of Unix application software, software development environments and The Internet. He is technical director of Fluffy Spider Technologies Pty. Ltd. and be contacted via email: robi@fluffyspider.com.au