Base de Conhecimento de Gestão Comercial de Saneamento

Você carregou uma revisão antiga desse documento! Se você salvá-la, irá criar uma nova versão com esses dados.

<h1>Proposta de Arquitetura da Evolução do Módulo Batch</h1>
<div class="level1">

</div>

<h2>Contextualização</h2>
<div class="level2">

<p>
Pretende-se com essa wiki, apresentar e receber contribuições dos interessados quanto a descrição da organização do módulo Batch, estabelecendo as principais decisões de projeto com o objetivo de realizar os requisitos não funcionais.
</p>

</div>

<h3>Motivação</h3>
<div class="level3">

<p>
Por motivos históricos o Gsan permanece utilizando praticamente a mesma versão do servidor de aplicação JBoss (4.x). O JBoss 4.0.0 teve sua data de lançamento em setembro de 2004, e o último release 4.2.3, foi lançado em julho de 2008. Essa versão é bastante antiga e apresenta uma série de vulnerabilidades de segurança conhecidas e não corrigidas. Portanto, faz-se necessário e urgente uma atualização da versão do servidor de aplicação do Gsan. A versão mais recente é o Wildfly 9.0.2 Final de outubro de 2015.
</p>

<p>
EJB 2 é uma parte requerida do Java EE 7, e como o WildFly é Java EE 7 compatível ele dá suporte a tecnologia EJB 2, com exceção de um determinado tipo de bean, chamado entity-bean, cuja persistência é gerenciada pelo container e que agora tornou-se opcional. Como o sistema Gsan só apresenta EJB 2 do tipo session bean e message driven bean, é tecnicamente possível realizar o deployment do Gsan no Wildfly.
</p>

</div>

<h3>Objetivo</h3>
<div class="level3">

<p>
Este documento compreende as informações pertinentes a Arquitetura Candidata para a atualização técnológica do Módulo Batch do GSAN. O documento está divido em três principais seções: <a href="/doku.php?id=comitegestor:arquiteturabatch#contexto_do_sistema" class="wikilink1" title="comitegestor:arquiteturabatch" data-wiki-id="comitegestor:arquiteturabatch">Contexto do Sistema</a>, <a href="/doku.php?id=comitegestor:arquiteturabatch#requisitos_arquiteturais" class="wikilink1" title="comitegestor:arquiteturabatch" data-wiki-id="comitegestor:arquiteturabatch">Requisitos Arquiteturais</a> e <a href="/doku.php?id=comitegestor:arquiteturabatch#representacao_da_arquitetura" class="wikilink1" title="comitegestor:arquiteturabatch" data-wiki-id="comitegestor:arquiteturabatch">Representação da Arquitetura</a>. 
</p>

<p>
O Contexto do Sistema tem a finalidade de descrever o contexto e o ambiente que o sistema em desenvolvimento esta inserido, é apresentado uma breve explanação em relação ao negócio e enumerados os usuários, canais de comunicação e sistemas externos que o módulo em desenvolvimento possui interação.
</p>

<p>
Na seção Requisitos Arquiteturais são enumerados os requisitos não-funcionais e requisitos funcionais relevantes do ponto de vista arquitetural. A Representação da Arquitetural foi dividida em Visão Conceitual, Visão dos Módulos, Visão da Execução e Visão do Código.
</p>

<p>
Para fechamento do documento temos duas seções complementares: Definições, acrônimos e abreviações e as Referências.
</p>

</div>

<h3>Estratégia</h3>
<div class="level3">

<p>
Migrar a aplicação para permitir a execução no Wildfly com o mínimo de interferência nas regras de negócio da aplicação. Será utilizado um migrador automático com o objetivo de diminuir o tempo necessário e permitir a reprodutibilidade das alterações de forma a minimizar possíveis bugs. Serão abordados os principais elementos arquiteturais e as bibliotecas utilizadas pelo Gsan de forma que seja possível o funcionamento do Gsan no Wildfly.
</p>

</div>

<h3>Benefícios</h3>
<div class="level3">
<ul>
<li class="level1"> Atualização tecnológica e de segurança</li>
<li class="level1"> Aumento da performance</li>
<li class="level1"> Possibilidade de utilização de cluster</li>
<li class="level1"> Alta disponibilidade</li>
<li class="level1"> Balanceamento de carga</li>
<li class="level1"> Administração de forma centralizada (domain)</li>
<li class="level1"> Melhores ferramentas de administração e monitoramento</li>
</ul>

</div>

<h2>Contexto do Sistema</h2>
<div class="level2">

</div>

<h3>Negócio</h3>
<div class="level3">

<p>
GSAN, sistema proposto para atender a demanda comercial de médias e grandes empresas de saneamento básico, tem como fim a gestão do faturamento, pendências, arrecadação, cadastral e operacional.
</p>

<p>
O Gsan é um sistema Java EE construído ao longo de mais de uma década e que contém cerca de 1.500.000 (um milhão e quinhentas mil) linhas de código e conta também com mais de 500 (quinhentos) relatórios diferentes. O sistema controla uma variedade de sistemas e módulos satélites, e possui um ciclo mensal de gerenciamento do faturamento e financeiro. O processamento do faturamento ocorre mensalmente e é formado por um conjunto de atividades e de procedimentos, que visam a obtenção do volume e do valor da água fornecida e do esgoto coletado, bem como a cobrança de cada serviço indireto, até a emissão das contas. A partir desse momento é desdobrado as demais ações comerciais relacionadas a arrecadação, com a baixa dos arquivos bancários através do EDI. Processos de garantia de receita, com as rotinas de cobranças e negativação que representam ações sobre as pendências comerciais.
</p>

<p>
Os processamentos de grupos de faturamento, bem como todos as demais rotinas críticas de processamento são realizadas em lote, utilizando tecnologia EJB 2.0, utilizando o projeto Open Source <a href="http://www.quartz-scheduler.org/overview" class="urlextern" title="http://www.quartz-scheduler.org/overview" rel="ugc nofollow">Quartz</a> como agendador.
</p>

<p>
O agendamento é feito manualmente pelo usuário através de funcionalidade específica do sistema. A organização das execuções deve considerar aspectos de negócio, como o processamento de rotinas de negativação e cobrança sempre após o processo de arrecadação. Como considerar a carga máxima suportada pelo sistema e o histórico de execução de determinado processo de forma que sua execução não conflite com a operação online. Naturalmente essas considerações variam de caso a caso, conforme infraestrutura e dimensão de cada operação.
</p>

<p>
&lt;WRAP center round box 80%>
&lt;html>&lt;center>Representação da Arquitetura base do sistema&lt;/center>&lt;/html>
<img src="/lib/exe/fetch.php?w=600&tok=f25ecb&media=comitegestor:arquitetura-gsan.png" class="mediacenter" loading="lazy" alt="" width="600" />
&lt;html>&lt;center>Figura 1 – Representação da Arquitetura&lt;/center>&lt;/html>
&lt;/WRAP>
</p>

</div>

<h3>Usuários e Responsabilidades</h3>
<div class="level3">

<p>
Foram identificados os seguintes usuários (papéis) no sistema:
</p>
<ul>
<li class="level1 node"> Administrador;<ul>
<li class="level2"> Consiste no usuário com privilégios elevados no sistema que atua na área de TI estabelecendo as configurações e ajustes críticos do sistema. </li>
</ul>
</li>
<li class="level1 node"> Operador;<ul>
<li class="level2"> Trata-se do usuário responsável pelo agendamento e execução dos batches, bem como, o acionamento do plantão correspondente em caso de falhas.</li>
</ul>
</li>
<li class="level1 node"> Usuário Externo;<ul>
<li class="level2"> Pode tanto ser uma PA de cobrança contratada, um terceirizado que atua na gestão de serviços em campo como qualquer outro usuário que faça relacionamento com o sistema além da fronteira da empresa responsável</li>
</ul>
</li>
<li class="level1 node"> Usuário de área de negócio<ul>
<li class="level2"> Trata-se do usuário chave da área de negócio, como Faturamento, Arrecadação, Cobrança e qualquer outro setor relevante na Companhia de Saneamento.</li>
</ul>
</li>
</ul>

</div>

<h3>Diagrama de Contexto do Sistema</h3>
<div class="level3">

<p>
&lt;WRAP center round box 80%>
<img src="/lib/exe/fetch.php?w=750&tok=32f9a7&media=comitegestor:diagrama-contexto-gsan.png" class="mediacenter" loading="lazy" alt="" width="750" />
&lt;html>&lt;center>Figura 2 – Diagrama de Contexto do Sistema&lt;/center>&lt;/html>
&lt;/WRAP>
</p>

</div>

<h2>Requisitos Arquiteturais</h2>
<div class="level2">

<p>
Em virtude do projeto ainda estar em uma fase incipiente, a lista abaixo não pode ser considerada completa. Os requisitos arquiteturais devem ser revisados após o término dos documentos de Visão e da elaboração dos Casos de Uso. Os requisitos arquiteturais também podem sofrer alterações com a prova de conceito da arquitetura.
</p>
<ul>
<li class="level1 node"> 1.	<b>Usabilidade</b><ul>
<li class="level2"> 1.1.	Interface com usuário na Web;</li>
<li class="level2"> 1.2.	Integração através de transferência de arquivos e web services.</li>
</ul>
</li>
</ul>
<ul>
<li class="level1 node"> 2.	<b>Suporte a processamento Batch e Workflow</b><ul>
<li class="level2"> 2.1.	ETL (Extract Transform Load), executar extração, transformação e carga. </li>
<li class="level2"> 2.2.	Suporte as diferentes fontes de dados: banco de dados, ORM, JMS e arquivos XML, Flat File e CSV.</li>
<li class="level2"> 2.3.	Controle transacional do processo;</li>
<li class="level2"> 2.4.	Configuração de intervalos para “commits” para melhora de desempenho;</li>
<li class="level2"> 2.5.	Fácil configuração do processo através de XML, não sendo necessário re-compilar a aplicação;</li>
<li class="level2"> 2.6.	Reutilização de classes e serviços (regras de negócios) de aplicações transacionais;</li>
<li class="level2"> 2.7.	Processamento em lotes com características de Workflow;</li>
<li class="level2"> 2.8.	Suporte a aprovações humanas ou automáticas para continuidade do processo;</li>
<li class="level2"> 2.9.	Processamento condicional e seqüencial com etapas dependentes;</li>
<li class="level2"> 2.10.	Atribuição de propriedade de execução única a uma etapa do processo;</li>
<li class="level2"> 2.11.	Recuperação automática após falha e re-execução de um passo de forma automática ou manual, sem a necessidade de executar todo o processo novamente;</li>
<li class="level2"> 2.12.	Possibilidade de “escapar” caso uma exceção previamente cadastrada ocorra, dando continuidade no processo;</li>
<li class="level2"> 2.13.	Suporte a particionamento do processamento através de inicialização de várias threads para melhora do desempenho;</li>
<li class="level2"> 2.14.	Suporte a clusterização para melhora do desempenho;</li>
<li class="level2"> 2.15.	Administração através de interface web;</li>
<li class="level2"> 2.16.	Suporte a pausa e finalização dos processos;</li>
<li class="level2"> 2.17.	Auditoria e acompanhamento dos processos, incluindo histórico de execuções;</li>
<li class="level2"> 2.18.	Suporte a agendamento de processos;</li>
<li class="level2"> 2.19.	Suporte a gatilhos de processos através de eventos, exemplo: recebimento de mensagem ou arquivo.</li>
</ul>
</li>
</ul>
<ul>
<li class="level1 node"> 3.	<b>Segurança</b><ul>
<li class="level2"> 3.1.	Possibilidade de Auditoria;</li>
<li class="level2"> 3.2.	Autenticação na Web;</li>
<li class="level2"> 3.3.	Autenticação na execução de Web Services;</li>
<li class="level2"> 3.4.	Filtro para acesso a URLs;</li>
<li class="level2"> 3.5.	Filtro para execução de métodos.</li>
</ul>
</li>
</ul>
<ul>
<li class="level1 node"> 4.	<b>Comunicação</b><ul>
<li class="level2"> 4.1.	Requisições pela Web, HTTP</li>
<li class="level2"> 4.2.	Requisições e envio por Web Services, REST.</li>
<li class="level2"> 4.3.	Requisições e envio por Arquivos, FTP.</li>
</ul>
</li>
</ul>
<ul>
<li class="level1"> 5.	<b>Persistência e controle transacional de Banco de Dados, Arquivos e Filas.</b></li>
</ul>
<ul>
<li class="level1 node"> 6.	<b>Integração com Sistemas Externos</b><ul>
<li class="level2"> 6.1.	Integração com sistemas externos a organização</li>
<li class="level2"> 6.2.	Integração através de troca de Arquivos</li>
<li class="level2"> 6.3.	Suporte aos formatos XML e Flat File</li>
<li class="level2"> 6.4.	Suporte a tipos pré-definidos de XML (XSD)</li>
<li class="level2"> 6.5.	Suporte a Web Services;</li>
</ul>
</li>
</ul>

</div>

<h2>Diagrama Esquemático (Cluster)</h2>
<div class="level2">

<p>
Cluster de servidores de aplicação visam a aumentar a escalabilidade e disponibilidade. De forma a obter estes benefícios, faz-se necessário gerenciar a configuração de uma série de serviços e componentes como por exemplo a camada de transporte, a replicação/distribuição dos dados entre os nós do cluster, como também todo o esquema de balanceamento de cargas entre os nós.
</p>

<p>
O maior desafio na configuração de um cluster é achar as condições ótimas de escalabilidade e disponibilidade.
</p>

<p>
Disponibilidade se refere ao fato de caso um nó falhe, outro nó assumirá a função. Escalabilidade representa a fato de aumentar o poder computacional a medida que novos nós são adicionados ao cluster. Estas duas propriedades se bem equilibradas podem promover um aumento considerável da performance das rotinas batch e também do módulo online.
</p>

</div>

<h2>Representação da Arquitetura</h2>
<div class="level2">

</div>

<h2>Referências</h2>
<div class="level2">

<p>
Java EE Technologies
<a href="http://www.oracle.com/technetwork/java/javaee/tech/index-jsp-142185.html" class="urlextern" title="http://www.oracle.com/technetwork/java/javaee/tech/index-jsp-142185.html" rel="ugc nofollow">http://www.oracle.com/technetwork/java/javaee/tech/index-jsp-142185.html</a>
</p>

<p>
Spring Integration
<a href="http://www.springsource.org/spring-integration" class="urlextern" title="http://www.springsource.org/spring-integration" rel="ugc nofollow">http://www.springsource.org/spring-integration</a>
</p>

<p>
Spring Batch
<a href="http://www.springsource.org/spring-batch" class="urlextern" title="http://www.springsource.org/spring-batch" rel="ugc nofollow">http://www.springsource.org/spring-batch</a>
</p>

<p>
Core J2EE Patterns
<a href="http://www.corej2eepatterns.com" class="urlextern" title="http://www.corej2eepatterns.com" rel="ugc nofollow">http://www.corej2eepatterns.com</a>
</p>

<p>
Patterns and Best Practices for Enterprise Integration
<a href="http://www.eaipatterns.com" class="urlextern" title="http://www.eaipatterns.com" rel="ugc nofollow">http://www.eaipatterns.com</a>
</p>

<p>
Domain-driven design
<a href="http://en.wikipedia.org/wiki/Domain-driven_design" class="urlextern" title="http://en.wikipedia.org/wiki/Domain-driven_design" rel="ugc nofollow">http://en.wikipedia.org/wiki/Domain-driven_design</a>
</p>

<p>
&lt;WRAP center round important 60%>
Documento em desenvolvimento…
&lt;/WRAP>
</p>

</div>

Enable Complex Tables Editor Height px Turn supplementary image paste support on

Resumo da edição: Minor changes