Enterprise Integration Patterns
Overview
Enterprise Integration Patterns (EIP), catalogued by Gregor Hohpe and Bobby Woolf, define a vocabulary of 65 patterns for designing robust, asynchronous messaging systems. The patterns describe how to connect applications, transform data in flight, route messages intelligently, and manage messaging infrastructure -- all while keeping systems loosely coupled and independently deployable.
The book organises patterns around the pipes-and-filters architectural style: messages flow through a series of processing steps (filters) connected by channels (pipes).
Pattern Categories
┌─────────────────────────────────────────────────────────────────┐
│ Enterprise Integration Patterns │
├───────────────┬───────────────┬───────────────┬─────────────────┤
│ Messaging │ Message │ Message │ Message │
│ Channels │ Construction │ Routing │ Transformation │
│ │ │ │ │
│ How messages │ How messages │ How messages │ How messages │
│ travel │ are built │ are directed │ are reshaped │
├───────────────┴───────────────┴───────────────┴─────────────────┤
│ Messaging Endpoints │ System Management │
│ │ │
│ How applications connect │ How to monitor, test, and │
│ to the messaging system │ control the messaging system │
└───────────────────────────────┴─────────────────────────────────┘
Pipes-and-Filters Architecture
┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐
│ Source │───>│ Filter A │───>│ Filter B │───>│ Sink │
│ (Producer)│ │(Transform│ │ (Route) │ │(Consumer)│
└──────────┘ └──────────┘ └──────────┘ └──────────┘
pipe pipe pipe
(channel) (channel) (channel)
Each filter performs a single processing step (validate, enrich, transform, route). Each pipe is a message channel connecting one filter to the next. This architecture provides:
- Composability -- combine simple filters into complex workflows.
- Replaceability -- swap a filter without touching others.
- Scalability -- scale individual filters independently.
- Testability -- test each filter in isolation.
When to Use Messaging vs. Direct Calls
| Concern |
Direct / Synchronous Calls |
Messaging / Asynchronous |
| Coupling |
Caller must know callee's address and API |
Sender only knows the channel |
| Availability |
Callee must be running |
Callee can be offline; messages queue |
| Latency |
Immediate response required |
Eventual response acceptable |
| Throughput |
Limited by slowest participant |
Buffer with queues; scale consumers |
| Error handling |
Caller handles errors in real time |
Dead-letter channels, retries, compensation |
| Complexity |
Simple for 1:1 interactions |
Worth it when >2 participants or reliability matters |
Rule of thumb: Start synchronous. Move to messaging when you need temporal decoupling, load levelling, reliable delivery, or fan-out to multiple consumers.
Pattern Selection Guide
| Problem |
Pattern Category |
Key Patterns |
| How do I send a message from A to B? |
Messaging Channels |
Point-to-Point Channel, Channel Adapter |
| How do I notify many subscribers? |
Messaging Channels |
Publish-Subscribe Channel |
| What goes inside a message? |
Message Construction |
Command Message, Event Message, Document Message |
| How do I correlate request and reply? |
Message Construction |
Correlation Identifier, Return Address |
| How do I route to the right consumer? |
Message Routing |
Content-Based Router, Recipient List |
| How do I split and reassemble? |
Message Routing |
Splitter, Aggregator |
| How do I orchestrate a multi-step flow? |
Message Routing |
Process Manager, Routing Slip |
| How do I reshape data between systems? |
Message Transformation |
Content Enricher, Normalizer, Canonical Data Model |
| How do I reduce message size? |
Message Transformation |
Claim Check, Content Filter |
| How do I consume messages reliably? |
Messaging Endpoints |
Competing Consumers, Idempotent Receiver |
| How do I monitor and debug? |
System Management |
Wire Tap, Message Store, Control Bus |
Reference Implementations
| Technology |
Language / Platform |
Strengths |
| Apache Camel |
Java / JVM |
Broadest connector ecosystem; DSL routes map 1:1 to EIP |
| Spring Integration |
Java / Spring |
Deep Spring ecosystem integration; annotation-driven |
| MassTransit |
C# / .NET |
First-class saga support; RabbitMQ & Azure Service Bus transports |
| NServiceBus |
C# / .NET |
Commercial-grade; strong tooling and monitoring |
| MediatR |
C# / .NET |
In-process mediator; great for CQRS without infrastructure |
| Azure Service Bus |
Cloud (Azure) |
Managed broker; topics, subscriptions, sessions |
| RabbitMQ |
Any (AMQP) |
Lightweight broker; exchanges map to routing patterns |
| Apache Kafka |
Any |
Log-based streaming; high throughput; replay capability |
Best Practices
- Learn the pattern language before choosing a framework -- the vocabulary transcends any single implementation.
- Prefer idempotent message handlers; at-least-once delivery is the norm.
- Design messages as immutable, self-describing contracts with schema versioning.
- Keep channels focused on a single data type or purpose (Datatype Channel).
- Use Dead Letter Channels for every queue -- never silently drop messages.
- Instrument messaging with Wire Taps and Message Stores from day one; debugging async flows without observability is painful.
- Start with the simplest topology (point-to-point) and evolve toward pub-sub or content-based routing only when the need is proven.
1---2name: integration-patterns3description: |4 Use when designing or evaluating enterprise integration architectures based on Hohpe & Woolf's Enterprise Integration Patterns.5 USE FOR: Enterprise Integration Patterns, messaging architecture, choosing integration patterns, pipes and filters, message-oriented middleware6 DO NOT USE FOR: specific pattern implementations in code (use sub-skills), API design (use dev/backend/api-design), event sourcing (use dev/architecture/event-driven)7license: MIT8metadata:9 displayName: "Integration Patterns"10 author: "Tyler-R-Kendrick"11compatibility: claude, copilot, cursor12references:13 - title: "Enterprise Integration Patterns — Hohpe & Woolf"14 url: "https://www.enterpriseintegrationpatterns.com/"15 - title: "Enterprise Integration Patterns — Wikipedia"16 url: "https://en.wikipedia.org/wiki/Enterprise_Integration_Patterns"17---1819# Enterprise Integration Patterns2021## Overview22Enterprise Integration Patterns (EIP), catalogued by Gregor Hohpe and Bobby Woolf, define a vocabulary of 65 patterns for designing robust, asynchronous messaging systems. The patterns describe how to connect applications, transform data in flight, route messages intelligently, and manage messaging infrastructure -- all while keeping systems loosely coupled and independently deployable.2324The book organises patterns around the pipes-and-filters architectural style: messages flow through a series of processing steps (filters) connected by channels (pipes).2526## Pattern Categories2728```29┌─────────────────────────────────────────────────────────────────┐30│ Enterprise Integration Patterns │31├───────────────┬───────────────┬───────────────┬─────────────────┤32│ Messaging │ Message │ Message │ Message │33│ Channels │ Construction │ Routing │ Transformation │34│ │ │ │ │35│ How messages │ How messages │ How messages │ How messages │36│ travel │ are built │ are directed │ are reshaped │37├───────────────┴───────────────┴───────────────┴─────────────────┤38│ Messaging Endpoints │ System Management │39│ │ │40│ How applications connect │ How to monitor, test, and │41│ to the messaging system │ control the messaging system │42└───────────────────────────────┴─────────────────────────────────┘43```4445## Pipes-and-Filters Architecture4647```48┌──────────┐ ┌──────────┐ ┌──────────┐ ┌──────────┐49│ Source │───>│ Filter A │───>│ Filter B │───>│ Sink │50│ (Producer)│ │(Transform│ │ (Route) │ │(Consumer)│51└──────────┘ └──────────┘ └──────────┘ └──────────┘52 pipe pipe pipe53 (channel) (channel) (channel)54```5556Each **filter** performs a single processing step (validate, enrich, transform, route). Each **pipe** is a message channel connecting one filter to the next. This architecture provides:57- **Composability** -- combine simple filters into complex workflows.58- **Replaceability** -- swap a filter without touching others.59- **Scalability** -- scale individual filters independently.60- **Testability** -- test each filter in isolation.6162## When to Use Messaging vs. Direct Calls6364| Concern | Direct / Synchronous Calls | Messaging / Asynchronous |65|---------|---------------------------|--------------------------|66| Coupling | Caller must know callee's address and API | Sender only knows the channel |67| Availability | Callee must be running | Callee can be offline; messages queue |68| Latency | Immediate response required | Eventual response acceptable |69| Throughput | Limited by slowest participant | Buffer with queues; scale consumers |70| Error handling | Caller handles errors in real time | Dead-letter channels, retries, compensation |71| Complexity | Simple for 1:1 interactions | Worth it when >2 participants or reliability matters |7273**Rule of thumb:** Start synchronous. Move to messaging when you need temporal decoupling, load levelling, reliable delivery, or fan-out to multiple consumers.7475## Pattern Selection Guide7677| Problem | Pattern Category | Key Patterns |78|---------|-----------------|--------------|79| How do I send a message from A to B? | Messaging Channels | Point-to-Point Channel, Channel Adapter |80| How do I notify many subscribers? | Messaging Channels | Publish-Subscribe Channel |81| What goes inside a message? | Message Construction | Command Message, Event Message, Document Message |82| How do I correlate request and reply? | Message Construction | Correlation Identifier, Return Address |83| How do I route to the right consumer? | Message Routing | Content-Based Router, Recipient List |84| How do I split and reassemble? | Message Routing | Splitter, Aggregator |85| How do I orchestrate a multi-step flow? | Message Routing | Process Manager, Routing Slip |86| How do I reshape data between systems? | Message Transformation | Content Enricher, Normalizer, Canonical Data Model |87| How do I reduce message size? | Message Transformation | Claim Check, Content Filter |88| How do I consume messages reliably? | Messaging Endpoints | Competing Consumers, Idempotent Receiver |89| How do I monitor and debug? | System Management | Wire Tap, Message Store, Control Bus |9091## Reference Implementations9293| Technology | Language / Platform | Strengths |94|-----------|-------------------|-----------|95| **Apache Camel** | Java / JVM | Broadest connector ecosystem; DSL routes map 1:1 to EIP |96| **Spring Integration** | Java / Spring | Deep Spring ecosystem integration; annotation-driven |97| **MassTransit** | C# / .NET | First-class saga support; RabbitMQ & Azure Service Bus transports |98| **NServiceBus** | C# / .NET | Commercial-grade; strong tooling and monitoring |99| **MediatR** | C# / .NET | In-process mediator; great for CQRS without infrastructure |100| **Azure Service Bus** | Cloud (Azure) | Managed broker; topics, subscriptions, sessions |101| **RabbitMQ** | Any (AMQP) | Lightweight broker; exchanges map to routing patterns |102| **Apache Kafka** | Any | Log-based streaming; high throughput; replay capability |103104## Best Practices105- Learn the pattern language before choosing a framework -- the vocabulary transcends any single implementation.106- Prefer idempotent message handlers; at-least-once delivery is the norm.107- Design messages as immutable, self-describing contracts with schema versioning.108- Keep channels focused on a single data type or purpose (Datatype Channel).109- Use Dead Letter Channels for every queue -- never silently drop messages.110- Instrument messaging with Wire Taps and Message Stores from day one; debugging async flows without observability is painful.111- Start with the simplest topology (point-to-point) and evolve toward pub-sub or content-based routing only when the need is proven.
Tyler-R-Kendrick