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.
TopIntroduction
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.