- 3.1 Making Design Decisions
- 3.2 Design Concepts: The Building Blocks for Creating Structures
- 3.3 Design Concepts to Support Performance
- 3.4 Design Concepts to Support Availability
- 3.5 Design Concepts to Support Modifiability
- 3.6 Design Concepts to Support Security
- 3.7 Design Concepts to Support Integrability
- 3.8 Summary
- 3.9 Further Reading
- 3.10 Discussion Questions
This chapter is from the book
This chapter is from the book
This chapter is from the book
3.7 Design Concepts to Support Integrability
Software architects need to be concerned about more than just making separately developed components cooperate: They must also consider the costs and technical risks of integration tasks. These risks may be related to schedule, performance, or technology. Consider that a project needs to integrate a set of components C1, C2, . . . , Cn into a system S. The task, then, is to design for, and analyze the costs and technical risks of, integrating additional, but not yet specified, components {Cn + 1, . . . , Cm}. We assume we have control over S, but the development of the unspecified {Ci} components may be outside our control.
Integration difficulty—the costs and the technical risks—can be thought of as a function of the size of and the “distance” between the interfaces of {Ci} and S: Size is the number of potential dependencies between {Ci} and S, and distance is the difficulty of resolving differences in each of the dependencies. Distance may be any of the following: syntactic distance, data semantic distance, behavioral semantic distance, temporal distance, or even resource distance. Although we may not capture size and distance as precise metrics, this understanding creates a frame of reference for thinking about integrability.
3.7.1 Integrability Tactics
The goals for the integrability tactics are to reduce the costs and risks of adding new components, reintegrating changed components, and integrating sets of components to fulfill evolutionary requirements. These tactics help to reduce size and distance attributes.
There are three categories of integrability tactics: Limit Dependencies, Adapt, and Coordinate, as shown in Figure 3.9.
)
FIGURE 3.9 Integrability tactics categorization
The first category, Limit Dependencies, may remind you of the Reduce Coupling category of modifiability tactics. This is not surprising because limiting dependencies can be achieved, in large part, by reducing coupling. Within the Limit Dependencies category, the tactics are:
Encapsulate. Encapsulation introduces an explicit interface to an element and ensures that all access to the element passes through this interface. Dependencies on the element internals are eliminated, because all dependencies must flow through the interface.
Use an intermediary. Intermediaries are used for breaking dependencies between a set of components Ci or between Ci and the system S. Intermediaries can be used to resolve different types of dependencies (e.g., syntactic, behavior, data semantic).
Restrict communication paths. This tactic restricts the set of elements with which a given element can communicate. In practice, this tactic is implemented by restricting an element’s visibility (when developers cannot see an interface, they cannot employ it) and by authorization (i.e., restricting access to only authorized elements).
Adhere to standards. Standardization in system implementations is a primary enabler of integrability and interoperability, across both platforms and vendors. Some standards focus on defining syntax and data semantics. Others include richer descriptions, such as those describing protocols that include behavioral and temporal semantics.
Abstract common services. Where multiple elements provide services that are similar, it may be useful to hide them behind a common abstraction. This abstraction might be realized as a common interface implemented by them all, or it might involve an intermediary that translates requests for the abstract service to more specific requests. The resulting encapsulation hides the details of the elements from other components in the system.
Within the Adapt category, the tactics are:
Discover. A discovery service is the mechanism by which applications and services locate each other. Entries in a discovery service are there because they were registered. This registration can happen statically, or it can happen dynamically when a service is instantiated.
Tailor interface. Tailoring an interface is a tactic that adds capabilities to, or hides capabilities in, an existing interface without changing the API or implementation. Capabilities such as translation, buffering, and data smoothing can be added to an interface without changing it.
Configure behavior. The behavior of a component can be configured during the build phase (recompile with a different flag), during system initialization (read a configuration file or fetch data from a database), or during runtime (specify a protocol version as part of your requests).
Finally, within the Coordinate category, the tactics are:
Orchestrate. This tactic uses a control mechanism to coordinate and manage the invocation of services so that they can remain unaware of each other. Orchestration helps with the integration of a set of loosely coupled reusable services to create a system that meets a new need.
Choreograph. Choreography is an alternative control mechanism in which a process is implemented as steps in a flow, each triggered by an event message upon completion of the previous step and unaware of the other steps in the flow. This results in composable, loosely coupled services without an orchestrator. Orchestration is centralized, whereas choreography is distributed.
Manage resources. A resource manager is a form of intermediary that governs access to computing resources; it is similar to the restrict communication paths tactic. With this tactic, software components are not allowed to directly access some computing resources (e.g., threads or blocks of memory), but instead request those resources from a manager.
3.7.2 Integrability Patterns
Many patterns exist to support integrability. In this section, we briefly describe just a few of them. The first three are related—adapters, bridges, and mediators.
3.7.2.1 Adapters, Bridges, and Mediators
An adapter is a form of encapsulation whereby some component is encased within an alternative abstraction. An adapter is the only element allowed to use that component; every other piece of software uses the component’s services by going through the adapter. The adapter transforms the data or control information for the component it wraps.
A bridge translates some “requires” assumptions of one arbitrary component to some “provides” assumptions of another component. The key difference between a bridge and an adapter is that a bridge is independent of any particular component. Also, the bridge must be explicitly invoked by some external agent—possibly, but not necessarily, by one of the components the bridge spans.
Mediators exhibit properties of both bridges and adapters. The major distinction between bridges and mediators is that mediators incorporate a planning function that results in runtime determination of the translation, whereas bridges establish this translation at bridge construction time.
All three of these patterns allow access to an element without forcing a change to the element or its interface. But these benefits, of course, come at a cost. Creating any of these patterns requires up-front development work. Moreover, all of the patterns introduce some performance overhead while accessing the element, although typically this overhead is small.
As a side note, a fourth pattern with a similar intent is Facade. We will discuss an example of the Facade pattern in Chapter 5, where it is instantiated as an API gateway.
3.7.2.2 Services
Another pattern often used to ease integrability concerns is services. A service (whether “micro” or not) is an independent decoupled software component that can be developed, deployed, and scaled independently. The Services pattern describes a collection of distributed components that provide and consume services. Components have interfaces that describe the services that they request and that they provide. A service’s quality attributes can be specified and guaranteed with a service level agreement (SLA). Components perform their computations by requesting services from one another.
The benefits of the Services pattern are that services are designed to be used by a variety of clients, leading them to be more generic. Also, services are independent: The only method for accessing a service is through its interface and through asynchronous messages over a network. This means that services typically have loose coupling with other services and with their environment. Finally, services can be implemented heterogeneously, using whatever languages and technologies are most appropriate.
However, service-based architectures, because of their heterogeneity and distinct ownership, come with many interoperability mechanisms such as Web Services Description Language (WSDL) and Simple Object Access Protocol (SOAP). This adds some up-front complexity and overhead. (We will discuss APIs and API-centric design in Chapter 5.)
3.7.2.3 Dynamic Discovery
Dynamic discovery applies the discover tactic to support finding service providers at runtime. A dynamic discovery capability sets the expectation that the system will advertise the services available for integration and the information that will be available for each service.
The main benefit of this pattern is that it allows for flexibility in binding services together into a cooperating whole. For example, services may be chosen at startup or dynamically at runtime based on their pricing or availability or other properties. The cost of this flexibility is that dynamic discovery registration and de-registration must be automated, and tools for this purpose must be acquired or generated.