Pattern Sections
Pattern: Backend Integration
a.k.a. Horizontal Integration, Backend-to-Backend Integration, Remote Component API, East-West Connectivity
Context
An enterprise-level architectural decision has been made to organize a system landscape (ecosystem) into multiple distributed systems and/or services. These systems and/or services have to communicate to realize end-to-end use cases, user stories, and/or job stories.
Due to the physical separation, it is not possible to let the involved system backends call each other via local, programming language- or operating system-internal APIs; remoting is required. Message-based remoting is generally preferred over remote object technology today (Hohpe and Woolf (2003)).
Problem
How can distributed applications and their parts, which have been built independently and are deployed separately, exchange data and trigger mutual activity while preserving system-internal conceptual integrity without introducing undesired coupling?
How can microservices and/or other distributed system parts communicate with each other?
Forces
Important high-level forces and quality attributes in/of backend-to-backend integration include:
- Runtime qualities such as performance and scalability
- Security
- Interoperability
- Development budgets
- Development culture and company politics
Pattern forces are explained in depth in the book.
Solution
Integrate the backend of a distributed application with one or more other backends (of the same or other distributed applications) by exposing its services via a message-based remote Backend Integration API.
Sketch
A solution sketch for this pattern from pre-book times is:
Example
In our insurance case study called Lakeside Mutual, the interface between the customer self service backend (that contains the server-side logic for one particular frontend application) and the customer core (micro-)service (that concentrates customer master data across applications) are examples of this pattern:1
The microservices in the backend communicate via HTTP resource APIs
and message queues; some of them exchange domain events. An example of a
queue-based Backend Integration API
is the policy update messaging between the
RiskManagementMessageProducer in the Policy Management
backend and the Risk
Management Server that uses ActiveMQ.
Are you missing implementation hints? Our papers publications provide them (for selected patterns).
Consequences
The resolution of pattern forces and other consequences are discussed in our book.
Known Uses
Known uses for this pattern are ubiquitous; for instance, business information systems (a.k.a. enterprise applications) often are integrated this way. In fact, an entire market of integration products and related consulting services exists: Enterprise Application Integration (EAI).
A major Swiss bank distinguishes its frontend APIs from its backend APIs (see IEEE Software/InfoQ article “Fifteen Years of Service-Oriented Architecture at Credit Suisse” Murer and Hagen (2014) as well as “Managed Evolution” Murer, Bonati, and Furrer (2010).
The Open Service Broker API allows cloud service providers to integrate their offerings into cloud platforms.
More Information
Related Patterns
This pattern has one sibling Frontend Integration; other patterns in this category deal with API visibility (Public API, Community API, Solution-Internal API).
The Data Access Component pattern and the Provider Adapter pattern in Fehling et al. (2014) make the need for Backend Integration APIs evident: the same holds for all patterns in the cloud integration category in the same book.
Other Sources
MDSL has pattern “Decorators” for this and other patterns.
References
Lakeside Mutual is a fictitious insurance company invented by the authors comprising several microservices to demonstrate the patterns in action.↩︎