Just Spring Integration

Filters

Consumers have different message requirements, with some wanting one type of message and others wanting a different type. Spring Integration Framework uses Filters and sets up criteria to decide which applications should receive the messages and which should not.

Let’s look at an example of Trades being published onto a trades-in-channel, which is configured to receive all types of Trades published by producers.

This requirement can be fulfilled in two ways without using Framework.

• Create and configure NewTradeConsumer to only pick up messages with tradeType=NEW and throw away everything else, and create and configure CancelTradeReceiver to only consume Trades with tradeType=CANCEL.

• Have a single receiver (e.g., TradeConsumer) that consumes all incoming messages regardless of the type of Trade, which then invokes the appropriate processing component based on the Trade type (e.g., by using if-else).

Although these two methods work fine, they are not ideal.

In both cases, most of the filtering work is done by the consumers. What happens if we have to introduce another set of filtering conditions?

As filtering is a common task, Spring Integration’s Filters can be configured to do this task and leave the consumers to receive their choice of messages. The framework takes away the filtering logic from the applications and ties it in with the channels.

Using Custom Filters

Framework provides a filter namespace for declaring the filters in configuration files. The filter element has an input ...