NIMBLE mapped on ICT performance characteristics

Comment: IIRA is the main reference. IIRA is closest in terms of conceptual design for NIMBLE. RAMI is not so applicable to us because we are closer to Internet B2C or B2B platforms. Industrial Data Space is on our radar, but was not sufficiently elaborated at the time of writing the proposal. See https://cloud.effra.eu/index.php/s/NiyTZgM3kw6VCxw The NIMBLE platform is designed to ingest data stemming from edge devices into the platform. Once data has reached the platform, data are stored for future uses such as offline analytics and auditing. In addition, processing of the data as it flows into the platform can be performed in real-time. Offline analytics complements the real-time view by enabling companies to gain insights from their data leading to more efficient processes. We follow the microservice approach for the NIMBLE architecture. Each microservice offers a specific and narrowly defined functionality that is deployed as an independent service [2]. It puts emphasis on real-time application monitoring, including architectural elements and business relevant metrics, e.g. number of orders per minute [2]. In addition, this approach provides decentralized data management and decentralized data storage decisions based on a polyglot persistence method. Microservices can still be combined with monolithic enterprise applications (monolith’s APIs) built as single units, fostering the federation and collaboration of various independent services in the Cloud. Figure 1 depicts the top-level architecture, which is inspired by the microservice infrastructure presented in [3]. Figure 2 then shows the core business services of the platform in more detail. The Gateway Proxy is the public entry point to the microservice application. All user requests are received via the Gateway Proxy and routed to the appropriate service. The Service Logging aggregates log outputs of each individual microservice and makes them available via a Web interface. The Service Monitoring collects data, which are necessary to monitor failures of services; this is implemented using the Circuit Breaker pattern [4]. The Service Monitoring can be used to monitor remote calls, or in any situation where parts of a system need to be protected from failures in other parts. After the number of erroneous executions exceeds a defined threshold, all future calls are immediately returned with an error without the actual function being executed. The Service Discovery enables registration of microservices, as well as mapping between service identifier and the endpoints of instances (e.g. URL or IP address). The role of the Service Configuration is to provide configuration settings for each service. The service communication is enabled either via REST (i.e. HTTP) or by using the Messaging Service (based on Apache Kafka), which provides asynchronous and scalable communication. Finally, the User Account and Authentication (UAA) & Identity Management administrates user identities on the platform. It combines the three standard protocols: OAuth2 for delegated authorization [5], OpenID Connect for session and authentication information [6], and the System for Cross-domain Identity Management (SCIM) for user and group management [7].