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:
- UNL Name Service Gateway.
- UNL Language Server.
- 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
1. UNL- Name Service Gateway ( UNL-NSG)
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.
2. Language servers role (Backend-service)
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.
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
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:
- Deconverting a UNL input back into natural language (NL).
- 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:
- Loading dictionary data.
- Loading universal words.
- 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