From 838975646f38f429aadf68c541303ab350f42e61 Mon Sep 17 00:00:00 2001 From: dsyer Date: Thu, 6 Mar 2008 08:57:07 +0000 Subject: [PATCH] Updated to add overview of listener callbacks. --- docs/src/site/docbook/reference/execution.xml | 168 +++++++++--------- 1 file changed, 82 insertions(+), 86 deletions(-) diff --git a/docs/src/site/docbook/reference/execution.xml b/docs/src/site/docbook/reference/execution.xml index e901c4880..b94899802 100644 --- a/docs/src/site/docbook/reference/execution.xml +++ b/docs/src/site/docbook/reference/execution.xml @@ -2,105 +2,101 @@ - The Batch Execution Environment + The Batch Execution Environment -
- Introduction +
+ Introduction - The "execution" layer is fertile ground for collaboration and - contributions from the community and from projects in the field. There is - lifecycle support for starting and stopping jobs. The vision for this is - that there can be multiple implementations of this interface providing - different architectural patterns, and delivering different levels of - scalability and robustness, without changing either the business logic or - the job configuration. The initial 1.0 release of Spring Batch will have a - single implementation for the Simple Batch Execution Service. + + The "execution" layer is fertile ground for collaboration and contributions from the community and from + projects in the field. There is lifecycle support for starting and stopping jobs. The vision for this is + that there can be multiple implementations of this interface providing different architectural patterns, and + delivering different levels of scalability and robustness, without changing either the business logic or the + job configuration. The 1.0 release of Spring Batch has an implementation of the core API that is targeted at + a single VM. + - The Execution Environment is responsible for providing - implementations of the core domain concepts. This includes: - - Run Tier - Implement the bootstraping and launching of the - Execution Environment. - + + The execution environment is responsible for providing implementations of the core domain concepts. This + includes: + + + + Run Tier - Implement the bootstrapping and launching of the Execution Environment. + - - Job Tier - Implement the Job Configuration and Job Execution - strategies. - + + Job Tier - Implement the Job and Step strategies. + - - Application Tier - Impleement the Step Configuration and Step - Executor strategies. - + + Application Tier - Implement the ItemReader and ItemWriter (or Tasklet) strategies. + - - Data Tier - Implement a Repository solution for storing the - persistence state of the batch domain. - - We will describe the flow of the simple batch - execution envrionment that is provided with spring-batch to clarify the - sequence of processing in the batch environment. The simple batch - execution environment is a concrete implementation of the core interfaces. - The Simple Batch Execution Environment can be described in the following - way. - - In the Run Tier, asingle Java Project may have one or more - Jobs. Jobs are configured with the JobConfiguration bean. - + + + Data Tier - Implement a Repository solution for storing the persistence state of the batch domain. + + + + + We will describe the flow of the simple batch execution envrionment that is provided with spring-batch to + clarify the sequence of processing in the batch environment. The simple batch execution environment is a + concrete implementation of the core interfaces. The flow of a job through the execution environment is as + follows. + + + + + In the Run Tier, a single Java Project may have one or more Jobs. Jobs are configured with the Job + bean. + + - - A single Job must contain at least one Step.Steps are - configured with the StepConfiguration bean. If more than one step is - configured for a Job, then they are executed serially and after the - previous step (all of its items / records) is complete. - + + + A single Job must contain at least one Step. Steps are configured with various flavours of Step + FactoryBean. If more than one step is configured for a Job, then they are executed serially and + after the previous step (all of its items / records) is complete. A Job is also responsible for + providing registered JobListener instances with callbacks before and after the job execution. + + - - Steps are executed by StepExecutor classes, being the - DefaultStepExecutor the most simple for it. - + + + Steps are responsible for executing business logic and recording progress in a StepExecution. + + - - Steps in turn are divided into two “cycles” or “iterators”; - the “stepOperations” iterator and the “chunkOperations” iterator. - The StepOperations of the Step cycles while there is data to be - processed (i.e. a CompletionPolicy returns true) whereas the - chunkOperations executes for every cycle of the stepOperations and - it is used as Transaction controlling mechanism. The idea is that - the chunkOperations iterator executes the number of “commit size” - defined in the configuration unless another CompletionPolicy is - defined. After “# of records per Commit” cycles, it returns control - to the StepOperations which in turn calls again the ChunkOperations - if there are more records to be processed. Programmers should only - define chunkOperations and not stepOperations, unless a parallel - execution strategy is chosen. - + + + Steps are also responsible for managing the lifecycle of ItemStreams that contribute input or output + to the business logic. ItemStreams can be registered with a Step using the factory beans. Any + ItemReader or ItemWRiter injected directly into the factory bean will also be registered + automatically. + + - - The RepeatTemplate class (implementator of the chunk and step - Operations) requires a Tasklet. A Tasklet is responsible for doing - something in each cycle of the "stepOperations". Simple tasklets may - fetch and process data in the same class but typicallyIdevelopers - will use the ItemProviderProcessTasklet that separates fetching data - from processing it in the ItemProvider and ItemProcessor interfaces. - If using DB access it's also common to use an - InputSourceItemProvider as ItemProvider and an - OutputSourceItemProcessor as ItemProcessor. There are even more - specialized classes for working the Jdbc (databases). - - -
+ + + Steps are also responsible for providing callbacks to the BatchListener family of listeners. These + provide a way for application developers to add additional behaviour to a step, e.g. if a checksum + or footer has to be added to an output file. + + -
- Simple Batch Execution Environment + +
- -
+
+ Simple Batch Execution Environment + +
-
- Configuration - - +
+ Configuration + + <property name="itemProvider"> <bean class="org.springframework.batch.sample.item.provider.PlayerItemProvider"> <property name="inputSource" ref="playerFileInputSource" />