IV Mostra de Tecnologia do Ministério Público Brasileiro. Arquitetura de referência para aplicações Web MPPE

Transcrição

1 IV Mostra de Tecnologia do Ministério Público Brasileiro Arquitetura de referência para aplicações Web MPPE

2 Rafael de Albuquerque Ribeiro

3 O pós-arquimedes Por um bom tempo a maior parte do desenvolvimento de aplicações Web no MPPE gravitava em torno do Arquimedes Novas aplicações eram normalmente módulos que foram sendo construídos no Arquimedes

4 O pós-arquimedes A vantagem de se construir sob a arquitetura do Arquimedes era fazer uso da excelente infra que o Arquimedes apresentava Entretanto, domínios distintos do original do Arquimedes foram sendo incorporados

5 O pós-arquimedes Com o tempo, combinar área meio com área fim em um mesmo sistema começou a apresentar problemas Implantação de módulos da área meio impacta a área fim por fazerem parte do mesmo sistema, dificultando as implantações

6 Cenário atual das aplicações web Com a popularização dos frameworks Javascript, browser deixou de ser visto como um renderizador html e passou a ser um runtime Esta evolução teve início com as técnicas AJAX iniciadas no Outlook Web Access em 1999

7 Cenário atual das aplicações web

8 Cenário atual das aplicações web Modelo request/response original da web foi substituído por um modelo de aplicações com uma única página Transições entre as áreas do sistema são feitas através da manipulação da árvore DOM da página

9 Cenário atual das aplicações web Aplicações web passaram a ser mais responsivas, quase não há mais carga completa das páginas Validações, mensagens de confirmação, etc. passaram a ser feitas do lado do cliente, melhorando bastante a experiência do usuário

10 Visão geral da arquitetura Serviços Apresentação JAX-RS RESTful ModelMapper Apache CXF Negócios Dados JPA

11 Camada de apresentação Backbone.js é responsável pela infra MVC da camada de apresentação Existe um modelo de rotas similar ao encontrado no Rails e em outros frameworks

12 Camada de apresentação Backbone.js usa por padrão o underscore como mecanismo de templates Próximos projetos devem adotar um plugin de Data Binding para o Backbone.js

13 Camada de apresentação RequireJS é responsável pela composição dos vários artefatos Javascript do projeto RequireJS é responsável também pela carga dos Javascripts de terceiros

14 Camada de serviços API RESTful foi desenvolvida com base no JAX-RS CXF foi a implementação JAX-RS adotada por conta da boa integração com o Spring e principalmente da maturidade

15 Camada de serviços API RESTful é independente das Entidades (JPA) Transformação entre as Entidades e os DTOs presentes na API RESTful fica a cargo do ModelMapper

16 Camada de serviços A Segurança da aplicação fica por conta do Spring Security e está presente tanto na camada de serviços quanto na de negócios Atualmente a segurança é baseada no diretório LDAP do MPPE mas futuramente pode migrar para SAML

17 Camada de negócios Controle transacional e de injeção de dependências da aplicação é baseado no Spring Execução de testes unitários de componente Spring é mais simples se comparado com o EJB

18 Camada de negócios Futuras aplicações terão parte da lógica de negócios expressa como regras Drools externas ao código Intuito da externalização de algumas regras é facilitar eventuais ajustes e flexibilizar parte da lógica do sistema

19 Camada de dados Persistência dos dados da aplicação é de responsabilidade do Hibernate através do JPA Maior parte das consultas estão expressas na forma de Named Queries (inclusive as dinâmicas )

20 Camada de dados Exemplo de cláusula where de NamedQuery dinâmica: where (s.datasolicitacao >= :datasolicitacaoinicio or date(:datasolicitacaoinicio) is null ) and (s.datasolicitacao <= :datasolicitacaofim or date(:datasolicitacaofim) is null ) and (s.solicitante.id = :solicitante or :solicitante = 0) and (s.autorizador.id = :autorizador or :autorizador = 0) and (s.aceita = :aceita or bool(:aceita) is

21 Camada de dados SGBD padrão é o PostgreSQL mas também existem aplicações com MySQL

22 Além da arquitetura... Construção da aplicação: Apache Maven Repositório de artefatos: Sonatype Nexus Servidor de Integração contínua: Hudson Testes unitários: junit, Powermock, hamcrest

23 Além da arquitetura... Gerenciamento de versão do SGBD: Liquibase Versionamento de infraestrutura: Vagrant e Puppet Pipeline de construção da aplicação

24 Construção da aplicação Apache Maven é responsável pelo empacotamento das aplicações Aplicações são compostas de vários artefatos e existe comumente um projeto pai responsável pela orquestração do build

25 Construção da aplicação Artefatos padrão do MPPE com overlays permitem a composição controlada de artefatos web em novas aplicações Arquétipos Maven permitem um início rápido de novas aplicações

26 Versionamento do SGBD Liquibase permite um controle eficiente das mudanças no banco de dados Conceito de contextos do Liquibase permite inclusive o versionamento de massa de dados para testes e aplicação seletiva nos ambientes adequados

27 Versionamento da infra Vagrant e Puppet permitem que a infraestrutura onde a aplicação executa seja versionada Dificuldades de implantação por conta de ambientes de desenvolvimento e produção divergentes é minimizada

28 Testes e entrega contínua Meta é implantar o conceito de Pipeline de construção onde testes são executados em série dos mais simples (unitários) ao mais completos (integração e aceitação)

29 Testes e entrega contínua Hamcrest, junit e Powermock são usados extensivamente nos testes unitários Vagrant, Puppet e Liquibase tem papel importantíssimo nos testes de integração

30 Rafael de Albuquerque Ribeiro