DIOM System Architecture

The DIOM system architecture, first introduced in [19], is a two-tier architecture offering services at both the mediator level and the wrapper level. Figure 1 presents a sketch of the Diorama architecture, which conforms to the mediator-based reference framework [15].

  
Figure 1: DIOM System Architecture

Mediators in DIOM are application-specific. Each mediator consists of a consumer's domain model and many information producer's source models and are described in terms of the DIOM interface definition language (DIOM IDL) [19]. The consumer's domain model specifies the querying interests of the consumer and the preferred query result representation. The producer's source models describe the information sources in terms of DIOM internal object representation generated by the DIOM interface manager. The consumer's domain model and the information producer's source models constitute the general knowledge of a mediator and are used to determine how a consumer's information request is processed. The main task of the mediator sub-system is to utilize the metadata provided by both information consumers and information producers for efficient processing of distributed queries.

Wrappers are software modules, each serving for one component data repository. The main task of a wrapper is to control and facilitate external access to the information repositories by using the local metadata maintained in the implementation repository and the wrapper functions.

Information sources at the bottom of the diagram are either well structured (e.g., RDBMS, OODBMS), or semi-structured (e.g., HTML files, text based records), or unstructured (e.g., technical reports). Each information source is treated as an autonomous unit. Component information sources may make changes without requiring consent from any mediators.

The following provides a brief description of the main components of the Diorama architecture:

DIOM Interface Manager:

interacts with the system user by presenting a GUI interface and underlying API to allow users to perform DIOM functions, compiles IDL statements using the IDL compiler and preprocesses IQL statements using the IQL preprocessor.

Distributed Query Mediation Service Provider:

provides the distributed query processing services including source selection, query decomposition, parallel access plan generation, and result assembly.

Runtime Supervisor:

executes subqueries by communicating with wrappers.

Information Source Catalog Manager:

responsible for the management of both information source repository metadata and interface repository metadata, and communicates with the local implementation repository managers to cooperate in the maintenance of wrapper metadata.

Query Wrapper Service Manager:

receives query requests from the runtime supervisor, uses data from the implementation repository, utilizes the wrapper query processing modules, and communicates with the local information sources to return a result.

Implementation Repository Manager:

manages the implementation repository metadata by coordinating with the Information Source Catalog Manager. The implementation repository maintains the correspondence between the source information and their DIOM internal object representation.

It is interesting to note that distributing subquery translations from the mediator layer to the wrapper layer helps to prevent query processing bottleneck at the DIOM mediator server level. We also believe that the approach of building wrappers to coordinate between a mediator and its underlying sources can greatly simplify the implementation of individual mediators, making interoperation among networks of mediators easily scalable to the ever growing number of information sources.