Appendix L: Glossary

A quick-reference glossary of terms used throughout this tutorial, organized by category.

EIP Patterns

Aggregator: A stateful processor that collects related messages and combines them into a single message. Requires a correlation expression, an aggregation strategy, and a completion condition. (Chapter 13)

Channel Adapter: Connects an application to the messaging system. Translates between application-specific protocols and message channels. (Chapter 2)

Channel Purger: Removes unwanted messages from a channel. Useful for clearing test messages or stale data. (Chapter 16)

Competing Consumers: Multiple consumers on the same channel, where each message is processed by exactly one consumer. Provides horizontal scalability. In Kafka, implemented via consumer groups. (Chapter 14)

Composed Message Processor: Splits a composite message, processes each part independently, and reassembles the results. Combines Splitter + Router + Aggregator. (Chapter 11)

Content-Based Router: Routes a message to the correct recipient based on message content. In Camel: choice().when().otherwise(). (Chapter 9)

Content Enricher: Augments a message with data from an external source. In Camel: enrich() or pollEnrich(). (Chapter 12)

Content Filter: Removes unwanted data from a message, keeping only relevant fields. In Camel: transform() or process(). (Chapter 12)

Control Bus: Manages and monitors the messaging system. In Camel: controlbus: component for starting/stopping routes, querying status. (Chapter 17)

Correlation Identifier: A unique identifier carried through a message flow to correlate requests with replies or related messages. Typically a header like correlationId or a Kafka key. (Chapter 8)

Datatype Channel: A channel where all messages conform to a specific data type. In Kafka: enforced by schema registry (Avro/Protobuf). (Chapter 5)

Dead Letter Channel: A channel that receives messages that cannot be processed successfully after all retries are exhausted. In Camel: errorHandler(deadLetterChannel()). (Chapter 4)

Detour: Routes messages through an additional processing step that can be toggled on/off without changing the route. Used for debugging, testing, and feature flags. (Chapter 18)

Document Message: A message that carries a complete data record. The receiver needs no additional context. Contrasts with Event Message. (Chapter 7)

Durable Subscriber: A subscriber that receives messages published while it was offline. In Kafka: the default behavior via consumer group offsets. (Chapter 15)

Dynamic Router: Routes messages to destinations determined at runtime by evaluating a routing function on each iteration. In Camel: dynamicRouter(). (Chapter 11)

Envelope Wrapper: Wraps application-specific data in a messaging envelope (headers + body), or unwraps it. JSON payloads with metadata headers are a common form. (Chapter 12)

Event-Driven Consumer: A consumer that is notified when a message arrives, rather than polling for it. Kafka consumers in their standard loop are event-driven. (Chapter 14)

Event Message: A message that signals something has happened. Typically immutable and past-tense (e.g., order.placed). Contrasts with Command Message. (Chapter 7)

Format Indicator: Metadata that identifies the format or schema version of a message. Enables schema evolution (e.g., Avro schema ID in the message header). (Chapter 8)

Guaranteed Delivery: Ensures a message is not lost, even if the messaging system or consumer fails. In Kafka: acks=all + min.insync.replicas. (Chapter 4)

Idempotent Receiver: Ensures a message is processed at most once, even if delivered multiple times. In Camel: idempotentConsumer() with a repository (memory, JDBC, Redis). (Chapter 15)

Invalid Message Channel: A channel for messages that fail validation. Separates bad data from the main processing flow. (Chapter 5)

Load Balancer: Distributes messages across multiple endpoints using a strategy (round-robin, random, failover, weighted). In Camel: loadBalance(). (Chapter 11)

Message: The atomic unit of communication in a messaging system. Consists of headers (metadata) and a body (payload). (Chapter 3)

Message Bus: An architecture where applications communicate through a shared messaging infrastructure. Kafka is our message bus. (Chapter 3)

Message Channel: A logical pathway for messages between sender and receiver. In Kafka: a topic. In Pulsar: a topic. In Redis: a Stream or Pub/Sub channel. (Chapter 3)

Message Dispatcher: Consumes messages from a channel and distributes them to performers based on criteria. In Camel: choice() inside a consumer route. (Chapter 14)

Message Endpoint: The boundary between application code and the messaging system. In Camel: the from() and to() URIs in a route. (Chapter 3)

Message Expiration: A time-to-live on a message. Expired messages are discarded. In Kafka: retention.ms on topics. In Camel: checked via headers in the route. (Chapter 8)

Message Filter: Drops messages that don’t match a predicate. In Camel: filter(). (Chapter 9)

Message History: Records the processing path a message has taken. In Camel: automatic via Exchange.MESSAGE_HISTORY when enabled. Useful for debugging. (Chapter 17)

Message Sequence: A set of messages that form an ordered sequence, identified by sequence number and a completion marker. Used when splitting a large payload. (Chapter 8)

Message Store: Persists messages for replay, audit, or debugging. In Kafka: the log is the store. For Wire Taps: a database or object store. (Chapter 17)

Message Translator: Transforms a message from one format to another. In Camel: transform(), marshal(), unmarshal(), or a Processor. (Chapter 12)

Messaging Bridge: Connects two messaging systems. For example, bridging Kafka to Pulsar or Redis Streams. (Chapter 6)

Messaging Gateway: Encapsulates messaging behind a domain-specific interface. The application calls a method; the gateway handles the messaging plumbing. (Chapter 16)

Messaging Mapper: Maps between domain objects and messaging formats. Jackson’s ObjectMapper with Camel’s marshal()/unmarshal() is the standard implementation. (Chapter 16)

Normalizer: Converts messages from different sources into a common canonical format. Combines a Router (detect format) with Translators (convert each format). (Chapter 13)

Pipes and Filters: Chains processing steps where each step (filter) transforms the message and passes it to the next via a pipe (channel). The core Camel route model. (Chapter 3)

Point-to-Point Channel: A channel where each message is consumed by exactly one receiver. In Kafka: a topic with a consumer group. (Chapter 4)

Polling Consumer: A consumer that actively checks for new messages on a schedule. In Camel: from("timer:...") or pollEnrich(). (Chapter 14)

Process Manager: Coordinates a multi-step business process, maintaining state across steps and handling compensation on failure. In Camel: Saga EIP. (Chapter 10)

Publish-Subscribe Channel: A channel where each message is delivered to all subscribers. In Kafka: multiple consumer groups on the same topic. (Chapter 4)

Recipient List: Routes a message to a dynamically computed list of recipients. In Camel: recipientList(). (Chapter 9)

Request-Reply: A two-message exchange: a request message and a corresponding reply message. In Camel: requestBody() or InOut exchange pattern. (Chapter 8)

Resequencer: Reorders out-of-sequence messages back into the correct order. In Camel: resequence() with batch or stream mode. (Chapter 11)

Return Address: A header that tells the receiver where to send the reply. In Kafka: a reply topic name in a message header. (Chapter 8)

Routing Slip: Defines a sequence of processing steps attached to the message itself. The message carries its own routing instructions. In Camel: routingSlip(). (Chapter 10)

Scatter-Gather: Broadcasts a message to multiple recipients and aggregates their replies. Combines Recipient List + Aggregator. (Chapter 10)

Selective Consumer: A consumer that filters messages based on criteria, processing only those that match. In Camel: filter() at the start of a consumer route. (Chapter 16)

Service Activator: Connects a service to the messaging system. Receives a request message, invokes the service, and sends the result as a reply. In Camel: bean(). (Chapter 15)

Smart Proxy: Intercepts request-reply interactions to add cross-cutting behavior (logging, transformation) transparently. (Chapter 18)

Splitter: Splits a composite message into individual parts for independent processing. In Camel: split(). (Chapter 9)

Test Message: A synthetic message injected to verify that the messaging system is functioning correctly. (Chapter 18)

Transactional Client: Sends/receives messages within a transaction, ensuring atomicity with other operations. The Outbox pattern is the preferred approach for Kafka. (Chapter 15)

Wire Tap: Sends a copy of a message to a secondary channel for monitoring, logging, or debugging. In Camel: wireTap(). (Chapter 11, 17)

Apache Camel concepts

CamelContext: The runtime container for Camel routes, components, and configuration. One CamelContext per application (in Quarkus, managed by the CDI container).

Component: A factory for endpoints. Each URI scheme maps to a component: kafka: → KafkaComponent, http: → HttpComponent. Components are auto-discovered from the classpath.

Consumer: The inbound side of an endpoint. Creates exchanges from external events (Kafka messages, HTTP requests, timer ticks).

DSL (Domain-Specific Language): The API used to define Camel routes. This tutorial uses the Java DSL exclusively. Camel also supports YAML DSL and XML DSL.

Endpoint: A channel identified by a URI. kafka:eip.orders.placed?brokers=localhost:9092 is a Kafka endpoint. Endpoints are both producers and consumers.

Exchange: The message container that flows through a route. Contains an In message (and optionally an Out message for InOut exchanges), headers, properties, and the exchange pattern.

ExchangePattern: InOnly (fire-and-forget) or InOut (request-reply). Kafka is typically InOnly; HTTP is typically InOut.

FluentProducerTemplate: A builder-style API for sending messages programmatically: producer.to("direct:foo").withBody(data).request(String.class).

Processor: A function that transforms an exchange. Implements Processor.process(Exchange).

Producer: The outbound side of an endpoint. Sends exchanges to external systems.

ProducerTemplate: A programmatic API for sending messages to endpoints without defining a route. Useful in CDI beans and tests.

Route: A processing pipeline from one endpoint to another, through zero or more processors. Defined in a RouteBuilder class.

RouteBuilder: The base class for defining routes in Java DSL. Extend it, override configure(), add routes with from().to().

Simple Expression Language: Camel’s built-in expression language. Access headers: ${header.foo}, body: ${body}, body fields: ${body.orderId}. Used in simple(), filter(), choice().

Infrastructure

Apache Kafka: A distributed event streaming platform. Used as the primary messaging backbone in this tutorial. Key concepts: topics, partitions, consumer groups, offsets.

Apache Pulsar: A multi-tenant distributed messaging platform. Used alongside Kafka for geo-replication and multi-tenancy scenarios. Key concepts: tenants, namespaces, topics, subscriptions.

Apicurio Registry: A schema registry for Avro, Protobuf, and JSON Schema. Stores and serves schemas for Kafka serialization/deserialization.

Consumer Group: A set of Kafka consumers that cooperate to consume from a topic. Each partition is assigned to exactly one consumer in the group. Adding consumers to a group increases parallelism (up to the partition count).

Idempotent Repository: A Camel abstraction for tracking processed message IDs. Implementations: in-memory, JDBC, Redis, Kafka (topic-based).

KRaft: Kafka’s built-in consensus protocol (replaces ZooKeeper). Used in all examples in this tutorial.

Offset: A sequential position in a Kafka partition. Each consumer group tracks its offset per partition. Committed offsets mark what has been processed.

Partition: A shard of a Kafka topic. Partitions provide parallelism and ordering guarantees (within a partition). Messages with the same key go to the same partition.

Docker Engine: The container engine (docker-ce) this tutorial runs on. The compose files run with the Docker Compose v2 plugin (docker compose), and the integration tests reach the same engine through Testcontainers.

Quarkus: A Kubernetes-native Java framework. Provides fast startup, live reload, Dev Services (automatic test containers), and native compilation via GraalVM.

Redis: An in-memory data store used for caching, idempotent repositories, and Pub/Sub messaging. In this tutorial: idempotent consumer state, rate limiting, and caching enrichment results.

Shipping domain

Carrier: A shipping provider (FedEx, UPS, USPS, DHL). Each carrier has its own API, rate structure, and service constraints.

Customs classification: Categorizing shipped goods by HS (Harmonized System) code for international shipments. Determines tariffs and regulatory requirements.

Hazmat (hazardous materials): Shipments containing dangerous goods. Subject to special routing, labeling, and carrier restrictions.

Inventory service: Manages stock levels. Consumes order events and emits reservation/confirmation events.

Notification service: Sends customer-facing messages (email, SMS) triggered by shipment events.

Order service: The entry point for customer orders. Publishes order.placed events to Kafka.

Payment service: Processes payments. Participates in the saga (compensates with refunds on failure).

Shipping service: Selects carriers, generates labels, and tracks shipments. The most integration-heavy service in the domain.