The CIM tool

The CIM was meant to be a general tool that could be implemented with any specific collection of technologies; its architecture is seen in Fig. 2. Its primary functions are mentioned below.
CIM Configuration: The CIM has two primary components for configuring its features: the GUI API and the Management API. Both components publish two APIs on a DR system’s local network; however, the GUI API is merely a graphical interface for users to engage with the Management API. As a result, the second API is the one that provides the primary configuration features. Several items may be created, read, updated, or deleted (CRUD) using this API, including:
Bridging Rules: These are user-supplied rules that translate XMPP queries to local APIs and vice versa. Furthermore, when the payloads transferred via the specified APIs need to be translated, these rules define the name of an interoperability module.
-A sample Bridging Rule is {”XMPP API”:”/dr/reports”, ”local_ API”:”http://localhost:900/reports/power”, ”method”: ”GET”, ”module”:”oadrReport.module”}, entailing that any request received through the XMPP network to /dr/reports will be sent to the local API localhost:900/reports/power, and the payload provided by such endpoint will be translated with the oadrReport.module.
Interoperability modules: These modules include translation mappings that may be used with any RDF serialisation approach [46,47]. The mappings include rules for converting data from various forms to RDF and vice versa. Any interoperability module must convert non-RDF data into RDF serialisation JSON-LD specified using an ontology.
SHACL shapes : is a collection of RDF documents containing SHACL shapes that are used to perform semantic and syntactic validation on the exchanged payloads. These shapes guarantee that all data, whether translated or not, is represented in accordance with the ontology used for data interchange with CIMs.
-Local users: When given, the CIM permits to attach JWT tokens [48] that must be utilized by the local APIs to deliver data over the CIM.
XMPP ACL: The XMPP access control list (ACL) is a list of CIMs to which the current CIM is authorized to transmit data, as well as a list of CIMs to which the local CIM is allowed to send data.
-XMPP credentials: These are the XMPP username and password used to access the XMPP network.
-XMPP certificates: The CIM is protected by two certificates: an X.509 encryption certificate and a mutual authentication certificate. The former encrypts all data transferred, whereas the latter establishes double- authenticated channels with other CIMs before exchanging data. The XMPP network administrator must offer these certificates.
-XMPP connection: The CIM relies on the XMPPClient component to connect with an XMPP server and join an XMPP network. This component has two aims. On the one hand, it connects and authenticates in an XMPP network using XMPP credentials and an X.509 mutual authentication certificate within the XMPP certificates. This component, on the other hand, enables the Router to send and receive requests with other CIMs connected to the XMPP cloud network, which encrypts all data transmitted using an X.509 encryption certificate within the XMPP certificates.
-Semantic interoperability: The PayloadTranslator, which is in charge of homogenizing the payloads to be transferred when necessary, implements the CIM’s semantic interoperability. This component is called by the Router, which gives the payload as well as the name of the Interoperability Module that must be used to translate it. The PayloadTranslator then fetches such an Interoperability Module and translates it. Finally, regardless of whether translation happened, the PayloadTranslator invokes the PayloadValidator and provides the payload (the translated or the original if no translation was required) to the Router, along with the validation report produced by the PayloadValidator.
-Semantic validation: The PayloadValidator is the CIM component in charge of this validation. It is important to note that semantically verifying a payload also requires syntactic checking. The PayloadTranslator, which offers a JSON-LD payload, calls this component. The PayloadValidator then validates the payload using SHACL shapes and delivers a validation report to the PayloadTranslator.
-Privacy and security: The SecurityMonitor handles privacy and security in CIMs; however, keep in mind that the XMPPClient also implements privacy and security features. The Router activates this component and supplies the distant CIM XMPP username whenever a request must be delivered across the XMPP network or is received by such network. The SecurityMonitor then examines the CIM XMPP username in the XMPP ACL to see if the local CIM is authorized to send data to the remote CIM or if the local CIM is allowed to receive data from the remote CIM. As a result, this component returns to the Router a status code indicating whether or not the request may be executed.
When a local API, on the other hand, makes a request, the Router activates the SecurityMonitor. In certain circumstances, this component determines if the request contains a JWT token and whether the token is genuine, implying that it has not expired and is associated with a local user. Similarly, the SecurityMonitor sends a status code to the Router indicating whether the request may be handled or is not authorized.
Finally, XMPP networks have additional security layers for data exchange, such as Transport Layer Security (TLS) for transport security,15 Simple Authentication and Security Layer (SASL) for authentication16 and End-to-End signing and object encryption for the extensible messaging and presence protocol. 17 XMPP networks, in example, enable you to organize various CIMs into clusters and then establish access control list restrictions on the clusters.
-CIM data exchange: The data interchange occurs in the CIM, which includes various components that execute complicated activities as previously mentioned. The Router component handles data interchange in the CIM; it must be distinguished whether a local API from the DR system delivers a request to the XMPP network or when a request is received from the XMPP network.
When the APIs of a DR system on the local network want to transmit a request over the XMPP network, they submit it to the Routing API. The request must include the distant CIM XMPP username from whom the response is expected, as well as a valid JWT token previously issued by the CIM.
The Routing API then routes this request to the Router component. The Router calls the PayloadTranslator, which returns a translation of the payload being transferred and a validation report, if necessary. If the
payload is invalid, the Router responds with an invalid status code using the Routing API. If the payload is valid, the Router validates whether the request is legitimate by invoking the SecurityMontior, and it provides an unauthorised response code to the API through the Routing API. If the request is legitimate, it is packaged as an XMPP request and sent to the XMPPClient. Finally, the XMPPClient routes the XMPP request across the XMPP network to the destination CIM, which processes the request and responds.
When a request arrives over the XMPP network, the XMPPClient accepts it and transmits it to the Router component, which unpacks the XMPP request into a local request. The Router then uses the SecurityMonitor to confirm that the request is legitimate, and if it is not, it returns an unauthorised response code to the remote CIM through the XMPPClient. Otherwise, the Router executes the PayloadTranslator, and if the given payload is invalid, the Router returns an invalid response code to the remote CIM. Finally, assuming the request was legitimate and authorized, the Router routes the local request through the Routing API to an existing API.
Decentralisation and integration of DR systems
One of the CIM’s primary aims is to enable DR systems that are centralized in a local infrastructure to distribute their components in an XMPP network and communicate data with other DR systems. There are various advantages of using the CIM to decentralized DR systems: (A) Distributing DR components across infrastructures utilizes the processing power required by these components; (B) Security in XMPP data sharing using an encryption mechanism and JWT tokens in local data exchange; (C) Decentralisation improves privacy because data access is controlled locally by the different CIMs based on their ACL, making it easier to address issues such as GDPR; (D) The DR system architecture becomes modular, making it easier to extend and scale these components; and (E) Integrating components from different DR systems requires only the development of Interoperability Modules as additional effort. It should be noted that the CIM-enabled advantages address the issues raised in Section 3.