Spring Integration：传输验证等逻辑应放通道拦截器还是端点？

Great question—this is exactly the kind of design call that separates clean, maintainable Spring Integration flows from messy ones, and it’s not just a style choice. Let’s break down when to use each approach based on Spring Integration’s core design principles.

Channel Interceptors: For Cross-Cutting, Transport-Focused Concerns #

Channel Interceptors are built for generic, infrastructure-level concerns that apply to every message passing through a channel—regardless of what business logic the message will trigger later. This makes them ideal for:

• Transport validation: Checks related to how the message is transmitted, not what it contains. For example, verifying required transport headers (like correlationId or traceId) exist, ensuring the message body is serialized correctly, or validating message size limits for the channel.
• Global state tracking: Monitoring message flow at the channel level, such as logging when a message enters/exits a channel, tracking throughput metrics, or updating a global message audit log.

The biggest win here is separation of concerns: you don’t have to duplicate validation/tracking code across every service activator or filter that uses the channel. Interceptors attach to the channel itself, so all traffic gets processed automatically.

Example of a tracking interceptor:

public class ChannelTrackingInterceptor extends ChannelInterceptorAdapter {
    private static final Logger log = LoggerFactory.getLogger(ChannelTrackingInterceptor.class);

    @Override
    public Message<?> preSend(Message<?> message, MessageChannel channel) {
        log.info("Message ID {} entering channel: {}", message.getHeaders().getId(), channel.getName());
        return super.preSend(message, channel);
    }

    @Override
    public void postSend(Message<?> message, MessageChannel channel, boolean sent) {
        log.info("Message ID {} exited channel {} (sent status: {})", 
                 message.getHeaders().getId(), channel.getName(), sent);
        super.postSend(message, channel, sent);
    }
}

Endpoints (Service Activators, Filters): For Business-Tied Concerns #

Service Activators, Filters, and other endpoints belong to the business logic layer of your flow. They’re the right choice when your validation or state tracking is tied to specific business rules, not just message transport:

• Business validation: Checking that message content adheres to business rules—like verifying an order’s amount is positive, a customer ID exists in your database, or a shipment date is in the future.
• Business state tracking: Updating process statuses that are part of your domain logic—like marking an order as "PROCESSING" in your database, or logging a step in a customer onboarding workflow.

Endpoints also give you more flexibility for handling failures: if a business validation fails, you can route the message to an error channel, trigger a compensation flow, or return a meaningful business error response—something that’s clunky to do in an interceptor.

Example of business validation in a Service Activator:

@ServiceActivator(inputChannel = "orderInputChannel")
public Message<?> processOrder(Message<Order> orderMessage) {
    Order order = orderMessage.getPayload();
    
    // Business-specific validation
    if (order.getAmount() <= 0) {
        throw new InvalidOrderException("Order amount must be greater than 0");
    }
    if (!customerRepository.existsById(order.getCustomerId())) {
        throw new UnknownCustomerException("Customer ID " + order.getCustomerId() + " not found");
    }

    // Business state tracking
    order.setStatus(OrderStatus.PROCESSING);
    orderRepository.save(order);

    return MessageBuilder.withPayload(order).build();
}

When to Combine Both? #

You’ll often use a mix of both approaches for layered concerns:

1. Use an interceptor to handle global transport checks (e.g., ensuring every message has a traceId for distributed logging).
2. Use a service activator to handle business-specific validation and state updates for that particular flow.

This keeps your code clean, avoids repetition, and aligns with Spring Integration’s design philosophy of separating infrastructure from business logic.

Final Rule of Thumb #

• Choose Channel Interceptors when your concern applies to all messages through a channel (infrastructure/transport-focused).
• Choose Endpoints when your concern is tied to specific business logic or requires integration with domain components.

It’s not just style—it’s about following separation of concerns to keep your flows maintainable and scalable.

内容的提问来源于stack exchange，提问作者Brian K