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.