diff --git a/docs/src/site/docbook/reference/core.xml b/docs/src/site/docbook/reference/core.xml
index 9b65e9375..f2630be07 100644
--- a/docs/src/site/docbook/reference/core.xml
+++ b/docs/src/site/docbook/reference/core.xml
@@ -177,175 +177,370 @@
Physical Resources in the Data Tier that are the source and
target of ItemReaders and Writers like Message Queues, Databases,
Files and Print Queues.
-
-
- Batch Domain Stereotypes
- We will discuss each of these Batch domain Stereotypes
- individually. This section describes stereotypes relating to the concept of a batch job.
- A job is an entity that encapsulates an entire batch process.
-
- Job Configuration
-
- The job configuration could be described as the heart of the Spring Batch framework.
- It is represented by a Spring bean of class _JobConfiguration_ and contains all of
- the information necessary to define the operations performed by a job. A job configuration
- is typically contained within a Spring XML configuration file and the job's name is
- determined by the "id" attribute associated with the job configuration bean. The job configuration contains:
-
-
-
- The simple name of the job
-
-
- Definition and ordering of [Step Configurations|#Step Configuration]
-
-
- The limit of how many times this job may be started
-
-
- Whether or not the job is restartable
-
-
- The mechanics of defining a job configuration will be discussed in the next chapter. [Provide a link]
-
-
- Job Instance
- A job instance refers to the business concept of a single job invocation. In other words, suppose
- you have a job called "foo" that is run three times a day. There will be one "foo" configuration,
- and each time "foo" is supposed to run would be an instance of the "foo" job. Each instance would be
- uniquely identified as each one represents a distinct batch need. Further, each instance might
- have attempted several times to complete its work. Each attempt is represented by a [#Job Execution],
- described below. A job instance is not considered to be complete until an associated job execution
- completes successfully. As such, a single job instance may have many executions.
-
- For example, a unique instance might be identified by just a job name, or by the combination of a
- job name and a scheduled date. Using this second type of identification, we might have two distinct
- instances, "foo-01-01-2008" and "foo-01-02-2008." Although these two instances would share the same
- configuration, they would each have their own set of executions and the successful completion of one
- instance would not affect the status of the other.
-
- Job instances are represented by objects of the _JobInstance_ class, which are created when the
- job is executed. Each job instance contains references to related [Step Instances|#Step Instance]
- and a _JobIdentifier_ that uniquely identifies this job instance.
-
-
-
-
- Job Execution
-
-A job execution refers to the technical concept of a single attempt to run a job. It is a single attempt to execute the logic represented by a job instance. A job execution may end in failure or success, but the job instance corresponding to a given execution will not be marked as complete unless the execution completes successfully.
-
-
-For instance, if we have a job instance "foo-01-01-2008" that fails to successfully complete its work the first time it is run, when we attempt to run it again, a new job execution will be created. If our "foo" configuration is restartable, we may begin our second job execution from a restart point. Otherwise, our job execution will start from the beginning. In either case, we will see that our single job instance has had two job executions.
-
-
-Job executions are represented by objects of the _JobExecution_ class. These job executions are created by an implementation of the _JobExecutorFacade_ interface from a given _JobInstance_ corresponding to a unique _JobIdentifier_. Each job execution contains a reference to its corresponding job instance, related Step Executions and step/chunk context data.
-
-
-
- Step Stereotypes
-
-This section describes stereotypes relating to the concept of a batch step. A step is an entity that encapsulates a single, independent phase of a batch job. Therefore, every batch job is composed entirely of one or more batch steps.
-
-
-
- Step Configuration
-
-The step configuration contains all of the information necessary to define a discrete set of business logic within a job configuration. This is a necessarily vague description because the contents of any given step configuration are at the discretion of the developer writing your jobs. A step can be as narrowly defined as a single line of code or as broadly defined as necessary to complete the entire work of your job. There are several factors that will affect the breadth of your step configurations.
-
-
-
- Re-usability - step definitions can be shared between jobs
-
-
- Transaction Management - depending on your desired transaction strategy, you may divide the work of your job differently between steps
-
-
- Extensibility - adequately granular definition of steps allows the addition or subtraction of steps at a later time in the appropriate position within your job configuration
-
-
-
-Step configurations are defined by instantiating implementations of the _StepConfiguration_ interface. Additionally, the utility class _StepConfigurationSupport_ provides a basic implementation of _StepConfiguration_ with default functionality that should be common to any concrete _StepConfiguration_ implementation. Generally, all step configuration implementations should extend from this class.
-
-
-Two step configuration classes are available in the Spring Batch framework, and they are each discussed in detail in other sections of this guide. For most situations, the _SimpleStepConfiguration_ implementation is sufficient, but custom transaction management behavior can also be configured by using a _RepeatOperationsStepConfiguration_.
-
-
-
- Step Instance
-
-A step instance, represented by the _StepInstance_ class, represents the business concept of a single step within a job invocation. That is to say, every job instance contains one or more step instances.
-
-
-For example, suppose we have a job instance called "foo-01-01-2008" that is an instance of a job configuration containing three steps. Suppose these steps are named "step1", "step2" and "step3." There will be corresponding "foo-01-01-2008#step1", "foo-01-01-2008#step2" and "foo-01-01-2008#step3" step instances, which will be distinct from the step instances of any other job instance (e.g. those of "foo-01-02-2008").
-{note}The step instance naming here is for clarity, this is not necessarily how the instance will be named internally within the framework.{note}
-
-
-Each step instance will contain the current status of the batch execution, restart data, and a reference to its corresponding [Job Instance]. Additionally, a step instance keeps track of how many attempts are made to run the corresponding step. Each attempt to run a step will create a [Step Execution], so a single job instance might have several corresponding step executions.
-
-
-
- Step Execution
-
-A step execution represents the technical concept of a single attempt to execute a step. It is a single attempt to execute the logic represented by a step instance.
-
-
-For instance, if we have a step instance "foo-01-01-2008#step1" that fails to successfully complete its work the first time it is run, when we attempt to run it again, a new step execution will be created. Each of these step executions may represent a different invocation of the batch framework, but they will all correspond to the same step instance.
-
-
-Step executions are represented by objects of the _StepExecution_ class. These step executions are created by an implementation of the _JobExecutor_ interface from a given _StepInstance_ and _JobExecution_. Each step execution contains a reference to its corresponding step instance and job execution, and transaction related data such as commit and rollback counts, start and end times and a _Properties_ instance containing statistics.
-
-
-
- Tasklets
-
- A tasklet represents the execution of a logical unit of work, as defined by its implementation of the Spring Batch provided _Tasklet_ interface. Tasklets are used when defining step configurations to specify the work done by the step. Subsequently, the logic in a tasklet is atomic in terms of transactions. A transaction will never commit until an entire tasklet execution is complete (unless an exception occurs - a transaction might either commit or rollback if that behavior is specified in the step's exception management strategy).
-
-
-
- Item-Oriented Processing Stereotypes
-
-A powerful batch processing paradigm implemented by the Spring Batch framework is the concept of item-oriented processing. That is, doing work by defining each unit of work as the operation of retrieving an item from input and then processing that item, including any side effects that processing might entail, such as file or database operations.
-
-
-There are two basic stereotypes that represent the first-class participants in item-oriented processing, item providers and item processors. They are each represented by a simple interface provided by the Spring Batch framework, which allows free reign over their implementations and improves our ability to leverage the Spring framework's dependency injection capabilities.
-
-
- Item Readers
-
- An item reader is an object that is used to retrieve the inputs for a step, one at a time. When the item reader has exhausted the items it can provide, it will indicate this in a meaningful way (generally by returning _null_). When coupled with an item processor, this forms a complete item-oriented process, as each item taken from the provider is then processed by the processor.
-
-
-
- Item Writers/Processors
-
- An item processor is an object that is used to perform processing for a step, one item at a time. Generally, an item processor has no knowledge of the input it will receive next, only the item that that was passed in its current invocation. As a result, item processors will generally make no assumptions about the input they receive an treat every item the same way and keep track of its own state between invocations. When coupled with an item provider, this forms a complete item-oriented process, as each item taken from the provider is then processed by the processor.
-
-
+
- Support Stereotypes
- While item providers and processors serve as the main entry points for item-oriented processing, they are supplemented by a number of support classes that perform specific tasks within the provider / processor lifecycle. These support stereotypes are useful for dividing the work of item providers and processors into reusable pieces, as well as abstracting away the details of processing, such as interaction with external systems. Additionally, they give us another opportunity to leverage the powerful configuration features of the Spring framework, as we can switch between several beans implementing these support interfaces without changing the driving item provider or processor.
-
+ Job Stereotypes
+
+ This section describes stereotypes relating to the concept of a
+ batch job. A job is an entity that encapsulates an entire batch process.
+ The file containing the job may sometimes be referred to as the "job
+ configuration.
+
- Input Sources
- An input source is a class that mediates interactions with an external source of input data, such as a file or a database. An input source often serves as a support for an item provider, typically abstracting away the details of interaction, such as the creation and maintenance of file handles, sockets or database connections.
-
+
+
+ Job
+
+
+
+ The job could be described as the heart of the Spring Batch
+ framework. It is represented by a Spring bean that implements the
+ Job interface and contains all of the
+ information necessary to define the operations performed by a job. A job
+ configuration is typically contained within a Spring XML configuration
+ file and the job's name is determined by the "id" attribute associated
+ with the job configuration bean. The job configuration contains:
+
+
+
+
+
+ The simple name of the job
+
+
+
+ Definition and ordering of [Step Configurations|#Step
+ Configuration]
+
+
+
+ The limit of how many times this job may be started
+
+
+
+ Whether or not the job is restartable
+
+
+
+ A default simple implementation of the
+
+ Job
+
+ interface is provided by Spring Batch in the form of the JobSupport class. Jobs can be defined by creating beans from subclasses of
+
+ JobSupport
+
+ . The
+
+ JobSupport
+
+ class, however, does not provide much in the way of functionality. The provided
+
+ SimpleJob
+
+ class creates some standard functionality on top of
+
+ JobSupport
+
+ , namely a standard execution logic that all jobs should utilize. In general, all job configurations should be defined using a bean of type
+
+ SimpleJob
+
+ .
+
+
+ Job Instance
+
+ A job instance refers to the business concept of a single job
+ invocation. In other words, suppose you have a job called "foo" that is
+ run three times a day. There will be one "foo" configuration, and each
+ time "foo" is supposed to run would be an instance of the "foo" job.
+ Each instance would be uniquely identified as each one represents a
+ distinct batch need. Further, each instance might have attempted several
+ times to complete its work. Each attempt is represented by a [#Job
+ Execution], described below. A job instance is not considered to be
+ complete until an associated job execution completes successfully. As
+ such, a single job instance may have many executions. To keep track of
+ this, every job instance provides a reference to the last execution
+ attempt.
+
+ For example, a unique instance might be identified by just a job
+ name, or by the combination of a job name and a scheduled date. Using
+ this second type of identification, we might have two distinct
+ instances, "foo-01-01-2008" and "foo-01-02-2008." Although these two
+ instances would share the same configuration, they would each have their
+ own set of executions and the successful completion of one instance
+ would not affect the status of the other.
+
+ Job instances are represented by objects of the JobInstance class, which are created when the job
+ is executed. Each job instance contains references to related [Step
+ Instances|#Step Instance] and a set of job parameters, represented by
+ the JobParameters that uniquely
+ identifies this job instance.
+
+
+
+ Job Execution
+
+ A job execution refers to the technical concept of a single
+ attempt to run a job. It is a single attempt to execute the logic
+ represented by a job instance. A job execution may end in failure or
+ success, but the job instance corresponding to a given execution will
+ not be marked as complete unless the execution completes
+ successfully.
+
+ For instance, if we have a job instance "foo-01-01-2008" that
+ fails to successfully complete its work the first time it is run, when
+ we attempt to run it again, a new job execution will be created. If our
+ "foo" configuration is restartable, we may begin our second job
+ execution from a restart point. Otherwise, our job execution will start
+ from the beginning. In either case, we will see that our single job
+ instance has had two job executions.
+
+ Job executions are represented by objects of the JobExecution class. These job executions are
+ created by an implementation of the JobExecutorFacade interface from a given
+ JobInstance corresponding to a unique
+ JobParameters object. Each job
+ execution contains a reference to its corresponding job instance,
+ related Step Executions and step/chunk context data.
+
+
+
+
+ Step Stereotypes
+
+ This section describes stereotypes relating to the concept of a
+ batch step. A step is an entity that encapsulates a single, independent
+ phase of a batch job. Therefore, every batch job is composed entirely of
+ one or more batch steps.
+
+
+ Step Configuration
+
+ The step bean contains all of the information necessary to define
+ a discrete set of business logic within a job configuration. This is a
+ necessarily vague description because the contents of any given step
+ configuration are at the discretion of the developer writing jobs. A
+ step can be as narrowly defined as a single line of code or as broadly
+ defined as necessary to complete the entire work of your job. There are
+ several factors that will affect the breadth of your step
+ configurations.
+
+
+
+ Re-usability - step definitions can be shared between
+ jobs
+
+
+
+ Transaction Management - depending on your desired transaction
+ strategy, you may divide the work of your job differently between
+ steps
+
+
+
+ Extensibility - adequately granular definition of steps allows
+ the addition or subtraction of steps at a later time in the
+ appropriate position within your job configuration
+
+
+
+ Step configurations are defined by instantiating implementations
+ of the Step interface. Additionally,
+ the utility class StepSupport and its
+ abstract subclass, AbstractStep provide
+ a basic implementation of Step with
+ default functionality that should be common to any concrete Step
+ implementation. Generally, all step configuration implementations should
+ extend from these classes.
+
+ Two step implementation classes are available in the Spring Batch
+ framework, and they are each discussed in detail in other sections of
+ this guide. For most situations, the SimpleStep implementation is sufficient, but
+ custom control flow behavior and transaction management behavior can
+ also be configured by using a RepeatOperationsStep.
+
+
+
+ Step Instance
+
+ A step instance, represented by the StepInstance class, represents the business
+ concept of a single step within a job invocation. That is to say, every
+ job instance contains one or more step instances.
+
+ For example, suppose we have a job instance called
+ "foo-01-01-2008" that is an instance of a job configuration containing
+ three steps. Suppose these steps are named "step1", "step2" and "step3."
+ There will be corresponding "foo-01-01-2008#step1",
+ "foo-01-01-2008#step2" and "foo-01-01-2008#step3" step instances, which
+ will be distinct from the step instances of any other job instance (e.g.
+ those of "foo-01-02-2008").
+
+
+
+
+ The step instance naming here is for clarity, this is not necessarily how the instance will be named internally within the framework.
+
+
+ Each step instance will contain the current status of the batch
+ execution and a reference to its corresponding JobInstance. Additionally, a step instance keeps
+ track of how many attempts are made to run the corresponding step. Each
+ attempt to run a step will create a StepExecution, so a single job instance might
+ have several corresponding step executions.
+
+
+
+ Step Execution
+
+ A step execution represents the technical concept of a single
+ attempt to execute a step. It is a single attempt to execute the logic
+ represented by a step instance.
+
+ For instance, if we have a step instance "foo-01-01-2008#step1"
+ that fails to successfully complete its work the first time it is run,
+ when we attempt to run it again, a new step execution will be created.
+ Each of these step executions may represent a different invocation of
+ the batch framework, but they will all correspond to the same step
+ instance.
+
+ Step executions are represented by objects of the StepExecution class. These step executions are
+ created by an implementation of the JobExecutor interface from a given StepInstance and JobExecution. Each step execution contains a
+ reference to its corresponding step instance and job execution, and
+ transaction related data such as commit and rollback count and start and
+ end times. Additionally, each step execution will contain a set of
+ execution attributes, which will contain statistics and restart
+ data.
+
+
+
+
+ Chunk
+
+ Each step execution is divided into one or more transactions. These
+ individual transactions are sometimes referred to as "chunks." Each
+ chunk may represent one or many individual operations within a step
+ execution, depending on configuration. Although chunk-based processing
+ is an important feature of Spring Batch, there is no domain object that
+ directly corresponds to a chunk, as chunks are implicitly created through
+ the opening and closing of transactions.
+
+
+
+
+ Step Contribution
+
+ A step contribution represents the metadata for an uncommitted portion, or chunk,
+ of a step execution that is being "buffered" until a transaction boundary is reached
+ and the operations within the chunk are successfully committed. Each step contribution
+ is created by the enclosing step execution, and each contribution is later "applied"
+ by the enclosing step executor, allowing metadata to be applied only after each processed
+ chunk succeeds.
+
+
+
+
+ Tasklets
+
+ A tasklet represents the execution of a logical unit of work, as
+ defined by its implementation of the Spring Batch provided _Tasklet_
+ interface. Tasklets are used when defining step configurations to
+ specify the work done by the step. Subsequently, the logic in a tasklet
+ is atomic in terms of transactions. A transaction will never commit
+ until an entire tasklet execution is complete (unless an exception
+ occurs - a transaction might either commit or rollback if that behavior
+ is specified in the step's exception management strategy).
+
+
+
+
+ Item-Oriented Processing Stereotypes
+
+ A powerful batch processing paradigm implemented by the Spring Batch
+ framework is the concept of item-oriented processing. That is, doing work
+ by defining each unit of work as the operation of retrieving an item from
+ input and then processing that item, including any side effects that
+ processing might entail, such as file or database operations.
+
+
+ Reader and Writer Stereotypes
+
+ There are two basic stereotypes that represent the first-class
+ participants in item-oriented processing, item providers and item
+ processors. They are each represented by a simple interface provided by
+ the Spring Batch framework, which allows free reign over their
+ implementations and improves our ability to leverage the Spring
+ framework's dependency injection capabilities.
+
+
+ Item Readers
+
+ An item reader is an object that is used to retrieve the inputs
+ for a step, one at a time. When the item reader has exhausted the items
+ it can provide, it will indicate this in a meaningful way (generally by
+ returning null). When coupled with an item processor, this forms a
+ complete item-oriented process, as each item taken from the provider is
+ then processed by the writer.
+
+
+
+ Item Writers/Processors
+
+ An item writer is an object that is used to perform processing
+ for a step, one item at a time. Generally, an item writer has no
+ knowledge of the input it will receive next, only the item that that was
+ passed in its current invocation. As a result, item writers will
+ generally make no assumptions about the input they receive an treat
+ every item the same way and keep track of its own state between
+ invocations. When coupled with an item provider, this forms a complete
+ item-oriented process, as each item taken from the provider is then
+ processed by the processor.
+
+
+
+
+
+ Support Stereotypes
+
+ While item readers and writers serve as the main entry points
+ for item-oriented processing, they might be supplemented by a number of support
+ classes that perform specific tasks within the reader / writer
+ lifecycle. These support stereotypes are useful for dividing the work of
+ item readers and writers into reusable pieces, as well as abstracting
+ away the details of processing, such as interaction with external systems.
+ Additionally, they give us another opportunity to leverage the powerful
+ configuration features of the Spring framework, as we can switch between
+ several beans implementing these support interfaces without changing the
+ driving item reader or writer.
+
Item Transformers
- An item transformer is a class that is capable of taking an object and changing it somehow before processing occurs. For instance, an item transformer my alter an object by changing its properties or by replacing it with another object entirely, such as a wrapper or derivative object. It can also be defined as an adaptor, allowing an object of one type to be converted for use as an object of a second type.
-
-
-
- Item Writers
- An item writer is a class that mediates interactions with an external target of output data, such as a file or database. An item writer often serves as a support for an item processor, typically abstracting away the details of interaction, such as the creation and maintenance of file handles, sockets, database connections and other output-related tasks such as buffering and stream flushing.
-
+
+ An item transformer is a class that is capable of taking an object
+ and changing it somehow before processing occurs. For instance, an item
+ transformer my alter an object by changing its properties or by
+ replacing it with another object entirely, such as a wrapper or
+ derivative object. It can also be defined as an adaptor, allowing an
+ object of one type to be converted for use as an object of a second
+ type.
-
+
High Level Processing Flow
diff --git a/docs/src/site/docbook/reference/index.xml b/docs/src/site/docbook/reference/index.xml
index a3334e686..578076866 100644
--- a/docs/src/site/docbook/reference/index.xml
+++ b/docs/src/site/docbook/reference/index.xml
@@ -37,6 +37,6 @@
-
+