Interoperability of O-O languages and databases

sowa <sowa@turing.pacss.binghamton.edu>
Date: Sun, 4 Apr 1993 11:35:23 -0700
Message-id: <9304041831.AA00737@turing.pacss.binghamton.edu>
Comment: List name: SRKB-LIST (do not use email address as name)
Originator: srkb-list@isi.edu
Errors-To: neches@ISI.EDU
Reply-To: <sowa@turing.pacss.binghamton.edu>
Sender: srkb-list@ISI.EDU
Version: 5.5 -- Copyright (c) 1991/92, Anastasios Kotsikonas
From: sowa <sowa@turing.pacss.binghamton.edu>
To: Multiple recipients of list <srkb-list@ISI.EDU>
Subject: Interoperability of O-O languages and databases

In commenting on my earlier note about object-oriented languages
and databases, Pat Hayes noted that the differences between the
declarative approaches for which logic was well suited and the
procedural approaches that are primarily used with languages like C++
created a major barrier to interoperability.

I don't disagree with that point, but I wanted to mention some other
issues that create barriers that are even more serious than with
traditional procedural languages like FORTRAN, COBOL, Pascal, etc.

In those old-fashioned languages, programmers have had "persistent
storage" since Day 1 (circa 1957).  It was simply called I/O on
good old-fashioned cards and tapes.  A program could write out a
file in FORTRAN and read it back in with COBOL or Pascal, as long
as the data in the file used the same machine-dependent data types
in each of the two languages.  With database systems and SQL, it
is possible to share data among multiple programs on different
computers written in different languages all running concurrently.

But with O-O languages, it is difficult if not impossible to
achieve the level of persistence that FORTRAN supported in 1957.
You can't write all the active data on a file, stop the program,
and then restart the program, reload the file, and pick up where
you left off the day before.  Instead, all the objects are complex
data structures that are intimately intertwined with activations of
procedures.  You can't checkpoint the state of each object in a
C++ program, save them all in a file, and later reload them to
recrerate the same environment at another time.

There are object-oriented database systems that do support
sharing and persistent storage to some degree.  But none of
them allow you to write out a collection of objects in one
language, such as C++, and read them back in another language
such as Smalltalk -- even when the both the procedural and
the declarative aspects of the object definitions in the two
languages are equivalent.

Even worse, two different O-O database systems written in the
same language such as C++ cannot share objects with one another.

All of these languages let you read and write files or issue
SQL queries to conventional databases.  But that does not give
you the capability of saving the states of active objects without
writing complex destructor and constructor routines that tear
apart the entire system of objects and painstakingly rebuild 
them from files of low-level data.

Despite the difficulties, I don't believe that the interoperabililty
problem is completely unsolvable.  Suppose, for example, that one
could specify the type hierarchy and attributes for a family of
objects in a declarative form and associate the names of the
appropriate methods or procedures for each object class.  Then
that specification could be translated into a collection of
definitions in C++ or Smalltalk or other O-O language, and
some programmer would be responsible for rewriting the purely
procedural parts.  If the programmer made a mistake or cheated,
the procedures might not be exactly equivalent, but the declarative
specifications could be used to take apart and reconstruct the
data parts in any of several different languages.  That ability
alone would be a major advance over the current state of OODBMS.
The next step would be to compile the procedural parts as well
>From some sort of high-level specification and ensure common
data and procedural compatibility.

John Sowa