Messaging & Integration

MessageChannel is a pipe you send messages into via send(). MessageHandler is code that receives one message via handleMessage(). A producer sends to a channel; a handler subscribed to that channel processes what arrives.

Message<T> is Spring's generic container for something being sent. It has two parts: a payload (the body of type T) and MessageHeaders (a map of metadata like an id and timestamp).

ApplicationEventPublisher with @EventListener sends events between beans inside one running JVM. spring-messaging (Message, MessageChannel) is a broader abstraction for passing messages, often across process boundaries through a broker like Kafka or RabbitMQ.

A SubscribableChannel pushes each message to handlers that subscribed to it (DirectChannel). A PollableChannel buffers messages in a queue and a consumer must pull them with receive() (QueueChannel).

Use MessageBuilder: MessageBuilder.withPayload(body).setHeader("key", value).build(). You can't mutate an existing message's headers because MessageHeaders is immutable — instead you build a new message, optionally copying the old headers.

A channel adapter connects an external system to a Spring Integration message channel. Inbound adapters bring external data IN as messages; outbound adapters send message payloads OUT to an external system. Both are one-way (no reply).

A message channel is the pipe connecting components; producers send messages to it and consumers receive from it. Point-to-point delivers each message to exactly one consumer; publish-subscribe broadcasts each message to every subscriber.

@Transformer marks a method that takes an incoming message (or its payload) and returns a changed version — a new payload or modified headers. It sits between two channels, reading from one and writing the result to the other.

A @ServiceActivator marks a method (or bean) that consumes messages from an input channel, runs your business logic, and optionally sends the return value to an output channel. It connects a message channel to plain application code.

It's a fluent Java API for building Spring Integration message pipelines instead of XML. You define an IntegrationFlow bean starting with IntegrationFlow.from(a source), then chain steps like .transform() and .handle().

A MessageConverter turns your Java objects into a jakarta.jms.Message (and back), so you send objects instead of raw messages. The default, SimpleMessageConverter, maps String, byte[], Map, and Serializable to matching message types automatically.

@EnableJms turns on scanning for @JmsListener methods. You put @JmsListener(destination = "queue") on a bean method; Spring runs it for each incoming message. You also need a ConnectionFactory and a listener container factory bean.

JmsTemplate is a Spring helper that hides raw JMS boilerplate (opening connections, sessions, producers). convertAndSend turns a Java object into a JMS message and sends it; receiveAndConvert reads a message and converts it back to a Java object.

It makes the JMS Session transacted: sends/receives are buffered and only take effect when the session commits, or are undone on rollback. On a listener, a failed message is rolled back and redelivered instead of lost.

DefaultMessageListenerContainer (DMLC) is the flexible default: it supports transactions, error recovery, and dynamic scaling of consumer threads (concurrency "lower-upper"). SimpleMessageListenerContainer (SMLC) is lightweight with a fixed number of consumers and no external transaction support. Use DMLC almost always.

Dead-lettering routes messages that can't be processed to a separate exchange instead of losing them. You set the queue arguments x-dead-letter-exchange (and optionally x-dead-letter-routing-key) when declaring the queue.

By default, sending a message via RabbitTemplate doesn't tell you if the broker actually received it. Publisher confirms make the broker send back an async ack (or nack) per message, so the producer knows the send succeeded.

@RabbitListener on a method makes it consume messages from a queue. @EnableRabbit (auto-configured by Spring Boot) switches on the machinery that scans for those annotations and starts listener containers that deliver each message to your method.

RabbitTemplate is Spring AMQP's helper for sending and receiving RabbitMQ messages. convertAndSend takes a Java object, converts it to a message, and publishes it to the named exchange with the given routing key.

A Queue holds messages. An Exchange receives published messages and routes them. A Binding links an exchange to a queue with a routing rule. In Spring you declare each as a @Bean (Queue, DirectExchange, Binding).

Declare a NewTopic as a @Bean (usually built with TopicBuilder). Spring's KafkaAdmin bean scans the context for NewTopic beans at startup and creates any that don't yet exist on the broker.

DefaultErrorHandler is the container's default handler when a @KafkaListener throws. It re-delivers the failed record several times (using a BackOff for delays), and if all attempts fail it hands the record to a recoverer.

@KafkaListener marks a method to consume messages from a Kafka topic. @EnableKafka turns on Spring's infrastructure that finds those methods and starts listener containers to feed them records.

Put @EnableKafkaStreams on a @Configuration class and provide a KafkaStreamsConfiguration bean named defaultKafkaStreamsConfig that sets the application.id and bootstrap.servers. Spring then creates a StreamsBuilderFactoryBean that builds and starts Kafka Streams.

KafkaTemplate is Spring's helper for producing messages. You inject it and call template.send("topic", key, value). Spring Boot auto-configures it from application.properties, so you just autowire and send.

WebSocket is a raw two-way connection; STOMP is a simple text messaging protocol layered on top that adds destinations (like topics). @EnableWebSocketMessageBroker turns on Spring's message-broker support so clients can subscribe and publish over WebSocket.

Add @EnableWebSocket on a config class that implements WebSocketConfigurer, then override registerWebSocketHandlers to map your handler (a TextWebSocketHandler subclass) to a URL path with registry.addHandler(handler, "/ws").

Application prefixes (like /app) route incoming client messages to your @MessageMapping controller methods. Broker prefixes (like /topic, /queue) go straight to the broker for subscription/fan-out. @SendTo names the broker destination the method's return value is published to.

afterConnectionEstablished runs when a client connects; handleMessage (or handleTextMessage in TextWebSocketHandler) runs per incoming frame; handleTransportError on I/O errors; afterConnectionClosed when the socket closes. You typically track sessions in the first and remove them in the last.

User destinations let you send to one specific user, not everyone. The client subscribes to /user/queue/... and the server sends via convertAndSendToUser(user, "/queue/...", payload) or returns from a @MessageMapping method annotated @SendToUser. Spring maps it to a session-unique queue.

Request-response (one in, one out), fire-and-forget (one in, no reply), request-stream (one in, many out), request-channel (many in, many out). In Spring: return Mono for the first two, Flux for streams; a Flux parameter means channel.

@EnableRSocketSecurity turns on Spring Security for RSocket and gives you an RSocketSecurity builder. You use it to create a PayloadSocketAcceptorInterceptor bean that defines who can connect and which routes require authentication.

Autowire the RSocketRequester.Builder, connect with tcp()/websocket() to get an RSocketRequester. Then call route("path"), data(payload), and a terminal like retrieveMono(), retrieveFlux(), or send() — the terminal picks the interaction model.

The SETUP payload authenticates the connection once, when the client establishes it. REQUEST payloads authenticate individual messages/routes. In the authorizePayload DSL you use .setup() for the connection and .route(...)/.anyRequest() for per-message rules.

Request-channel is a two-way stream. The @MessageMapping handler takes a Flux parameter (inbound stream) and returns a Flux (outbound stream); the client passes a Flux to data() and calls retrieveFlux(). Both directions are independent, backpressured Reactive Streams. Choose it when the client must keep sending while receiving.