ORB/ODBMS Integration

• Discussion
  • Storing CORBA Objects in an Object Database: The Issues
  • Persistence of CORBA Object References
  • Storability of CORBA Object References
  • Relationship with the Persistent Object Service
• Links to Additional Information

Discussion

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

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:

• It would be a waste of database space: a C++ CORBA object has ORB-specific data members that should not be stored. It typically also has a pair of hidden vbase and vtable pointers for each interface class in its inheritance chain up to CORBA::Object.
• More importantly, the CORBA operations duplicate and release update the object's reference count. If the reference count were actually stored in the database, every operation on the object would have to be performed within an update transaction, because duplicate and release appear everywhere.
• Yet more importantly, ORB implementations keep a per-process table of active objects: a new entry is inserted into this table whenever the constructor of a CORBA object is invoked by the corresponding process. In a C++-based ODBMS, however, the constructor of a persistent object is only invoked when the object is added to the database. As far as the ORB is concerned, CORBA objects stored by other processes (including previous runs of the same program) would not be active.

Persistence of CORBA Object References

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

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

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

ORB/ODBMS Integration

• my own research on ORB/ODBMS integration, performed as part of the Advanced Computing Laboratory's Sunrise project.

• Iona's Orbix+ObjectStore Adapter;

• Iona's Orbix+Versant Adapter (not yet released as a product);

• Expersoft's plans on the integration of its ORB with ObjectStore (press release).

Distributed Transactions in a CORBA Environment

• the Object Transaction Service specified by the OMG;

• Orbix-TP, the integration of Orbix and Novell's Tuxedo TP monitor;

• TPBroker, Hitachi and PostModern Computing's implementation of the Object Transaction Service.

Distributed Queries in a CORBA Environment

• the Object Query Service specified by the OMG,