Nexus Architecture
Conceptually, Nexus consists of a core server engine that combines a modern SQL database with a bulk data storage mechanism. The database stores both metadata for the data items and the report templates. The Nexus system is accessed via a REST API that has been wrapped in Python for convenience and simplicity. This API allows for items in the database to be added, removed, and edited. This interface has been integrated into EnSight as an extension to simplify the capture of new data elements directly from within EnSight. The Python API can be used directly from the interpreter embedded in EnSight or from a standalone Python instance. The Python interface provides access to Nexus from custom, non-Ansys applications. A desktop GUI tool, the Nexus template editor, provides interactive editing of report templates and supports complex server operations, including generating new databases, local server control (start, stop, etc.), and copying data items and templates between servers.
Key to the Nexus system is the Nexus server. The server provides the web interface to the database and report generation infrastructure. It processes the REST API for external applications, providing an Nginx-based load-balanced service that can be integrated behind a departmental or externally facing server using simple HTTP proxy interfaces.
The server can be configured to run locally on a user's desktop in a configuration with the following structure:
It can also be configured to run on a remote server (such as a departmental resource) or deployed in a cloud setting:
Users can push data into the database from within EnSight:
Or from other applications:
The resulting database supports query operations and report generation:
The Nexus infrastructure provides a simple framework that enables remote "sessions". More accurately, Nexus provides a means to authenticate and authorize access to a pre-configured resource pool. Access is provided via a web-server based VNC client embedded in the Nexus web framework.
Before the remote Nexus service is launched, the site administrator needs to design a collection of "sessions" and the mechanisms to start and stop a session. In the simplest form, this can be a pair of shell scripts that "start" and "stop" a VNC server desktop session based on parameters dynamically captured by Nexus (e.g. the username, session screen dimensions and index into a collection of sessions). This is detailed in this section.
The Nexus framework reads this configuration and presents the authenticated and authorized user a selection of available sessions they can use. If a session is selected from the list, a webpage with an embedded VNC viewer which routes communication over a web-socket connection is opened and the session started. When the page is closed, the session is closed. Additionally, built-in sessions allow for local invocations of EnSight or EnVision to be displayed embedded in a report.
Architecturally, this service adds an additional component, websocketserver to Nexus.
A websocket connection is established through NGINX and websocketserver and a Session process launched to provide SSL encryption and WS protocol encapsulation of the VNC server stream produced by the EnVision instance. The HTML/JavaScript VNC client served to the web browser via NGINX is the consumer of the VNC stream tunneled via the websocket protocol through NGINX. That client then displays the remote desktop/applications in a frame in the web browser.
For the simple case of EnVision and EnSight viewing of .evsn and .ens file items, the websocketserver has session support built-in. The launcher GUI or command line can be used to enable and specify the number of concurrent sessions of each built-in type that are allowed.
In general, the Nexus system relies on common security solutions for remote web services.
While Nexus supports user logins within the Nexus framework itself, the more common approach is to have the site configure the NGINX server to proxy the authentication. This allows the site to include its own authentication system in the web server without modification to the Nexus system. If Nexus sees an authenticated user coming in from NGINX, it will honor that authentication, provided a username match can be made to a user in the Nexus administration system.
Authorization in Nexus is controlled by the user administration system in Nexus and is generally handled by the group system. The current implementation allows any authenticated user to be able to use both the GUI and REST APIs to manipulate the data in the database. The administration system can select what users are allowed to do (e.g. read/write/etc). Access to the Session system is controlled by the group permissions. A user must be a member of the "RemoteSession" group to be able access web pages and other resources related to the remote session system.
Nexus makes no explicit attempt to encrypt data itself. Thus, encryption is left to the web server and web socket systems in addition to any storage system encryption. It is strongly recommended that web access is limited to SSL connections and all outward facing aspects of Nexus support this. On the backend, the media store and the database store are asked to provide their own solutions for stored data encryption.