libgda architecture

libgda is composed of three independant layers. The lower level is covered by the GDA providers, which are CORBA servers whose task is to map the RDBMS-specific API to the GDA model. That is, they are CORBA objects implementing the GDA CORBA interfaces.

Then, in a midlle layer, are the client libraries: a CORBA client library, which hides all the CORBA complexity to client applications, also including several utility functions to help you on the development of applications based on GDA.

Finally, at the upper level sit all the client applications provided in the suite, as well as any application that may make use of the client libraries.

libgda is CORBA based and uses ORBit as the CORBA implementation. Basically the system provides an IDL file as the interface to the client. For every different data source type (ODBC,Sybase, Informix, MySQL, LDAP, ...) a server must be written. This server ideally is a shared library which is linked with a small driver program to form a standalone CORBA server. The shared driver approach makes it possible to use the server as a library for the client, reducing round trip time (no sockets and context switches required).

The advantage of using a CORBA server is, that the server may run on another machine, balancing the load. This is possible because ORBit is small and fast. You can use the same server from a CORBA aware scripting language and you might do tracing and transaction control in the server, without needing to change the client. The drawback is that if such a provider crashes all the clients are disconnected from the database. To overcome this problem it is possible for each client to request a new copy of the provider (although the client API doesn't yet provide this flag).

The other type of providers are shared library providers. These providers are linked to the client when the client requests something from the provider. The disadvantage is that the server is hosted on the same machine as the client. But a server crash only affects one client. The startup cost is comparable to an executable provider. The big advantage of this sort of providers is that debugging the provider code is simpler, since you must not attach GDA to a running provider and you also can catch errors during server initialization.

Per default every GDA provider is available as an executable and as a shared library. The build process and the conventions used to implement the provider make sure that the executable and the shared library are made and installed. Thus, GDA providers are implemented in shared libraries, which are then linked with a small program which just acts as a driver for the shared library.