Technical Integration—Transformation, Adaptation

The goal of bridging technical spaces is to enable the use of tools from one space on data from the other. To achieve this, there are two different possibilities. First, one can transform data present in one space to the physical representation required by the tools in the other space. This approach will be called a transformational bridge. Second, one can adapt existing query language engines or the API used by tools in the target space to access the data of the source space directly. This method will be called an adapter bridge. The difference between the two kinds of bridges is also depicted in Fig. 5.3.

Adapter bridges can be used only if tools process data indirectly using an API or query language. If tools access data directly (e.g., by reading files from a disk), a transformational bridge must be used. Both styles of bridges have their pros and cons. To clarify which style is best to be used in which situation, we will investigate both kinds of bridges in more detail.

In [154], bridges are distinguished into extractors and injectors. The latter create models from software artifacts, while the former realize the opposite. Also, the term projector is used in [154] to denote both extractors and injectors. This differentiation is orthogonal to transformation and adaptation. It depends on the target space of a bridge rather than its technical realization.

5.1 Technical Spaces - Definitions and Properties

Technical Space B (Target)

Language Query Languages, APIs Tools Data use conforms to process Technical Space A (Source)

Language Query Languages, APIs Tools Data use conforms to

process _{access access}

Transformation

Figure 5.3: Transformation vs. adaptation to bridge two technical spaces.

Integration by Transformation

When integrating tools that employ different data formats, transformations can be used to convert from one format to the other. These transformations take the physical data format of one technical space as input and produce the format of another one as out- put. If bidirectional tool interoperability is aimed for, either multiple transformations or bidirectional ones are needed. As translations are executed monolithically, a batch-like processing of data is inevitable. Tools must be executed strictly in sequential order, where transformations may be placed between the execution of tools or tool runs.

One drawback of the transformational approach is the need to serialize (save) and deserialize (load) data whenever switching to another technical space is necessary. This can become a serious bottleneck if switching spaces is required often or if large amounts of data need to be transformed.

Furthermore, transformational approaches must deal with the concrete syntax of all involved artifacts. If there exist formal specifications of these syntactic representations, one can use dedicated tools (e.g., parser generators) to read and persist artifacts. If the knowledge about the concrete syntax is hidden (e.g., only the artifact-specific tools implement the functionality to access files), this can become a serious problem. In this case, the concrete syntax needs to be reverse engineered, which usually requires a large amount of work.

Integration by Adaptation

When using transformations to bridge technical spaces, each tool (or group of tools) uses its own physical representation of the information to be processed. To avoid such physical replication of data, an alternative solution is to implement an adapter that translates data instantly by forwarding data requests to a different data repository. Here, tools from the target space access the data of the source space using an API. Instead of replicating data, the data is directly presented to tools in the required form. In other words, the data repository interface is adapted to a repository of a different technical space.

5 Bridging Technical Spaces

Transformational Bridges Adapter Bridges

⊕ feasible if tools access data directly restricted to tools that use an API replication of data ⊕ no replication of data

monolithic translation ⊕ incremental translation sequential use of tools ⊕ concurrent use of tools

Table 5.1: Comparison of transformational vs. adapter bridges.

If tools use an API to access data, one can exchange the implementation of this API with a custom one which adapts the different representation dynamically. In this case, only knowledge about the concrete syntax within one technical space is needed. This can sometimes ease the creation of such an adapter-based bridge.

In addition, data that is accessed using an API can be shared in the sense that multiple APIs can be bound to the same data repository. This avoids the batch-like processing that is characteristic for transformational bridges. Tools from different technical spaces can access data simultaneously if respective adapters exist.

Comparison

When comparing the two styles of bridges that can be used to close the gap between two technical spaces, the drawbacks of one style can often be resolved by the opposite style. Consult Table 5.1 for the differences between the two styles.

While adapter bridges avoid replication, allow for on-the-fly translation and permit the use tools concurrently, they are restricted to applications where the involved tools use an API or query language to retrieve data. In contrast, transformational bridges are not restricted w.r.t. the tools in the target space. However, they force to transform monolithically and to replicate data.

The style to pick for a concrete scenario needs to be selected according to this criteria. If tools in the target space are sufficiently decoupled from the physical representation of data by the use of an API or query language, implementing an adapter bridge is a good choice. The integration of this kind of bridge is more tight than transforming physical data back and forth. If tools are strongly coupled to the physical representation of their data, a transformational bridge is the only option left. Despite of the drawbacks listed in Table 5.1, transformational bridges often perfectly serve their purpose. If there is no need to modify data concurrently and if the transformation of reasonable amounts of data is sufficiently fast, replication may be tolerable.

From a more global point of view, there are parallels between the two types of bridges between technical spaces and the two options to counter redundancy in software devel- opment (cf. Sect. 3.1). Adapter bridges avoid redundancy by tying tools to different data repositories. Transformational bridges create redundancy by representing data dif-