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
tradeType=NEW and throw away
everything else, and create and configure
Receiver to only consume
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
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.
Framework provides a
namespace for declaring the filters in configuration files. The
filter element has an input ...