O Java EE 7 foi lançado em junho trazendo um conjunto de novas especificações, entre elas a JSR-352. Essa nova especificação define um modelo de programação para processamento em lote dentro da plataforma Java EE e baseia-se fortemente no projeto Spring Batch da VMware. O Spring Batch também recebeu atenção recentemente por conta de um lançamento importante que traz configurações mais enxutas e simplifica o acesso a dados.
A JSR-352 (Batch Applications for the Java Platform) oferece aos desenvolvedores um modelo de programação para desenvolver sistemas de processamento em lote robustos. O ponto central desse modelo de programação é um padrão de desenvolvimento emprestado do Spring Batch: o Reader-Processor-Writer. Esse pattern incentiva os desenvolvedores a adotar um estilo padrão de processamento orientado a pedaços (chunks).
O padrão Reader-Processor-Writer é composto por um fluxo de trabalho de três passos que os desenvolvedores devem seguir:
- Uma classe ItemReader que consome um pedaço do dado a ser processado (normalmente um único registro);
- Um ItemProcessor que processa cada um dos pedaços, aplicando a lógica de negócio e de domínio;
- E, finalmente, um ItemWriter para o qual os registros serão delegados após o processamento e agregados.
De acordo com a especificação, os Jobs (tarefas) são descritos através de documentos XML e contém Steps (passos) no fluxo de processamento. Cada Step é responsável por descrever como cada pedaço de dado será processado e qual o intervalo entre os commits. Requisitos mais complexos para se processar determinados Steps do fluxo de trabalho podem ser implementados com um batchlet. Um batchlet é a versão da JSR-352 para o tasklet do Spring Batch, o qual oferece estratégias para processar Steps.
A JSR-352 também emprega o padrão do Spring Batch para acessar e controlar jobs. Jobs são invocados através de um JobOperator e os resultados são acessíveis através de um JobRepository. No Spring Batch o nome JobRepositorypermanece o mesmo, enquanto o JobOperator é chamado de JobLauncher.
A forma de definição de jobs no Java EE 7 é um pouco diferente do Spring Batch. Os desenvolvedores são obrigados a colocar os documentos XML de configuração de jobs no diretório META-INF/batch-jobs dos projetos. Com o Spring Batch, os desenvolvedores podem colocar as configurações de jobs em qualquer local do contexto do Spring para torná-las disponíveis no container.
Os arquivos XML de configuração de jobs no Java EE 7 definem classes concretas para as interfaces ItemReader, ItemProcessor e ItemWriter, além de especificar o tamanho do buffer, o intervalo entre commits e a política de checkpoints. A política de checkpoints indica como os commits serão tratados. O valor padrão é "item", mas os desenvolvedores podem optar por usar "time" (tempo) como estratégia. O primeiro caso especifica o número de registos processados, enquanto o último descreve os segundos decorridos entre um commit e outro.
<job xmlns="http://batch.jsr352/jsl">
<step id="myStep">
<chunk
reader="MyItemReader"
writer="MyItemWriter"
processor="MyItemProcessor"
buffer-size="5"
checkpoint-policy="item"
commit-interval="10" />
</step>
</job>
A configuração de jobs no Spring Batch é quase idêntico ao Java EE 7. A exceção é que os passos (steps) são colocados em uma diretiva tasklet. Os atributos reader, process e writer de configuração dos chunks (pedaços) são referências para beans que existem no contexto da aplicação. A partir da versão 2.2.0, o intervalo de commits na configuração de chunks indica quantos itens devem ser processados antes de se efetivar um commit.
<job id="myJob">
<step id="myStep">
<tasklet>
<chunk
reader="myItemReader"
processor="myItemProcessor"
writer="myItemWriter"
commit-interval="2" />
</tasklet>
</step>
</job>
<bean class="...MyItemReader" />
<bean class="...MyItemProcessor" />
<bean class="...MyItemWriter" />
Embora o Spring Batch esteja atualmente sendo trabalhado para se tornar aderente à JSR-352, ele vai além da especificação para oferecer aos desenvolvedores uma perfeita integração com outros componentes do ecossistema Spring. No caso do processamento em lote, o Spring Data pode ser aproveitado diretamente como uma instância de ItemReader no padrão Reader-Processor-Writer, para permitir que os desenvolvedores recuperem chunks de um repositório de dados do Spring Data. A versão 2.2.0 do Spring Batch oferece interface simplificada para bancos de dados MongoDB e Neo4J usando o Spring Data.
Além da interface simplificada para leitura de várias fontes de dados, a última versão do Spring Batch disponibiliza uma extensão para configuração do Spring Java, de forma a simplificar as funcionalidades de processamento em lote. Para habilitar essa configuração simplificada, os desenvolvedores só precisam fornecer a anotação @EnableBatchProcessing em uma classe anotada com @Configuration. A partir dessa classe, qualquer recurso de processamento em lote, como a JobRepository e JobLauncher, pode ser diretamente injetado sem nenhuma configuração adicional.
@Configuration
@EnableBatchProcessing
public class AppConfig {
@Autowired
private JobBuilderFactory jobs;
@Bean
public Job job() {
return jobs.get("myJob").start(step1()).next(step2()).build();
}
@Bean
protected Step step1() {
...
}
@Bean
protected Step step2() {
...
}
}
Além das melhorias no Spring Batch 2.2.0 para recuperação de dados e configuração, esse lançamento também atualizou sua dependência com o framework Spring. Agora os desenvolvedores que quiserem utilizar a última versão do Spring Batch terão que atualizar a versão do Spring para a 3.1.2 (mínima).