Spring Integration (EIP)

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().

@MessagingGateway on an interface makes Spring create a proxy. Calling an interface method turns the arguments into a Message sent to a request channel; the reply Message's payload is returned. Your code never touches MessageChannel or Message APIs.

DirectChannel runs the consumer synchronously on the sender's thread with no buffer, so send and handling share one thread and transaction. QueueChannel buffers messages and needs a poller; the consumer runs on a separate poller thread later.

@Router marks a method that inspects a message and returns the name(s) of the channel(s) to send it to — content-based routing. HeaderValueRouter is a built-in that picks the channel based on the value of a specified message header.

An event-driven consumer subscribes to a channel and is invoked immediately when a message is sent (push). A polling consumer periodically checks a channel for messages (pull). Which you get depends on whether the input channel is subscribable or pollable.

transform changes the payload and passes it on; filter drops messages that fail a boolean test; route sends messages to different channels/sub-flows based on a value; handle consumes the message to do work, often ending the flow.

@Splitter breaks one message into many (e.g. a list into per-item messages). @Aggregator collects related messages back into one. They pair up: the aggregator uses a correlation strategy to group messages and a release strategy to decide when a group is complete and ready to emit.

A file inbound channel adapter uses FileReadingMessageSource, polled on a schedule, to emit each new file as a Message. To avoid re-reading the same file, add a FileListFilter such as AcceptOnceFileListFilter (in-memory) or a persistent one backed by a MetadataStore.

@Filter marks a method returning a boolean: true forwards the message unchanged to the output channel, false drops it. It's a keep-or-drop gate — unlike a router (which picks among destinations) or a transformer (which changes the message).

HTTP is request-reply, so it maps to gateways. An inbound HTTP gateway (HttpRequestHandlingMessagingGateway) receives an HTTP request, runs the flow, and writes the reply as the HTTP response. An outbound HTTP gateway (HttpRequestExecutingMessageHandler) calls a remote HTTP endpoint and puts the response back on the flow.

ExecutorChannel is a subscribable point-to-point channel that hands each message to a TaskExecutor, so the handler runs asynchronously on an executor thread instead of the sender's thread — but unlike QueueChannel it has no buffer/poller.

AbstractEndpoint is the base class for consumers; it implements Spring's SmartLifecycle. On start() it wires the handler to the channel (an EventDrivenConsumer subscribes; a PollingConsumer schedules polling). On stop() it unsubscribes or cancels the poll. autoStartup and phase control when it starts.

PollerMetadata is a bean holding a poller's settings — trigger, maxMessagesPerPoll, receiveTimeout, task executor, transaction/advice, error handler. @Poller is the annotation form on an endpoint. If none is given, Spring uses a bean named the default poller; if that's missing too, startup fails.

Spring Integration's IntegrationFlowBeanPostProcessor detects the IntegrationFlow bean, unpacks its endpoints and channels, and registers each as its own bean in the context. Versus XML you get compile-time safety, DI, lambdas, and top-to-bottom readability.

By default consecutive steps are joined by DirectChannels that run synchronously on the caller's thread. To go async or switch threads you insert an explicit .channel() that is an ExecutorChannel (thread pool) or a QueueChannel (with a poller).

A ChannelInterceptor is a hook attached to a channel that fires around send and receive. Its callbacks (preSend, postSend, afterSendCompletion, preReceive, postReceive, afterReceiveCompletion) let you inspect, transform, filter, log, or measure messages without changing endpoints. Receive callbacks only apply to pollable channels.

Use a persistent MessageGroupStore so partial groups survive restarts, set a group-timeout so incomplete groups don't leak, decide via send-partial-result-on-expiry whether to emit or discard partial groups, and configure expire-groups-upon-completion plus idempotency to handle late/duplicate messages for a reused correlation key.

Both are pollable point-to-point channels. PriorityChannel is a QueueChannel that orders buffered messages by priority instead of FIFO. RendezvousChannel is a zero-capacity queue where the sender blocks until a receiver takes the message (direct handoff).

TCP endpoints share a connection factory (server or client) that owns sockets plus a serializer/deserializer defining message framing. Use TcpInboundGateway/TcpOutboundGateway for request-reply, or a TcpReceivingChannelAdapter + TcpSendingMessageHandler pair sharing one factory for asynchronous flows, correlating replies by the connection id header.

With a DirectChannel the handler runs on the sender's thread, so exceptions propagate straight back to the caller in the caller's transaction. With a polling consumer (or ExecutorChannel) the handler runs on a scheduler/pool thread, so errors go to an error channel or the poller's errorHandler instead. Design reliability with transactional pollers, error channels, and retry advice.

Use the DSL for in-JVM EIP-style orchestration across adapters (files, HTTP, JDBC, Kafka) where routing/transforming/filtering adds value. For simple call chains, plain services are clearer; for cross-service, durable, scalable messaging, use a real broker. Keep flows small and composed from reusable sub-flows.