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
NewTradeConsumerto only pick up messages with
tradeType=NEWand throw away everything else, and create and configure
Receiverto only consume Trades with
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
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
namespace for declaring the filters in configuration files. The
filter element has an input ...