stepName : The name of the step to be remotely executed by the slave processes. In
this case, it's the step1 step.
• gridSize : The number of slaves involved in the processing of the partitioned step.
You run three JVMs, so you have three slaves.
• replyChannel : Where MessageChannelPartitionHandler listens for incoming replies
from the remotely executed steps.
• messagingOperations : A MessageTemplate configured with the requests queue as
the default channel. MessageChannelPartitionHandler uses this to send outgoing
messages to the slave JVMs as well as listen for incoming messages.
After MessageChannelPartitionHandler , you configure the channels you use for communication.
Five channels are involved in this example: an inbound and an outbound channel on each of the two
queues and a channel for the final aggregated message. Each outbound channel puts messages on the
queues; the inbound channels receive messages from each queue. The following channels and adapters
are configured for this job:
outbound-requests : This channel puts the requests for each partition on the
request queue. You use a JMS outbound channel adapter to take the messages
from the Spring Integration channel and put them on the JMS queue.
inbound-requests : This channel receives the messages put on the requests queue.
A message-driven channel adapter pulls the messages off the JMS queue and puts
them in this channel.
• outbound-staging : When a step has been processed, the response from an
individual step is staged in this channel, which is then persisted to the staging
queue. Again, a JMS outbound channel adapter persists the messages to the JMS
• inbound-staging : Messages received from the staging queue are placed in this
channel via a message-driven channel adapter, to be aggregated together into a
single message for processing by MessageChannelPartitionHandler .
• outbound-replies : This is the single channel used to transport the aggregated step
results back to MessageChannelPartitionHandler .
You're already putting messages onto the outbound-requests channel and receiving them with the
outbound-replies channel with MessageChannelPartitionHandler . To execute the job when you receive a
message, you use the next bean that is configured: StepExecutionRequestHandler .
StepExecutionRequestHandler takes the StepExecution you created in the ColumnRangePartitioner
and executes the step you've requested with that StepExecution. Because it's a message-driven POJO,
you use Spring Integration's service activator to execute it as messages are received. The two
dependencies with which StepExecutionRequestHandler is configured are references to a JobExplorer
and a StepLocator. Both are used to locate and execute the step.
The last thing to configure is a Spring Integration aggregator. You use this because
MessageChannelPartitionHandler expects a single message containing a list of StepExecutions in return
for sending out all the individual StepExecutions to worker JVMs. Because
MessageChannelPartitionHandler requires the consolidated input, it's what provides the method to do
the aggregation, as you can see in the configuration.
Before you consider the configuration finished, let's examine a couple of elements in the launch-
context.xml file, shown in Listing 11-31.