Enterprise Integration Patterns
Enterprise Integration Patterns, or EIP, is a technology-independent pattern language for message-based integration. Cohesive uses the catalog as an important architecture vocabulary while preserving the distinction among domain semantics, system-graph structure, operational concerns, architecture practices, and realization substrate.
An EIP pattern is not automatically a Cohesive semantic primitive. A pattern may instead:
- Carry a semantic value or intended interpretation in a message.
- Arrange messages, channels, routes, endpoints, or flow operators in the system graph.
- Require delivery, ordering, compatibility, correlation, retention, or recovery guarantees.
- Realize an interaction through a broker, file exchange, database, application host, or network protocol.
- Compose several lower-level structures and guarantees into an architecture practice.
Foundational Correspondence
Message emission and ingress are occurrences. At a receiving boundary, message ingress is an exogenous event carrying a value. A message contract may explicitly express singular command intent, report an occurrence, transfer a document, request a reply, or signal another protocol role. That contract supplies strong evidence for interpretation without replacing the receiving observer that admits and interprets the input.
The transport medium remains distinct from the semantic construct while maintaining an explicit correspondence. A channel or broker realizes delivery; a message carries a value and contract; an observer interprets the received occurrence; a transition or process determines the resulting semantic work.
Later Control-Flow Extension
The original EIP catalog mainly depicts the data flow of messages through endpoints, channels, routers, and transformers. Gregor Hohpe's later control-flow extension adds a second, orthogonal question: which element actively drives each interaction? Cohesive represents this as interaction control flow.
The extension distinguishes active senders and fetchers from passive sinks and sources. Applying those roles independently to both ports of a stage yields pushers, pullers, queues, and drivers. A queue accepts an active producer on one side and serves an active fetcher on the other, separating arrival cadence from departure cadence. A driver actively fetches and pushes, giving it direct control over polling, batching, and rate.
This is not a sixty-sixth peer pattern or a new semantic primitive. It is a cross-cutting operational facet of the original patterns, especially Pipes and Filters, Message Channel, Polling Consumer, Event-Driven Consumer, Competing Consumers, and broker-backed routing. A pattern diagram should state whether each arrow depicts message or data movement, interaction control, causal order, or process progression because those directions can differ.
Realm Orientation and Domain Reconciliation
EIP patterns tend to gravitate toward System Graph, Operational Concerns, and Realization Substrate. They are strongest at describing carriers, paths, endpoints, transformations, routing, delivery arrangements, and management structures. DDD gravitates toward Domain Semantics and the architecture practices that preserve semantic boundaries, authority, invariants, and ubiquitous language.
The two vocabularies meet through explicit correspondence rather than identification:
| EIP construct | Semantic reconciliation |
|---|---|
| Command Message | A carrier whose contract strongly indicates command intent; ingress remains an exogenous event and command interpretation remains relative to the receiving observer. |
| Event Message | A carrier reporting an occurrence; the reported domain event and the message-receipt event are distinct occurrences at different boundaries. |
| Message Channel | An interaction locus that does not decide the semantic role, authority, or business completion meaning of what it carries. |
| Process Manager | A routing and coordination pattern that may realize part of a semantic process but does not define its purpose, state authority, recovery policy, or terminal outcomes. |
| Canonical Data Model | A selected integration representation that does not become canonical domain meaning or one enterprise-wide ubiquitous language. |
The realm correspondence framework starts with the DDD meaning and boundary, places that meaning into messages, channels, observers, effects, and process graphs, assigns EIP structures and operational obligations, and only then selects a broker, runtime, store, protocol, or file exchange.
Catalog Coverage
Integration Styles
| EIP pattern | Cohesive correspondence |
|---|---|
| File Transfer | batch and file exchange, interaction, and storage systems |
| Shared Database | storage systems, shared-state interaction, boundaries, and isolation |
| Remote Procedure Invocation | request/reply, network, and application hosts |
| Messaging | interaction, messages and envelopes, interaction channels, and brokers |
Messaging Systems
| EIP pattern | Cohesive correspondence |
|---|---|
| Message Channel | interaction channels and interaction control flow |
| Message | messages and envelopes |
| Pipes and Filters | flow operators, flow views, and interaction control flow |
| Message Router | routing models |
| Message Translator | anti-corruption layer and compatibility and evolution |
| Message Endpoint | endpoints, observer models, and ports and adapters |
Messaging Channels
| EIP pattern | Cohesive correspondence |
|---|---|
| Point-to-Point Channel | interaction channels and consumer coordination |
| Publish-Subscribe Channel | interaction channels and brokers |
| Datatype Channel | interaction channels, shape, and compatibility and evolution |
| Invalid Message Channel | retention, expiration, and quarantine and recovery |
| Dead Letter Channel | retention, expiration, and quarantine and asynchronous interaction design |
| Guaranteed Delivery | delivery semantics, durability, and acknowledgments |
| Channel Adapter | ports and adapters and realization |
| Messaging Bridge | interaction channels, brokers, and network |
| Message Bus | interaction channels, brokers, and infrastructure graph |
Message Construction
| EIP pattern | Cohesive correspondence |
|---|---|
| Command Message | messages and envelopes carrying explicit command intent as an exogenous event at ingress |
| Document Message | messages and envelopes carrying an observation, state transfer, artifact, or other shaped value |
| Event Message | messages and envelopes carrying a reported occurrence; receipt is also an exogenous messaging event |
| Request-Reply | request/reply, request effects, and correlation and conversations |
| Return Address | correlation and conversations and interaction |
| Correlation Identifier | correlation and conversations, identity, and causality |
| Message Sequence | correlation and conversations and ordering |
| Message Expiration | retention, expiration, and quarantine and time |
| Format Indicator | compatibility and evolution, version, and shape |
Message Routing
| EIP pattern | Cohesive correspondence |
|---|---|
| Content-Based Router | routing models and policy scopes |
| Message Filter | flow operators and policy scopes |
| Dynamic Router | routing models, observer models, and routing observations |
| Recipient List | routing models and interaction channels |
| Splitter | flow operators |
| Aggregator | flow operators, correlation and conversations, and consistent cuts |
| Resequencer | flow operators and ordering |
| Composed Message Processor | flow operators, flow views, and compositionality |
| Scatter-Gather | flow operators, request/reply, and correlation and conversations |
| Routing Slip | routing models and process graphs |
| Process Manager | process managers and process graphs |
| Message Broker | routing models and brokers |
Message Transformation
| EIP pattern | Cohesive correspondence |
|---|---|
| Envelope Wrapper | messages and envelopes |
| Content Enricher | flow operators, observations, and projection models |
| Content Filter | flow operators, shape, and boundary-relative projection or redaction |
| Claim Check | messages and envelopes, identity, and storage systems |
| Normalizer | anti-corruption layer and compatibility and evolution |
| Canonical Data Model | anti-corruption layer, compatibility and evolution, and system language and realization |
Messaging Endpoints
| EIP pattern | Cohesive correspondence |
|---|---|
| Messaging Gateway | ports and adapters, observer models, and application hosts |
| Messaging Mapper | ports and adapters, shape, and realization |
| Transactional Client | commit boundaries, ACID, transactional outbox, and transactional inbox |
| Polling Consumer | consumer coordination, interaction control flow, scheduling, and interaction |
| Event-Driven Consumer | consumer coordination, interaction control flow, observer models, and runtimes |
| Competing Consumers | consumer coordination, arbitration, and fairness |
| Message Dispatcher | consumer coordination and routing models |
| Selective Consumer | consumer coordination, routing models, and policy scopes |
| Durable Subscriber | consumer coordination, durability, and retention, expiration, and quarantine |
| Idempotent Receiver | idempotency and transactional inbox |
| Service Activator | ports and adapters, observer models, and application hosts |
System Management
| EIP pattern | Cohesive correspondence |
|---|---|
| Control Bus | operational control and infrastructure graph |
| Detour | operational control, routing models, and policy scopes |
| Wire Tap | observability and provenance |
| Message History | observability and provenance and causality |
| Message Store | observability and provenance, persistence, and storage systems |
| Smart Proxy | correlation and conversations, routing models, and interaction |
| Test Message | operational control and observability and provenance |
| Channel Purger | operational control and retention, expiration, and quarantine |
Boundary of Adoption
Cohesive adopts EIP with three qualifications: guaranteed delivery is not business completion; a canonical integration model is not canonical domain meaning; and a process manager is not the semantic process it coordinates.
Formal relations
documents: Messages and Envelopes — Organizes message construction, translation, correlation, and envelope concerns without identifying carried records with semantic events or commands.documents: Interaction Channels — Organizes channel, endpoint, adapter, routing, and mediation patterns for message-based interaction structure.documents: Routing Models — Organizes content-, context-, recipient-, process-, and topology-sensitive routing alternatives and their composition.
External References
- Gregor Hohpe and Bobby Woolf, Enterprise Integration Patterns, Addison-Wesley Professional, 2003.
- Enterprise Integration Patterns, Messaging Patterns Overview and Table of Contents.
- Gregor Hohpe, Control Flow—The Other Half of Integration Patterns, 2024.
Related concepts: pattern languages and correspondence, domain-driven design, architecture practices, interaction, interaction control flow, messages and envelopes, interaction channels, routing models, flow operators, observer models, effect, event, command, process, delivery semantics, realization.