Camadas da Aplicação

  1. Camada de Tecnologia - possui componentes com papel de estruturação da aplicação, principalmente em aspectos não funcionais, estabelecendo padrões e frameworks para utilização de persistência, auditoria, feito/conferido, integrações, segurança, processamento distribuído, etc. Pertencem a esta camada componentes que são utilizados como estrutura tecnológica para construção de outras funcionalidades. Isola a camada de negócios de aspectos técnicos, permitindo foco total no negócio, além de abstrair serviços externos como banco de dados e legados, o que melhora a portabilidade e verificabilidade.
  2. Camade de Negócio - contém a implementação da lógica de negócio e define o domínio da aplicação, tendo como base para implementação as estruturas da camada tecnológica. Pertence a essa camada toda a lógica utilizada para controle de fluxo e processos que implementam o negócio específico da aplicação.
  3. Camada de Comunicação - composta por 3 sub-camadas, uma para cada modalidade de comunicação. a. Sub-camada de Web UI (User Interface) - camada web que contém toda a implementação relacionada à interface com o usuário. Telas são implementadas utilizando o padrão MVC, portanto essa camada contém todos os models e controllers por trás das views, além de componentes (como combo-boxes e tabelas) para reuso entre diferentes telas. Interage diretamente com a camada de negócio para realizar as funcionalidades necessárias. b. Sub-camada de Web Services - disponibiliza dados e funcionalidades da aplicação no formato de Web Services, que podem ser utilizados por outras aplicações. Interage com a camada de negócio para obter os dados e disparar operações. c. Sub-camada de Mensageria - hospeda os Message Driven Beans que consomem mensagens do MoM e trata eventos da aplicação que demandam o envio de mensagens a outros sistemas. Pertence a essa camada todo o código que diz respeito a integrações com outros sistemas, o que mantém a camada de negócio independente de integrações e facilita o desenvolvimento das mesmas.
../_images/camadas.png

Nestas camadas o Jmine e dependências compôe grande parte da camada de tecnologia (que também pode contar com outros componentes tecnológicos). O Jmine também possui facilitadores para as 3 sub-camadas de comunicação, com componentes e páginas Wicket para Web UI, comunicação RPC própria para Web Services e o Hydra para estruturar a sub-camada de mensageria.

Camada de Tecnologia

A Camada de Tecnologia tem papel de estruturação da aplicação, definindo os padrões para desenvolvimento e frameworks para implementação de casos de uso comuns, além de isolar a camada superior do contato direto com as APIs externas de mensageria e persistência.

O diagrama abaixo representa os principais módulos da camada de tecnologia e a relação entre eles, além da sua relação com dependências externas chave, representadas em cinza. Os módulos abaixo estão descritos de forma simplificada, com uma visão conceitual/lógica, para melhor compreensão.

../_images/tecnologia.png
  1. Component - Define o padrão para construção de componentes da aplicação, com base no Spring Framework, além de suporte básico a internacionalização.
  2. Monitoramento - API centralizada para log de erros e expõe via protocolo JMX diversas métricas sobre o estado da aplicação. Estrutura extensível, permite que as camadas superiores exponham dados relevantes ao monitoramento, permitindo o cruzamento de dados de infraestrutura e de negócio durante o diagnóstico de falhas e problemas de desempenho.
  3. Segurança - Define API para autenticação, e armazena o usuário atual, com controle de permissões baseada nas credenciais de segurança. São disponibilizados adapters que implementam a autenticação com diferentes protocolos, como LDAP.
  4. Persistência - Define todo o controle de persistência da aplicação, agregando o controle de diversas APIs, com a implementação de pontos fundamentais de segurança como Chinese Wall, feito/conferido e auditoria. Define um framework extensível que permite extender o controle de persistência com validações e listeners para todas as etapas do ciclo de vida de objetos de domínio.
  5. Data digester - Framework para implementação de cargas de arquivos, utilizado principalmente para dados de mercado. Fornece segregação da leitura do arquivo e processamento dos dados, além de interface unificada para execução e rastreabilidade.
  6. Services - Framework para definição de serviços, ações que podem ser executadas no sistema. Estas ações podem ser definidas nas camadas de negócio, e podem ser representadas em diversos formatos (como XML e XLS). Módulo amplamente utilizado para invocar ações de negócio decorrentes de integrações e arquivos externos, pois garante a rastreabilidade do que foi executado e evita acoplamento com código de negócio.
  7. Batch - Framework para definição de jobs batch paralelos e distribuídos. Realiza todo o controle da execução do job, incluindo distribuição, controle transacional, crash recovery e rastreabilidade.
  8. Script - Componente que fornece a possibilidade da implementação de funcionalidades utilizando scripts em outras linguagens que executam na JVM, como Beanshell e Groovy. Esta capacidade adiciona grande flexibilidade a pontos que demandam resposta rápida e grande flexibilidade, sem necessidade de nova versão.

Camada de Negócio

A Camada de Negócio é a parte da aplicação que irá conter toda a lógica de negócio propriamente dita, incluindo o domínio da aplicação, controles de fluxos, processamentos e etc. Não há nenhuma segregação estrutural forte entre a camada de tecnologia e de negócios, a divisão é principalmente lógica. A separação do negócio da tecnologia permite que aspectos e padrões tecnológicos possam ser expressos de forma mais pura, e que o negócio possa ser expresso de forma mais clara e sem preocupações estruturais, separando melhor as responsabilidades.

Enquanto a camada tecnológica é mais facilmente testada por testes unitários e integrados escritos em Java, os cenários para validação de regras de negócio são melhor descritos em planilhas de validação, criadas por especialistas no negócio. Para tal, devem ser implementados serviços que darão acesso às funcionalidades de negócio, permitindo a escrita destes testes.

Sub-camada de Web UI

A camada Web UI (Web User Interface) contém as telas que dão ao usuário acesso às funcionalidades da aplicação.

Na figura abaixo, dependências externas aparecem em cinza, módulos em azul.

../_images/web.png
  1. Servlet filters - provê filtros que interceptam requisições e aspectos não funcionais, como controle transacional, controle de erros e verificações de segurança.
  2. Componentes - contém componentes reutilizáveis, construidos utilizando a biblioteca Apache Wicket. Fornece estruturas comuns, como menus, controle de padrões visuais, facilitadores para criação de telas de consulta e cadastro, etc.
  3. Páginas comuns - conjunto de telas comuns a diversas aplicações, como login, relatórios de auditoria, relatórios de erros, etc.

Sub-camada de Mensageria

Contém toda a implementação necessária para integração via mensageria com outras aplicações, em geral sistemas legados.

Na figura abaixo, dependências externas aparecem em cinza, módulos em azul.

../_images/mensageria.png
  1. Hydra - Framework para definição de integrações com sistemas legados inteiramente baseado em metadados, incluindo scripts. Fornece modelo de programação com clara separação de responsabilidades, independência tanto de formatos de dados quanto de canal de comunicação, rastreabilidade e facilmente testável. Grande parte da lógica das integrações é mantida nos meta-dados mantidos neste módulo.
  2. MDBs - Conjunto de Message Driven Beans que recebem mensagens e delegam o tratamento específico da mensagem para o módulo de integrações. Realiza o controle transacional, log de origem, controle do número de tentativas e outros aspectos específicos do contexto EJB.

Na aplicação é configurado o Hydra, que é feito inteiramente através de cadastros e scripts. Na aplicação também devem ser registrados listeners de eventos necessários na camada de Negócio, que irão disparar integrações no Hydra nos momentos corretos.

Sub-camada de Web Services

Esta sub-camada de comunicação trata da implementação Web Services, que permitem comunicação entre aplicações utilizando requisições web comuns. O Jmine conta com um formato próprio para comunicação entre diferentes aplicações que também utilizam o Jmine (utilizando o módulo jmine-tec-rpc), mas também é possível implementar Web Services utilizando bibliotecas padrão como JAX-WS e JAX-RS, recomendável no caso de comunicações com aplicações de terceiros.

O módulo jmine-tec-rpc implementa RPC (Remote Procedure Calls) através de Web Services. É utilizado um formato de comunicação em que objetos da aplicação são serializados em JSON durante a comunicação, promovendo um modelo de implementação e utilização transparente ao desenvolvedor.

../_images/webservices.png
  1. RPC - Common - Define objetos comuns ao lado cliente e servidor, permitindo a comunicação entre as partes, principalmente a forma de serialização, protocolo para descoberta de serviços e para invocação de métodos remotos.
  2. RPC - Server - Implementa a interface Servlet e cuida da serialização da chamada para delegar para o objeto que implementa o serviço no lado do servidor. Cuida do log e controle transacional.
  3. RPC - Client - Implementa stubs dinâmicos para acesso a objetos remotos, utilizado na aplicação que está invocando um web service.

No modelo de programação de web services na estrutura adotada, o módulo expõe um artefato com a API dos seus serviços providos, e esta API é conhecida por módulos que a utilizam. A implementação do serviço fica em um artefato separado, disponível apenas no próprio módulo.

Por clareza, os módulos RPC - Client e RPC - Common foram colocados nesta camada, mas eles não dependem de estruturas Web e podem ser utilizados por outras camadas para obter informações de outras aplicações, no caso de soluções que são implementadas ao longo de diversas aplicações.