Article Preview
TopIntroduction
Whenever two or more applications need to interact, interoperability and coupling problems arise. Historically, interoperability has been the main goal in Web-based distributed systems, whereas coupling has been one of the top concerns in software engineering, when developing an application, along with other metrics such as cohesion (Saxena & Kumar, 2012).
Software development methods emphasize decoupling, changeability and agility, which means structuring modules of an application so that a change somewhere affects as little as possible the remaining modules and can be implemented in a very short time. Interoperability between modules of an application is the easy part. Type names and inheritance are shared and there is usually a single programming language.
The interaction between distributed applications is completely different. Interoperability is hard, since these applications are independently developed, compiled, and linked. Most likely, this means different type names, inheritance hierarchies, programming languages, execution platforms, and data formats. In this context, coupling is of paramount importance, but has been treated as a side issue, a best-effort endeavor after achieving the primary objective, interoperability.
Interoperability and coupling are two facets of the same problem, application integration, and unfortunately reflect two conflicting goals:
- •
Interoperability: Applications need to interact to accomplish collaboration. This necessarily entails some form of mutual knowledge and understanding, but it creates dependencies that may hamper the evolution (changes) of these applications.
- •
Decoupling: Applications should not have dependencies on others, in order to be able to evolve freely and dynamically. Unfortunately, independent applications do not understand each other and are not able to interact, which means that some form of coupling is unavoidable.
Therefore, the fundamental problem of integration is to provide (at most) the minimum coupling possible while ensuring (at least) the minimum interoperability requirements. In other words, 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 integration approaches, Software-Oriented Architecture (SOA) (Erl, 2016) and Representational State Transfer (REST) (Pautasso, Wilde, & Alarcon, 2014) hardly comply with the principle of least knowledge. They achieve interoperability, but do not solve the coupling problem, since they require sharing of the data schemas.
In addition, they lie at the extremes of the axis of modeling principle: SOA is guided by behavior (services), whereas REST is guided by state (resources). SOA defines which application types are used and establishes the set of operations provided by each, whereas REST starts with a state diagram, without relevant concern about distinguishing which state belongs to which application.
SOA has the goal of a low semantic gap, since it models real-world entities by services that express their capabilities. This is good in modeling terms, but entails a coupling between the provider and the consumer that hampers dynamic changeability and adaptability. If the provider’s interface changes, the consumer’s interface also needs to change in accordance. There is no apparent structure, since service composition is hidden behind each service interface.
One of the main goals of REST is to reduce the coupling between provider and consumer, both to increase scalability and adaptability. Real-world entities are modeled in a data-oriented manner by resources, all with the same syntactical interface (same set of operations). Semantics are restricted to a set of data types (or schemas), either standardized or previously agreed upon between the interacting entities. The variability of the characteristics of entities is modeled by visible structure (resources composed of other resources) and the semantics of the agreed data types.