The Electronic Notebook Toolkit Architecture

We propose a CORBA compliant architecture for connecting multiple EN data repositories, interfaces, and other applications, where each component (client) would be able to transparently access other local or remote components (servers), without concern for the physical location of the server or the underlying data management system itself. Further, EN components could be programmed using a wide variety of programming languages, such as Smalltalk, Java or C++, and implemented using a variety of platforms and operating systems, while making use of a common and well-defined interface.

We discuss below in more detail an architecture and implementation strategy for an OPM interface for the OPM tools in a CORBA compliant environment.

A CORBA compliant OPM interface should provide server access to an OPM database (native or retrofitted) via a CORBA-compliant ORB. It should allow client objects to access the metadata (schema) for an OPM database and to execute OPM queries over the database.

  
Figure 4: Connecting an OPM database to an ORB using the CORBA OPM Interface

We propose to pursue a single generic CORBA interface for OPM databases. This interface will support access to OPM metadata through generic representations of the data, and will allow for the execution of queries against the database using the OPM Query Language Translator (OPM-QLT) (see figure 4). The module specification will describe classes representing OPM schemas, OPM databases and query results.

  
Figure 5: Main classes for the CORBA OPM interface

The main IDL classes of the CORBA OPM interface module are illustrated in figure 5: double arrows represent inheritance and dotted arrows represent dependencies in the IDL definitions:

1. The OPM Schema class has methods for accessing the metadata stored in an OPM schema, including OPM class and attribute definitions, descriptions, sample data and so on.
2. The OPM Database class has methods for accessing the schema of a database (returning an object of the OPM Schema class), and for submitting queries to a database.
3. Queries are submitted as strings representing an OPM-QL query. The result of such a query invocation will be an object of the Query Results class. The Query Results class will be self-describing, in that it will contain type information and metadata in addition to data values, and will provide methods for accessing the types and metadata for the data returned.

The IDL class specifications will be used for generating the appropriate stubs for the client application, while the methods for the IDL classes of the CORBA OPM interface will be provided as part of the OPM database server.

The combination of such an interface with the OPM retrofitting tools is particularly powerful: it will allow EN applications to access EN databases implemented with a variety data management systems using a single CORBA interface and query language, regardless of whether a CORBA compliant interface for a particular data management system is available. This includes databases implemented using DBMSs such as Sybase or ObjectStore, or flat files. Additional benefits of this system include the ability to access metadata and constraints for a particular EN database, and the ability of OPM to provide a semantically enhanced view of an EN database, allowing queries to be formulated in terms of the conceptual entities represented by the database rather than the relational or other lower level representation.

The EN interfaces we envision will be CORBA based versions of the Web interface described in section : OPM schemas will be retrieved via the CORBA compliant OPM interface, and OPM queries expressed over these schemas will be submitted to the OPM query translator and underlying database via the CORBA ORB, as described above (see figure 4).

Note that client applications can be implemented in any programming language supported by CORBA, and could access OPM tools running on a remote system. Such client applications could also be implemented on any platform for which a CORBA ORB is available, including platforms which are not directly supported by the OPM tools. Furthermore, it would be transparent to the client application whether it was accessing local or remote OPM databases, or even multiple versions of the OPM tools implemented on different platforms.