White Paper: CORBA Applications In GNOME

The GNOME CORBA Framework

Even though the CORBA specification, and the ORBit implementation thereof, provide much functionality for GNOME, there are still pieces of a complete CORBA framework that are missing from those components. One of the biggest gaps in the CORBA specification is the lack of a standard way to start a server program for a particular object.

The implementation repository has sometimes been touted as the solution to this problem. The problem with the impl repo is that none of its interfaces are specified by the CORBA spec, meaning that one would have to be tied to a specific CORBA implementation in order to access the impl repo. When used via persistent object references, one must also have an implementation repository daemon running at all times on a well-known port. The impl repo also does not typically allow specifying server activation options, nor does it allow activating a server from a shared library.

Enter GOAD. The GNOME Object Activation Directory stores information on all the programs on a system that can act as an object server. The information stored in this directory includes the server type (shared library, executable, or "relay"), a listing of the CORBA interfaces supported by the server, a unique "server_id" that identifies the particular implementation, a human-readable description, and the filename of the executable or shared library.

The ``executable'' activation method of GOAD executes a program and returns an object reference to the object server that the program provides. Using the GNOME plug-in specification, the ``shared library'' activation method loads the object server from a shared library directly into the address space of the current program. This takes advantage of ORBit's in-process operation invocation abilities to make lightweight CORBA objects practical.

The ``relay'' activation method adds extensibility to the GOAD directory. It acquires an object reference to the object server by contacting a CORBA ``relay'' server which can do further processing on the activation request. This may become useful, for example, when large numbers of GOAD objects need to be load-balanced across multiple computer systems.

In addition to the above methods, GOAD also can check if a server for the object is already running. GOAD uses the CORBA name service as a central registry of running object servers. The information necessary to contact the name service is stored as a property on the root window of the X display of the GNOME session, contributing to GNOME's goal of network transparency. The approach of using existing object servers whenever possible allows multiple clients to share the same server, reducing resource usage.

When activating an object server, the client also has the ability to specify how it would prefer that the object be activated and other activation details. The result is a system of object server activation that allows maximum flexibility for object clients, object servers, and system administrators alike.

In addition to GOAD, the GNOME library that stores CORBA-related functionality (libgnorba) also has the behind-the-scenes routines for handling CORBA request authentication and ORB integration with the GTK main loop. Request authentication is handled on a per-display basis by passing a secret cookie along with every CORBA operation invocation. This is all completely transparent to the GNOME application, allowing future use of new security mechanisms such as SSL or the CORBA security service.

Besides GOAD and other libgnorba functionality, the GNOME CORBA framework also defines a number of standard interfaces that programs commonly implement, including generic factory and reference-counted object interfaces. These are implemented by many of the CORBA servers in the various GNOME applications, such as the panel, file manager, and spreadsheet.