Skip to content
Software Architecture Guide

Integration Styles

Explanation

Section titled “Explanation”

Integration means making separate applications work together. Four basic styles exist for this.

File Transfer. Each application writes files containing data that others need. It also reads files that other applications wrote. Producer and consumer must agree on the file name, the location and the file format.

Shared Database. Applications keep the data they want to share in one common database. They all use the same schema (the structure of the data) in a single physical database. Because the data is not copied, nothing has to be transferred between applications.

Remote Procedure Invocation. Each application exposes some of its procedures so other applications can call them remotely. This is real-time and synchronous. The caller is blocked until the called procedure finishes.

Messaging. Each application connects to a common messaging system. Applications exchange data and trigger behavior by sending messages. Messaging works asynchronously. It needs an event-driven programming model, and the messaging system adds some overhead.

All four styles solve essentially the same problem. Each has distinct advantages and disadvantages. So the choice is made for each integration opportunity, not once for the whole landscape.

Related articles: File Transfer, Shared Database, Remote Procedure Call and Messaging.

Example

Section titled “Example”

A shop runs an order system, a warehouse system and a reporting tool.

  • The order system writes a file of new orders for the reporting tool. Both sides agree on file name, folder and layout.
  • The order system needs a stock answer right away. It calls a stock procedure on the warehouse system and waits for the result.
  • The warehouse system announces shipped parcels by sending messages through a common messaging system. Other applications pick them up when they are ready.

The shop uses three styles, each chosen for one integration point.

Trade-offs

Section titled “Trade-offs”
  • File Transfer: producer and consumer must agree on name, location and format.
  • Shared Database: no data is duplicated, so nothing needs transferring.
  • Remote Procedure Invocation: the call is real-time, but the caller is blocked while it runs.
  • Messaging: the exchange is asynchronous, but it needs an event-driven programming model and adds overhead.
  • Bulk data replication: ETL (extract, transform, load) tools are much more efficient than messaging for this job.

No style wins everywhere. Pick the best one for each integration opportunity.

The four basic integration styles between applications

Diagram source 
flowchart TB
  subgraph FT[File Transfer]
    A1[App A] -->|writes file| F[(File)] -->|reads file| B1[App B]
  end
  subgraph SD[Shared Database]
    A2[App A] --> D[(Common database)]
    B2[App B] --> D
  end
  subgraph RPC[Remote Procedure Invocation]
    A3[App A] -->|remote call, waits| B3[App B]
  end
  subgraph MSG[Messaging]
    A4[App A] -->|message| M{{Messaging system}} -->|message| B4[App B]
  end

Checks

Section titled “Checks”
  • Each integration point names the integration style used and why it was chosen over the others.
  • Where File Transfer is used, the file name, location and format are agreed and documented.
  • Where Remote Procedure Invocation is used, the document acknowledges that callers are blocked during the call.
  • Where Messaging is used, the event-driven programming model and the added overhead are accepted explicitly.
Section titled “Related”

Sources

Section titled “Sources”