Nexus Architecture

Introduction ››
Parent Previous Next

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.

Basic Nexus Server Architecture

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 either as a standalone HTTP server or as a WSGI server gateway that can be integrated into an external HTTP server (e.g., NGINX or Apache).

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 an AWS cloud:

Data Operations

Users can push data into the database from within EnSight:

Or from other applications:

The resulting database supports query operations and report generation:

Remote Sessions

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.  

Architecturally, this service adds a few additional components to Nexus.  Most notable is the inclusion of a web-socket server, WebSockify) and a Session State file that tracks the current session state.

When a session is active, additional processes are launched to set up the remote hardware accelerated desktop.  The diagram then looks like this:

A websocket connection has been established through NGINX and WebSockify and a Session process launched to provide SSL encryption and WS protocol encapsulation of the VNC server stream produced by the instance of x11vnc (likely running on a separate system, e.g. a graphics enabled cluster node).  The HTML/JavaScript VNC client served to the web browser via a Nexus instance running under Gunicorn 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.

On Nexus Security Concerns

In general, the Nexus system relies where it can on common security solutions for remote web services. In most cases, personnel at a specific site will want to host Nexus on their own systems.  The design of Nexus as a WSGI system makes it possible for Nexus to leverage an existing NGINX web server and PostgreSQL server.


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.