Secoes Interessantes a Serem Feitas

Contextualizacao / Proposito da Arquitetura
Tecnologias Utilizadas
Camadas da Arquitetura
Fora de escopo (ou seja, aquilo que a arquitetura nao faz - pelo menos na versao atual)
Componentes da Solucao (Quais as partes - que existem dentro das camadas - da arquitertura, e o que cada uma faz e como elas se relacionam com outras)
Estrutura Logica de Dependencias dentre os Componentes / Projetos (maven, IDE) da arquitetura
Exemplo Pratico (passo a passo, desde um checkout inicial para fazer uma tela - usar como exemplo os tres casos: Compania, Periodo e Aplicacao)
FAQ
Mais ideias ?

Camadas da Aplicacao

Interface do Usuario

Consulte o projeto grafico para um detalhamento dos componentes internos, estrutura, aparecia e comportamento dessa camanda.

Camada de Servicos

Todos os servicos do sistema estao implementados na forma de Enteprise Java Beans, padrao 3.1, que em suma:

Nao utilizam interface para descricao dos servicos, apenas classe de implementacao diretamente (visando minimizar tempo de programacao)
Todos os EJB sao locais
Todos os EJB sao sem estado (@Stateless)
Todos os EJB sao nomeados (@Named)

Persistencia e Banco de Dados

O Sistema EMapping utiliza a modelagem Orientada a Objetos para suas entidades de negocio e dados. Os dados persistentes sao mapeados para banco de dados relacional utilizando o padrao JPA (JSR-317), com geracao automatizada das estruturas na base de dados atraves da implementacao Hibernate.

A responsabilidade das estruturas OO do sistema ficam a cargo do projetista do sistema, conforme necessidades de negocio elencadas pelo Product Owner e direcionamentos dos arquitetos.

O banco de dados padrao do sistema eh o Oracle, mas devido o uso de JPA, Postgres tambem deve ser suportado.

Todo e qualquer acesso a base de dados deve ser feito unica e exclusivamente atraves do objeto EntityManager que esta encapsulado nos EJBs do sistema. Excecoes a essa regra competem apenas ao arquiteto do sistema.

Abaixo, um exemplo de uso da camada de persistencia

@Stateless
public class ReferentialDomainService extends AbstractCoreService<AbstractNamedCoreModel> {
  public void persist(ReferentialField field) {
    ReferentialField fieldToPersist = field;
    if (isUsed(fieldToPersist)) {
      fieldToPersist = new ReferentialField(field);
    }
    super.persist(fieldToPersist); //persist eh um metodo implicito e disponivel para os EJBs de servico como este
  }
}

Servicos Externos

Os servicos externos que acessam o EMapping poderao fazer isso atraves do padrao REST, podendo realizar leitura e escrita de informacoes desde que autenticados e conforme o nivel de permissao atribuido.

Os servidos REST disponiveis no EMapping sao implementados unica e exclusivamenete pelos EJB de fachada.

O formato padrao de dados REST no EMapping eh, primeiro XML, e opcionalmente JSON.

Detalhes e exemplos sobre essa parte serao disponibilizados quando necessario.

Funcionamento

Os quatro vertices (Logico, Fisico, Processamento e Implantacao) da arquietetura sao dados pelo Diagrama 4+1 abaixo:

Logico

Fisico

Processamento

O Diagrama de Atividades mostra o ciclo completo de processamento de negocio de um acao de usuario no sistema:

Onde:

Cores:
- Azul: Em suma eh o navegador web, que executa no computador cliente. Captura as acoes do usuario e converte em requisicoes http/s. Tambem captura os retornos do sistema e exibe-os em uma interface html rica (web 2.0).
- Verde: As actions sao componentes da aplicacao escritos em codigo java. Recebem as requisicoes do browser e realizam validacoes simples (que nao exigem acesso ao sistema). Quando uma acao necessita o processamento de uma regra de negocio, ela aciona um EJB de Fachada.
- Laranja: Sao EJBs. Eles dividem-sem em "Fachada" (pelo sufixo Facade) e Servicos (pelo sufixo Service). EJBs de fachada encapsulam todas as operacoes de um modulo do sistema. Em outras palavras, um modulo nao deve ser acessado de outra forma que nao pelo seu EJB de Fachada. EJBs de fachada nao contem regras de negocio, eles apenas delegam a execucao das opeeracoes para os EJBs de servico. EJBs de fachada sao sem estado por natureza (@Stateles), e elegiveis para oferecer servicos REST. Todos metodos nos EJBs de Fachada sao transacionais por natureza. Ja os EJBs de servico sao os responsaveis pela implementacao das regras de negocio do sistema. Eles somente podem ser acessados por EJBs de fachada (qualquer EJB de fachada) ou entao por outros EJBs de servico dentro do mesmo modulo. EJBs de servico podem acessar a camada de persistencia ou invocar operacoes em classes utilitarias ou sistemas externos. EJBs de servico nao devem realizar acesso direto ao banco de dados, exceto metodos marcados explicitamente pelos arquitetos da aplicacao. EJBs de servico sao por natureza sem estado (@Stateles). Todos os componentes Laranja executam dentro do servidor de aplicacao, e contam com recursos implicitos para log, persistencia, transacionamento, seguranca e escalabilidade.
- Amarelo: Classes utilitarias da aplicacao, criadas para o proprio sistema ou utilizadas de frameworks e bibliotecas de terceiros. Deve-se evitar ao maximo a utilizacao de metodos estaticos em classes utiliarias. Quando isso for desejado, entao deve-ser utilizar o padrao Singleton.
- Lilas: Sistema externo eh todo e qualquer componente, ferramenta ou aplicativo avesso ao Sistema EMapping que deve ser acessado para leitura ou escrita de informacoes. Somente EJBs de Servico ou entao Classes Utilitarias (Util) podem acessar um sistema externo, e nunca uma Action ou Facade.
- Marrom: Persistencia, representada pelo JPA (JSR-317) pela implmentacao do Hibernate, oferece metodos para escrita e leitura de dados no banco de dados. Todas as operacoes realizadas sobre a camada de persistencia operam sobre o modelo de objetos da aplicacao, e nunca deve fazer acesso direto as tabelas do banco de dados. Em outras palavras, comandos SQL nao deve ser executados sobre a camada de persistencia, mas sim comandos da EJB-QL. A camada de persistencia eh livre para realizar cache de objetos conforme indicacoes da equipe de arquitetura
- Vermelho: Eh o banco de dados do sistema, representado por um SGBD relacional Oraclel ou Postres, e contem os objetos persistentes da aplicao, salvos em tabelas atraves do framework JPA da persistencia. Nenhum acesso direto da apliacao (codigo de programador) deve ocorrer nessa camada, exceto explicitamente demarcado pela equipe de arquitetura.

Acoes:
1. Toda iteracao do sistema inicia com uma solicitacao de usuario, que pode ser uma pessoa ou um sistema. A acao do usuario corre sempre sobre um navegador web. Eh exatamente esta acao de usuario a chamada Feature do sistema, ou seja, uma funcao que o sistema oferece para o usuario.
2. A Action eh o ponto de entrada na aplicacao, ela representa a acao do usuario e pode executar operacoes simples como validacao de dados quanto ao tipo de dados, intervalo de valores e aplicacao de mascaras. Porem, fora isso, toda e qualquer regra de negocio do sistema eh despachada para o EJB de Fachada.
3. Os EJBs de fachada sao objetos sem estado que simplesmente aglutinam os diversos servicos oferecidos por um modulo do sistema em uma inteface comum, que pode ser acessada pelo meio externo. Eles nao implementam nenhuma regra de negocio, apenas delegam as chamadas das Actions para os respectivos servicos de negocio. EJBs de fachada possuem caracteristicas de seguranca, transacao, log e auditoria implicitamente.
4. Os EJBs de servico sao os principais elementos da aplicacao. Eles contem as regras de negocio do sistema, e sao acionados pelos EJBs de fachada.
5. Quando necessario, um EJB de servico pode invocar operacoes em outros EJBs de servico dentro do mesmo modulo para complementar a regra de negocio necessaria.
6. Quando necessario, um EJB de servico pode invocar operacoes em classes utilitarias da aplicacao, tanto criadas pelo programador (vide classe utilitaria DependencyBuilder@emapping) quanto de frameworks e bibliotecas de terceiros (vide classe utilitaria org.apache.commons.lang3.StringUtils@google).
7. Nos casos onde um EJB de servico precisa invocar operacoes de regras de negocio de EJBs de servico que estao em outro modulo, ele precisa obrigatoriamente fazer isso atraves do EJB de fachada do respectivo modulo. Assim, nunca EJBs de servico de modulos distintos devem ter dependencias diretas entre si.
8.
9.
10.
11.
12.