Architecture
Description
The system is made up of a set of components which can be plugged together in variety of way to produce different configurations. The components fall into the following categories:
Data servers are repositories of information in various languages; they will in general be provided by third parties who already have the data in some appropriate form.
Brokers use information in metadata repositories (q.v.) to locate appropriate data servers for the queries submitted by users; they then use information in multilingual thesauri to translate those queries into the appropriate languages for the data servers; they broadcast the translated searches to the appropriate data servers, collate the results, and feed them back to the user.
Metadata repositories contain information about a set of data servers, including their language and the domain of the information they contain; they are used only by brokers.
Multilingual thesauri are used for translating search terms between the supported languages and broadening and narrowing searches; they too are used only by brokers.
Front ends act as brokers' faces to human users, presenting a comprehensible view of the system's complexity. Users may elect to use one of a number of plug-compatible front ends, e.g. one for the web, one for WAP phones.
Front ends are themselves typically made up of two components - one close to the user (e.g. a web browser or WAP phone) and one close to a broker (e.g. a web server or WAP gateway).
The latter part of each front end communicates with a broker using the Z39.50 protocol configured with an appropriate application-level profile. The broker in turn communicates with further brokers and/or data serves using Z39.50 with the same profile, and consults both its metadata repository and its multilingual thesaurus using Z39.50 configured with appropriate low-level profiles.
Examples of possible configurations:
The simplest configuration of all would feature a single front end plugged directly into a single data server, communicating via Z39.50 using the application-level profile.
A more typical configuration would feature a front end communicating with a broker; the broker would then translate and forward queries to a number of data servers with reference to a metadata repository and a multilingual thesaurus.
A more complex configuration might consist of two front ends - one on the web, one for WAP phones - both communicating with a broker (which functions with reference to a metadata repository and a multilingual thesaurus), and that broker translating and forwarding queries both to a set of data servers, and to a second broker, which in turn translates and forwards queries to a further set of data servers.
The second broker may or may not share the metadata repository and/or multilingual thesaurus with the first; the architecture supports either design.
To clarify, here is a diagram of the third example:
The Multi-Lingual Search System Architecture.
Network connections across local area networks are represented by straight lines, and those over the internet by jagged lines.
From the perspective of front ends, the broker masquerades as a data server, and from the persective of data servers, it masquerades as a front end. Similarly, a given broker always functions as though connected to a front end at the top, and data servers at the bottom - other brokers above or below it in the system are effectively masquerading as front ends and data servers respectively.
There is no theorietical limit to the depth to which brokers may be ``stacked'' in this way.
Component Interchangeability
Because a standard protocol is used to connect the various components of the system, various benefits accrue, besides that of the system's amenability to multiple configurations:
Substantial portions of the implementations (that is, the low-level code that deals with the protocol) may be shared between components.
Apart from this shared portion, each component can be developed separately, by separate partners where appropriate. This can be done with high confidence that they will interoperate correctly because the interfaces are formally defined.
Components may further be replaced piecemeal provided they conform to the specifications: in particular, multiple alternative front ends may be developed, and freely used against any given broker/thesaurus/metadata/server back-end combination.