liveBook · Manning

Channel

As explained in Quarkus in Action

A channel is a virtual messaging address through which messages are propagated between application components or external services.

A channel is a named virtual address for passing messages between application components. In MicroProfile Reactive Messaging, CDI bean methods produce, consume, or process messages through channels. Connectors can attach external services to the same messaging model, so communication need not stay inside one application. section 9.3 section 9.3.2

Use @Outgoing("name") on a producer and @Incoming("name") on a consumer. A processor has both annotations: it reads from one channel and writes to another. Each channel has one source and one sink; unique channel names between processors establish their order. Reactive Streams provides the flow model, while SmallRye Reactive Messaging controls the flow in Quarkus. section 9.3.2 section 9.10

A two-channel pipeline

A producer emits ticks on "ticks". A processor receives them from "ticks", transforms them into timestamp strings, and emits those on "times". A consumer reads "times" and prints each string. The channel names connect the methods even when the methods reside in different CDI beans. section 9.3.2

Channels also bridge code and services outside a method-to-method pipeline:

  • Inject @Channel("requests") with an Emitter to send from imperative code. Its send operation returns a CompletionStage that completes on acknowledgment or exceptionally on negative acknowledgment; an unacknowledged message leaves it incomplete. section 9.3.4
  • Inject @Channel("ticks") as a Multi to expose produced events through a server-sent events endpoint. section 9.3.4
  • Add a connector extension to route a channel through a broker. With quarkus-messaging-rabbitmq as the only connector, the outgoing "invoices" channel is automatically mapped to a RabbitMQ exchange; the receiving side uses an incoming channel configured for the broker queue and exchange. section 9.7

An asynchronous channel can buffer messages while a receiving service is unavailable, allowing the sender to continue rather than wait for a synchronous response. That resilience depends on the channel and its delivery behavior; a virtual channel name alone is not a buffering guarantee. For reactive-messaging CDI beans, use the supported @ApplicationScoped or @Dependent scopes. section 9.3.1 section 9.3.2

How Quarkus in Action covers it

How deep it goes
Defines virtual addresses and annotation-based flows, then applies them through imperative injection and broker integration.
Examples
Uses a ticks-to-times processing pipeline, an imperative request emitter, an SSE endpoint, and RabbitMQ-backed invoices.
What it assumes
Assumes CDI bean methods and prior Reactive Streams context while defining the channel address and its annotations.
What you can do after
Build it from scratch with named producer, processor, and consumer channels; apply it via a Quarkus RabbitMQ connector when messages must cross services.
How it connects
Links CDI, Reactive Streams, MicroProfile Reactive Messaging, connectors, message acknowledgment, and server-sent events.

Also explained in

Compare how 10 books explain channel →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Quarkus in Action. The section links point to the parts of the book it draws on.