Persistent objects -- ODMG

Instructor's Guide

intro, components, standards, Java workgroup, corba and hush, summary, Q/A, literature
In a similar vein as the OMG, a number of vendors of object database management systems (including SunSoft, Object Design, Ontos, O_{2} Technology, Versant, Objectivity, Hewlett Packard, POET Software, Itasca, Intellitic, Digital Equipment Corporation, Servio, Texas Instruments) have participated in the ODMG (Object Database Management systems Group) to develop a standard for the definition and manipulation of persistent objects. The standards proposal of the ODMG encompasses an object definition language ODL, which is intended as an extension of the OMG/IDL standard, an object manipulation language, OML and an object query language, OQL, that provides SQL-like facilities for the retrieval of information. The advantage of employing an object database system over employing a relational database system is that, in principle, the application programmer may work within a unified type system, encompassing both persistent and transient objects. See slide 11-ODMG.

Persistent objects

ODMG


Object Definition Language

ODL


Object Manipulation Language

OML


Object Query Language

OQL


slide: The ODMG-93 standardization efforts
 The extensions to the various languages, which include C++ and Smalltalk, involve the definition of persistent objects, the creation and use of objects and facilities to pose queries concerning their attributes and relations. These extensions are proposed as language-specific bindings for respectively ODL, OML and OQL. The object model proposed by the ODMG supports objects (which may have attributes and methods), literals (which may be considered as primitive values), relationships between objects (including m-n relations), extents (which contain the collection of instances of a particular type), and named objects (to facilitate retrieval). To define objects and literals, the programmer may employ the standard types offered by the language, as well as a number of additional parametrized types to define references and collections. For references the ODMG-93 proposal employs a Ref smart pointer construct. For dealing with collections a number of generic collection classes such as List, Bag and Set must be provided by a standard library. (To provide a binding for Smalltalk, which does not have a type system, type annotations must be employed to define the properties of persistent objects.) The manipulation of persistent objects conforms with the manipulation of ordinary objects as far as attribute access and method invocation are concerned. However, the language-specific OML bindings must take precautions for the creation, deletion and modification of objects. In particular, when employing a reference to a persistent object, the implementation must check whether the referenced object has been modified. The C++ binding for the object query language OQL in the ODMG-93 proposal is quite simple. It consists merely of a function that allows the programmer to pass an extended SQL-like query as a string. The query may contain symbolic variables that are bound in a similar way as allowed by the C printf function. The design principle guiding the ODMG effort has been to promote that the programmer feels that there is one language. However, there are a number of difficulties that arise when defining a particular language binding for the ODMG object model, as for example for C++. See slide 11-binding.

Design principles

object model


Language binding

C++ODL/OML


slide: Language binding -- C++ ODL/OML
 Embedded objects which are defined in C++ as object data members, must be taken as literals in the ODMG object model, whereas embedded references to objects are to be taken as objects. Relationships are not directly supported in C++. In the ODMG-93 proposal, the programmer is required to employ an explicit data structure for updating and traversing a relation. Extents, which contain the collection of instances of a type, must explicitly be maintained by the programmer. Extents may conveniently be stored in a collection that is associated with a static data member of the class. Keys, which are needed for efficient retrieval, must be simulated by C++ data members. Support for indexing and retrieval by key requires additional compiler support, for which no provision is made in the ODMG-93 proposal. Other problems that arise in defining a binding to C++ involve the naming of objects, the restriction that C++ allows for only one implementation of a particular type and the duality between arrays and pointers.

Discussion

 Both the OMG and ODMG standardization efforts aim at the portability of software. The ODMG proposal not only entails the portability of design and source code, but also includes object code, in the form of persistent objects. The ODMG-93 proposal is inadequate due, partially, to the self-imposed restrictions with respect to the compiler support required.

C++ODL/OML binding -- future

  • no distinction between persistent and transient objects
  • better integration of the query sublanguage

Modifications to C++
  • overloading dot (access operator), r/l values, ...

Standardization efforts -- de facto market share

  • PDES/STEP, ODA, PCTE, OSI/NMF, ISO ODP, ANSI X3
slide: Future standardization efforts
 The future C++ODL/OML binding will probably no longer distinguish between references to persistent and transient objects, and will provide a better integration of the query language OQL. To realize these goals, however, extended compiler support is needed and perhaps also modifications of C++ to allow the incorporation of code for integrity checking. It is worth noting that there are a number of additional efforts at defining a standard object model. See slide 11-efforts. The ODMG proposal is explicitly meant as a superset of the object model proposed by the OMG, in order to become what they aptly phrase as a standard enforced by a de facto market share.