Novidades da JSR 352 – Batch Applications

Artigo no estilo: Curso

Em abril de 2013, a versão final da JSR 352 foi disponibilizada. Esta nova JSR, que tem o nome de Batch Applications for the Java Platform, especifica um modelo de programação voltado para processamento em lote (batch), permitindo assim o desenvolvimento de aplicações batch de forma simplificada.

Essa facilidade só é possível através da implementação de interfaces bem definidas e o uso de arquivos de configuração, que nos permitem desenvolver jobs, fazendo com que vários steps sejam executados em prol de um objetivo específico.

Para quem não está habituado com essa nomenclatura, um job pode ser considerado como a unidade básica de uma execução batch. Um job descreve uma sequência de passos (steps) que, juntos, conseguem atender a um objetivo de negócio específico, como um processamento de operações de DOC em uma instituição financeira.

Portanto, a proposta desta JSR é descrever uma linguagem específica para jobs, denominada Job Specification Language, a partir do modelo de programação Java, possibilitando com ela o desenvolvimento de um ambiente de execução para aplicativos batch de forma padronizada.

Embora anunciada em meio a todas as melhorias da Java EE 7, esta JSR foi projetada para uso em ambas as plataformas, Java SE e Java EE, e possui algumas características importantes, como:

· Configuração orientada a XML;

· Interfaces e classes abstratas para estabelecimento de contratos;

· Possui suporte a injeção de dependências;

· Comunicação entre os elementos da solução através de contextos.

Deste modo, temos como meta no decorrer de dois artigos trabalhar toda a proposta desta nova JSR, explorando desde a parte teórica, através da conceituação dos elementos chaves, até a parte técnica, através de uma implementação utilizando a nova plataforma Java EE.

Introdução ao Processamento Batch

Antes de começarmos a falar sobre a JSR 352, é importante termos o discernimento entre os dois principais tipos de processamento existentes hoje, como o processamento batch se encaixa nesse meio e quais são as suas aplicabilidades, permitindo que todos os leitores consigam aproveitar o assunto abordado.

Como informado, basicamente existem dois tipos de processamento nas organizações. São eles

· Processamento Batch: Nesse tipo de processamento, também conhecido como processamento em lote, as informações são obtidas por diversos meios. Elas podem ser coletadas de uma base de dados, recebidas através da leitura de filas de mensagens ou também armazenadas pelo próprio sistema e submetidas a processamento posterior.

Normalmente um processamento batch não requer nenhuma intervenção do usuário, pois o mesmo acaba sendo automatizado por inteiro. O que acontece manualmente neste caso é apenas a reexecução de uma determinada etapa do processo, caso o mesmo apresente algum tipo de problema ao final de sua execução.

No dia a dia de uma organização, temos diversos processos batch, e eles estão em qualquer segmento, como: Petroquímico, Varejista, Energia, Financeiro, Telecomunicação, entre outros. Nessas organizações, podemos, por exemplo, ter os seguintes processos considerados como batch:

o Processos de convivência, visando à sincronização/equalização de informações;

o Processos voltados para BI (Business Intelligence) como o ETL, no qual existe a necessidade de se processar grandes volumes de dados aplicando regras de conversão, regras de negócio e redefinição de layout, visando o armazenamento posterior das informações em um Data Warehouse ou Data Mart;

o Processos de contabilização de movimentos diários;

o Operações bancárias de DOC;

o Operações bancárias de fechamento financeiro mensal;

o Operações bancárias de movimentações financeiras em geral;

o Equalização de contas bancárias abertas no dia;

o Leituras de consumo de água, luz, cartões de crédito e débito.o

· Processamento On-line: Se trata do processamento que ocorre quase que em tempo real, no qual as informações são processadas no mesmo momento em que são registradas. Este é o processo que mais conhecemos, pois basicamente é o tipo de processamento que mais faz parte de nosso dia a dia. Podemos citar as seguintes situações como exemplos de processos on-line:

o Aquisição de créditos para celulares pré-pagos;

o Operações financeiras de TED;

o Aquisição de ações por meio de sistemas de home broker;

o Operações com cartões de débito, onde o débito do valor proveniente de uma operação é realizado logo após a submissão da mesma.

Levando em consideração que já entendemos o que é um job e o que é um step, podemos considerar o processamento batch como sendo a execução de diversos jobs contendo diversos steps que não requerem interação com o usuário e possuem o objetivo de tratar grandes cargas de trabalho.

Normalmente são responsáveis por processos críticos e tarefas de longa duração e hoje, diversas empresas no mercado dependem e muito das informações que são geradas através de processamentos batch. Por este motivo, os processos batch, em sua maioria, possuem janelas (oportunidades para execução) específicas de tempo dentro das organizações para serem executados.

Como os processos batch não requerem interação com o usuário, os mesmos podem ser executados a partir de várias formas de inicialização, incluindo execução ad hoc (com uma finalidade específica), agendamento ou sob demanda.

Ao iniciarmos o entendimento sobre processos batch, a seguinte pergunta pode nos vir à cabeça: por que os processos batch precisam ser executados em uma janela de tempo específica? Um dos principais motivos é o alto consumo dos recursos da máquina que esses processos necessitam para serem mantidos em execução.

Caso os mesmos fossem processados a qualquer momento, por exemplo, em horário comercial, provavelmente inviabilizariam o tempo de resposta das aplicações que atendem à parte operacional, pois tanto os processos batch quanto as aplicações operacionais compartilham, muitas vezes, o mesmo hardware servidor e, consequentemente, seus recursos.

Por causa disso, também existe uma grande probabilidade de haver concorrência no acesso às informações da organização.

Deste modo, o planejamento da execução de processos batch deve ser avaliado caso a caso e diversos fatores devem ser levados em consideração.

Em sua maioria, os processos batch possuem um mecanismo de log e checkpoint devido à grande quantidade de informações processadas e sua criticidade. Além disso, dependendo do caso, podem ser executados em paralelo para viabilizar um aumento de performance.

Por tudo isso, é quase que uma premissa que se tenha uma ferramenta de monitoramento desses processos, para que a área de produção da organização tenha controle sobre todos os jobs em execução.

Por fim, vale ressaltar que os processos batch, em sua maioria, são agendados. Desta forma, se faz necessária a utilização de mecanismos de scheduling para que seja possível realizar tais agendamentos.

Exemplos de mecanismos que podem ser utilizados são EJB timers ou softwares como Control-M, Tivoli Workload Scheduler, UC4 ONE Automation, entre outros. Alguns inclusive dispõem de interface de monitoramento.

Java Batch API (JSR 352) – Entendendo a Teoria

A elaboração da JSR 352 obviamente teve alguns motivadores que foram levados em consideração, como por exemplo, a consolidação do processamento batch nas organizações e a concorrência com relação a produtos existentes, como o Spring Batch.

Além disso, diversas organizações acabaram desenvolvendo soluções batch personalizadas para atender as suas necessidades. Este também foi outro motivo levado em consideração para a construção desta especificação.

A JSR 352 tem por objetivo fornecer a opção padrão para organizações que trabalham com processos batch, servindo para tarefas não interativas e processos longos, onde se pode ter um processamento computacional intensivo.

Além disso, a implementação desta JSR permite a execução destes processos de forma sequencial ou em paralelo e possibilita a inicialização dos mesmos através de chamadas ad hoc ou mecanismos de agendamento, como os citados anteriormente, mas que não estão no escopo da especificação.

A partir da utilização desta API podemos definir Job e Steps para realização de atividades que visam atingir objetivos específicos. Todas as configurações de jobs e seus respectivos steps são realizadas por meio de arquivos de configuração no formato XML.

A criação dos processos é feita com a implementação de interfaces bem definidas, que serão descritas em sua teoria no decorrer do artigo.

Com a utilização da JSR 352, podemos notar uma clara separação de responsabilidades e uma arquitetura familiar para arquitetos que já conhecem a arquitetura padrão de processos batch.

Na Figura 1 podemos visualizar, de forma simplificada, os conceitos chave desta arquitetura, que já é utilizada por décadas e está bem consolidada em grandes organizações. Essa figura apresenta uma visão geral dos componentes que fazem parte de um processo batch.

Figura 1. Visão Geral – Arquitetura de Processos Batch.

Para facilitar o entendimento dessa arquitetura, podemos interpretá-la da seguinte maneira:

· Um JobOperator é necessário para que um Job possa ser executado;

· Um Job possui um ou mais steps;

· Cada Step possui apenas um ItemReader, responsável pela leitura (recuperação) dos dados de entrada, um ItemProcessor, que representa o motor de negócio (onde é armazenada a lógica de negócio) e um ItemWriter, que corresponde ao objeto que viabiliza e provê a saída dos dados (muitas vezes, a persistência);

· Todo o processo (JobOperator, Job e Steps) em execução necessita ter seus metadados armazenados em um repositório, para que possam ser realizadas consultas futuras. O JobRespository é o local onde estes metadados são armazenados.

Todos esses itens serão mais bem descritos posteriormente.

Em uma arquitetura batch, podemos ter diversas implementações de acordo com a sua plataforma, que pode ser, por exemplo, COBOL/Mainframe, Java e C++. Para quem já trabalhou ou trabalha com COBOL, a linguagem que corretamente espelha a JSR 352 é a JCL (Job Control Language).

Esta é utilizada para realizar o tratamento de arquivos a partir da execução de programas desenvolvidos em linguagens como COBOL, Easytrieve, Assembler ou a partir da execução de aplicativos utilitários instalados em sistemas operacionais presentes em Mainframes.

Além disso, a arquitetura da JSR 352 especifica as camadas, componentes e todos os serviços necessários para o desenvolvimento de aplicações batch simples e complexas.

Devido à grande quantidade de informações contida na JSR 352, neste primeiro artigo trataremos de conceituar os quesitos básicos que permitirão o entendimento dos demais pontos desta especificação e também permitirão que você, leitor, consiga ter o embasamento teórico necessário para que seja possível desenvolvermos uma aplicação batch no próximo artigo."