ERCIM News No.45 - April 2001 [contents]

Open Services for Information Sharing among Legacy Systems

by Mark Roantree

---

The problems associated with defining interoperable protocols for heterogeneous information systems has been the subject of researchers for many years. While numerous solutions have been offered, the problem remains unsolved, mainly due to the distinctive nature of each target environment, and the uniqueness of each solution. This is not helped by the use of proprietary common data models or the use of non-open or non-standard technologies to provide an infrastructure and services. In the OASIS project, services and processors were defined and implemented using a platform of existing standards such as ODMG and CORBA. This provides a more open platform for the GRIDs architecture, and enhances forward interoperability with new systems over time.

The Interoperable Systems Group at Dublin City University conducts research in issues concerned with the sharing of complex objects between information systems. The OASIS project (www.compapp.dcu.ie/~oasis) which used ODMG databases as interfaces to integrate heterogeneous healthcare systems, was started in October 1998 and completed in December 2000. Research was focused on the usage of modern technologies, standards, and common database models rather than the introduction of new proprietary solutions.

This type of GRIDs architecture comprises five layers and numerous processor types for the integration of non-ODMG information systems. Any number of local systems may be integrated to form a federated schema. At the local information system level, two services are required to prepare information systems for participation in the GRIDs system: a wrapper service which binds the information system to a common model representation; and a view service to define an object-oriented subschema of shareable data.

Essentially, the Wrapper Service comprises a specification language for mapping ODMG to non-ODMG entities, and a language parser combined with a storage mechanism. Briefly, a wrapper may contain any number of entities specified in the form of a class; a class has a name and is comprised of attributes and relationships; and a class may have relationships with other classes. In other words, the wrapper language permits an ODMG-style specification. Due to its close association with the ODMG model, the wrapper specification language is known as ODLw, the Object Definition Language for Wrappers.

The View Service comprises a specification language for defining local and global views, and a language parser combined with a storage mechanism. The view language, ODLv (Object Definition Language for Views) is more complex than ODLw due to the nature of the operations involved. The purpose of the view language is to define subschemata which contain as much semantic information as possible, and to provide an operator set which supports the integration of subschemata. In figure 1, the view definition (an ODLv file) is processed by the View Service and stored as a collection of metaclass instances. A standard interface to the schema repository is crucial to both the view and display services. During the design of ODLv, it was necessary to extend the ODMG schema repository specification to include the concept of virtual types. These extensions maintained the structure and naming scheme of the original repository interface for the purpose of interoperability.

Figure 1: Definition of metadata for sharing with external Information Systems.	Figure 2: Legacy Systems in the GRIDs Architecture.

Once ODMG views are defined, they are passed to a global information server known as the Federated Kernel. Here they can be integrated using the same ODLv language to form global or federated schemata.

The Transport Processor is used to move data between local ISs (at the export layer) and the federated database kernel (at the federated layer). In practical terms metadata is moved when export schemata are extracted from local ISs and transferred to the federated kernel; query data is passed from the federated kernel to local ISs; data is moved to the federated kernel, or to local ISs which may request data. The Transport Layer (displayed in figure 2) contains different implemen-tations of transport processors depending on the required function and the constituent parts which comprise the federation. This facilitates the participation of heterogeneous software and hardware systems in the GRIDs architecture.

The service architecture described in this article has been implemented sufficiently to create and query federated schemata. Several healthcare systems with ODBC interfaces were employed as participating systems, and using the view language, federated schemata were defined. The View and Wrapper Services were implemented for NT platforms using Java and ANTLR to code the BNF production rules for each language, and C++ to code the semantic actions to process and store view and wrapper definitions. The Versant object-oriented database was used to provide ODMG storage for component, export and federated schemata. Finally, at the transport layer, three versions of transport processor were implemented: a Versant (vendor) processor which provides a direct connection between each local and global Versant database for direct migration of meta-objects; an XML processor which converts ODMG objects into XML objects for transfer between any ODMG database in the federation; and a CORBA processor implemented in Orbix. A Display Service has been implemented to display local and global views, including those which have been integrated using any of the join operators earlier. It is implemented using C++ for NT platforms. Details of how to build the prototype system is available at the OASIS web page.

Link:
Oasis web page: http://www.compapp.dcu.ie/~oasis/

Please contact:
Mark Roantree - Dublin City University
Tel: +353 1 7005 636
E-mail: mark.roantree@compapp.dcu.ie