Software-Defined PolyGlot Power System Architecture Template for Non-Terrestrial Data Centers ^†

Abstract

Non-terrestrial data centers (NTDCs) should be capable of functioning in harsh environments and are located in space, the stratosphere, and underwater. They require power to execute data processing and algorithm execution. NTDCs need power systems that are cyber-physical systems. These systems use data and programmed systems (using different programming languages), i.e., software enabling power system functionality, to realize the desired integration and functionality. Different programming languages have varying performance capabilities and integration support to enable the interworking of multiple entities in the software aspects of open NTDC power systems. Such open NTDC power systems support different operational objectives. It is important to achieve a high number of successful component integrations for system functioning. The proposed system considers the choice of the programming language, enabling multi-interface communications as a selectable and configuration parameter in a polyglot multi-language NTDC power system computing paradigm. Evaluation shows that the proposed approach increases the number of successful integrations between power system software-defined entities by 20.2%, with a maximum of 60%.

1. Introduction

Data centers play an important role in hosting content accessed by network subscribers via the internet. The use of terrestrial data centers has received significant consideration for realizing computing platforms. The use of terrestrial data centers faces challenges necessitating the consideration of the use of non-terrestrial data centers. Examples of such challenges are high water footprint [1,2,3], high land footprint [4,5,6], and low power efficiency [7,8,9]. The low power efficiency has resulted in a case where there is high power usage effectiveness figure. The use of terrestrial data centers also has high real estate costs.

These challenges have begun to receive public attention leading to criticizing the future role and importance of terrestrial data centers. An approach addressing this challenge is using non-terrestrial data centers (NTDCs) sited in locations such as the underwater environment [10,11], stratosphere (near space) [12,13], and space [14,15].

NTDCs require power resources and supporting systems for continuous and uninterrupted server operation. The NTDC power systems should be scalable and adaptive. Scalability ensures operation when more computing nodes are included in NTDCs. It is important that the architecture of the power system is suitable for use with NTDCs. The realized power system architecture should be suitable for NTDCs. The research recognizes the increasing role of NTDCs due to their low operational (cooling) costs. NTDCs can be hosted in different locations leading to the realization of space-based data centers (SBDCs), stratosphere-based data centers (STDCs), and underwater data centers (UDCs). The research is organized as follows:

• The research recognizes the role of computing and software solutions in NTDC power systems. It presents a software-defined and machine learning (ML)-driven power system architecture for SBDCs, STBCs, and UDCs. It identifies system entities to predict operational parameters. The design considers the realization of an architecture template. The proposed architecture template provides a generic framework for designing power systems for the SBDCs, STBCs, and UDCs.
• Second, the research proposes a polyglot programmed computing system to ensure robustness in an integrated NTDC software-defined power system. The motivation for the polyglot system is ensuring the realization of interoperability as the power system architecture is deployed in environments hosting SBDCs, STBCs, and UDCs.
• The research recognizes the number of integration successes as the key performance metric of the power system architecture template. It is formulated and evaluated for the proposed software-defined power system. The evaluation examines how the proposed architecture enhances the number of integration successes compared to the existing architecture. The existing architecture does not support multi-location NTDCs.

The rest of the research is organized as follows. Section 2 describes the problem being addressed. Section 3 focuses on the proposed solution. Section 4 formulates the performance metric. Section 5 discusses the performance evaluation. Section 6 is the conclusion.

2. Problem Description

The scenario is that of a data center operator utilizing NTDCs for their operational cost benefits. The operator seeks a power system architecture that can be ported to any NTDC. It is expected that the designed power system architecture enables a long uptime duration. The designed architecture uses artificial intelligence enabling mechanisms to determine the power levels. The set of NTDCs, $\alpha$, is

$$\alpha =\left\{{\alpha }_{SBDC},{\alpha }_{STDC},{\alpha }_{UDC}\right\}$$

(1)

${\alpha }_{SBDC},$ ${\alpha }_{STDC},$ and ${\alpha }_{UDC}$ are the set of SBDCs, STDCs, and UDCs, respectively.

$${\alpha }_{SBDC}=\left\{{\alpha }_{SBDC}^1,{\alpha }_{SBDC}^2,\dots ,{\alpha }_{SBDC}^I\right\}$$

(2)

$${\alpha }_{STDC}=\left\{{\alpha }_{STDC}^1,{\alpha }_{STDC}^2,\dots ,{\alpha }_{STDC}^J\right\}$$

(3)

$${\alpha }_{UDC}=\left\{{\alpha }_{UDC}^1,{\alpha }_{UDC}^2,\dots ,{\alpha }_{UDC}^K\right\}$$

(4)

The subsystems for the $i^{th}$ SBDC, ${\alpha }_{SBDC}^i,{\alpha }_{SBDC}^iϵ{\alpha }_{SBDC};j^{th}$ STDC, ${\alpha }_{STDC}^j,{\alpha }_{STDC}^jϵ{\alpha }_{STDC},$ and $k^{th}$ UDC, ${\alpha }_{UDC}^k,{\alpha }_{UDC}^kϵ{\alpha }_{UDC}$ are designated as follows:

$${\alpha }_{SBDC}^i=\left\{{\alpha }_{SBDC}^{i,1},{\alpha }_{SBDC}^{i,2},\dots ,{\alpha }_{SBDC}^{i,M}\right\}$$

(5)

$${\alpha }_{STDC}^j=\left\{{\alpha }_{STDC}^{j,1},{\alpha }_{STDC}^{j,2},\dots ,{\alpha }_{STDC}^{j,N}\right\}$$

(6)

$${\alpha }_{UDC}^k=\left\{{\alpha }_{UDC}^{k,1},{\alpha }_{UDC}^{k,2},\dots ,{\alpha }_{UDC}^{k,P}\right\}$$

(7)

The power system architecture for NTDCs determines the power to be allocated to the subsystems in (5), (6), and (7). The determination of the required subsystem power levels is an important challenge for the power system architecture designer. In this case, that is the determination of the power level for the NTDC’s multi-contextual case via data-driven artificial intelligence and ML. Operational data heterogeneity is associated with the SBDC, STDC and UDC. This leads to a scenario where different ML algorithms are suited for each class of NTDCs. The use of diverse ML algorithms arises from using different implementations of ML algorithms in existing research [16,17,18]. The ML algorithms should morph when the power system architecture is deployed to different NTDCs.

3. Proposed Solution—System Architecture

This section presents the proposed system architecture with a focus on the power system architecture template. The architecture template does not consider power sources. Instead, it focuses on how power accessible from the concerned power sources is utilized by data centers in non-terrestrial locations. This is because of the recognition of the power sources that can be used to provide operational power to the concerned non-terrestrial data centers. SBDCs and STBCs are powered by onboard solar energy. UDCs can derive operational power from the grid and offshore wind [19,20]. Hence, research recognizes the suitable energy sources for data centers in non-terrestrial locations. However, the manner of energy allocation to different subsystems and their components requires further attention. The aspects of the system architecture template are: (i) Subsystem Identification Entity (SIE), (ii) Subsystem Depth Determination Entity (SDDE), (iii) Subsystem Database Probe Entity (SDPE), and (iv) Subsystem Machine Learning Entity (SMLE).

The SIE identifies entities in the NTDC via the transmission of signals to all connected entities. Each entity responds with a serial number and functional descriptor-related information. Descriptor information is used to determine the function of each component and the NTDC subsystem with which it is associated. The SDDE determines the number of entities and the associated redundancy level. This is important as NTDCs incorporate varying levels of redundancy with each redundant entity having own different power levels but with the same or similar descriptor-related information. The SDPE hosts different serial numbers in its database associated with each non-terrestrial location.

The SMLE hosts different machine learning (ML) algorithms and solutions developed for each NTDC (considered locations). These ML solutions determine the operational power for each entity identified in the SIE. The ML solutions are developed from the operational data acquired in the NTDC exploration phase. The ML training and testing is done in the training phase. Developed ML solutions are used in the SDPE (application phase). The entities are associated with the NTDC, i.e., the SBDC, STDC, and UDC. The ordered relations between these entities are shown in Figure 1. In Figure 1, SIE to SDDE relations, SDDE to SDPE relations, and SDPE to SMLE relations are identified as number 1, number 2 and number 3, respectively.

The SMLE determines and selects the suitable ML that has been developed for power level prediction in the NTDC, i.e., SBDC, STDC or UDC. The realization of the goal of enabling power provisioning for each entity is via external connections from the SMLE to the NTDC power subsystem. The NTDC power subsystem comprises modular components that connect to each subsystem and associated NTDC entity. An important entity in this link is the subsystem-component power supply entity (SCPE). In executing its function, the SCPE is aware of all interfaces between subsystems (components) and the NTDC power subsystem. The relations between the SMLE with predicted power output and the SCPE are shown in Figure 2. The SMLE is updated to ensure that the appropriate power level is determined and supplied to the subsystem and entity associated with the SCPE. This is done via an update of the ML training matrices.

The update is executed via the SMLE connection to an ML repository via an external network. The external network enables access to a data center-based repository. The anchor repository is hosted aboard a terrestrial data center due to its significant coverage. However, the repository can be hosted aboard NTDCs as their use gains a wider adoption.

The proposed architecture can be integrated into SBDCs having varying levels of power consumption, i.e., small scale, moderate scale and hyper-scale. The proposed architecture is integrated during the SBDC design and testing phase. This phase precedes the execution of orbital launch. A similar pathway is applicable to the STBC. The small-scale STBC has reduced energy consumption with units to tens of kW. Furthermore, the hyper-scale STBC has reduced energy consumption (hundreds of MW to tens of MW). The motivation for this reduction is the technical challenge associated with realizing large-sized aerial vehicles in the absence of an external STBC launch system. The integration into UDCs considers their integration into varying UDC system scales. In this case, small-scale UDCs realize their entire operational energy from offshore wind energy resources. They have a similar energy consumption profile with small-scale STBCs. Large-scale UDCs use offshore wind, onshore solar and the conventional grid for operation.

Hyper-scale UDCs have a similar energy profile to hyper-scale STBCs. Hyper-scale NTDCs realized via the networking of several small-scale NTDCs are hosted in either of the considered locations. Such an array of NTDCs derives operational power from a significant large-sized power farm. In this case, multiple SMLEs are connected to the power outlet port associated with the external and large-sized power farm. Each SMLE is connected to the SCPE and entity power interface.

The operation of the proposed architecture template requires the functionality of the SIE, SDDE, SDPE, and SMLE. These entities are defined in software and realize their functionality via different programming languages. Emerging programming paradigms and approaches advocate the use of entities that benefit from multiple programming languages [21,22]. This approach, i.e., polyglot programming, is used in the proposed architecture template that benefits from programming language strength diversity [23]. The different combination of languages achieves different levels of inter-connectivity functionality success and varying inter-operable system failures in the relations between these entities and across SBDC, STBC and UDC’s power systems.

The SIE, SDDE, SDPE, and SMLE can be implemented using Python, JavaScript, C++, and C#. The order of the programming languages is interchangeable in system realization. Furthermore, each of these languages in the polyglot multi-language computing system can have a different build and version. This is in line with the design of power systems [24,25]. The output of each of the programming languages is interchanged between the SIE, SDDE, SDPE and SMLE. The output of the SIE is an index enabling the identification of the system’s entities concerned. This output serves as an input to the SDDE. The SDDE’s output is the number of entities fitting for a given index and the redundancy level. The SDDE’s output is the SDPE’s input. The SDPE’s output is a number enabling NTDC identification. The SMLE receives the index and uses it to identify the trained neural network to be loaded for operational parameter prediction in the NTDC.

4. Performance Formulation

The discussion formulates the performance metric for the use of the polyglot programming multi-language system in realizing the architecture template. The set of languages in the polyglot multi-language system is denoted as $\beta$ such that:

$$\beta =\left\{{\beta }_1,{\beta }_2,\dots ,{\beta }_Z\right\}$$

(8)

The $z^{th}$ programming language (PL) ${\beta }_z,{\beta }_zϵ\beta$ can be used to realize an entity for either the SBDC, STBC or UDC. The PL associated with the SIE for the SBDC at the epoch $t_y$ is denoted as ${\rm Y}({\beta }_z,{\alpha }_{SBDC}^{i,SIE},t_y)$. The PL associated with the SDDE, SDPE and SMLE is denoted as ${\rm Y}\left({\beta }_z,{\alpha }_{SBDC}^{i,SDDE},t_y\right),{\rm Y}\left({\beta }_z,{\alpha }_{SBDC}^{i,SDPE},t_y\right),$ and ${\rm Y}\left({\beta }_z,{\alpha }_{SBDC}^{i,SMLE},t_y\right)$, respectively. The PL for the STBC’s SIE, SDDE, SDPE and SMLE is denoted as ${\rm Y}({\beta }_z,{\alpha }_{STDC}^{j,SIE},t_y)$, ${\rm Y}({\beta }_z,{\alpha }_{STDC}^{j,SDDE},t_y)$, ${\rm Y}({\beta }_z,{\alpha }_{STDC}^{j,SDPE},t_y)$, and ${\rm Y}({\beta }_z,{\alpha }_{STDC}^{j,SMLE},t_y)$, respectively. The PL for the STBC’s SIE, SDDE, SDPE and SMLE is denoted as ${\rm Y}({\beta }_z,{\alpha }_{UDC}^{k,SIE},t_y)$, ${\rm Y}({\beta }_z,{\alpha }_{UDC}^{k,SDDE},t_y)$, ${\rm Y}({\beta }_z,{\alpha }_{UDC}^{k,SDPE},t_y)$, and ${\rm Y}({\beta }_z,{\alpha }_{UDC}^{k,SMLE},t_y)$, respectively.

In the existing case, the relations between the power system architecture entities do not consider disruption by the execution of an upgrade. However, disruptions arise when the parts of the NTDC power system undergo a significant hardware upgrade. Such upgrades involve a significant software upgrade. The resulting sophisticated systems are not affected by a vendor lock-in. In the polyglot multi-language computing system, the languages are tested and interchanged to enable system integration. The interchange enables the realization of correct format associations for the input and output. The polyglot system achieves this via the integration of wrappers for the software-defined power system. Examples of wrappers are MATLAB Executable (MEX) (MATLAB to C/C++), Python ctypes (Python to C++), and simplified wrapper and interface generator.

In the existing case, multiple languages can be used. However, this is not done in a polyglot fashion due to the absence of integration frameworks with supporting wrappers. The integration frameworks define the polyglot computing system in the proposed system. The number of integration success (in the proposed solution)—in the existing case, ${\theta }_1$—is:

$${\theta }_1={\displaystyle \sum _{z=1}^Z}{\displaystyle \sum _{y=1}^Y}\sum _{m ϵ \{SBDC,STBC,UDC\}}{C}_m\left(z,y\right)$$

(9)

$$C_{SBDC}\left(z,y\right)={\displaystyle \sum _{b=1}^2}{A}_b$$

(10)

$$A_1=\left|{\rm Y}\left({\beta }_z,{\alpha }_{SBDC}^{i,SIE},t_y\right)\right|+\left|{\rm Y}\left({\beta }_z,{\alpha }_{SBDC}^{i,SDDE},t_y\right)\right|$$

(11)

$$A_2=\left|{\rm Y}\left({\beta }_z,{\alpha }_{SBDC}^{i,SDPE},t_y\right)\right|+\left|{\rm Y}\left({\beta }_z,{\alpha }_{SBDC}^{i,SMLE},t_y\right)\right|$$

(12)

$$C_{STDC}\left(z,y\right)={\displaystyle \sum _{n=1}^2}{B}_n$$

(13)

$$B_1=\left|{\rm Y}\left({\beta }_z,{\alpha }_{STDC}^{j,SIE},t_y\right)\right|+\left|{\rm Y}\left({\beta }_z,{\alpha }_{STDC}^{j,SDDE},t_y\right)\right|$$

(14)

$$B_2=\left|{\rm Y}\left({\beta }_z,{\alpha }_{STDC}^{j,SDPE},t_y\right)\right|+\left|{\rm Y}\left({\beta }_z,{\alpha }_{STDC}^{j,SMLE},t_y\right)\right|$$

(15)

$$C_{STDC}\left(z,y\right)={\displaystyle \sum _{n=1}^2}{D}_n$$

(16)

$$D_1=\left|{\rm Y}\left({\beta }_z,{\alpha }_{UDC}^{k,SIE},t_y\right)\right|+\left|{\rm Y}\left({\beta }_z,{\alpha }_{UDC}^{k,SDDE},t_y\right)\right|$$

(17)

$$D_2=\left|{\rm Y}\left({\beta }_z,{\alpha }_{UDC}^{k,SDPE},t_y\right)\right|+\left|{\rm Y}\left({\beta }_z,{\alpha }_{UDC}^{k,SMLE},t_y\right)\right|$$

(18)

$\left|x\right|$ is the number of entities or elements associated with the set $x$. In (9)–(18), this describes the number of programming languages associated with a given context.

The polyglot computing system builds on the existing derivation by including the integration multiplier (IM). The IM incorporates the influence of code-converting wrappers associated with the proposed approach. The number of integration successes, ${\theta }_2$, is:

$${\theta }_2={\displaystyle \sum _{z=1}^Z}{\displaystyle \sum _{y=1}^Y}\sum _{m ϵ \{SBDC,STBC,UDC\}}{C}_m^{\prime }\left(z,y\right)$$

(19)

$$C_{SBDC}^{\prime }\left(z,y\right)={\displaystyle \sum _{b=1}^2}{A}_b$$

(20)

$$A_1=\left|{\rm Y}\left({\beta }_z,{\alpha }_{SBDC}^{i,SIE},t_y\right)\right|+{\mathrm{\Gamma }}_1\left|{\rm Y}\left({\beta }_z,{\alpha }_{SBDC}^{i,SDDE},t_y\right)\right|$$

(21)

$$A_2={\mathrm{\Gamma }}_2\left|{\rm Y}\left({\beta }_z,{\alpha }_{SBDC}^{i,SDPE},t_y\right)\right|+{\mathrm{\Gamma }}_3\left|{\rm Y}\left({\beta }_z,{\alpha }_{SBDC}^{i,SMLE},t_y\right)\right|$$

(22)

${\mathrm{\Gamma }}_1,{\mathrm{\Gamma }}_2,$ and ${\mathrm{\Gamma }}_3$ are the SBDC’s IM factor for the SDDE, SDPE and SMLE, respectively.

$$C_{STDC}^{\prime }\left(z,y\right)={\displaystyle \sum _{n=1}^2}{B}_n$$

(23)

$$B_1=\left|{\rm Y}\left({\beta }_z,{\alpha }_{STDC}^{j,SIE},t_y\right)\right|+{\mathrm{\Gamma }}_4\left|{\rm Y}\left({\beta }_z,{\alpha }_{STDC}^{j,SDDE},t_y\right)\right|$$

(24)

$$B_2={\mathrm{\Gamma }}_5\left|{\rm Y}\left({\beta }_z,{\alpha }_{STDC}^{j,SDPE},t_y\right)\right|+{\mathrm{\Gamma }}_6\left|{\rm Y}\left({\beta }_z,{\alpha }_{STDC}^{j,SMLE},t_y\right)\right|$$

(25)

${\mathrm{\Gamma }}_4,{\mathrm{\Gamma }}_5,$ and ${\mathrm{\Gamma }}_6$ are the STDC’s IM factor for the SDDE, SDPE and SMLE, respectively.

$$C_{UDC}^{\prime }\left(z,y\right)={\displaystyle \sum _{n=1}^2}{D}_n$$

(26)

$$D_1=\left|{\rm Y}\left({\beta }_z,{\alpha }_{UDC}^{k,SIE},t_y\right)\right|+{\mathrm{\Gamma }}_7\left|{\rm Y}\left({\beta }_z,{\alpha }_{UDC}^{k,SDDE},t_y\right)\right|$$

(27)

$$D_2={\mathrm{\Gamma }}_8\left|{\rm Y}\left({\beta }_z,{\alpha }_{UDC}^{k,SDPE},t_y\right)\right|+{\mathrm{\Gamma }}_9\left|{\rm Y}\left({\beta }_z,{\alpha }_{UDC}^{k,SMLE},t_y\right)\right|$$

(28)

${\mathrm{\Gamma }}_7,{\mathrm{\Gamma }}_8,$ and ${\mathrm{\Gamma }}_9$ are the UDC’s IM factor for the SDDE, SDPE and SMLE, respectively.

5. Performance Evaluation

The discussion here describes the performance results. The simulation and evaluation parameters are in

Table 1. Simulation parameters.

S/N	Parameter	Value
Number of Languages Associated with NTDC Entities
Space-Based Data Centers
1	Maximum, Mean, Minimum (SBDC, SIE)	(1.025, 0.50, 0.057)
2	Maximum, Mean, Minimum (SBDC, SDDE)	(1.377, 0.653, 0.152)
3	Maximum, Mean, Minimum (SBDC, SDPE)	(1.376, 0.653, 0.2653)
4	Maximum, Mean, Minimum (SBDC, SMLE)	(1.049, 0.657, 0.127)
Stratosphere-Based Data Centers
5	Maximum, Mean, Minimum (STDC, SIE)	(1.187, 0.513, 0.115)
6	Maximum, Mean, Minimum (STDC, SDDE)	(1.216, 0.819, 0.226)
7	Maximum, Mean, Minimum (STDC, SDPE)	(1.015, 0.535, 0.111)
8	Maximum, Mean, Minimum (STDC, SMLE)	(1.435, 0.524, 0.153)
Underwater Data Centers
9	Maximum, Mean, Minimum (UDC, SIE)	(1.352, 0.689, 0.081)
10	Maximum, Mean, Minimum (UDC, SDDE)	(1.276, 0.818, 0.353)
11	Maximum, Mean, Minimum (UDC, SDPE)	(1.131, 0.794, 0.276)
12	Maximum, Mean, Minimum (UDC, SMLE)	(1.323, 0.704, 0.272)
Implementation Multiplier (IM) Aspects
Space-Based Data Center
13	Maximum, Mean, Minimum (SBDC, SDDE)	(260.8, 216.6, 139.4)
14	Maximum, Mean, Minimum (SBDC, SDPE)	(164.8, 106.4, 40.8)
15	Maximum, Mean, Minimum (SBDC, SMLE)	(241.6, 150.8, 42.2)
Stratosphere-Based Data Center
16	Maximum, Mean, Minimum (STDC, SDDE)	(135.7, 81.8, 0.76)
17	Maximum, Mean, Minimum (STDC, SDPE)	(217.6, 113.0, 27.1)
18	Maximum, Mean, Minimum (STDC, SMLE)	(198.5, 123.4, 57)
Underwater Data Center
19	Maximum, Mean, Minimum (UDC, SDDE)	(135.8, 81.8, 0.76)
20	Maximum, Mean, Minimum (UDC, SDPE)	(184.5, 122.4, 31.9)
21	Maximum, Mean, Minimum (UDC, SMLE)	(204.2, 99.5, 13.3)

. The scenario is the one in which the three locations are considered. The maximum number of programming languages associated with each software entity is two, and an average of one. The simulation is done for a scenario where ensuring communication network continuity necessitates handover between the SBDC, STBC and UDC. The use of the proposed approach via the IM is considered. The values differ for the non-terrestrial locations. The IM values have also been fine-tuned to achieve a non-greedy performance improvement accommodating the case of non-ideal performing IM wrappers. For NTDCs, a change necessitated via the use of the proposed polyglot multi-language computing system arises due to the changes in the operational environment. The simulation results are in Figure 3. The number of programming languages corresponds to the total associated with entities associated with data centers in a given location.

Simulation shows that the number of successful integrations increases with the proposed approach in comparison with the existing approach. The number of successful integrations is not constant as the simulation considers measures taken to achieve integration without the proposed approach. Such measures do not fully consider the incorporation of the IM and polyglot specific measures. Analysis shows that the proposed approach increases the number of successful integration epochs by an average of 20.2%.

The simulation examines the improvement associated with varying IM values and the results are in Figure 4. The mean IM value is evaluated across all entities and locations. This is done to evaluate the overall performance improvement. Analysis of the results in Figure 4 shows that an increasing overall mean IM enhances the performance improvement. An increasing IM is associated with increased computational complexity with the proposed aspect of the power system.

6. Conclusions

The research proposes the use of a software-defined paradigm for a reconfigurable power system suitable for non-terrestrial data centers (NTDCs). It identifies that the choice of programming language is important for continued system functioning. This leads to the emergence of a polyglot multi-language computing system for implementing the power system’s software-defined aspects. The polyglot system ensures inter-operability and integration between components of power system associated with non-terrestrial data centers. This inter-operability is realized via the inclusion of wrappers for enhanced integration. The software-defined paradigm is intended to be useful in a scenario where each of these non-terrestrial data centers has an open interface implementation. The number of successful integrations is important in the system design, planning and pre-deployment phase. Analysis shows that using the polyglot-based system enhances the number of successfully executed integrations by 20.2% on average. Analysis shows that using the proposed approach enhances the number of successful integrations with the use of more computing software agents. This leads to increased computing complexity. Future research explores increased dimensions of the polyglot programming system (alongside wrapper considerations) while reducing computational complexity.