ORB/ODBMS Integration

Discussion

In many situations, objects should outlive the processes that implement them. These situations include most practical scenarios in which distributed objects are desirable: in real-world applications, persistence is almost always a requirement. While CORBA does not support object persistence directly, its open architecture includes an object adapter, an intermediary between an object implementation and the ORB core. Object persistence can then provided by the object adapter.

The CORBA specification defines a Basic Object Adapter (BOA) that does not provide object persistence. As an example of another object adapter that might be useful, CORBA briefly mentions an adapter that makes objects stored in an object-oriented database accessible through the ORB. This idea is pursued in an appendix of the object database standard proposed by the ODMG. The ODMG-93 specification, in its Appendix B, identifies a number of issues involved in using an Object Database Management System (ODBMS) in a CORBA environment and proposes an Object Database Adapter (ODA) to realize the integration of the ORB with the ODBMS.

An Object Database Adapter allows object implementations to be written in the database programming language of the ODBMS, a language that incorporates persistence into the programming environment. The object implementation -- a CORBA server -- is still responsible for managing the persistent state of the objects it implements, but the object implementor's task is much simpler in the programming environment provided by ODBMS. Besides persistence, other database features -- data consistency in the presence of concurrent accesses, crash recovery, and so forth -- are available to the object implementation.

In existing database systems, regardless of their data model (object-oriented or relational), database clients must have some knowledge of the database schema. In the case of an object-oriented DBMS, clients need to know the object layout. In a relational DBMS, views can be used for data independence. But relational clients still need to know the external (view level) schema. By contrast, ORB/ODBMS integration makes database objects accessible to CORBA clients without exposing the database schema to these clients. The data members and the layout of a persistent CORBA object remains private, only its interface (a set of methods) is made public. This is specially interesting for web browser access to databases. With the integration of the Java language into the ORB environment, Java applets can interact with persistent CORBA objects through domain-specific interfaces, without any knowledge of how the objects are actually stored.

ORB/ODBMS integration leads to ORB-connected multidatabases. Together with OTS, the Object Transaction Service specified by the OMG, it enables the construction of distributed object databases that are truly heterogeneous, even with respect to the DBMS software running on the various database server nodes.

Storing CORBA Objects in an Object Database: The Issues

The gap between object access times in the ORB and in the ODBMS environment is the first issue an Object Database Adapter must address. Because CORBA clients access objects via remote method invocation, access times for CORBA objects are expressed in milliseconds. Because ODBMSs keep an object cache at the client side, ODBMS clients can access objects much faster: access times for ODBMS objects are typically expressed in microseconds.

Due to the this performance gap, an Object Database Adapter cannot force all accesses to the objects in a database to be made through the ORB remote method invocation mechanism. In the case of a large collection of very small objects, the overhead would be unacceptable. Instead, the ODA should let the object implementor choose a suitable subset of database objects, presumably the higher level ones, to be accessed as CORBA objects. Since this subset may still be large, individual registration of its objects with the ORB is not practical. The ODA should allow a subset of database objects to be accessed through the ORB, without requiring an explicit registration call for each object.

Moreover, in the common case of an ODBMS that adds database features to C++, an object implementation cannot simply store in an object database the CORBA objects it implements:

An Object Database Adapter has to solve these problems, ideally in a way that makes persistent CORBA objects appear exactly like ordinary database objects. As much as possible, object implementors should be unaware that a persistent CORBA object does not really live in the database.

Persistence of CORBA Object References

Besides providing persistence to CORBA objects, the Object Database Adapter must also provide persistence to the corresponding object references. In CORBA, persistence of object references means that "a client that has an object reference can use it at any time without warning, even if the (object) implementation has been deactivated or the (server) system has been restarted".

With persistence of object references, it makes perfect sense for a client to store an object reference for later use. References to persistent CORBA objects implemented by server X can be stored by server Y (a client of server X) and vice-versa, thereby enabling the construction of ORB-connected multidatabases. In such a multidatabase, references to remote objects are used to express relationships between CORBA objects implemented by different servers. If distributed transactions are needed, they can be supported by a TP monitor that implements the Object Transaction Service.

Storability of CORBA Object References

Because an object reference is opaque and ORB-dependent, CORBA provides operations that convert an object reference to string and vice-versa. Object references are stored as strings; upon retrieval they must be converted back to their native form.

Translation to and from string format provides maximum flexibility, allowing object references to be kept in any media. In an ODBMS environment, however, object storage and retrieval are transparent to the programmer. The need for explicit translation of stored references does not prevent the construction of ORB-connected multidatabases, but is unnatural in the context of an object database: ODBMS users expect stored references that behave like any other database object.

Transparent storability of CORBA object references is yet another desirable feature of an Object Database Adapter. It eliminates the need for explicit object reference conversions, both before storage and after retrieval, and allows transparent use of stored references to invoke methods on possibly remote objects.

Relationship with the Persistent Object Service

The Persistent Object Service (POS) is one of the object services specified by the OMG. Designed to provide client control over object persistence, POS is geared towards objects that expose their persistence to CORBA clients.

In the POS terminology, a Persistent Object (PO) is an object whose persistence is controlled externally by its clients. POS adopts a two-level store model: a Persistent Object has a dynamic state and a persistent state. The latter is typically kept in memory, and may not exist for the whole lifetime of the object. The PO interface defines the operations connect, disconnect, store, restore, and delete. Through these operations, clients can control the persistence of a PO. For instance, they can request an update of the persistent state with the contents of the dynamic state (store), or vice-versa (restore).

The PO interface is the client's view of this service. On the server side, POS defines components used by PO implementations. A Persistent Object Manager (POM) provides a uniform interface to the underlying Persistent Data Services. A Persistent Data Service (PDS) provides a uniform interface for any combination of Datastore and Protocol. The persistent state of a PO is ultimately kept in a Datastore. Data is read and written to a Datastore through a Protocol, which depends both on the Datastore and on how data is moved into and out of (the dynamic state of) objects.

POS defines its lower level components in rather vague terms, in an attempt to encompass a large variety of storage services. Although no "standard" Protocol is specified, POS mentions three possible Protocols. One of them is the ODMG Protocol, used when the Datastore is an ODMG-compliant ODBMS. Rather than fully defining this Protocol, the POS specification discusses it very briefly, in a half-page section.

According to one of the principal architects of POS, this service "is about open frameworks that allow objects to be stored anyplace, with special emphasis on the mainstream databases on which corporations depend." At first, an Object Database Adapter may seem a much more restrictive approach, as most corporate data is kept in relational databases. Nevertheless, ORB/ODBMS integration does not exclude relational databases. Through object-relational mapping, relational DBMSs can be viewed as ODBMSs. Relational databases can then be integrated into the ORB environment, and be components of ORB-connected multidatabases. Object-relational mapping allows an object structure to be superimposed onto an existing relational database. The superimposed object structure can even include user-defined methods, through which the relational data may be accessed in a fully object-oriented fashion. In our opinion, object-relational mapping plus an Object Database Adapter is the best way to integrate relational DBMSs into the ORB environment.

ORB/ODBMS integration and POS have opposite goals. Instead of exposing object persistence to clients, ORB/ODBMS integration provides object persistence in a way transparent to clients. Rather than adopting a two-level store model, ORB/ODBMS integration uses the ODBMS single-level store model and extends it to CORBA clients. Even so, it appears that POS still requires an Object Database Adapter, to deal with the case of an ODMG-compliant ODBMS as the Datastore and ODMG as the Protocol.

Additional Information

I'd like to have more links here. Please send me mail if you can help extend or update this information.

ORB/ODBMS Integration

Distributed Transactions in a CORBA Environment

Distributed Queries in a CORBA Environment


Francisco Reverbel's Home Page
[HTML 3.0 (Beta) Checked!]
Last modified:
Francisco Reverbel
reverbel at ime.usp.br