. This paper aims at proposing a global view of the interoperability problem, independently of any domain. We first describe explicitly the problem, and the context in which it appears. We then suggest a general structure to handle the possible solutions. Finally, we propose some possible application of our model. Keywords: Interoperability, systemic modeling, model, abstraction level, decision-aid.
Last year, in the context of the network of excellence INTEROP [
Starting with these statements, we shall propose an updated definition, as well as
associated models and meta-models. All diagrams are written in the Unified Modeling
Language [
We propose in this section an enhanced definition of interoperability, and identify the particular points that necessitate a more formal model. The definition we propose is the following one: “The interoperability problem appears when two or
more heterogeneous resources are put together”.
In order to discuss this definition in more detail, we first focus on the important meta-models that will describe the aspects of ‘problem’ and ‘resource put together’ identified in the definition. As it is a necessary complement to solve interoperability problems, we also propose a meta-model showing the systemic view of modeling. 1..* 1..* 0..* application condition
Interoperability is obviously a problem. And there may be some solutions that will
solve it. In [
0..* resource interface
0..* objective via
relation structural relation
Interoperability is about resources put together. This part of the definition is
illustrated by the resource composition meta-model in Fig.2. More precisely, the
interoperability problem appears when putting together resources. By resource we
mean tangible things (e.g. a piece of steel), or pseudo-tangible things, i.e., that are
tangible for a specific environment (e.g. a file is tangible from the OS point of view).
The definition of interoperability implies that we consider the relationships that exist
between these resources. Fig.2 identifies two kinds of relations: structural relation,
which is time independent, and behavioral relation, which is time dependent. For
example, a structural relation exists between a plug and an electrical connector. The
fact of calling a Web service in an application represents a behavioral relation. The
concept of relation is a generalization over the communication concept highlighted in
[
Fig. 2 introduces two other important concepts: the objective, and the interface of
the resource. The interface is the ‘physical’ realization of the relation. It allows the
resource to be used or assembled. Often, and particularly in software engineering,
only the interface is considered (port and connector) and seems to be the only focus,
as the concern is to know whether tools will be connectible or not. Usually, the
objective is not considered. However, the objective really plays a major role. It
defines what the resource is useful for. The model in Fig.2 defines an upper
abstraction level from which the architectural model of Software Engineering [
At this stage, we discussed the fact that interoperability is a problem related to
resource in relation. We now need to further discuss the fact that a resource is not
only a tangible thing, but also the result of a building process. Indeed, in the context
of Engineering, a resource is a result of modeling, and is also part of a global system
to build (see [
+metamodel describes model 1..* 1..* 1..* objective resource
In Fig.3, we show the systemic view that describes the relation between resource, system and model. As stated previously, the introduction of these concepts is very important to handle the ‘internal’ structure of the resource, in addition to its interface.
The three meta-models we have presented so far are necessary to define the interoperability problem as an instantiation of these models. Fig. 4 illustrates this instantiation and provides a global view of the interoperability problem.
From this view, two different solutions for the interoperability problem are
considered [
After having presented the structural aspects of our model, we shall describe its dynamic part. This part will particularly focus on questions like: ‘when are the resource heterogeneous?’ or ‘ how to choose between homogenization or bridging?’.
Model (Fig. 1) 1..* solution creates solves 1..* problem homogenization bridging
relation structural relation behavioral relation 0..* 2..n
condition 1..*
In order to establish the heterogeneity of several resources, it is obviously necessary to compare them. At this stage, it is important to note that there cannot be an interoperability problem at the level of objectives as in Fig. 2. The matching of objectives is another problem pertaining to the engineering (the system building) of the concerned domain. So, even if the objectives are key concepts of the resource composition meta-model, they are out of the scope of the Interoperability problem. This one is related to the ‘physical’ matching of the resources. The check of the interfaces is thus the first step to identify heterogeneity. If the interfaces are not compatible (e.g., the diameter of the screw is different from the internal diameter of the nut, or methods signatures of a library are not compatible with the calling program), then heterogeneity is established and an interoperability problem appears when one decides to relate these resources. This first check should be quite simple as the interfaces are normally clearly identified. The second step consists in the ‘internal’ compatibility check between the resources. For instance the diameter of screw and nut can perfectly be compatible, but if the screw is made of plastic and the nut of metal, there might be an interoperability problem, as the assemblage could be really defective. To check this level of interoperability, it is necessary to compare the available models of the resources. Having common syntax and metrics will facilitate this operation. If this is not the case, the interoperability model shown in Fig. 4 should be applied to the resource models themselves. This point will be discussed further in future papers.
After having identified the heterogeneity and the possible interoperability problems that may arise from it, it is necessary to try to solve it. The first important solution criterion is to know if it is possible to modify the resources. If not, then the bridging is the only solution. If the modification is permitted, homogenization is possible. Nevertheless, the modification of a resource is only possible if enough knowledge (in fact, models) is available. If this is not the case, a modeling process should be started. In general, homogenization should be preferred to bridging, as it will ensure a better level of validation of the resulting system with respect to the objectives. The interested reader can find detailed information and examples in [3.]
In this brief paper, we proposed a new version of our interoperability model. The meta-models and the considered abstraction level enabled us to work independently of any specific domain.
The work that we currently perform consists in characterizing well-known software architectures against our interoperability model. This task will be particularly useful to help software architects solving classical interoperability issues in relation with other technical problems such as distribution, persistence, or legacy integration.
Besides this top-down validation and use of our model, its instantiation from the
INTEROP perspectives (enterprise, architecture, platform and ontological aspects)
will also serves as a pragmatic validation. Finally, connecting the models we have
presented to some foundational ontologies (such as the ones presented in [