Skip to content
Software Architecture Guide

Integration Pattern vs. Middleware Technology

Explanation

Section titled “Explanation”

An integration pattern is a proven way to connect applications. The Enterprise Integration Patterns book describes its patterns as vendor-independent. They apply to most messaging solutions. Its authors also chose pattern names that stay neutral about technology and product, yet still describe the idea. Teams can use these names in everyday conversation without naming a product.

Middleware technology is the other side. It covers the products and protocols that exist in real systems. A pattern says what kind of solution you want. A technology is one concrete way to build it.

The four integration styles show what “pattern level” means:

  • File Transfer: each application produces files of shared data for others to read, and reads files that others produced.
  • Shared Database: applications store the data they share in one common database.
  • Remote Procedure Invocation: each application exposes some of its procedures so others can call them remotely.
  • Messaging: applications connect to a common messaging system. They exchange data and trigger behavior through messages.

None of these four names a product. Each is a choice about how applications relate, made without naming a tool. The articles Integration Styles and Messaging cover them in more detail.

Technology choice brings its own concerns. Many messaging implementations rely on proprietary protocols. That raises platform and protocol constraints. Weigh these when you select a technology, not when you select a style.

Example

Section titled “Example”

A team must let an order system share data with a billing system. They first decide on the style: messaging, not a shared database. They record this in product-neutral terms. Then they compare messaging products. They check whether a candidate relies on a proprietary protocol and whether it fits their platforms. The style decision stays valid even if the product comparison changes.

Trade-offs

Section titled “Trade-offs”

Separating pattern from technology adds a step. You describe the style first and the product second. In return, the pattern vocabulary stays neutral and easy to discuss. The technology question stays open for its own constraints, such as the proprietary protocols many messaging products rely on.

Checks

Section titled “Checks”
  • The integration style (file transfer, shared database, remote procedure invocation, or messaging) is named in product-neutral terms.
  • Pattern names used in the document are neutral about technology and product.
  • Platform and protocol constraints of a chosen messaging product, such as proprietary protocols, are stated.
Section titled “Related”

Sources

Section titled “Sources”