Java Reference
In-Depth Information
<service-activator input-channel="customerIdChannel"
ref="customerDeletionServiceActivator"/>
</beans:beans>
The configuration for this is not terribly different from the previous solutions. The Java code is just
about the same as well, except that the return type of the method annotated by the @Splitter annotation
is of type java.util.Collection .
package com.apress.springenterpriserecipes.springintegration;
import org.apache.commons.io.IOUtils;
import org.springframework.integration.annotation.Splitter;
import java.io.File;
import java.io.FileReader;
import java.io.Reader;
import java.util.Collection;
public class CustomerBatchFileSplitter {
@Splitter
public Collection<String> splitAFile(File file) throws Throwable {
Reader reader = new FileReader(file);
Collection<String> lines = IOUtils.readLines(reader);
IOUtils.closeQuietly(reader);
return lines;
}
}
A message payload is passed in as a java.io.File and the contents are read. The result (a collection
or array value; in this case, a Collection<String> ) is returned. Spring Integration executes a kind of
“foreach” on the results, sending each value in the collection out on the output-channel configured for
the splitter. Often, you split messages so that the individual pieces can be forwarded to processing that's
more focused. Because the message is more manageable, the processing requirements are dampened.
This is true in many different architectures: in map/reduce solutions (see Chapter 10 for more on this)
tasks are split and then processed in parallel, and the fork/join constructs in a BPM system (see
Chapter 11) let control flow proceed in parallel so that the total work product can be achieved quicker.
Aggregators
Ineluctably, you'll need to do the reverse: combine many messages into one, and create a single result
that can be returned on the output-channel . An @Aggregator collects a series of messages (based on
some correlation that you help Spring Integration make between the messages) and publishes a single
message to the components downstream. Suppose that you know that you're expecting 22 different
messages from 22 actors in the system, but you don't know when. This is similar to a company that
auctions off a contract and collects all the bids from different vendors before choosing the ultimate
vendor. The company can't accept a bid until all bids have been received from all companies. Otherwise,
there's the risk of prematurely signing a contract that would not be in the best interest of the company.
An aggregator is perfect for building this type of logic.
Search WWH ::




Custom Search