More work on chapter 2, I completely updated the reference model and made some javadoc updates in the repository.
This commit is contained in:
Binary file not shown.
@@ -49,20 +49,19 @@
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title id="s.2">Simple Batch Execution Environment high level flow and
|
||||
interaction of the architecture.</title>
|
||||
<title id="s.2">Batch Application Style Interactions and Services</title>
|
||||
|
||||
<mediaobject>
|
||||
<imageobject role="fo">
|
||||
<imagedata align="center"
|
||||
fileref="images/spring-batch-reference-model.png"
|
||||
format="JPG" />
|
||||
format="PNG" />
|
||||
</imageobject>
|
||||
|
||||
<imageobject role="html">
|
||||
<imagedata align="center"
|
||||
fileref="images/spring-batch-reference-model.png"
|
||||
format="JPG" />
|
||||
format="PNG" />
|
||||
</imageobject>
|
||||
|
||||
<caption><para>Figure 2.1: Batch Stereotypes</para></caption>
|
||||
@@ -211,8 +210,8 @@
|
||||
meaning the January 1st run processes data for January 1st, etc) That is
|
||||
to say, each <classname>JobInstance</classname> can have multiple
|
||||
executions. (<classname>JobExecution</classname> is discussed in more
|
||||
detail below) and only one instance can be running at a given time.
|
||||
</para>
|
||||
detail below) and only one instance can be running at a given
|
||||
time.</para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
@@ -247,7 +246,7 @@
|
||||
<classname>JobInstance</classname> of the EndOfDay job for 01-01-2008,
|
||||
as described above, that fails to successfully complete its work the
|
||||
first time it is run, when we attempt to run it again (with the same job
|
||||
parameters of 01-01-2008), a new job execution will be created. </para>
|
||||
parameters of 01-01-2008), a new job execution will be created.</para>
|
||||
|
||||
<para>A Job defines what a job is and defines how it is to be executed,
|
||||
and <classname>JobInstance</classname> is a purely organization object
|
||||
@@ -673,17 +672,56 @@
|
||||
</tgroup>
|
||||
</table>
|
||||
</section>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title id="s.2.1.6">Tasklets</title>
|
||||
<section>
|
||||
<title>JobRepository</title>
|
||||
|
||||
<para>A <classname>Tasklet</classname> represents the execution of a
|
||||
logical unit of work, as defined by its implementation of the Spring
|
||||
Batch provided <classname>Tasklet</classname> interface. A
|
||||
<classname>Tasklet</classname> is useful for encapsulating processing
|
||||
logic that is not natural to split into read-(transform)-write phases,
|
||||
such as invoking a system command or a stored procedure.</para>
|
||||
</section>
|
||||
<para>The <classname>JobRepository</classname> is the persistence
|
||||
mechanism for all of the Stereotypes mentioned above. When a job is first
|
||||
launched, a <classname>JobExecution</classname> is obtained by calling the
|
||||
repository's <methodname>createJobExecution</methodname> method, and
|
||||
during the course of execution, <classname>StepExecution</classname> and
|
||||
<classname>JobExecution</classname> are persisted by passing them to the
|
||||
repository:</para>
|
||||
|
||||
<programlisting> public interface JobRepository {
|
||||
|
||||
public JobExecution createJobExecution(Job job, JobParameters jobParameters)
|
||||
throws JobExecutionAlreadyRunningException, JobRestartException;
|
||||
|
||||
void saveOrUpdate(JobExecution jobExecution);
|
||||
|
||||
void saveOrUpdate(StepExecution stepExecution);
|
||||
|
||||
void saveOrUpdateExecutionContext(StepExecution stepExecution);
|
||||
|
||||
StepExecution getLastStepExecution(JobInstance jobInstance, Step step);
|
||||
|
||||
int getStepExecutionCount(JobInstance jobInstance, Step step);
|
||||
|
||||
}
|
||||
</programlisting>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>JobLauncher</title>
|
||||
|
||||
<para><classname>JobLauncher </classname>represents a simple interface for
|
||||
launching a <classname>Job</classname> with a given set of
|
||||
<classname>JobParameters</classname>:</para>
|
||||
|
||||
<programlisting> public interface JobLauncher {
|
||||
|
||||
public JobExecution run(Job job, JobParameters jobParameters) throws JobExecutionAlreadyRunningException,
|
||||
JobRestartException;
|
||||
}
|
||||
</programlisting>
|
||||
|
||||
<para>It is expected that implementations will obtain a valid
|
||||
<classname>JobExecution</classname> fromt he
|
||||
<classname>JobRepository</classname> and execute the
|
||||
<classname>Job</classname>.</para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
@@ -708,6 +746,17 @@
|
||||
various implementations can be found in Chatper 3.</para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title id="s.2.1.6">Tasklet</title>
|
||||
|
||||
<para>A <classname>Tasklet</classname> represents the execution of a
|
||||
logical unit of work, as defined by its implementation of the Spring Batch
|
||||
provided <classname>Tasklet</classname> interface. A
|
||||
<classname>Tasklet</classname> is useful for encapsulating processing
|
||||
logic that is not natural to split into read-(transform)-write phases,
|
||||
such as invoking a system command or a stored procedure.</para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title id="s.3">High Level Processing Flow</title>
|
||||
|
||||
|
||||
@@ -2,101 +2,97 @@
|
||||
<!DOCTYPE chapter PUBLIC "-//OASIS//DTD DocBook XML V4.4//EN"
|
||||
"http://www.oasis-open.org/docbook/xml/4.4/docbookx.dtd">
|
||||
<chapter id="execution">
|
||||
<title>The Batch Execution Environment</title>
|
||||
<title>Executing A Job</title>
|
||||
|
||||
<section>
|
||||
<title>Introduction</title>
|
||||
<section>
|
||||
<title>Introduction</title>
|
||||
|
||||
<para>
|
||||
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.
|
||||
</para>
|
||||
<para>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.</para>
|
||||
|
||||
<para>
|
||||
The execution environment is responsible for providing implementations of the core domain concepts. This
|
||||
includes:
|
||||
</para>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Run Tier - Implement the bootstrapping and launching of the Execution Environment.</para>
|
||||
</listitem>
|
||||
<para>The execution environment is responsible for providing
|
||||
implementations of the core domain concepts. This includes:</para>
|
||||
|
||||
<listitem>
|
||||
<para>Job Tier - Implement the Job and Step strategies.</para>
|
||||
</listitem>
|
||||
<itemizedlist>
|
||||
<listitem>
|
||||
<para>Run Tier - Implement the bootstrapping and launching of the
|
||||
Execution Environment.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>Application Tier - Implement the ItemReader and ItemWriter (or Tasklet) strategies.</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Job Tier - Implement the Job and Step strategies.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Data Tier - Implement a Repository solution for storing the persistence state of the batch domain.
|
||||
</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
<para>
|
||||
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.
|
||||
</para>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>
|
||||
In the Run Tier, a single Java Project may have one or more Jobs. Jobs are configured with the Job
|
||||
bean.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Application Tier - Implement the ItemReader and ItemWriter (or
|
||||
Tasklet) strategies.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
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.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>Data Tier - Implement a Repository solution for storing the
|
||||
persistence state of the batch domain.</para>
|
||||
</listitem>
|
||||
</itemizedlist>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
Steps are responsible for executing business logic and recording progress in a StepExecution.
|
||||
</para>
|
||||
</listitem>
|
||||
<para>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.</para>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
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.
|
||||
</para>
|
||||
</listitem>
|
||||
<orderedlist>
|
||||
<listitem>
|
||||
<para>In the Run Tier, a single Java Project may have one or more
|
||||
Jobs. Jobs are configured with the Job bean.</para>
|
||||
</listitem>
|
||||
|
||||
<listitem>
|
||||
<para>
|
||||
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.
|
||||
</para>
|
||||
</listitem>
|
||||
<listitem>
|
||||
<para>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.</para>
|
||||
</listitem>
|
||||
|
||||
</orderedlist>
|
||||
</section>
|
||||
<listitem>
|
||||
<para>Steps are responsible for executing business logic and recording
|
||||
progress in a StepExecution.</para>
|
||||
</listitem>
|
||||
|
||||
<section>
|
||||
<title>Simple Batch Execution Environment</title>
|
||||
<para></para>
|
||||
</section>
|
||||
<listitem>
|
||||
<para>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.</para>
|
||||
</listitem>
|
||||
|
||||
<section>
|
||||
<title>Configuration</title>
|
||||
<para>
|
||||
<programlisting>
|
||||
<listitem>
|
||||
<para>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.</para>
|
||||
</listitem>
|
||||
</orderedlist>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>Simple Job Execution Flow</title>
|
||||
|
||||
<para></para>
|
||||
</section>
|
||||
|
||||
<section>
|
||||
<title>Configuration</title>
|
||||
|
||||
<para><programlisting>
|
||||
<property name="itemProvider">
|
||||
<bean class="org.springframework.batch.sample.item.provider.PlayerItemProvider">
|
||||
<property name="inputSource" ref="playerFileInputSource" />
|
||||
@@ -105,14 +101,12 @@
|
||||
</property>
|
||||
</bean>
|
||||
</property>
|
||||
</programlisting>
|
||||
</para>
|
||||
</programlisting></para>
|
||||
|
||||
<para>The LineTokenizer is just one additional property to the
|
||||
InputSource as seen here:</para>
|
||||
<para>The LineTokenizer is just one additional property to the InputSource
|
||||
as seen here:</para>
|
||||
|
||||
<para>
|
||||
<programlisting>
|
||||
<para><programlisting>
|
||||
<property name="tokenizer">
|
||||
<bean
|
||||
class="org.springframework.batch.io.file.support.transform.DelimitedLineTokenizer">
|
||||
@@ -120,9 +114,6 @@
|
||||
value="ID,lastName,firstName,position,birthYear,debutYear" />
|
||||
</bean>
|
||||
</property>
|
||||
</programlisting>
|
||||
</para>
|
||||
|
||||
</section>
|
||||
|
||||
</chapter>
|
||||
</programlisting></para>
|
||||
</section>
|
||||
</chapter>
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 32 KiB After Width: | Height: | Size: 37 KiB |
Reference in New Issue
Block a user