The external and data loose coupling for the integration of software units: a systematic mapping study

Introduction

Enterprises are typically made up of hundreds of home-made (in-house development) applications, purchased from third parties, legacy systems, or a combination of all of them, operating in multiple layers on different operating systems. Currently, the integration of systems acquired from third parties and legacies has become a major concern in companies. As a result, most of the applications used in the enterprise are heterogeneous, autonomous, and operate in a distributed environment. Heterogeneity has been considered one of the most severe problems to solve because it tends to cause interoperability problems. In particular, semantic conflicts, which occur when applications use different meanings for the same information item. The challenges are integration is not an easy job; the real challenges are made up of several business and technical issues (Hohpe & Woolf, 2004).

In the context of SE, this area is known as Enterprise Application Integration (EAI) (Irani, Themistocleous & Love, 2003). EAI deals with integrating a heterogeneous set of applications and systems in any organization to integrate them and communicate information between the systems facilitating interoperability. According to this, enterprise integration is achieved using different sets of integration tools, technologies, and methodologies to ensure that transformation, translation, and communication of information items are accomplished efficiently. So, advances in integration technology, mainly concerning middleware, provide new ways to design more agile and responsive business architectures.

The integration of systems acquired by third parties is a real problem, mainly due to the lack of information exchange between entities such as banks, suppliers, customers, among others. Continual changes in the information systems environment have become the most important challenge in enterprises. The applications to be integrated are usually developed by different teams that often do not focus on the integration as a relevant issue for them. Aiming at eliminating the integration challenges, EAI is proposed as a solution. Faced with this situation, the need arises for new architectures for EAI, particularly, those with which to improve loose coupling in integrating software units.

There are hardly any research work with regard to EAI in scientific literature such as Soomro & Awan (2012) and Gorkhali & Xu (2016). Soomro & Awan (2012) reviewed industrial challenges and problems in a general form only with which the limitations and research lines are not deep enough. In addition, in the field of the EAI the technological platforms evolve rapidly as a consequence since the year of the publication of this article is more than 9 years it is required to update the research to the current time. Under other conditions, Gorkhali & Xu (2016) performed a systematic literature review focused on categorizing EAI on the basis of industries. Regrettably, the primary studies were limited to those one published in Science Citation Index (SCI) and Social Science Citation Index (SSCI) database. Therefore, this study does not include publications in other recognized sources as Elsevier’s, PeerJ, IEEE or Scopus. There is a SMS described by Banaeianjahromi & Smolander (2014) to survey and analyse the available literature on determining the role of enterprise architecture in enterprise integration and also to identify gaps and state-of-the-art in research. This is a very limited area study since search exclusively for methodologies and trends change over time. Another research studies focused on a particular technique to process integration such as the proposal from Cerqueira et al. (2016) which presents a SMS that investigated the use of ontologies to deal with semantics in integration at process layer level. In this regard, the work from Fusco & Aversano (2020) is about an ontology-based approach for semantic integration of heterogeneous data sources named DIF (Data Integration Framework); this work is not particularly of the field of EAI itself. These papers allow us to go deeper into related topics but specifically none of them has addressed the specific issue regarding to resolve the external and data loose coupling for the integration at software units level. Therefore, a review is needed since it is conducted based on a scientific search strategy such as SMS. To the best of our knowledge, no systematic mapping study has been conducted in this particular topic.

The goal of this study is to provide the state-of-the-art as well as a map of existing literature in this area. Furthermore, its evolution over time is shown to enable improvement of the practice with the known research results and to identify gaps for future research. For this purpose, this review aims to present a comprehensive summary of the studies in this field during the span of 2008–2021. The contributions of this review are:

• This SMS includes quality literature from pre-defined resources and based on pre-defined inclusion/exclusion criteria. Therefore, out of the 3,178 full-text articles studied, 39 articles were included.

• The proposals found in the primary studies for loose coupling software unit integration are based in an environment conformed by Service-Oriented Architecture (SOA), Web Services, and Microservices. Usually there are implemented by a pre-defined data types structure at design time, leaving an immovable structure at runtime.

• A comprehensive discussion on the existing proposals and the research gaps in this area. Furthermore, some suggestions for new research directions are suggested.

The intended audience of this research work refers but not limited to software engineers, information technology managers, business integration practitioners, researchers related to the area of EAI at software unit level as well as novice student researchers.

This article is organized as follows: in “Enterprise Application Integration Fundamentals” the relevant concepts to the context of this work are presented. “Survey Methodology” introduces the research and conduction protocol applied. In “Mapping Results”, are presented the mapping results. “Discussion” introduces a discussion of the findings arising from research. Finally, “Conclusions” presents the final considerations and future work.

Enterprise application integration fundamentals

This section introduces fundamental concepts necessary for a correct understanding of the rest of the article. The concepts addressed are Enterprise Application Integration, Middleware, Software Unit, External Coupling, Data Model, Loose Coupling, PUB/SUB Architecture, Federated Database System, Belief-Desire-Intention Architecture, Hub-and-Spoke, Apache Camel, Message-Oriented Middleware, Service Component Architecture, Grid Computing, Microservices REST, Service-Oriented Architecture and Model-Driven Architecture. These concepts are used thorough this SMS for the sake of understandability and completeness.

Survey methodology

To know different proposals to improve the loose coupling in the integration of software units around this topic, a Systematic Mapping Study (SMS) was conducted. SMS is a methodology widely used in research in the medical area. Recently, it has begun to be applied to the field of SE to classify and structure the research results published. To learn about advances in a topic and identify gaps in research, there is also the methodology known as Systematic Literature Review (SLR). It seeks to identify best practices (based on empirical evidence) by conducting an in-depth exploration of the studies, describing their methods and results.

The difference from SMS is that it seeks to provide a more general vision, and SLR is focused on gathering and synthesizing evidence (Petersen et al., 2008). The main goal of SMS is to provide an overview of the research area and identify the amount and type of research and the available results. It is also essential to map published frequencies over time to understand trends and identify forums where research in the area has been presented (Kitchenham et al., 2010).

In this work, the methodology for SLR described in Petersen et al. (2008) was used. However, the adaptation proposed in Kitchenham et al. (2010) is applied to adjust to the SMS.

The review procedure to follow is composed of five stages: (1) Definition of research questions, (2) Search for primary studies, (3) Selection of documents for inclusion and exclusion, (4) Classification schema, and (5) Data extraction and systematic mapping. Each stage is detailed next concerning how it was carried out for this research.

Search of primary studies

Primary studies were identified using search strings in scientific databases. The Springer, IEEE, CONRICYT¹ , Google Scholar, arXiv, and DOAJ databases were used to select the primary studies in this work. It is important to point out that CONRICYT is a resource supported by the Mexican government that allows researchers to search for scientific articles in databases/editorials such as Web of Science and Elsevier, among others.

To search for the scientific production associated with the concept of Loose Coupling and Enterprise Application Integration, the keywords were defined to construct the search strings to be consulted. To do this, keywording was performed (Petersen et al., 2008). In the first place, the main concepts of the research were identified such as keywords. Then, similar terms (synonyms) or phrases that might also be used to describe these concepts were defined. Next, a thesaurus was consulted to find synonyms. After that, the search terms were combined using Boolean operators. It is essential to mention that a recommended manner to create a search string is structuring them in terms of population, intervention, comparison, and result (Kitchenham, 2007).

The selected search period is from the years 2008 to 2021. The restriction with respect to the time period is to achieve a focused approach, the search was narrowed down to published journal articles from 2008 to 2021. Moreover, since the field of EAI and especially at the data level integration, is relatively old and it has been during the last decade where these ideas have been most developed with the emergence of web services and cloud computing. Likewise, this period of time has been validated during the development of the systematic mapping, since all the studies in this area are located within that period of time. In this sense, generic search expressions were considered considering the structure of each research question, the essential terms, and identified synonyms. The expressions were constructed using logical operators for searches (AND and OR). Table 1 shows how the search string was generated concerning the research questions.

Table 1:

Structuring search strings.

Most important terms	Synonyms, terms and, topics	Search expression
RQ-1
“Loose Coupling”, “Enterprise Application Integration”, “Software Integration Proposal”, “Coupling”, “Integration”	“EAI”, “Software Unit Integration”	Loose Coupling OR Enterprise Application Integration OR Software Integration Proposal OR (Coupling AND Integration)
RQ-2
“Loose Coupling”, “Enterprise Application Integration”, “Software Integration Proposal”, “Coupling”, “Integration”, “Technological architectures”	“EAI”, “Software Unit Integration”	(Loose Coupling AND Technological architectures) OR (Enterprise Application Integration AND Technological architectures) OR (Software Integration Proposal AND Technological architectures) OR ((Coupling) AND (Integration) AND (Technological architectures))
RQ-3
“Loose Coupling”, “Enterprise Application Integration”, “Software Integration Proposal”, “Coupling”, “Integration”, “Framework”	“EAI”, “Software Unit Integration”, “Library”	(Loose Coupling AND Framework) OR (Enterprise Application Integration AND Framework) OR (Software Integration Proposal AND Framework) OR ((Coupling) AND (Integration) AND (Framework))

DOI: 10.7717/peerj-cs.796/table-1

Based on the defined search strings detailed in Table 1, a bibliometric analysis was performed using Vosviewer (https://www.vosviewer.com) software. To identify the tendencies of the literature on loose coupling in the integration of software units, an initial analysis of co-occurrences of keywords was conducted based on articles with at least five occurrences. The research resulted in six clusters (see Fig. 1) involving eighty-one keywords. The clusters are (1) loose coupling, (2) enterprise application integration, (3) management, (4) performance, (5) model and (6) impact.

Classification scheme

For the SMS, a systematic process was followed, which is shown in Fig. 2. It is a way to reduce the time necessary to develop the classification scheme and guarantee that it considers the existing studies. It was performed in two steps: (1) reading the summaries of the articles found and (2) searching keywords and concepts that reflected the article’s contribution to identifying the research context. It caused the combination of a set of different keywords of the research articles reviewed, allowing the development of a high-level understanding of the nature and contribution of the study, which allowed to find a group of representative categories of the underlying population. In relation to, if abstracts are of lower quality to allow choosing meaningful keywords, you may select to study the introduction or conclusion sections of the article. If a final set of keywords has been chosen, they can be grouped and used to form the map categories (Irani, Themistocleous & Love, 2003).

Businesses must be agile and flexible, and IT managers are being asked to deliver improved functionality while leveraging existing IT investment. Mostly of business organizations nowadays are using packaged software for their key business processes and goals (legacy business applications). Some of them are those who attend activities with respect to Enterprise Resource Planning (ERP), Supply Chain Management (SCM), Customer Relationship Management (CRM), and Electronic Commerce (EC). These systems assist business organizations in supporting their operational and financial goals. Bearing this considerations in mind, the classification scheme is divided in: Proposals, Architectures and Technologies/Libraries.

The first classification scheme (Proposals) refers to loose coupling software unit integration proposed to integrate these packaged software applications with each other regardless of its conformation. This scheme can include a framework, an architecture, a full computer package, or software abstractions that facilitate the development of loos coupling software unit integration, i.e. systems where elements can be easily added, removed, or replaced without needing widespread changes across the system. The second classification scheme refers to architectures that have been considered to improve loose coupling in software unit integration. The goal is to analyze the technological architectures proposed at loose level components until now, as well as the emerging architectural styles for developing and integrating enterprise applications. The third classification scheme refers to technologies and libraries that have been developed for loose coupling in software unit integration. In this concern, the organizational and technical framework to enable an enterprise to deliver self-describing and platform independent business functionality is considered.

The classification scheme used can be consulted at the cloud (https://figshare.com/s/a65784c26931b96570fb), where it is possible to see the classification according to proposals, architectures and technologies.

Mapping results

This section presents and analyzes the results obtained after conducting the data extraction process from the primary studies. Several articles were found in the literature focused on different aspects of EAI. The selected studies provided relevant knowledge on the research questions. It is important to remark that the 39 primary studies found provide an answer to more than one research question. These are answered below:

RQ-1. Which are the main proposals to improve the loose coupling in the integration of software units?

The main proposals obtained from the publications were those based on SOA, Web Services and Microservices. These proposals implemented different forms to perform the loose coupling between the software units, using techniques based on asynchronous messages through middleware queues and topics. Some of them used to make this task standardized service contracts such as WSDL (Web Services Description Language) for Web Services and Microservices. This is done by the implementations of protocols such as SOAP (Simple Object Access Protocol), HTTP, REST with the help of the data schema standard such as XSD (XML Schema Definition). For XSD, the data travels in an XML format (eXtensible Markup Language); in the case of REST the format used is JSON. Another alternative that arises is through the construction and development of Frameworks, Constraints, and Models of Metadata. The use of Federated Database Systems is another way to establish loose coupling at the data level using the creation of Data Models where information is exchanged based on predefined schemes called Canonical Data Models (CDM). Most recently, SOA implements an orchestration of Web Services and Microservices for loose coupling between the software units. Next, Table 3 summarizes the main proposals collected from primary studies.

From the proposals found in the publications, 34.5% were implemented with SOA, 24.1% through Web Services, and 17.2% using Microservices, representing approximately 76% of the proposals as shown in Fig. 3. The rest is composed of several technologies of which stand out the use if Middleware, Federated Databases Systems, and Frameworks (see Section “Enterprise Application Integration Fundamentals”).

RQ-2. Which technology architectures have been considered to improve loose coupling in software unit integration’s?

From the review made to the primary studies, it was found that a series of architectures were applied in the integration of software units to improve the loose coupling in the mentioned integration’s. The architectures most implemented for this purpose were SOA and Microservices REST. SOA comes to be an orchestration of technologies supported by existing communication protocols such as SOAP and HTTP. Microservices based on REST is the second most used architecture for this purpose. Table 4 presents each one of these proposals found in the primary studies. As shown in Fig. 4, SOA architecture represents 50% of the implementations found in the primary studies, Microservices represents 15.6%, the 6.3% the PUB/SUB architecture; these, are as a whole 72%. However, there are other architectures that have been implemented such as PUB/SUB (Green, 2013; Antipov, Antipov & Pylkin, 2016), Hub & Spoke (Krishna Mohan et al., 2013), Camel Apache (Cranefield & Ranathunga, 2013), MOM (Message-Oriented Middleware) (Gutiérrez, Garca-Castro & Mihindukulasooriya, 2013), Federated Database Systems (Muñoz & José, 2009), BDI (Belief Desire Intention) (Weyns & Georgeff, 2009), Intermediate Layer (Lehsten, Gladisch & Tavangarian, 2011), SCA (Service Component Architecture) (Ma, Tang & Wang, 2009) and Grid Computing (García & Montoya, 2011), which is not widely used. This corresponds to the rest 28% of the total of primary studies.

In the case of the implemented architectures, Fig. 4 shows that the SOA architecture represents 50% of the implementations found in the primary studies, Microservices represents 17.6%, the 11.8% through Web Services; these are as a whole approximately 80%. The rest 20% a series of diverse architectures such as PUB/SUB, Camel Apache, Federated Database Systems (Muñoz & José, 2009), BDI (Weyns & Georgeff, 2009), Intermediate Layer and SCA (Ma, Tang & Wang, 2009).

RQ-3. Which technology or frameworks (including libraries) have been developed for loose coupling in software unit integration?

Several technologies were found in primary studies to address loose coupled in software unit integration, most of them being applied to architectures already validated such as those based on architectural patterns or archetypes. These are SOA, SOAP, WSDL, XSLT, ESB (Enterprise Service Bus), XML, XSD, BPEL (Business Process Execution Language), JMS (Java Message Service). For this reason, another set of technologies found for these purposes are the Microservices REST, and JSON. The primary studies also reported the application of Web Services with WSDL, SOAP, XML and XSD for integration’s. Furthermore, technologies such as PUB/SUB, JMS, Queue, Topics, MDB (Message Driver Bean) were used to for software unit integration. Additionally, a set of technologies with fewer implementations with regard to software units integration were found, these are Apache Camel which is an open-source integration framework for data production or consumption, HL7 (Health Level Seven) (García & Montoya, 2011), Dublin Core, CORBA (Common Object Request Broker Architecture), RMI (Java Remote Method Invocation), Canonical Model, ODBC/JDBC (Open Database Connectivity/Java Database Connectivity) (Muñoz & José, 2009), Self Adaptive, AI (Artificial Intelligence), KQML (Knowledge Query Manipulation Language), Neuronal Network (Weyns & Georgeff, 2009) and Service Component Architecture (Ma, Tang & Wang, 2009). Next, Table 5 summarizes the technologies extracted from the primary studies according to technology/frameworks implemented for loose coupling in software units integration.

Relating to applied technologies, as shown in Fig. 5, the most implemented technologies are those based on SOA, Microservices REST, and Web Services. At glance, SOA represents 50%, in second place are Microservices with 17% and Web Services at last with 12% of technological implementations. The rest 21% of the technology/frameworks represent a diversity of scientific and technical knowledge implemented, which includes standards, frameworks, libraries, technological patterns and communication protocols.

Entirely, 79% of the 39 primary studies give a solution in the loose coupling in software units integration through these technologies. It is important to mention that, since these were selected from the primary studies reviewed, these technologies represent a large percentage of the results obtained in the review. Likewise, their application and publication in scientific articles highlight the fact that they are considered as the main technologies used today for the integration of loose coupling software units.

To provide a solution in the loose coupling in software integration’s, the scientific community made a prominent effort to solve this problem from 2008 to 2011. Regrettably, this attempt began to decline in the period 2012 to 2017. Nevertheless, it gained momentum again in the year of 2018. It is possible to see that in these periods from 2008 to 2021; SOA, Web Services, and Microservices were the technologies primarily implemented for this purpose leaving aside technologies such as XML (eXtensible Markup Language). The analysis presented in Section “Mapping Results” shows a trend towards the investigation of approaches and architectures to increase connectivity since this is the most significant issue for EAI. The classification by year of publication concerning the different proposed research questions are shown in Fig. 6.

Most of the proposals found in the primary studies for loose coupling software unit integration are based in an environment conformed by SOA, Web Services, and Microservices. In this environment, the nodes of the network make their resources available to other participants in the network as independent services to which they have access in a standardized way, most of the definitions identify the use of Web Services using SOAP and WSDL in its implementation; however, it can be implemented using any service-based technology.

To clarify the limitations found on these most implemented proposals, a WSDL structure for analysis is introduced in Fig. 7. This exemplifies how data types are defined at design time, leaving an immovable structure at runtime. In this concern, a WSDL document defines a set of services as collections of network endpoints or ports. The abstract definition of endpoints and messages is separated from their concrete network deployment or data format bindings. This separation enables the reuse of abstract definitions such as messages and types of ports. The messages are structured in such a way that they represent a description of the data that is exchanged that includes the ports as collections of operations to be performed. In that sense, the reusable link is made up of a protocol and contains the data format specifications for a particular type of port and a collection of ports defines a service.

The definition of network services in the structure of a WSDL document is made up of a series of elements, these are: Types, Message, Operation, Port Type, Binding, Port, and Service. These are detailed below:

1. Types: these are the data types of a system and are commonly defined in XSD structure.

2. Message: it is the structure that contains the data that is exchanged in a connection.

3. Operation: describe the actions supported by the service.

4. Port Type: are the operations supported by various endpoints.

5. Binding: this permits to specify the data format for a particular type of port.

6. Port, it is a combination of a link and a network address, it is a defined end point.

7. Service: is defined as a collection of related points.

These elements are divided in two parts, the Concrete part, which defines the “how” and “where” and the Abstract for the definition of what the service does through the messages it sends and receives. Analyzing this structure, there is a deficiency in the high external and data level coupling in the integration of applications or software units because it is created before being used. According to Fig. 7, the element highlighted in yellow corresponds to the node (element) <message>, this element generates this coupling issue because it is created under a predefined fixed structure XSD before being used.

Analyzing the structure of the XSD showed in Figs. 7 and 8, if it is considered a change in the element highlighted <TradePrice>, this contract would impact all the applications or software units that are integrated into this structure. This which will cause a close coupling between them, consequently a high cost of maintenance and time. This is due to Fig. 7 exemplifies how data types are defined at design time, leaving an immovable structure at runtime. In Fig. 8, the label of the <TradePrice> element is observed, where the tags highlighted in yellow in the code represents the data and the properties of the structure called <price> and the type of this property <float> marking the strict way of receiving the exchange of information between software units. Therefore, if a change in the element <TradePrice> is considered, this contract would impact all the applications or software units that are integrated into this structure.

Clarifying this, let us assume this scenario, a Web Service or Microservice is consumed by a hundred clients where each one of them uses the same service contract (or WSDL document) to access to perform an operation. At once, if a change in the type of data is requested by some of those clients it will be necessary to create another new contract or WSDL document for each client that has changed. Furthermore, this scenario can be present if a client wants to integrate a new data type making it necessary to send one more data. This is important, since this entails having control and maintenance for each contract created, which implies that it is mandatory to create a hundred contracts in order to maintain the integration. This would represent a high cost in resources such as time, effort occasioning and increment in the project budget.

Discussion

This SMS has brought several perceptions into the research trends in EAI at the software unit level. These discernment’s are discussed in this section.

Throughout the years, the main problem of EAI has been the communication and exchange of data between heterogeneous systems. In recent years, particularly in the period covered by this systematic mapping study, new technologies have emerged to develop software systems. Moreover, some existing technologies have been used in combination to provide robust frameworks for applications development that satisfy the needs of enterprises.

An issue that has been left behind over the years is the one related to considering an EAI project as an independent project reflecting its unique characteristics. No research was found on primary studies with regard to proposals for a step-by-step guide for EAI project definition and implementation. This is a critical issue to be studied since a software development project with a distributed architecture optimized for the data exchange is not the same as an EAI project. The SE guidelines allow obtaining a product that satisfies the customer’s needs in a software development project, but this is not the case in EAI projects. There is no generic methodological approach for enterprises to implement it. This kind of project is considered one more component of a traditional software development process that implies a delay in its completion. Therefore, it is not considered an independent project that must be defined within a methodological approach only for EAI. In this sense, enterprises do not prioritize questions such as how to measure the value that an EAI project brings to them in the near future and how it could help significantly reduce maintenance costs. When they decide on an EAI project, they lack ad-hoc planning guided through a methodology for it.

Through the constant evolution of technological platforms for the development of software systems, many proposals for EAI have emerged in the scientific literature according to primary studies found. Most of them are based on SOA and microservices (see Fig. 4).

As shown in Fig. 6, the evolution of technology has been such that it has overcome the proposals that should exist to solve problems that the EAI has dragged on from the time when its early years. Furthermore, the scene is complicated again, as novel technologies appear to develop software systems, and as a result, new integration essentials are born with it. In this regard, research has dedicated much attention to succeeding simple data exchange among software units. Therefore, data privacy and security concerns have increased. Even though this area is out of the scope of this SMS, it is well-thought-out that research to date has overlooked the data security and privacy problems that emerged due to technological platforms and thus have not been adequately studied.

Over time the research in EAI does not provide a general framework for integration projects, nor at the level of data exchange, databases, or interfaces. In this regard, some efforts have been made, integration proposals have been industrialized, and scientific articles have even been published presenting solutions. The proposals help along with being universal for EAI because they are based on MDA (see Section “Microservices REST”). The advantage proposed by MDA approaches to solve the EAI problem is that the same models created can be converted to the source code of the user’s preference. This provides an advantage to EAI projects because by reusing the models, it is possible to generate the exact solution for different technological platforms (Alahmari, De Roure & Zaluska, 2010) and to build help along with new integrations in models to obtain the source-code for the integration. The advantage of this idea regards to improve a vital deficiency that is the re-configuration of business systems and not only the integration. Regardless of the importance of an approach like MDA, there has been not enough research in this field, as have many other topics at EAI.

The scientific literature emphasizes that current EAI solutions face a heterogeneity problem. Therefore, EAI solutions lack a robust and consistent integration approach supported by a methodology designed for that labor. Particularly, dedicated to the integration of heterogeneous enterprise applications that consider Requirements Engineering (RE) activities (Aguilar et al., 2010). Which can be modeled according to the necessities of the integration bearing in mind important software quality attributes such as security and privacy. Even that permits the requirements to be explicitly modeled on-demand as planned integration can be improved in execution. Nonetheless, it is predictable that the research will be uniformly concentrated through all activities of RE with emphasis within different research categories that provide supports to validated solutions such as experience reports, frameworks, and empirical studies that assist their decision-making. Nowadays, this is unaccomplished in EAI at the software unit level.

As mentioned above, enterprise applications are growing in number in different sectors of society. Almost all the business processes they handle have their software systems. These systems are based on different platforms and recent technologies. For this reason, they include multiple sources that lack interoperability, so dynamic EAI solutions are needed to solve integration problems. Dynamic EAI solutions can be achieved using SOA web services and with recent technology such as REST microservices. An advantage of these new technologies is the ease of integration at a low level that improves data exchange among applications. This enables interoperability through a controlled flow of data.

As new technologies evolve, it is important that EAI solutions adapt to these new technologies, but it is mandatory to increase the research in this area because the evolution is so fast that the problems that exist today will continue to exist tomorrow along with others more formed as a result of: (i) new implementation technologies, (ii) the growing demand of the telecommunications market, and (iii) a rapid change of the enterprise IT department as well as their technological environment. In addition, meanwhile, the main application of the EAI is the collaboration among systems of different enterprises (e.g., banks for payments in sales, shipping services, as well as product providers). They dedicate a considerable amount of their budget more than human resources to maintain the exchange of data between the enterprises with which they interact in their business processes operating efficiently. Therefore, by creating interfaces at the software unit level that can integrate their applications, reducing the resources dedicated to maintenance will be possible. According to primary studies, SOA, as described by various authors as an architecture that can help solve not only the integration problem but also optimize integration techniques.

Finally, today, the EAI faces two significant challenges: syntactic and semantic integrations among enterprise applications at the level of software or data units. One reason for this is because each department/area built its software systems, making interoperability difficult. Primary studies show that it is essential to have a coherent semantic integration approach due to analysis. For this, the proposals continue to use a declarative definition for the data types and formats of the field that will facilitate the exchange of information in the integration configuration.

Conclusions

This work presents the results obtained after conducting an SMS. This research creates a synthesis of the current state of the art concerning loose coupling in software unit integrations in EAI. The goal is to provide scholars and practitioners with a comprehensive summary of recent research on this topic. Unfortunately, the literature lacks studies that report research work summarizing recent trends in this area.

For this, a total of 3,178 articles published in the literature were considered. These were extracted from scientific sources such as Springer, IEEE, CONRICYT, World Wide Web through Google Scholar, arXiv, and DOAJ. In the end, 39 primary studies (see Tables 6 and 7) were analyzed in-depth because they fulfilled the research questions proposed according to our inclusion and exclusion criteria detailed in Section “Selection of Documents for Inclusion and Exclusion”.

SMS results shows that, in 13 years period, from 2008 to 2021, the same architectures or architectural patterns and technologies are still being used. Among them are SOA, Web Services, and in recent years Microservices. However, the technology used is limited because they continue using a WSDL data structure or service contract. Therefore, the coupling at the data level becomes a tight coupling. Additionally, this work remarks that EAI, particularly at loose coupling in software unit integration, has distinct requirements for e-commerce, banking, manufacturing, energy, and healthcare industries. Hence, to perform successful integration, various frameworks, architectures, and approaches are obligatorily needed. Thus, it is necessary to provide solutions within the architectures that offer us the goodness of decoupling the software units when they are integrated.

EAI at the software unit level is more than a technological trend. It is a form to consider structuring the information system to leverage the existing IT investments more effectively when developing new applications. Although the EAI has existed since the beginning of IS, it has constantly been evolving. As a result, integration has become more important than development in creating new applications for enterprises to deal with this problem.

The paper concludes that, as is well-known, EAI is a technology that helps an enterprise to achieve integration to inter and external software systems for data exchange. However, the integration technology solutions are often brand-named, which present interoperability issues because vendors restrict access to the code level, the complexity of services, and connectivity issues. Nevertheless, the distributed environment of enterprise applications outcomes in a complicated integration system. Consequently, new methodologies, platforms, protocols, technologies, and frameworks are still necessary to accomplish an all-inclusive EAI. In this regard, the future of EAI is based on platform-independent based solutions such as MDA, but lack of standards, robust frameworks for model-to-model (M2M) and model-to-text (M2T) transformations, problems related to tool support lacking usability with a poor user experience. This must be reviewed in terms of security and performance. Model-Driven technologies have been there since the 2000 year, and there are still the same issues. Likewise, changing dynamics of the application development process and usage pose a further challenge to achieve the desired result from EAI. Some of the current research suggests that much of EAI research is concentrated on developing a framework for EAI that can be used in different applications domains such as e-commerce, healthcare, and enterprise resource management systems. Additionally, the research on EAI is insufficient. There is an urgent demand to conduct more in-depth and significant research in developing new and enhanced frameworks and methodologies for EAI for cloud computing and IoT because these are technologies that are growing worldwide.

Some directions that future research from this SMS are suggested next:

1. The growing demand of the telecommunications market requires new implementation technologies, especially the development of robust frameworks considering cloud computing because enterprises applications drive their systems to this technology.

2. The emergence of new technologies, particularly technological platforms, demands more research at the EAI focused on the heterogeneity problem. The migration of old systems to new platforms such as cloud computing requires methodological guides and trained human resources who can direct the migration and integration with new technologies within the company.

3. The lack of research in the Requirements Engineering area within a methodological approach to implement an EAI project from the scratch. The idea to consider an EAI project as a different software development project must be adopted in enterprises because both have their particular characteristics. However, most of the time, they are considered the same or part of the main development software project because EAI’s development cost is higher than a traditional approach. Furthermore, implementation takes more time and consumes more resources.

4. EAI is for data exchange among different technological platforms. Until now, microservices and SOAP are the most used technological platforms for that goal, according to Table 3. It is well known that microservices are distributed above several data centers, cloud providers, and host servers. Therefore, constructing an infrastructure through many cloud locations increases the probability of losing control and visibility of the application components. In this regard, data security and privacy issues must be of greater importance to researchers.

5. Consider to make more effort in Model-Driven based solutions. Considering MDA for framework development since their advantages are notorious and can be perfectly implemented in EAI ate software unit level. The solution for EAI can be generated in several programming languages just executing the M2M or M2T transformation over the same definition models.

As future work, we propose an architecture or pattern using a Dynamic Data Canonical Model (Mork et al., 2014) through the management of Agnostic Messages (Celar, Mudnic & Seremet, 2017). The messages will create a low external and data level coupling established in the service contracts that help integrate software units.