More work on chapter 2, I completely updated the reference model and made some javadoc updates in the repository.

This commit is contained in:
lucasward
2008-03-13 04:29:11 +00:00
parent 070fb68cad
commit c14e334072
4 changed files with 150 additions and 110 deletions

View File

@@ -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>

View File

@@ -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>
&lt;property name="itemProvider"&gt;
&lt;bean class="org.springframework.batch.sample.item.provider.PlayerItemProvider"&gt;
&lt;property name="inputSource" ref="playerFileInputSource" /&gt;
@@ -105,14 +101,12 @@
&lt;/property&gt;
&lt;/bean&gt;
&lt;/property&gt;
</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>
&lt;property name="tokenizer"&gt;
&lt;bean
class="org.springframework.batch.io.file.support.transform.DelimitedLineTokenizer"&gt;
@@ -120,9 +114,6 @@
value="ID,lastName,firstName,position,birthYear,debutYear" /&gt;
&lt;/bean&gt;
&lt;/property&gt;
</programlisting>
</para>
</section>
</chapter>
</programlisting></para>
</section>
</chapter>

Binary file not shown.

Before

Width:  |  Height:  |  Size: 32 KiB

After

Width:  |  Height:  |  Size: 37 KiB