Structural Data Binding for Agile Changeability in Distributed Application Integration

Structural Data Binding for Agile Changeability in Distributed Application Integration

José Carlos Martins Delgado (Instituto Superior Técnico, Universidade de Lisboa, Portugal)
Copyright: © 2020 |Pages: 31
DOI: 10.4018/978-1-7998-2531-9.ch003

Abstract

The interaction of distributed applications raises an integration problem that consists in how to satisfy the minimum interoperability requirements while reducing coupling as much as possible. Current integration technologies, such as Web Services and RESTful APIs, solve the interoperability problem but usually entail more coupling than required by the interacting applications. This is caused by sharing data schemas between applications, even if not all features of those schemas are actually exercised. This has its toll in application development agility. This chapter proposes compliance and conformance as the concepts to minimize coupling without impairing interoperability by sharing only the subset of the features of the data schema that are actually used. In addition, data binding between messages and the receiver's schema is done structurally in a universal and application-independent way. This eliminates the need for application-specific stubs and allows clients to use any server with which they comply and servers to replace any server to which they conform.
Chapter Preview
Top

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.

Key Terms in this Chapter

Service: The set of operations supported by an application that together define its behavior (the set of reactions to messages that the application is able to receive and process).

Interoperability: Asymmetric property between a consumer C and a provider P ( C is compatible with P ) that holds if C is compliant with P .

Compliance: Asymmetric property between a consumer C and a provider P ( C is compliant with P ) that indicates that C satisfies all the requirements of P in terms of accepting requests.

Agility: The ability to adapt (reactively and/or proactively) an application to changes in its interoperability requirements with other applications, in a timely and cost-efficient manner.

Consumer: A service role performed by an application A in an interaction with another B , which involves making a request to B and typically waiting for a response.

Conformance: Asymmetric property between a provider P and a consumer C ( P conforms to C ) that indicates that P fulfills all the expectations of C in terms of the effects caused by its requests.

Complete Chapter List

Search this Book:
Reset