The Splitter is a component whose role is to partition a message in several parts, and send the resulting messages to be processed independently. Very often, they are upstream producers in a pipeline that includes an Aggregator.

The API for performing splitting consists from one base class, AbstractMessageSplitter, which is a MessageConsumer implementation, encapsulating features which are common to splitters, such as filling in the appropriate message headers CORRELATION_ID, SEQUENCE_SIZE, and SEQUENCE_NUMBER on the messages that are produced. This allows to track down the messages and the results of their processing (in a typical scenario, these headers would be copied over to the messages that are produced by the various transforming endpoints), and use them, for example, in a Composed Message Processor scenario. An excerpt from AbstractMessageSplitter can be seen below: public abstract class AbstractMessageSplitter extends AbstractReplyProducingMessageConsumer { ... protected abstract Object splitMessage(Message<?> message); } For implementing a specific Splitter in an application, a developer can extend AbstractMessageSplitter and implement the splitMessage method, thus defining the actual logic for splitting the messages. The return value can be one of the following: a Collection (or subclass thereof) or an array of Message objects - in this case the messages will be sent as such (after the CORRELATION_ID, SEQUENCE_SIZE and SEQUENCE_NUMBER will be populated). Using this approach gives more control to the developer, for example for populating custom message headers as part of the splitting process. a Collection (or subclass thereof) or an array of non-Message objects - works like the prior case, except that each collection element will be used as a Message payload. Using this approach allows to focus on the a Message or non-Message object (but not a Collection or an Array) - it works like the previous cases, except that there is a single message to be sent out. In Spring Integration, any POJO can implement the splitting algorithm, provided that it defines a method that accepts a single argument and has a return value. In this case, the return value of the method will be interpreted as described above. The input argument might either be a Message or a simple POJO. In the latter case, the splitter will receive the payload of the incoming message.

A splitter can be configured through XML as follows:<channel id="inputChannel"/> <splitter id="splitter" ref="splitterBean" method="split" input-channel="inputChannel" output-channel="outputChannel" /> <channel id="outputChannel"/> <beans:bean id="splitterBean" class="sample.PojoSplitter"/> The id of the splitter is optional. A reference to a bean defined in the application context. The bean must implement the splitting logic as described in the section above. Required. The method (defined on the bean specified above) that implements the splitting logic. Optional. The input channel of the splitter. Required. The channel where the splitter will send the results of splitting the incoming message. Optional (because incoming messages can specify a reply channel themselves).

The @Splitter annotation is applicable to methods that expect either the Message type or the message payload type, and the return values of the method should be a collection of any type. If the returned values are not actual Message objects, then each of them will be sent as the payload of a message. Those messages will be sent to the output channel as designated for the endpoint on which the @Splitter is defined. @Splitter List<LineItem> extractItems(Order order) { return order.getItems() }