UNL System Architecture

The System architecture consists of a set of servers that communicate through predefined interfaces. Each server is responsible for providing a specific functionality that is needed by one or more components of the system. Required functionalities are exposed using XML Web Services technology, and they follow the agreed upon interfaces. Communication between a component and another can be done either remotely or locally, depending on the endpoint location of the service being consumed. The following servers are currently implemented and running:

  1. UNL Name Service Gateway.
  2. UNL Language Server.
  3. UNL Data Provider Server.

A lit, more engine-like, version of the modern de-conversion engine has been extracted from open source "dev.undelfoundation.org" framework and modified to work with the new architecture.

The following figure describe the overall system.

UNL System Architecture
UNL System Architecture

1. UNL- Name Service Gateway ( UNL-NSG)

Description:

The service is responsible for providing a universal and centralized gateway for discovering language servers. It is universal in the sense that all language servers are to register themselves at the gateway regardless of their language, implementation technology or deployment location. The implementation being modern (as per the new UNL specification) or classic (as per the classic UNL Development Set ) is seamless to the operation of the UNL-NSG.

Operation life cycle

1. Name service gateway starts with an initial list of available languageservers.
    (Core service)
2. Language servers role (Backend-service)

Registration

A process by which a language server registers itself, announcing itself available for consumption under a certain language. Normally this is done at the installation/startup time of the language server. The UNL-NSG persists the language server info under the registration language.

Deregistration

A process by which a language server deregisters itself,announcing itself down and not available for consumption.
Normally it's done upon the shutdown of the language server.The UNL-NSG deletes the language server info under the registration language.

3. Consuming clients role (Frontend-service)

  • Client queries the UNL-NSG for all available language servers
  • Client queries the UNL-NSG for available language servers for a certain language
  • Client picks a language server and consumes it.

(2) UNL Language Server

Description

A UNL Language Server (LS) encapsulates one or more language server endpoint implementations and a lit modern de-conversion engine. Also, it exposes some methods in a web service. Server stubs are generated and linked against at the client side. The generated stubs are implementation independent. That is, the same stubs can be used to consume the exposed service, regardless of the endpoint implementation (currently, either modern or classic engines). Upon startup (shutdown), the LS registers (unregisters) its endpoint interface location at (from) the UNL Name Service Gateway (NSG). As the name suggests, NSG for clients is sort of like DNS for web browsers. A client discovers the available UNL LS's and their locations by
contacting the NSG.

A UNL LS supports the following functionalities:
  1. Deconverting a UNL input back into natural language (NL).
  2. Enconverting an NL input into UNL.

As an advantage, a web server can deploy and start as many LS's as desired and serves, not necessarily different, languages. Add to that, and for backward compatibility with classic endpoints, a LS includes the classic UNL Development Set (UDS) which serves locally within the classic endpoint context.

(3) UNL Data Provider Server

Engines at the UNL LS fetch its data from the Data Provider Server. Either a DB or plain files, the Data Provider Server is responsible for providing the engines with the required data, dictionary and rules, whenever requested. The Data Provider supports the following functionalities:

  1. Loading dictionary data.
  2. Loading universal words.
  3. Loading rule sets.

Each UNL LS supports a certain language, and the Data Provider provides the LS with dictionaries and rules that are specific to that language accordingly. For the Data Provider to function, dictionaries and rules are validated and flagged as either valid or invalid by a linguist. A Data Provider works only on entries marked as valid UNL System Architecture