Enterprise Integration Patterns (Hohpe & Woolf, 2003)
The canonical 65-pattern vocabulary organizes messaging design into message construction, channels, routing, transformation, endpoints, and system management; its continuing value is precise problem/solution language rather than allegiance to an ESB or broker product.
Gregor Hohpe and Bobby Woolf's catalog grew from repeated integration projects into a 2003 book and a technology-independent pattern language. The official site still presents all 65 names and short problem/solution descriptions and applies them to contemporary brokers, cloud messaging, event-driven systems, and serverless workflows.
Contribution #
The catalog's most useful move is to separate six concerns that diagrams often collapse into “the message bus”:
| Family | Owned decision |
|---|---|
| Message Construction | intent, payload form, identity, correlation, sequence, expiry |
| Messaging Channels | point-to-point or publish-subscribe relationships, invalid/dead-letter paths, adapters and bridges |
| Message Routing | recipient selection, splitting, aggregation, resequencing, scatter-gather, process coordination |
| Message Transformation | translation, enrichment, filtering, normalization, canonical representation |
| Messaging Endpoints | polling or event-driven consumption, competing workers, durability, idempotency, activation |
| System Management | control, tracing, wire taps, history, storage, tests, and purging |
That vocabulary helps an architecture review ask who owns each responsibility. A queue or topic is a channel; it is not automatically a Content-Based Router, Idempotent Receiver, Aggregator, or Message History. Conversely, the same pattern can live inside one process, a broker plugin, a stream processor, or a managed cloud service.
Applying patterns safely #
Pattern names specify a recurring problem and a shaped solution, not complete failure semantics. An Aggregator still needs durable partial state, correlation, completeness rules, deadlines, late-message handling, duplicate handling, and recovery. Request-Reply still needs timeouts and late-response disposal. A Dead Letter Channel preserves failed work but does not diagnose or repair it. Guaranteed Delivery still requires a precise acknowledgement and durability boundary.
The catalog should therefore be used as a design vocabulary and checklist, then completed with the guarantees of the selected transport and the application's state transactions. It should not be used to justify an enterprise service bus, canonical schema, or distributed hop when a simpler local composition owns the same concern.
Visual audit #
The complete official overview page and its single pattern-language map were inspected. The map is information-bearing: it connects the six pattern families to endpoints, channels, routing, transformation, and management. However, it is a dense catalog image whose ordinary labels are not readable at GTK article width. It is omitted rather than downscaled. The chapter retains the family structure as a table and teaches a concrete Splitter → Idempotent Receiver → Aggregator → Router flow in prose, where the required state and failure rules can be made explicit.