Improving the Integration of Distributed Applications

Improving the Integration of Distributed Applications

José Carlos Martins Delgado
Copyright: © 2021 |Pages: 16
DOI: 10.4018/978-1-7998-3479-3.ch017
(Individual Chapters)
No Current Special Offers


The interaction of distributed applications raises an integration problem that needs to be solved. 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. The fundamental problem of application integration is therefore how to provide at most the minimum coupling possible while ensuring at least the minimum interoperability requirements. This article proposes compliance and conformance as the concepts to achieve this goal, by sharing only the subset of the features of the data schema that are actually used.
Chapter Preview


Complex software systems typically involve many interacting applications, with many decisions to take and many tradeoffs to evaluate, not only in each application but also in the ways in which the various applications interact. Ideally, applications should be completely decoupled, with no constraints on one another and completely independent lifecycles. This would allow separate development of each application and elimination of design and programming inefficiencies due to interaction between the specifications of applications, which usually cause iterations in requirements for other applications and consequent changes.

However, applications do need to interact and to cooperate, to collectively fulfill the goals of the system. Therefore, a fundamental tenet in software design is to reduce application coupling as much as possible (Bidve, & Sarasu, 2016) without hindering the interaction capabilities necessary to support the required application interoperability. Application decoupling has also the advantage of improving:

  • § Changeability: A change in one application is less likely to have a significant impact in other applications.

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

  • § Reusability: An application with fewer requirements and constraints has an increased applicability range.

  • § Reliability: A smaller set of requirements simplifies the task of finding an alternative application in case of failure.

In general, the fundamental problem of application design, in terms of interaction, is how to provide (at most) the minimum coupling possible while ensuring (at least) the minimum interoperability requirements. Therefore, the main goal is to ensure that each interacting application knows just enough about the others to be able to interoperate with them but no more than that, to avoid unnecessary dependencies and constraints. This is an instance of the principle of least knowledge (Hendricksen, 2014).

The two most used application integration approaches, Service-Oriented Architecture (SOA) (Erl, Merson, & Stoffers, 2017) and Representational State Transfer (REST) (Fielding, Taylor, Erenkrantz, Gorlick, Whitehead, Khare, & Oreizy, 2017) hardly comply with the principle of least knowledge. They achieve interoperability but do not solve the coupling problem, since they require, in practice, that the schemas used by the interacting applications are the same.

SOA is good at modeling distributed systems based on the service paradigm (an extension the object-oriented paradigm for distributed applications) but involves rather complex and static service specifications and entails sharing schemas between client and server, which is a heavy form of coupling. Changing the interaction between Web Services is not a trivial task. REST is much simpler, justifying its increasing popularity, but is rather low level and not the best match for general-purpose, behavior-oriented distributed applications. It also entails a high level of coupling, since it requires that both interacting applications share the same media type specification.

This article revisits the application integration problem with an open mind, without a priori restrictions from specific technologies, such as Web Services for SOA and RESTful APIs for REST. The only assumption is that there are applications that need to interact, by using messages. The idea is to base the interoperability mechanism on the concepts of compliance (Czepa, Tran, Zdun, Kim, Weiss, & Ruhsam, 2017) and conformance (Carmona, van Dongen, Solti, & Weidlich, 2018), which allow partial interoperability, rather than on sharing data schemas. This makes all the difference. Unlike Web Services, there are no declared schemas that a client is forced to use in their entirety. Unlike RESTful applications, the client and server do not have to agree on a specific data type. Each resource (dataset, message or distributed application) has its own schema, stemming from its service (interface) definition. Checking for interoperability between two resources (for example, between a message and the parameter required by an operation) is done structurally, component by component, recursively until primitive resources are found.

Key Terms in this Chapter

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

Server: A role performed by a resource S in an interaction with another C , which involves waiting for a request from C , honoring it and typically sending a response back to C .

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

Resource: The computer-based implementation of a service.

Client: A role performed by a resource C in an interaction with another S , which involves making a request to S and typically waiting for a response.

Conformance: Asymmetric property between two servers, S 1 and S 2 ( S 1 conforms to S 2 ) that indicates that S 1 fulfills all the expectations of all the clients of S 2 in terms of the effects caused by its requests, which means that S 2 can replace S 1 .

Interoperability: Asymmetric property between a client C and a server S that holds if C is compliant with the set of requests allowed by S and S is conformant with the set of responses expected by C .

Complete Chapter List

Search this Book: