From a product perspective there are three major distinguishable parts in the architecture:
The Laboperator Connector
The Laboperator Server
- The Laboperator Application
The Connector is a hardware and/or software node that acts as a bridge between devices and the system. The Server is usually hidden from the user and is the backend for processing and persisting any activity in the system. As part of the server a technical user interested in third party integrations might consider the API used as non-visual communication interface to the system. The Laboperator Application is a browser-based application providing a visual user interface to user directed system functionality.
On this level of abstraction information flows in both directions between a connector and a server, an application instance and a server, and a third-party software and the server.
In this section a functional perspective on the three previously mentioned high level parts (the Laboperator Connector, the Laboperator Server, and the Laboperator Application) is described. This intermediate step should give the reader a rough overview of available functionalities. Some of the aspects are directly mirrored by system components in the next section. Coming from a product or user perspective this overview bridges the gap to understand the system components architecture.
A key takeaway from the Figure 2 should be the understanding that the Application itself is merely a web client. It does hold little business logic beyond that related to visualization and user input. A lot of effort, time and customer feedback has been put into the Application as at Labforward are convinced that the user experience will decide over user acceptance in the laboratory by the end of the day. From an architectural perspective however most of the logic happens on the server.
Platform Components Overview
As can be seen in the figure above. most system components are part of what is generally referred to as the server. Each component with a solid stroke is started and managed as dedicated process and can with limitations be scaled out horizontally to account for higher loads. Dashed strokes indicate merely a logical separation with common behavior. Blue and orange lines indicate network-based communication, where blue is Server internal and orange external communication.
Scaling individual components across multiple physical or virtual nodes might imply additional communication between instances of the components. A common example would be the database or messaging services running in a cluster. Details regarding the means of communication are discussed in4 Information Flow.
Any application logic is contained in the Core Application, or the Background Services, with routing being the only exception. Though routing of messages is defined by services upon start it is then executed by the Messaging Service.
While the Messaging Service handles load balancing between the Core Application, the Websocket Service and the Background Services, the Load Balancing Service handles any Request coming from the outside, usually one of three depicted: the Application or Web Client, the Connector or any third-party client communicating with the API.
Currently there are some parts of the API exclusively accessible to the Laboperator Application, thus not open to any other applications. In the future this distinction likely will be eliminated. Also, not available to third-party applications is a direct access to the Websocket connection and subscriptions to real-time data by these means. Websocket connections are currently also limited to use by the Laboperator Application and the Laboperator Connector.
Depending on the deployment strategy there is a process monitoring in place to keep the services running and keep track of available resources.
This Figure depicts a high-level perspective on the network architecture. Usually, the Laboperator platform is bridging the gap between a lab network, where devices are located which are connected to the Connector Boxes, and an office network, from where end users want to access data from these devices. As each of these segments are separated by a firewall, the common hub is the Laboperator platform, which can be distributed across multiple instances, having a load balancer/gateway as a single unified endpoint. The processes and data are distributed by the application and worker processes to several backend services, e.g. a database for permanent storage.