3.1 -- Introduction: The Hermes system architecture includes components for evaluating queries and domain functions on a single machine or across a network. Hermes provides standalone and client/server programming interfaces for application-specific interfaces, logic-based interfaces, and external software.
Much of the Hermes system is readily accessible due to its numerous Ascii initialization and data files. Our overview of the system architecture begins with the text files.
3.1.1 -- The domain catalog file declares domains (relation, quadtree, text, etc.) and their functions (select, range, search, etc.). Each domain function declaration includes the inputs, outputs and a brief English description of the process. Chapter 6 describes the domain catalog syntax and usage.
3.1.2 -- Mediator files list declarations and rules for accessing and combining diverse software and data. A mediator often corresponds to an application, such as for inventory management or travel planning. Chapter 7 describes the mediator language syntax and usage.
3.1.3 -- Mediator catalog files declare the names and locations of mediator files available to the user. Chapter 8 describes mediator catalog declaration syntax and usage..
3.1.4 -- Hermes search engine software forms the core of the Hermes project. Search engine code, such as that linked into the Hermes, XHermes, RHermes2, and RCall2 interfaces, processes mediator declarations and rules, performing the data exchange and computations through accessible domain interfaces.
3.1.5 -- Domain interfaces include C program code for each domain. Larger domains, such as those which access relational, spatial or text databases, are linked with or communicate with external software and data. Smaller domains, such as for math or string functions, simply use the domain interface for their computations. The process of integrating domains is explained in Chapter 11.
A domain interface can use the domain function client provided by Hermes to send a domain function to a server to process and return the answers. A domain interface on a local machine determines whether to send a domain function to a server, and can use either the automatic facilities provided by Hermes or its own domain-specific communications, which may be more efficient.
3.1.6 -- Domain function servers process domain function (versus an entire query). The domain function server uses the same domain catalog, domain interfaces and external software and data as on a local machine. A domain function server can also be configured to process only certain domains and functions.
3.2 -- Hermes provides standalone and client/server programming interfaces that can be used for developing various applications. For the client/server interface, the query server processes entire queries. It is directly linked to the search engine. The query client is a module with a C programming interface with half a dozen functions for sending queries to the query server and receiving answers. These standalone and client/server programming interfaces can be used in various ways:
3.2.1 -- Application interfaces are easy-to-use interactive graphical or text interfaces for specific applications, such as the web front-end (see chapter 9), the stand-alone inventory management application, and a travel planning interface. Interfaces, developed in in Motif, Tcl/Tk, Windows, and so forth, can either be linked to the search engine using the standalone programming interface or can communicate with the search engine using a client/server programming interface.
3.2.2 -- Logic interfaces process queries using the Hermes logical language. This type of user interface is completely flexible, since it can process any query in any mediator, but it requires the user to be familiar with the Hermes logical language. The hermes text-based logic interface and the xhermes graphical logic interface are described in Chapter 9. These two programs are standalone programs (since the interface is linked directly to the search engine), although they can also process distributed queries. Logic-based user interfaces can also be developed using the client/server programming interface.
3.2.3 -- External software can query Hermes using either the standalone interface or the client/server interface. This two-ended approach allows Hermes to be integrated with external software, just as external software is integrated with Hermes. For example, an application may be built around a relational database or multimedia database, and use Hermes for selecting and filtering external data to be stored in the database.
3.3.1 -- The search interface encompasses the various end-user and programming-level interfaces illustrated in figure 2.1. (Application interfaces, logic interfaces, external software and search engine), each of which can use either the Hermes standalone programming interface or the Hermes client/server interface.
3.3.2 -- The search engine compiles mediator files into run-time procedures necessary to process query requests.
3.3.3 -- A mediator file defines data predicates, lists of rules and data sources, used singularly or in combination to form complex queries.
3.3.4 -- The domain interface code forms the link between Hermes and external software (domains) and data.
3.3.5 -- The external software and data can include a wide range of commercial, legacy and other third-party software, with associated data.
3.4 -- Hermes and this manual support various tasks in the development and use of mediators. A basic issue in the design and use of Hermes is where to do what, in terms of the five levels illustrated in figure 2.2. As with software design in general, there can be trade-offs. Some functionality is best accomplished at a certain level, while different aspects of some functionality are best accomplished at different levels of the architecture. For example, as described in sections 10.6.1 and 11.4.2, some type conversions are better handled in the mediator and some are better handled in the domain interface.