Tags:

• complex-logic-framework

Categories:

• architecture
• components

Aura Complex Logic Framework architecture and components

CLF architecture

Aura Complex Logic Framework is a docker container, meaning that it is configured as a lightweight, stand-alone, executable package of software that includes all the required elements to run an application.

The Complex Logic Framework architecture is schematically shown in the following figure, containing different elements described in the succeeding sections.

CLF main components

Sandbox

A sandbox is an isolated testing environment that enables users to run programs or execute files without affecting the application, system or platform on which they run and to test new programming code.

Plugins

Plugins in Aura Complex Logic Framework are components that add a specific feature to an existing computer program, enabling its customization.

The role of plugins within the Complex Logic Framework is to receive data, make the required computations and return an adequate response to the handler.

CLF manages different types of plugins, which are encapsulated in the sandbox. Moreover, it contains several global plugins, but it is possible for developers to add custom ones.

Some key features of CLF plugins are defined below:

• Architecture allows each package of plugins to be deployed in its own environment: it is possible to have an isolated container deployed in an independent way containing all the plugins of a specific package (for instance, global plugins).

• Each package is isolated by being run as a different process by a unique user with randomized name. The rationale behind this is to provide an isolated sandbox to make sure no package of plugins is a security risk. Thereby, each user has limited privileges and computational resources (memory, file descriptors and CPU time) and only runs one process for package.

• The running packages can only receive data from a socket, and the appropriate plugin is then executed depending on both the plugin type and the intent contained in the data. The API handler is in charge of forwarding the data to the package, acting as a proxy, but it also checks the requests and transforms the responses back.

To ease working with this architecture, packages, users and sockets have the same random name. This name also appears in the information and error log files.

• OBs can develop their own custom plugins in the Aura Complex Logic Global repository, with each plugin implemented as a class that inherits from PluginBase and overwrites run method. This method receives the request data and contains the logic of the plugin. It must also generate a response that will be returned to the API handler. When a request is performed, depending on the intent, the request data will be forwarded to the corresponding plugin automatically. Note that two intents can trigger the same plugin but it is not possible to trigger two plugins with the same intent.

• Each package of plugins is watched by a supervisor. If the package process crashes, it will be restarted automatically by supervisor. The causes of abrupt exit could be excessive consumption of resources (CPU time, memory or file descriptors) or plugin internal malfunction.

Stub

A stub, in the context of distributed computing, is a piece of code that is used to convert parameters during a remote procedure call (RPC). An RPC allows a client computer to remotely call procedures on a server computer.

The parameters used in a function call have to be converted because the client and server computers use different address spaces. Stubs perform this conversion so that the remote server computer perceives the RPC as a local function call.

API server

API server is the process that listens for requests. This API server is based on the cognitive API package and, in this case, is configured to run the Complex Logic module.

HTTP requests will be passed to the package API handlers according to the CLF configuration.

It is also important to mention that API server process is watched by supervisor (meaning that it is fault-tolerant).

API handler

In Aura Complex Logic Framework, API handlers are classes that inherit from BaseComplexLogicAPIHandler. They are responsible for dealing with HTTP requests through the following methods:

• Checking the request is valid.
• Checking that the response is in the correct format.
• Making a new request to the corresponding package process, which contains a group of plugins.

The first two items are implemented by the declaration of schemas that define the query request and the response. Plugin API handlers are only responsible for defining which request schema is accepted and which response is valid (also by using a schema).

The request to a specific package is made automatically by the system as long as the specific intent that summons the trigger is recognized. The configuration is described in plugins configuration.

API plugin

API plugin is an internal component based on the cognitive API package. It exposes the plugins contained in a package.

Kernel Platform connectors

Kernel is the database where Telefónica stores all the data of its customers in a safe and reliable way, allowing users to control their data at the same time.

These data can be consulted through a Kernel API with the necessary permissions. From the Complex Logic Framework, the only way to access Kernel is through our connectors. The connectors are used, for example, to obtain customer invoices or offer the catalog of devices and services.

These connectors provide total security in order to avoid problems of wrong, malicious or not careful use by third party developers. For this purpose, prior to any request to Kernel, a check of the required permits is made.

CLF Sequence diagram

The following sequence diagram shows the functional flow of the Complex Logic Framework, starting with the request from aura-bot to the Complex Logic module.