Explore chapters and articles related to this topic
Parallel Architectures
Published in Pranabananda Chakraborty, Computer Organisation and Architecture, 2020
A typical usage of a three–tier architecture is observed in transaction processing in which a separate process, called the transaction monitor located on middle–tier server coordinates all transactions across possibly different data servers. Here, the thin client (workstation) is, however, equipped with a local disk of its own that contains part of the data, and runs most of the applications. But all operations on files or database entries go to the respective servers. Conclusively, it can, however, be inferred that the interaction between the client and the middle–tier server as well as that between the middle–tier server and the backend server also follow the client–server model in which the middle–tier server acts both as a server to the client, and also as a client to the backend server. Thus, the middle–tier system acts at times as a client or as a server. Many examples of a distributed computing system based on the workstation–server model can be cited; an earlier one perhaps is the V–System [Cheriton, 1988].
Lan Softwarepotpourri
Published in Paul J. Fortier, Handbook of Local Area Network Software, 1991
Migent has developed a backend database server called Emerald Bay. This server is built as two elements, a server element and a user element. The user or client element provides the user workstation with a local database, controlled by the local client process, and access to the backend data base server. This type of environment will provide faster access to user locally stored data and provide management of the data for the user. The server component runs on the backend database machine and provides procedural database management access and management to the server data base. Migent at present does not support any particular interface, but provides basic services for transaction processing, including logging and recovery. To get details of this product you must direct inquiries to the vendor, since not much has yet been published regarding this product.
Enterprise Architecture
Published in Vivek Kale, Enterprise Process Management Systems, 2018
Multitier architecture is commonly used for distributed systems. It usually consists of three element types, as follows: The client element is responsible for graphical user interface presentation, accepting user requests, and rendering results.The middleware element gets the requests from the client element, processes the requests based on the business logic, and sends a data request to the backend tier.The data store server element manages data querying and updating.
Towards a Systematic Requirement-Based Approach to Build a Neutronics Study Platform
Published in Nuclear Science and Engineering, 2023
Alberto Previti, Alberto Brighenti, Damien Raynaud, Barbara Vezzoni
While the considerations of this analysis drawn so far may be considered as of general application, the allocation to the frontend and backend is strictly related to the specific competencies of the teams working in the construction of a given lattice calculation platform. Indeed, according to the desired software architecture, it may happen that some functionalities could appear in either the frontend, backend, or both. Although a universal rule does not exist, the systems engineering workflow provides a standardized way to solve the distribution of responsibilities jointly. Regardless of the actual decomposition and of the actual subsequent software implementation, the formal identification of use cases provides a systematic way to write acceptance tests that guarantee the fulfillment of user needs.
Potential applications of connected vehicles in pavement condition evaluation: a brief review
Published in Road Materials and Pavement Design, 2023
Maryam Samie, Amir Golroo, Donya Tavakoli, Mohammadsadegh Fahmani
Jang et al. (2017) introduced a framework that utilised connected vehicles to detect and categorise pavement distress. The framework proposed a method where vibration-based sensors were used to collect vibration data, eliminating the need for large space. The system architecture consisted of two main parts: the vehicle client and the backend server. The vehicle client, which served as a data send-and-receive kit, comprised a triaxial accelerometer, a microcomputer, and a GPS sensor. The GPS sensor collected data at a rate of ten Hz with a localisation error of less than three metres. While the microcomputer had limited storage space, it was essential to have enough capacity until the vehicle reached an internet source to transmit the data. To address this, a data collection algorithm was developed to block unnecessary data, involving two steps: Preprocessing: As vehicles turned or traversed intersections, the accelerometer data experienced shifts. This step modified the data to ensure no shifts were applied to them.Filtering: Pavement defects resulted in higher vibrations compared to the smooth surface. In this step, a filtering index called ‘Vibration level’ was utilised to exclude smooth surface data and optimise storage in the limited space. A threshold was used to determine which data to store.
Human-centered performance management in manual assembly – The impact of gamified KPI provision on performance and motivation
Published in International Journal of Computer Integrated Manufacturing, 2023
Jasmin Ohlig, Thomas Hellebrandt, Patrick Pötters, Ina Heine, Robert H. Schmitt, Bert Leyendecker
Within the setup of the business game, each workstation is equipped with a tablet that displays a prototypical MES application which indicates different information depending on the treatment group. For data collection and visualization of KPIs on a team level, the tablets of the three workstations must be connected. Therefore, the MES module is set up as a client-server architecture, with a server-side backend covering data collection and preparation, and visualization of KPIs. The backend has open API/REST interfaces that can be used to connect to existing MES or other software systems. The client represents the visualization module and is implemented as a web application optimized for a tablet view. The client-server communication is realized via a hypertext transfer protocol (http) request. The back-end server for the data storage is realized via GlassFish, which is an open-source application server for Java EE. The technical realization of the business game enables automatic data collection of the unix timestamp data of order registration, rework count, error count, and the number of finished products, which are needed for KPI aggregation. Visualizations of the KPIs are based on standard representations. For example, the average lead time and output are displayed in form of a bar chart. Furthermore, the visualization includes a list of the top three errors within their business game.