Tenemos a nuestra disposición muchos frameworks para facilitar el desarrollo de aplicaciones Web, para la construcción de servicios web, para el mapeo objeto-relacional con bases de datos, pero los frameworks que intentan estandarizar tareas propias del procesado por lotes no son muy comunes. Spring Batch es el framework para procesamiento por lotes de Spring Framework.
En el diagrama de abajo vemos un diagrama típico de la arquitectura de procesamiento por lotes. Los elementos grises corresponden a recursos externos como planificadores o bases de datos. Los azules son los servicios que proporciona Spring Batch a los programadores. Por último los elementos coloreados de verde son las piezas que debe construir un programador para llevar a cabo una tarea por lotes específica.
Como vemos la arquitectura de procesamiento por lotes se divide en 4 capas:
- Capa de ejecución. Está relacionada con la planificación y el lanzamiento de la aplicación.
- Capa de tareas. Es la responsable de la ejecución de las tareas. En cada tarea se ejecutan secuencialmente un determinado número de pasos, asegurando que todos ellos acaban en un estado correcto y se aplican las políticas apropiadas.
- Capa de aplicación. Contiene los elementos necesarios para ejecutar la lógica de procesamiento por lotes aplicando unas políticas determinadas.
- Capa de datos. Son las bases de datos, ficheros o colas fuentes o destinos del procesamiento por lotes.
El elemento principal de Spring Batch es el Job (Trabajo). Está compuesto por varios Steps (Pasos), que se ejecutan de forma secuencial.
Un Job puede configurarse con distintos parámetros que lo diferencian. Un Job con unos determinados parámetros es un JobInstance. Un JobInstance representa la ejecución de un JobExecution.
Spring Batch lleva un registro de todas las ejecuciones y parámetros con las que se lanzaron los Jobs. El encargado de guardar estos registros es el JobRepository, que cuenta con una implementación para almacenar esta información en base de datos o memoria.
La interfaz de un JobLauncher es la siguiente:
package org.springframework.batch.core.launch;
(...)
public interface JobLauncher {
public JobExecution run(Job job, JobParameters jobParameters) throws JobExecutionAlreadyRunningException,
JobRestartException, JobInstanceAlreadyCompleteException,
JobParametersInvalidException;
}
Este método acepta dos parámetros: el Job (normalmente configurado en un fichero de configuración XML ) y una clase JobParameters (que se crea dinámicamente en el proceso de ejecución de tareas).
Nuestras aplicaciones pueden usar esta clase para lanzar un Job, pero también se puede realizar mediante línea de comandos o planificadores como Quartz o Cron.
El JobLauncher encapsula políticas para lanzar los Jobs síncrona o asíncronamente.
El JobRepository se encarga de almacenar información sobre las ejecuciones de los Jobs. Existen dos implementaciones básicas de JobRepository, una que almacena la información en memoria y otra en base de datos.
- MapJobRepositoryFactoryBean. Esta implementación almacena toda la información de las ejecuciones de los Jobs en memoria.
<bean id="transactionManager" class="org.springframework.batch.support.transaction.ResourcelessTransactionManager"/><bean id="jobRepository" class="org.springframework.batch.core.repository.support.MapJobRepositoryFactoryBean"> <property name="transactionManager" ref="transactionManager"/>
</bean>
</beans>
<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close"> <property name="driverClassName" value="org.apache.derby.jdbc.ClientDriver"/> <property name="url" value="jdbc:derby://localhost:1527/springbatch"/><property name="username" value="springbatch"/>
<property name="password" value="springbatch"/>
</bean>
<bean id="transactionManager"
class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
<property name="dataSource" ref="dataSource" />
</bean>
<bean id="jobRepository"
class="org.springframework.batch.core.repository.support.JobRepositoryFactoryBean"
p:databaseType="derby"
p:dataSource-ref="dataSource"
p:transactionManager-ref="transactionManager"/>
- JobRepositoryFsctoryBean. Esta implementación utiliza un modelo de datos propio de Spring Batch.para almacenar la información de las ejecuciones. Los scripts de las diferentes bases de datos se encuentra en la raíz del fichero spring-batch-core{VERSION}.jar.
<bean id="dataSource" class="org.apache.commons.dbcp.BasicDataSource" destroy-method="close"> <property name="driverClassName" value="org.apache.derby.jdbc.ClientDriver"/> <property name="url" value="jdbc:derby://localhost:1527/springbatch"/><property name="username" value="springbatch"/>
<property name="password" value="springbatch"/>
</bean>
<bean id="transactionManager"
class="org.springframework.jdbc.datasource.DataSourceTransactionManager">
<property name="dataSource" ref="dataSource" />
</bean>
<bean id="jobRepository"
class="org.springframework.batch.core.repository.support.JobRepositoryFactoryBean"
p:databaseType="derby"
p:dataSource-ref="dataSource"
p:transactionManager-ref="transactionManager"/>
Un Job está compuesto por varios Steps. Los Steps más comunes se implementan mediante las clases:
- SimpleStepFactoryBean. Crea Steps que constan de un lector de datos (ItemReader) y un procesador de datos (ItemWriter). El ItemReader se encarga de leer datos de algún origen. Cada dato se pasará al ItemWriter para su procesamiento. Existen Reader y Writer por defecto en Spring Batch (base de datos, ficheros, colas...). Además se pueden implementar nuevos con facilidad.
- TaskletStep. Es una acción básica en Spring Batch. Un Step que ejecuta un tasklet se implementa con la clase TaskletStep.
Visto en DosIdeas
Comentarios
Publicar un comentario