Structural Data Binding for Agile Changeability in Distributed Application Integration

Introduction

Agile software development methods (Hoda et al., 2018) aim to improve productivity in developing complex applications by attempting to better match human programming capabilities and problem requirements. From an application integration point of view (Panetto & Whitman, 2016), agility is defined as the ability to prompt and cost-effectively adapt an application (reactive and / or proactive) to changes in its interoperability requirements with other applications.

A complex software system usually involves many interacting modules, with many compromises to consider and many decisions to make, not only in each module, but also in the way the various modules interact. Object-oriented modeling is a classic paradigm designed to minimize the semantic gap between a problem specification and the software application's architecture. It addresses this issue through close correspondence between entity establishment and the corresponding software models (classes). However, this is not enough.

Ideally, classes should be completely decoupled, without mutual restrictions and completely independent life cycles. This would allow separate development of each class and eliminate inefficiencies in software development and programming due to the interaction between the class specifications, which usually results in iterations of the requirements for other classes and resulting changes. However, the classes must interact and cooperate to work together to achieve the goals of the system. A fundamental principle in agile software design is to reduce class coupling as much as possible (Bidve & Sarasu, 2016) without compromising the interoperability required to support the required class interaction (Queiroz et al., 2018). A weaker coupling means a higher:

• •

  Changeability: A change in one class is less likely to have a significant impact on other classes.

• •

  Adaptability: Fewer constraints require less effort to adapt to changes in other.

• •

  Reusability: A class with fewer requirements and constraints has an extended scope of applicability.

• •

  Reliability (In a Distributed Context): A smaller set of requirements simplifies the search for an alternative application in the event of a failure.

The correct tuning of the decoupling is not an easy task in practice. The basic problem of application design in terms of interaction is to provide (at most) the least possible coupling while ensuring (at least) the minimum requirements for interoperability. This means that the main goal is to ensure that each interacting class knows enough about the others to work with them and avoid unnecessary dependencies and restrictions. This is particularly relevant when agility is one of the main concerns.

Software development methods emphasize decoupling, changeability and agility. This means structuring classes of an application so that implementing a change takes only a short time and other classes are not badly affected. Interoperability between classes of a local application is not a big problem, as classes are implemented in the same programming language. Type names and inheritance are generally shared.

The interaction between distributed applications is completely different. Interoperability is difficult as these applications are developed, compiled and linked independently. This most likely results in different type names, inheritance hierarchies, programming languages, execution platforms, and data formats. The interoperability of current technologies is based on a strict data format alignment (Data Schema Sharing). Although decoupling is of paramount importance, it has been treated as a secondary issue in distributed contexts where best efforts are made after the primary objective of interoperability has been achieved.