Java Reference
In-Depth Information
</beans:bean>
</int:interceptors>
</int:channel>
<jms:listener-container connection-factory="connectionFactory"
transaction-manager="transactionManager" acknowledge="transacted">
<jms:listener destination="requests" ref="chunkHandler"
response-destination="replies" method="handleChunk"/>
</jms:listener-container>
</beans:beans>
The configuration for the remote-chunking piece of the example begins with the ChunkHandler. It's
configured as an instance of
org.springframework.batch.integration.chunk.RemoteChunkHandlerFactoryBean
, which creates an
instance of a ChunkHandler and injects it into the step you configure as its ItemProcessor. The other
dependency the
RemoteChunkHandler
has is the ChunkWriter, which is the next bean configured.
The ChunkWriter, as you saw previously, is a specially created writer used to send the items out to
the slave listeners to be processed and listen for the items to come back as processing completes. This
class requires three dependencies: a reference to a MessageTemplate to perform the required JMS
functions, the name of the reply channel (because the request channel is the default for the
MessageTemplate), and the maximum timeout errors it can accept before considering the job a failure
(10 in this case). If, during execution of the job, the number of timeouts you configure is reached, the
step is marked as a failure.
The
messageGateway
bean is an instance of Spring Integration's
org.springframework.integration.core.MessageTemplate
and is used to do the heavy lifting with regard
to JMS functions in remote chunking. You define the outgoing channel (requests) as
defaultChannel
and
specify a timeout value for how long to wait when listening for replies.
The requests channel is an in-memory representation of a queue. Spring Integration uses channels
to abstract the concept of messaging from an application to let you use either real JMS queues or lighter-
weight in-memory messaging. In this case, you back this up with a real JMS queue later in the
configuration. Just as the requests channel sends items from your job to the slave nodes, the incoming
channel receives the results.
To back up the requests channel with a true JMS queue, you use Spring Integration's outbound
channel adapter. This adapter takes all interactions done with the channel and persists them to the
queue you configure. In order for it to work, you need to specify a connection factory for it to connect
with your JMS queues, tell it what channel to get the items from, and specify the name of the queue to
put it on.
As you process messages from remote servers, a number of things can happen, such as timeouts or
various nodes going down. Because of this, an item is flagged as redelivered if it has been delivered more
than once for any reason. What you do with it from there depends on a number of business conditions
(whether this a restart, and so on). However, to obtain that redelivered flag, you use a Spring Integration
transformer
. This transformer takes the messages from one channel (incoming), applies some form of
logic (the
extract
method of the
headerExtractor
bean, in this case), and places them on another
channel (replies, in this case).
With all the communication configured as well as the components used in your job, the only thing
left to configure are the slave workers. Each slave in this case is nothing more than a message-driven
POJO, configured using Spring Integration's listener container and listener. The listener container is
used to pull messages off of the queue and put replies back on it. For each message it receives, the
listener itself is called.
