HIT4B3 Platform - Architecture

Get to know the revolutionary architecture of the HIT4B3 platform

Modern multi-process model

In traditional (previous) server system architecture, the application server consisted of a single process and multiple threads. A single process could be an executable file or an ISAPI, Apache worker process, or possibly a Windows service. In all these cases, all sessions were located in one process, and several threads of the same process were used to handle incoming requests.

HyperServer architecture changes the above model and introduces it into a multi-process, multi-threaded model. In this new model, several worker processes are launched, supporting the same web application. Sessions are divided between worker processes and, depending on the configuration, multiple worker processes can be created/exist for the same weblication. Worker processes are managed and coordinated by another process, which is actually HyperServer itself.

Entry point

HyperServer will be the main entry point for all incoming requests. It accepts all requests and distributes them among the worker processes.

Node management

HyperServer is responsible for creating new worker processes (nodes) when needed and reprocessing them.

Session routing

Since HIT4B3 sessions are stateful, HyperServer routes incoming requests to the correct worker process that created that particular session.

Improving stability and performance

The applied HyperServer architecture aims to drastically improve stability. HyperServer achieves this goal by implementing various mechanisms: internal load balancing and node recycling. Load balancing distributes the total server load among nodes.

Node recycling shortens the life cycle of nodes by recycling them based on predefined rules. Recycling ensures that nodes will only reside in the process memory space for a specified time. In contrast to the classic model, which keeps the application server process in memory indefinitely.

The main task of HyperServer is to ensure that the entire application server does not crash as a result of a memory defect or other problem in a node (Node).


System structure

The HyperServer architecture is divided into two main parts:

  • HyperServer executable file - entry point for the web application, handling client requests.
  • Node cluster - component weblications of HIT4B3 (e.g. EKAIZEN).

Remote deployment and business continuity

Another function of HyperServer is the ability to remotely deploy new versions of weblications without having to stop the server. This ensures business continuity in the 24/7/365 model.

You can remotely upload a new version of the weblication, and HyperServer will gradually and automatically update the nodes. New sessions will go to the new version, and old nodes will be removed as soon as all their sessions are logged out.

Adding the data access layer, implemented using an SQL standard database server (in our implementation it is Firebird Database Server), we get a full picture of the architecture of the entire HIT4B3 system.

Back