<figure><img src="image_1.png" /></figure>

HAL
open science

# Analysis and Remediation of Interoperability problems of an AMQP based system

Yassine Elcaidi, Jannik Laval, Nawel Amokrane, Néjib Moalla

► To cite this version:

Yassine Elcaidi, Jannik Laval, Nawel Amokrane, Néjib Moalla. Analysis and Remediation of Interoperability problems of an AMQP based system. IWST 2019 - International Workshop on Smalltalk Technologies, Aug 2019, Cologne, Germany. hal-04053123

HAL Id: hal-04053123

https://inria.hal.science/hal-04053123

Submitted on 31 Mar 2023

HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entific research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.

L'archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diffusion de documents
scientifiques de niveau recherche, publiés ou non,
émanant des établissements d'enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.

Public Domain
# Analysis and Remediation of Interoperability problems of an AMQP based system

Yassine Elcaidi

Jannik Laval

yassine.elcaidi@gmail.com

jannik.laval@univ-lyon2.fr

University of Lyon, University

Lumière Lyon 2, DISP Lab EA4570

Bron, France

Nawel Amokrane

nawel.amokrane@Berger-Levrault.com

Berger-Levrault

Lyon, France

Nejib Moalla

nejib.moalla@univ-lyon2.fr

University of Lyon, University

Lumière Lyon 2, DISP Lab EA4570

Bron, France

## Abstract

To achieve a high level of communication at different layers independently of a specific actor, interoperability represents the current interest for all types of organizations for its open standard aspect capable of performing collaboration on different concerns. Indeed, interoperability allows the exchange of information along several axes and the use of this information to achieve common objectives. Dysfunctions related to these exchanges can have a negative impact on the overall performance of communicating. Therefore, interoperability should be continuously verified and improved. We present in this paper a monitoring considering interoperability at the data level, through the information collected about existing data exchanges that use the messaging based broker RabbitMQ as a mean of communication. The information collected supplies a set of indicators that are confronted with interoperability requirements allowing us to detect interoperability problems and provide their potential causes. Indicators characteristics offer various exploitations depending on their nature and utility. We use AHP to provide an analysis of the importance of these indicators and give an ordering of the potential causes of interoperability problems based on experts' judgments. We implemented our framework on top of the data analysis platform: Moose and experimented it on a Publish-Subscribe system implemented with the broker RabbitMQ using the protocol AMQP.

**Keywords** Data Interoperability, Interoperability Assessment, Monitoring, Data exchange, Message Brokers, Interoperability Requirements

Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. Copyrights for components of this work owned by others than ACM must be honored. Abstracting with credit is permitted. To copy otherwise, or republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. Request permissions from permissions@acm.org.

Conference '17, July 2017, Washington, DC, USA

© 2019 Association for Computing Machinery.

ACM ISBN 978-x-xxxx-xxxx-x/YY/MM...$15.00

https://doi.org/10.1145/nnnnnn.nnnnnnn

## ACM Reference Format:

Yassine Elcaidi, Jannik Laval, Nawel Amokrane, and Nejib Moalla. 2019. Analysis and Remediation of Interoperability problems of an AMQP based system. In *Proceedings of ACM Conference (Conference '17)*. ACM, New York, NY, USA, 8 pages. https://doi.org/10.1145/nnnnnnn.nnnnnnn

## 1 Introduction

Interoperability is defined as the ability for two or more systems/components to exchange information and to use the information exchanged [12], a term related to several socioeconomic, techno-economic, or even governmental contexts. Currently, it is admitted that the literature surrounds and specify the academic plot and jargon related to this notion. Enterprise interoperability can be developed between different levels of interacting enterprises (business, processes, services, and data). Decreasing interoperability capacities caused by unsatisfied interoperability requirements can have profound impacts as it refers to b2b interaction capacity. Indeed, interoperability problems can have a significant influence on the performance and results of the whole enterprise network.

In our context, Berger-Levrault (BL)<fnref n="1" /> assures interoperability between communicating applications; with a Message-Oriented Middleware API (BL-MOM). The latter implements asynchronous exchange of messages according to the protocol AMQP. The capacity sought behind interoperability in this context is based on the use of an open standard without relying on a particular actor to exchange data [4].

Improving interoperability implies that a level or degree of interoperability is assessed. However, identifying interoperability problems and their causes can represent a real challenge. We can summarise our research problems in two categories: data exchange monitoring and interoperability assessment.

For the data exchange monitoring, we notice that existing monitoring tools propose low-level metrics unable to represent business informations. They offer information related to the number of resources and visualisation of consumption and publication rates. This is due to the multiplicity of data

<footnote n="1">¹Software provider specialised in the fields of education, health, sanitary, social and territorial management.</footnote>
arisen from message exchanges in addition to the different
components to manipulate.

Concerning the assessment part, few studied approaches
offer computer-mediated approaches to support the assess-
ment and decision-making processes. Also, a few number of
interoperability assessment approaches convey information
to identify problems and improve the interoperability level.
On the other hand, approaches with dealing with several in-
teroperability concerns do not provide a detailed analysis. We
aim with this work to provide an interoperability evaluation
approach that offers a set of indicators allowing to specify the
origin of interoperability problems.

In the remaining sections of this paper, Section II presents related works and the motivation behind the proposed approach. Section III is dedicated to describing the global framework with all its components. Then, the implementation part of the framework describing the used technologies is described in Section IV. The interest behind the approach in Section V. Finally, we conclude with perspectives.

2 Motivation and Related Work

This section will be divided into two parts, it touches the data
exchange monitoring for evaluation of interoperability, and to
reach it, a study of the literature will aim the Interoperability
Assessment approaches, the monitoring, and its tools.

## 2.1 Monitoring

Our approach uses monitoring for the assessment of interoper-
ability, an analysis capable of defining a sort of classification
of potential causes by order of importance for a given prob-
lem. A monitoring system is defined as a process or a set
of distributed processes including the function and collec-
tion, interpretation, and dynamic processing of information
relating to an application being run [5]. Literature classified
these techniques into two categories: Direct Monitoring and
Indirect Monitoring.

Direct Monitoring aims at actively involving the system
in the data collection phase; these data are generated by the
target system itself or obtained by querying the target system.
This type of monitoring and linked to the development phase
for the detection of problems related to the engineering phase.
In the case of our approach, monitoring is qualified as Indi-
rect Monitoring, aiming to collect data without pressing the
system, with monitoring the data generated in different places
[6]. In our case data collection is related to the trace files of
various plugins of the RabbitMQ broker.

Different tools are used to exploit indirect monitoring ap-
proaches for brokers. In the case of messaging exchange
monitoring, Dynatrace<fnref n="2" /> allows detecting RabbitMQ instances
and displays measures such as processor, consumers, and
queues also nodes that are assigned. Datadog<fnref n="3" /> can go until

navigating between logs and test hypotheses by superimpos-
ing events. These tools or others mainly focus on low-level
monitoring information such as messages, resource rates, or
memory usage. Monitoring requires an intervention method
based on advanced filters and more precise data while refer-
ring to orderly potential causes.

Disaggregating data monitoring modules is difficult; The
approach work overcomes these limitations of conventional
indirect monitoring, by providing a messaging metamodel
as a single data source, able to assemble disaggregated data
into Moose data analysis platform. It provides performance
metrics with a runtime aspect, and even statistics obtained via
the data accumulated of indicators will have an impact on the
improvement of the maintenance; useful to define thresholds
for anomalies detection. Even with a large dataset, the ap-
proach can turn to the second level of predictive maintenance
for fatal falls.

In the web service monitoring context, the closest work
to our approach is [7] dedicated to checking the quality of
requirements of web service consumers. These requirements
form the basic contents of an XML log. The approach contains
an example of requirements as well as the relevant metrics
and associated log fields, also, interventions as needed for
response time issues or availability issues.

## 2.2 Interoperability Assessment

Literature provides a broad range of methods used for in-
teroperability assessment. Several recent systematic reviews
[14] [10] [12] had surrounded interoperability assessment
approaches according to some types and characteristics that
structured these methods.

We eliminated during the selection phase all methods dedi-
cated to the evaluation of potentiality. The laters define levels
of maturity in the assessment of interoperability of a given
system without knowing the interoperating partner. As well
as these approaches offer an evaluation according to criteria
for each given level, but generally they do not provide any
contribution for the improvement of interoperability, and lack
good intervention practice for the resolution of the problems
of interoperability.

However, interoperability assessment related works will
primarily focus the data concern, mainly those related to
interoperability requirements :

- Interoperability assessment of compatibility approaches [15] are categorized in the engineering phase of systems when solutions are re-engineered in order to establish interoperability. Partners/systems of the interoperation are known during the implementation of interoperability solutions. Related approaches, in this case, depend on a referential of requirements to satisfy, that we will use for the selection of requirements.

- Performance assessment related to the interoperation, which the assessment is done during the operational phase; where interoperability solutions exist and are implemented. This phase represents the positioning of our framework. As far

<footnote n="2">²https://www.dynatrace.fr/</footnote>

<footnote n="3">³https://www.datadoghq.com/</footnote>
as we know, only the three evaluation approaches according to those selected in reviews are dedicated to the performance. Even more, only one of them is classified as a computer-mediated support approach.

In compatibility assessment, it is interesting to mention [15] for its message checking aspect. Authors propose a process of interoperability test development in a structured way. They consider it as a formalization of interoperability tests. Its use case is a compatibility assessment of two systems depending on the data concern. Interoperability is evaluated this time far from the interoperability requirements. For the conceptual part, they checked it by the compatibility of message formats. For the technological level, they checked the connection and exchange capacity.

[8] deals with all three types of evaluation. The authors propose a five-level maturity assessment model. Compatibility assessment is effected using the compatibility matrix, while for performance measures, cost, time and quality are checked to find the gap between the current system state and the desired result.

For [3], a technological approach of performance assessment aimed at improving interoperability according to the concerns (process, service, data). The framework is composed of the architecture of three layers to evolve the effect of interoperability solutions for the achievement of high-level business objectives. For that, the Authors use KPI key indicators and evaluate the as-is state that corresponds to the way in which decisions currently executed. A comparison between the latter and the to-be state, which represents the expected solutions will have as a result a capacity for improvement by calculating the gap between the two stats.

Concerning [9], the approach is consecrated to the definition and verification of interoperability requirements; The authors classified requirements according to four classes: compatibility, interoperation, autonomy, and reversibility. They verify a set of compatibility and performance requirements using model checkers. However, they mention that not all requirements are formally checked. Also, the link between requirements and interoperability solutions needs to be refined; and the choice of solutions needs to be guided with the most refinement possible.

## 2.3 Requirements Usage

For all that precedes, the work of this approach is to select interoperability requirements according to [13] and [18]. They treat them with a computer-mediated support approach that identifies the link between requirements, problems and potential causes by messaging indicators able to maintain initially the exchange of data, and a good level of interoperability.

An interoperability requirement is defined as "a statement that prescribes a function, capability or feature related to the ability a partner must provide for its partnership in terms of its accounting, interoperability, reversibility and autonomy to which he must satisfy." [13]

Grouping these requirements constitutes a referential of the interoperability requirements, the interest is to have this as a guide of the analyst who will look for interoperability problems [13]. The identification classifies a given problem in the related concern, layer and the requirement concerned.

The two referential chosen opt two different natures, but that does not influence the fact of the existence of some common point. [13] classes the requirements according to the classes quoted in the definition:

* Compatibility requirement: "A statement that prescribes a function, capability or characteristic considered invariable throughout the collaboration and related to interoperability barriers and each level of interoperability that partners must meet before any collaboration".

* Interoperation requirement: "A statement that prescribes a function, an aptitude or a characteristic - considered variable during the collaboration - related to the interactions between partners".

* Autonomy requirement: "A statement that prescribes a function, ability, or characteristic - related to the ability of partners to maintain their governance and operational capabilities during the collaboration - that partners must meet".

* Reversibility requirement: "A statement that prescribes a function, aptitude or characteristic related to a given partner's ability to return to its original state that the company must meet at the end of the collaboration".

We excluded the last two classes: they are related to other concerns of interoperability.

[18] adopts a structured approach that respects maturity levels related to some basic evaluation criteria, adding interdependence, decomposition and best practices for each of the requirements of the 12 interoperability zones of the MMEI.

This work consists of using these two referential to achieve an analysis based on interoperability requirements. The study had as an objective, finding intersections and the common points in those referential.

The selection of intersections was complicated due to vague terms used to describe requirements. The intersection is represented by the compatibility part; as [18] deals with evaluation according to maturity levels, and [13] proposes a class of compatibility requirements, and interoperation requirements related to the effective interoperability treated with the global framework of this approach. The analysis resulted is the collection of elements adapted to the approach based on the following criteria:

* Requirements must be related to the data axis.

* Requirements should have any contradictory meaning with the asynchronous aspect and the Publish-Subscribe method.

* Selected performance Requirements must be variable.
* Compatibility requirements selected had a link with implemented solutions verified, and associated with interoperability solutions established before a messaging exchange.

The selected list of compatibility requirement in Table 2 requirements is given below, according to interoperability barriers :

* Basic guarantee of an exchange establishment barrier : "Data storage devices shall be connectable and simple electronic exchange shall be possible": Set up technical resources for the exchange of data within the company. This is related to the BL-MOM API aspect of ensuring the data exchange between modules, relying on the RabbitMQ broker and the AMQP protocol.

"Direct database exchanges capability and full data conversion tool". This is related to the direct capacity of the heterogeneous exchange databases which represents the desired basic interest of a message exchange.

* Exchange Format barrier:
"Exchanged data is formalized and unambiguous":an exchange format is chosen by the developers of two extremes

* Exchange Authorities barrier:
"Responsibilities and authorities shall be defined and in place" and "Partners have the required permissions to carry out data exchanges" : a permission set must be assigned to the partner for access and exploitation of resources.

"Partners provide permissions for data updates": Data consumption may involve changes in the own data of a partner. Partners must provide permission for actions on their data.

* Security barrier:
"Confidential data is secured": The security mechanisms defined by partners are carried out with the encryption of the payload.

To adapt in a precise way the selection phase of requirements, Other requirements related specifically to the appearance of technological message exchanges will be added to those selected from the existing.

# 3 A Framework For Interoperability exchanges assessment

The contribution is represented by the global framework in Fig. 1, which represents the collection of data from different sources related to the exchange of messages. A messaging metamodel groups all these aspects.

The exploitation of the latter provides different operations using Moose technologies. The work consists of using indicators to guide the intervention to patterns problems due to some classified causes. Indicators, according to their weights, are used as criteria of choice of causes, which represent the last layer of alternatives in AHP.

<figure><img src="image_2.png" /><figcaption>**Figure 1.** The global framework</figcaption></figure>

## 3.1 Metamodel

A single source of data that gathers the different trace files, is implemented by a messaging metamodel described in [1].

It gathers the whole messaging structure carrying out the system of queuing and messages exchange, according to the AMQP protocol. The additional layer providing the Business level of interactions via BL-MOM. The metamodel groups the messaging entities, as well as the global process and events related to exchanges with their timestamps.

Basics of messaging in the metamodel are described as the following process: a set of publisher clients who authenticate with user credentials. Create messages and publish them into exchanges in the broker server. A message has two parts; The payload that corresponds to the data to transmit and a header that describes it. RabbitMQ sends it to the interested consumer represented by a consuming process for each queue; using the information provided by the header.

The messaging metamodel unifies all trace metrics from the following sources:

* Message traces provided by RabbitMQ tracing plug-in.

* Current configuration of the broker in terms of exchanges, queues, their bindings, and existing users and permissions. This is audited through the use of RabbitMQ REST management.

* History of events of creation and deletion of resources, virtual hosts, users, and permissions; creation and closing of connections and channels and user authentication attempts. This is provided by the RabbitMQ Event Exchange plug-in.

* The layer added using BL-MOM which provides the contextual elements about the communicating applications.

A passage through Moose (explained in Section 4) is necessary for the metamodel to be populated and ready for interrogation and deep analysis. Moose is more than just a tool, it's a platform designed to offer the aspect of creating right tools for all analysis theme, to control and customize the data flow,
using data importers, parsers, advanced queries and all types
of visualization.

## 3.2 The tuples requirement-problem-cause

Table 1 represents an analysis guide, describes a part of the selected requirements related to effective interoperability. These requirements have a progressive aspect, described by [13] as interoperation.

Despite its classification among compatibility requirements, the first requirement in the table has a progressive aspect in messaging exchange. This allows to assess it during the operational phase.

The table represents the link between problems of interoperability due to the dissatisfaction of requirements, indicators, and potential causes. Fields in the table represent

* The statement of the requirement respecting all rules set during the selection phase.

* The qualitative weight of the requirement concerning exchange retention.

* Problems associated with the dissatisfaction of the requirement.

* Runtime type indicators had a nature related to intervention and corrective maintenance. The AHP weight designates the order of importance of the indicator with respect to a given problem.

* Reporting Indicators are used differently, as statistics that accumulate with an aspect of time. These accumulated rates can define, for instance, mathematical thresholds according to the probability distribution. Then, an analyst can refer to the detection of technical thresholds for anomaly detection by detecting the rate value and time-related to the mathematical threshold; thus, it will predict failures in a second level.

* A column is intended for potential causes, which represent the alternatives of the AHP hierarchy.

## 3.3 Classification of causes using AHP

The AHP method [16] is a powerful and flexible method capable of breaking down a complex problem into a hierarchical system, allowing organizations or individuals to place calculated weights and importance on various options. By quantifying the essential criteria, it is often easier to see the final decision than to simply try to understand different levels of importance and preference. Thanks to this, the decision maker can deduce relative properties. As well as, compared to other MCDM methods, like Topsis [11], AHP offers the possibility to measure the consistency of the decision maker's judgments. The method is feasible as computer software helps to apply it fast and precisely. AHP allows the possibility to turn it into a Fuzzy AHP, which is more complex and precise in terms of calculation.

The simplest example of an AHP architecture is one of the 3 layers, whereas it can have several layers; for instance,

the case of the calculation of the level of maturity [17] [2]. These three layers contain, in the first level, the goal of the AHP analysis, which is the axis of choice of the decision. The second layer is for decision criteria, where they are ranked by importance order weights. The last layer represents alternatives related to the main purpose.

AHP defines multiple properties:

* the scale of relative decision coefficients between criteria or alternatives, and their inverse values for inverse comparison.

* Criteria weight (CW): After the definition of coefficients, it will be devised by a vertical sum VS, and CW is obtained horizontally for each criterion in the following way: $CW_i = \Sigma (Coef_j * VS_i)$.

* Weighted sum value (WSV): $WSV_i = \Sigma (coef_j * CW_j)$.

* $\lambda_{max} = \Sigma (WSV_i / cw_i) / n$.

* Consistency index (CI): $(\lambda_{max} - n) / (n - 1)$.

* Consistency Ratio (CR) : CI / RI, where the RI is a predefined value depends on the number of criteria.

CR calculation gives an idea of the consistency of the calculation metrics in which a value less than 10 % is considered a reasonable consistency. It is ensured during each comparison matrix, includes the next step which is the ranking of causes for each indicator criteria.

<figure><img src="image_3.png" /><figcaption>Figure 2. AHP layers</figcaption></figure>

Fig. 2 represents the architecture of AHP in the case of this approach, where runtime indicators are placed as criteria for the selection of potential causes in order of importance. Coefficient choices of decisions are made on the basis of experts human judgment, which gives importance coefficients as patterns of recognition and detection of potential causes. This human judgment, however, will have as support, a log analysis, able to study mathematically curves of frequency and the level of impact of the detected causes.

# 4 Implementation

This section treats the implementation of the global framework of Fig. 1, from files of all sources, up to the classification of the potential causes by weights obtained using AHP.
<table><caption>**Table 1.** Set of Messaging Interoperability Requirements - AHP results</caption><thead><tr><th rowspan="2">Requirement</th><th rowspan="2">System Retention qualification</th><th rowspan="2">interoperability Problems</th><th colspan="2">Reportin Indicators</th><th rowspan="2">Reporting indicators</th><th colspan="2">Potential Cause(s)</th></tr><tr><th>Description</th><th>AHP weight</th><th>Description</th><th>AHP weight</th></tr></thead><tbody><tr><td rowspan="6">-"Partners have the necessary authorizations to carry out the exchanges"</td><td rowspan="6">Strong</td><td rowspan="6">Missing permission to exchange data</td><td>-Authentication status</td><td>0.30934</td><td rowspan="6">-Authentication failure rate<br/>-Disconnection rate<br/>-Permissions change rate</td><td>-Deleted / nonexistent user</td><td>0.073088</td></tr><tr><td>-User presence / user information</td><td>0.33646</td><td>-Vhost deleted</td><td>0.056137</td></tr><tr><td>-Connection status</td><td>0.05769</td><td>-User not allowed to access</td><td>0.151300</td></tr><tr><td>-Channel status</td><td>0.06666</td><td>-Limited permissions in Vhost</td><td>0.109388</td></tr><tr><td>-Presences of access permission</td><td>0.10322</td><td>-Not communicated permissions update</td><td>0.126665</td></tr><tr><td>-Permissions status related to the Vhost</td><td>0.12663</td><td>-Not communicated credentials update</td><td>0.138059</td></tr><tr><td rowspan="6">-"The quantity of data received is equal to the quantity of data required"</td><td rowspan="6">Medium</td><td rowspan="6">Consumption Stopped</td><td>-Consumer process presence</td><td>0.48689</td><td rowspan="6">-Lost messages rate<br/>-Rejected messages rate<br/>-Not routed messages rate</td><td>-Connection closed</td><td>0.123456</td></tr><tr><td>-State of the connection linked to the consumer</td><td>0.08246</td><td>-Authentication failed</td><td>0.146151</td></tr><tr><td>-State of the channel linked to the consumer</td><td>0.07836</td><td>-Error in publishing or consuming properties attribution</td><td>0.075665</td></tr><tr><td>-Information about the last message consumed</td><td>0.13022</td><td>-Consumer offline / crashed / under maintenance</td><td>0.4919131</td></tr><tr><td>-Messages Accumulation in concerned queue</td><td>0.22207</td><td>-Problems of missing permission to exchange data</td><td>0.278667</td></tr><tr><td></td><td></td><td></td><td></td><td></td><td>-Inadequate value the basicQos method</td><td>0.171861</td></tr><tr><td></td><td></td><td></td><td></td><td></td><td>-Round-robin effect disabled</td><td>0.130341</td></tr></tbody></table>

<table><caption>**Table 2.** Source of requirements</caption><thead><tr><th>Class</th><th>Layer</th><th>Mallek et al. 2012 IR</th><th>Leal et al 2019 IR</th><th>Messaging IR</th></tr></thead><tbody><tr><td rowspan="6">Compatibility</td><td>Conceptual</td><td>"Exchanged data is formalized and unambiguous"</td><td></td><td>-</td></tr><tr><td rowspan="2">Technological</td><td>-</td><td>"Data storage devices shall be connectable and simple electronic exchange shall be possible"</td><td>-</td></tr><tr><td>-</td><td>"Direct database exchanges capability and full data conversion tool".</td><td>-</td></tr><tr><td rowspan="3">Organizational</td><td>"Partners have the required permissions to carry out data exchanges"</td><td>"Responsibilities and authorities shall be defined and in place"</td><td>-</td></tr><tr><td>"Partners provide permissions for data updates"</td><td>-</td><td>-</td></tr><tr><td>"Confidential data is secured"</td><td>-</td><td>-</td></tr><tr><td rowspan="6">Performance</td><td rowspan="3">Conceptual</td><td>"Received data are conform with those required"</td><td>-</td><td>-</td></tr><tr><td>"The quantity of data received is equal to the quantity of data required"</td><td>-</td><td>-</td></tr><tr><td>"Effective exploitation time of data is less or equal to defined exploitation time"</td><td>-</td><td>-</td></tr><tr><td rowspan="3">Technological</td><td>-</td><td>"Received data must be acknowledged"</td><td>-</td></tr><tr><td>-</td><td>"Important data exchanged must be persisted"</td><td>-</td></tr><tr><td>-</td><td>"Partners have an acceptable exchange debit"</td><td>-</td></tr><tr><td rowspan="3">Organizational</td><td>"Data is exchanged among partners"</td><td>-</td><td>-</td></tr><tr><td>"Exchanged data is available"</td><td>-</td><td>-</td></tr><tr><td>"The exchanged data is only accessible by authorized entities"</td><td>-</td><td>-</td></tr></tbody></table>

## 4.1 Moose Technologie

Moose represents a Smalltalk based platform for data analysis, which gives it its strength is its open space for analysts to control and manage their data flow according to their own vision and analysis. Programming relies on one of these platform strengths; the Pharo language, simple and powerful, elegant with a syntax that can be summed up in a few keywords, helps to achieve results with fewer lines of code.

The development of importers consists in providing a mechanism of population and instantiation of the messaging meta-model, employing an internal parser. These data, once imported, will be stored in instances of the messaging meta-model. It will be easily navigable in the Moose panel. We implemented all the different types of data analysis in Moose, such as queries, visualization, and messaging indicators.
<table><caption>**Table 3.** characteristics description of messaging indicators</caption><tr><td>Data exchanges analysis</td><td>Function: INF</td></tr><tr><td>RMQ-AMQP</td><td>Decision center: Operational</td></tr><tr><td>MOOSE PLATFORM</td><td>Utility: Runtime</td></tr><tr><td></td><td>Exploit Horizon-Period: Hours</td></tr><tr><td>Indicator</td><td>Presence of the queues related to a consumer</td></tr><tr><td>Keyword</td><td>PQC</td></tr><tr><td>Goal</td><td>Traces of a consumer client</td></tr><tr><td>Origin</td><td>File trace: RMQ trace plugging</td></tr><tr><td>Nature/Unity</td><td>Set of PulseQueues</td></tr><tr><td>Coverage</td><td>Consumer</td></tr><tr><td>Influence on other indicators</td><td>Number of existing resources</td></tr><tr><td>Exploit</td><td>Using the message: "QueuesConsumer:"</td></tr><tr><td>Change's nature</td><td>Expires</td></tr><tr><td>Change's frequency</td><td>Hours</td></tr><tr><td>Parameters</td><td>Consumer Name</td></tr></table>

## 4.2 Metamodel implementation

According to moose documentation<fnref n="4" />, FAMIX is a family of meta-models, exploiting a rich API for queries and navigation. The generation of the messaging metamodel according to the current generation of Famix steps consist, in a first action, the creation of a FamixMetamodelGenerator subclass. Then, according to the class-side, the implementation of methods #PackageName which corresponds to the package chosen for the generation of the metamodel and #prefix for the common prefix of generated classes. Then, it comes the phase of defining the messaging metamodel. A Domain Specific Language is used with a performant way to describe those elements.

## 4.3 Indicators

The implementation of indicators is done in the same framework by interrogating the metamodel in the Moose platform. Table 3 show a runtime indicator implemented. This table summarises the interest and all features

* period of Exploitation: the duration/period over which the information remains significant.

* Function: two types of functions are assigned, INF for all that concern notifications and alerts, or STA for long-term decisions, an indicator can have both functions.

* Decision center: depends on the type of information extracted by the indicator, which is related to an aspect of security, operational, stability, or performance.

* Origin: the origin trace file.

* Coverage: the different levels on which the indicator can be obtained.

* Change's nature: depends on the behavior of the indicator, is it examined with a one-shot way as an isolated indicator, its value expires after a period, or the information desired is in continuous change.

* Change's frequency: related to the nature of change, in which an isolated indicator has an empty field and corresponds to the frequency of data recording to be collected for reporting indicators.

## 4.4 AHP layers

The implementation of AHP layers, which is, the tuples problems indicators and potential causes are implemented using the software Super decisions<fnref n="5" /> developed by the team of AHP creator [16]. The Software facilitates the computation, and gives an easy interface for coefficient choices of all elements, and helps to keep the CR reasonable.

# 5 Application : decision-making and intervention improvement

In this section, we present the interest of the approach for the improvement of the intervention in the case of dysfunctions. Table 1 represents solid support able to draw the perimeter of potential causes of interoperability problems. This helps decision making to maintain or improve interoperability.

We illustrate the problem of stopped consumption during an exchange. An administrator will check the list of determined runtime indicators Table 1, with an order of importance related to the problem specified by experts Fig. 3, in conjunction with potential causes seen as patterns of dysfunction.

<figure><img src="image_4.png" /><figcaption>**Figure 3.** Indicators order</figcaption></figure>

The administrator should rely on the importance of indicators Table 1 to be checked using Moose, and a set of potential causes classified for a given problem (Fig. 4).

It should be noted that the message routing problem and incompatibility of AMQP versions between partners can also stop the consuming process. These causes are not mentioned in the guide because BI-MOM, besides providing the traceability layer, ensures the communication between applications by eliminating this type of problems.

The existing interoperability assessment approaches, generally propose qualitative and quantitative measures that serve only to classify a given entity concerning its degree of interoperability. Our work suggests messaging indicators as a set of technical measures. The latter give a pragmatic and

<footnote n="4">⁴moosetechnology.org</footnote>

<footnote n="5">⁵https://www.superdecisions.com/</footnote>
<figure><img src="image_5.png" /><figcaption>Figure 4. Potential causes order</figcaption></figure>

practical view of the satisfaction of the interoperability requirements and provides this way an indication of the level of interoperability.

## 6 Conclusion and perspectives

The interoperability assessment represents a large part of the proposed articles in the interoperability domain. The authors specify the calculation and classification metrics of a given entity, at a maturity level, or calculate the degree of interoperability, by analyzing the system from a global view. However, the need is related to the detection of causes behind interoperability problems. This work consists of analyzing data interoperability assured by Berger-levrault for communicating applications via BL-MOM API, based on the RabbitMQ broker and the AMQP protocol. The monitoring according to different data sources presents a challenge due to the complexity of detecting the dysfunction area for fast intervention. For this reason, patterns of dysfunction must be implemented to detect the problem instead of getting lost between different log files.

The intervention is led by an AHP implementation. Admittedly, the choice of coefficients is based today on experts human judgment. The work for the next stage is related to the mathematical study of frequency and the impact of potential causes of failures. AHP will be based this time, for the choice of coefficients, on a mathematical study as support. Also, a switch to Fuzzy AHP will give more precision by changing coefficients to vectors named Fuzzy numbers.

One of these work perspectives will be the validation of the proposed framework using a global case study of all these aspects. Besides, The condition monitoring part which relies on the collection of a large dataset related to the reporting type of indicators, measured from a normal state until a fall or a fatal dysfunction. These measures will be used as training data for a machine learning model capable of defining real-time alert thresholds and maintenance predictive of falls. The implementation will require the use of the Voyage tool in the Moose platform for database connection and persistence to accumulate indicators measures.

## References

[1] Nawel Amokrane. 2018. Analysis of Data Exchanges, Contribution to Data Interoperability Assessment. (2018).

[2] D. da Silva Avanzi, A. Foggiatto, V. A. dos Santos, F. Deschamps, and E. de Freitas Rocha Loures. 2017. A framework for interoperability assessment in crisis management. *Journal of Industrial Information Integration* 5 (2017), 26–38. https://doi.org/10.1016/j.jii.2017.02.004

[3] Mamadou Samba Camara, Yves Ducq, and Rémy Dupas. 2014. A methodology for the evaluation of interoperability improvements in inter-enterprises collaboration based on causal performance measurement models. *International Journal of Computer Integrated Manufacturing* (2014). https://doi.org/10.1080/0951192X.2013.800235

[4] David Chen, Guy Doumeingts, and François Vernadat. 2008. Architectures for enterprise integration and interoperability: Past, present and future. *Computers in Industry* 59, 7 (2008), 647–659. https://doi.org/10.1016/j.compind.2007.12.016

[5] Marcello Cinque, Domenico Cotroneo, Raffaele Della Corte, Student Member, and Antonio Pecchia. 2016. A Method to Benchmark Direct Monitoring Techniques in Software Systems. (2016), 1–16.

[6] Marcello Cinque, Domenico Cotroneo, Raffaele Della Corte, and Antonio Pecchia. 2019. A framework for on-line timing error detection in software systems. *Future Generation Computer Systems* 90 (2019), 521–538. https://doi.org/10.1016/j.future.2018.08.025

[7] S.M.S. da Cruz, M.L.M. Campos, P.F. Pires, and L.M. Campos. 2004. Monitoring e-business Web services usage through a log based architecture. (2004), 61–69. https://doi.org/10.1109/icws.2004.1314724

[8] Nicolas Daclin, David Chen, and Bruno Vallespir. 2016. Developing enterprise collaboration: a methodology to implement and improve interoperability. *Enterprise Information Systems* (2016). https://doi.org/10.1080/17517575.2014.932013

[9] N. Daclin, S. Mallek Daclin, V. Chapurlat, and B. Vallespir. 2016. Writing and verifying interoperability requirements: Application to collaborative processes. *Computers in Industry* 82 (2016), 1–18. https://doi.org/10.1016/j.compind.2016.04.001

[10] Wided Guédria, Yannick Naudet, and David Chen. 2015. Maturity model for enterprise interoperability. *Enterprise Information Systems* 9, 1 (2015), 1–28. https://doi.org/10.1080/17517575.2013.805246

[11] Ching-Lai Hwang and Abu Syed Md. Masud. 1979. Multiple Objective Decision Making — Methods and Applications. 164 (1979). https://doi.org/10.1007/978-3-642-45511-7

[12] António Leal, Fátima Oliveira, and Purificação Silvano. 2018. Path scales: Directed-motion verbs, prepositions and telicity in European Portuguese. *Studies in Language Companion Series* 197, 1 (2018), 335–355. https://doi.org/10.1075/slcs.197.15rod

[13] Sihem Malek. 2012. *Contribution au développement de l'interopérabilité en entreprise : vers une approche anticipative de détection de problèmes d'interopérabilité dans des processus collaboratifs*. Ph.D. Dissertation.

[14] Reza Rezaei, Thiam Kian Chiew, Sai Peck Lee, and Zeinab Shams Aliee. 2014. Interoperability evaluation models: A systematic review. *Computers in Industry* 65, 1 (2014), 1–23.

[15] Thomas Rings, Patrick Poglitsch, Stephan Schulz, Luca Serazio, and Theofanis Vassiliou-Gioles. 2014. A generic interoperability testing framework and a systematic development process for automated interoperability testing. *International Journal on Software Tools for Technology Transfer* 16, 3 (2014), 295–313. https://doi.org/10.1007/s10009-013-0281-2

[16] Thomas L. Saaty. 2006. Decision making — the Analytic Hierarchy and Network Processes (AHP/ANP). *Journal of Systems Science and Systems Engineering* 13, 1 (2006), 1–35. https://doi.org/10.1007/s11518-006-0151-5

[17] Maicon Saturno, Luiz Felipe Pierin Ramos, Fabrício Polato, Fernando Deschamps, and Eduardo de Freitas Rocha Loures. 2017. Evaluation of Interoperability between Automation Systems using Multi-criteria Methods. *Procedia Manufacturing* (2017). https://doi.org/10.1016/j.promfg.2017.07.321

[18] Gabriel DA SILVA SERAPIÃO. 2019. Decision Support for Interoperability Readiness in Networked Enterprises. *Free Radical Biology & Medicine* 52 (2019), 1075–1085.