## Sixty-Five Patterns and One Runtime: Enterprise Integration with Apache Camel

### Abstract

Every integration starts as a single HTTP call. Then a retry gets bolted on, someone adds a queue, a nightly poller appears to catch what the queue dropped, and eighteen months later you are operating a distributed system nobody designed. The worst part is that each of those decisions was locally reasonable.

These problems were catalogued and named more than twenty years ago. Hohpe and Woolf's sixty-five integration patterns describe the shapes your integration is already taking, and Apache Camel implements them directly — so the pattern you draw on a whiteboard is close to the code you deploy. This talk connects the two: the vocabulary that lets a team reason about integration, and the runtime that makes the pattern executable.

**What you'll learn:**

- Map the integration problems you already have onto named patterns, so design discussions stop starting from zero
- Build routes with Camel's DSL for the patterns that carry most systems — content-based router, splitter, aggregator, content enricher
- Make integrations survive reality with dead letter channels, idempotent consumers, and retry with backoff
- Coordinate long-running distributed work using the Saga pattern instead of reaching for two-phase commit
- Run Camel on Quarkus in containers, and understand what that does to startup, memory, and native compilation

**Demos:** a content-based router splitting a mixed inbound feed; a splitter/aggregator processing a batch and reassembling the result; an idempotent consumer absorbing duplicate delivery; a poison message landing in a dead letter channel rather than wedging the route; a saga compensating a partially completed booking.

**Key Takeaways:**
Attendees leave with a working vocabulary and running code for the patterns that appear in nearly every integration. More importantly, they leave able to recognize which pattern a given problem calls for — and which failure mode that pattern introduces in exchange, because every one of them trades a problem for a different problem.

This is not a tour of Camel's three-hundred-component list. It is about recognizing that your integration problem already has a name, a diagram, and a well-understood failure mode.

### Level of Expertise

Intermediate — attendees should be comfortable with Java and have worked on at least one system that talks to another system. No prior Camel experience assumed.

### Target Audience

Integration developers, solution architects, and Java engineers who have inherited integration code they did not write. Also useful for architects standardizing how their teams describe integration designs.

Everything will be done in a browser.

Requirements:

Laptop
Browser
Github account