Diferenças

Aqui você vê as diferenças entre duas revisões dessa página.

--- comitegestor:arquiteturabatch [02/12/2015 00:47]
moises.simoes [Requisitos Arquiteturais]
+++ comitegestor:arquiteturabatch [31/08/2017 01:11] (atual)
@@ Linha 1: / Linha 1: @@
+<WRAP center round todo 60%>
+documento em construção
+</WRAP>
 ====== Proposta de Arquitetura da Evolução do Módulo Batch ======
@@ Linha 5: / Linha 9: @@
 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.
-===== Objetivo =====
+==== Motivação ====
+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.
+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.
+==== Objetivo ====
 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: [[:comitegestor:arquiteturabatch#Contexto_do_Sistema|Contexto do Sistema]], [[:comitegestor:arquiteturabatch#requisitos_arquiteturais|Requisitos Arquiteturais]] e [[:comitegestor:arquiteturabatch#representacao_da_arquitetura|Representação da Arquitetura]].
@@ Linha 13: / Linha 23: @@
 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.
-Para fechamento do documento temos duas seções complementares: Definições, acrônimos e abreviações e as Referências
+Para fechamento do documento temos duas seções complementares: Definições, acrônimos e abreviações e as Referências.
+==== Estratégia ====
+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.
+==== Benefícios ====
+  * Atualização tecnológica e de segurança
+  * Aumento da performance
+  * Possibilidade de utilização de cluster
+  * Alta disponibilidade
+  * Balanceamento de carga
+  * Administração de forma centralizada (domain)
+  * Melhores ferramentas de administração e monitoramento
 ===== Contexto do Sistema =====
@@ Linha 21: / Linha 45: @@
 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.
-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.
+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.
 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 [[http://www.quartz-scheduler.org/overview|Quartz]] como agendador.
@@ Linha 102: / Linha 126: @@
     * 6.4.	Suporte a tipos pré-definidos de XML (XSD)
     * 6.5.	Suporte a Web Services;
+===== Diagrama Esquemático (Cluster) =====
+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.
+O maior desafio na configuração de um cluster é achar as condições ótimas de escalabilidade e disponibilidade.
+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.
+<WRAP center round box 80%>
+{{ :comitegestor:cluster.png?nolink&750 |}}
+<html><center>Figura 3 – Diagrama de Clusterização</center></html>
+</WRAP>
 ===== Representação da Arquitetura =====
+===== Referências =====
+Java EE Technologies
+http://www.oracle.com/technetwork/java/javaee/tech/index-jsp-142185.html
+Spring Integration
+http://www.springsource.org/spring-integration
+Spring Batch
+http://www.springsource.org/spring-batch
+Core J2EE Patterns
+http://www.corej2eepatterns.com
+Patterns and Best Practices for Enterprise Integration
+http://www.eaipatterns.com
+Domain-driven design
+http://en.wikipedia.org/wiki/Domain-driven_design
 <WRAP center round important 60%>

Base de Conhecimento de Gestão Comercial de Saneamento

Ferramentas do usuário

Ferramentas do site

Diferenças

Ferramentas da página