Figure 1 is the software architecture of the HERMES system. As emphasized in the introduction, a prime motivation behind the design of HERMES is to modularize the activities involved in creating a mediator. In particular, central to HERMES is the logical separation of the construction of the mediation code, and the integration of new domains. These were referred to, respectively, in the previous section, as semantic integration and domain integration. In Figure 1, the domains that are integrated are represented by the box in the lower right-hand corner. Each of the items in the box represents a data source or a reasoning system that mediation code written inside HERMES can access. Each of these software packages constitutes a domain.
As the figure indicates, the system is accessed by two types of individuals: the mediator author, and the end-user. The interaction of the mediator author with HERMES is through the mediator programming environment, while the end-user accesses existing mediators through a variety of user-interfaces. The mediator programming environment offers a set of toolkits to assist the mediator author in both the domain, and the semantic integration phase.
Broadly speaking, the mediator author designs and implements the code that integrates data across data sources and reasoning systems. The logical division that we have taken between semantic and domain integration implies that a mediator author may, at one time, perform only domain integration, or only semantic integration, but not necessarily both.
Existing mediating software is typically written in C-like languages. In HERMES, we have chosen a high-level, declarative, logic based language for constructing mediation code. The theory of this language has been investigated in considerable detail in [15,22,1]. The syntax of this language will be introduced in Section 2.2
HERMES provides a set of tools to assist the mediator author in the construction of mediators. Some of the tools are useful for domain integration, while others are used for semantic integration. These tools together with the logical language forms the mediator programming environment depicted in Figure 1. We briefly discuss the ideas behind the tools.
In general, access to a software package involves a few, relatively common steps. These same steps need to be taken whether the software is accessed manually, or automatically. As an example, to manually execute a query in Sybase requires first invoking Sybase from a Unix prompt, followed by retrieving the relevant Sybase databases from within Sybase, and lastly issuing a query using the SQL query language. When the answer is received, there may exist an option for storing the answer for future use. The final operation is to close Sybase. The automation of these steps is non-trivial as it involves communication between multiple processes on a workstation. These processes include: the calling process, namely HERMES; Sybase, the called process; and any subprocesses that Sybase itself may spawn. The situation becomes considerably more complex when these subprocesses in turn spawn other new processes.
The mediator language underlying HERMES is a logical, rule-based language. Consequently, a natural choice for the end-user query language is also a logical query language, similar to HERMES'. In addition, a host of other query languages is provided in HERMES that together, make up the heterogeneous user interface. The interface supports conjunctive queries whose parts may be expressed in different languages, including the logical mediator language, and an English-like language. A mix of the logic and English language may also be possible. Work is currently under way to augment the interfact with voice, as well as graphical queries. More discussion on the user interface will be given in Section 2.6.
[ Top ] [ Previous Section ] [ Next Section ]
Click here to go back to the Hermes homepage .