Edição das 16h34min de 28 de maio de 2015

Introdução

Apresentamos neste documento a arquitetura de referência para o desenvolvimento do software Processo Judicial Eletrônico versão 2.0 (PJe 2.0) e suas evoluções futuras. As seções e subseções do documento explicarão os detalhes pertinentes da arquitetura.

Objetivo do documento

O objetivo principal é especificar a arquitetura de software de referência a ser utilizada como padrão para o desenvolvimento do PJe 2.0 e suas evoluções futuras. Nesta especificação está incluído: a estruturação do projeto do software, a organização das camadas do software, os componentes e arcabouços utilizados no software, a definição das principais tecnologias e ferramentas a serem utilizadas, os padrões de projeto e boas práticas de programação que devem ser utilizadas no desenvolvimento do software. A metodologia de desenvolvimento do software proposta será tratada em outro documento.

Termos, abreviações e convenções adotadas

Explicitamos nesta seção, uma tabela contendo os termos, abreviações e convenções adotadas no documento da arquitetura de referência do PJe 2.0. A leitura prévia desta seção é fortemente recomendada para compreensão das demais seções.

[TODO: citar as ref. bib. nos termos necessários]

Restrições da arquitetura

TODO: verificar se existem restrições obedecidas.

Justificativas arquiteturais

Nesta seção, explicitamos o conjunto de memorandos (técnicos, gerenciais, institucionais) que justificam as decisões arquiteturais da arquitetura de referência do PJe 2.0. Esses memorandos são resumos das discussões e estudos os quais balizam este trabalho.

Requisitos do projeto PJe 2.0.

O conjunto completo de premissas e requisitos (funcionais e não funcionais) consta no Plano Geral do Projeto PJe 2.0 ( [TODO: colocar link para o plano, se for desejado]). A saber, explicitamos apenas um resumo desse conjunto:

• Isolamento dos módulos de negócio (ou seja, módulos responsáveis pela lógica de negócio do software PJe) a fim de evitar efeitos colaterais indesejáveis provenientes das modificações no código-fonte.
• Permitir que o desenvolvimento dos módulos de negócio seja realizado isoladamente, inclusive com equipes distribuídas.
• Permitir que a implementação de um módulo de negócio qualquer seja totalmente substituída por nova implementação, sem prejudicar o funcionamento dos demais módulos.
• Isolamento das camadas lógicas do software, para evitar ao máximo o embaralhamento da lógica de negócio do software PJe e a dificuldade de leitura e compreensão do código-fonte
• Permitir que os módulos mais exigentes, quanto ao consumo de recursos de infraestrutura, possam ser "instalados" (deploy) mais de uma vez.

Experiências prévias.

Foram consideradas as seguintes experiências:

• Experiência prévia da equipe de arquitetos servidores do Poder Judiciário.
• Foram analisadas arquiteturas de referência de outras instituições (TCU, STF, SERPRO, TJRO, TJPE).
• Estudos diversos foram realizados pela equipe de arquitetos na primeira Sprint do projeto.

Tecnologias adotadas.

As tecnologias e/ou ferramentas adotadas para a implementação foram selecionadas a partir da análise dos requisitos do projeto PJe 2.0:

• Java Enterprise Edition (JEE): a escolha pela plataforma JEE foi um consenso dada a notória posição de destaque dessa plataforma na construção de aplicações corporativas com grande volume de acesso e necessidade de escalabilidade, de robustez, de segurança, de controle de transação e de processamento em batch, entre outras necessidades. Além disso, a plataforma JEE traz um conjunto expressivo de APIs que aumentam a produtividade da construção do software e encapsulam parte da complexidade inerente às funções que elas implementam.
• Apache Maven: a escolha pela ferramenta Maven foi norteada pela necessidade de modularização do software e pela adoção da plataforma JEE, como também pelo consenso, na comunidade de desenvolvedores Java, de que a ferramenta Maven é a melhor ferramenta para gerenciamento de builds e dependências na atualidade.
• Git: a escolha pela ferramenta Git (um software de controle de versões de código-fonte) se deu pela complexidade do ambiente de desenvolvimento do software PJe no qual é desejável que várias equipes, em diferentes localidades (Tribunais de Justiça), estejam trabalhando, paralelamente, no desenvolvimento de diferentes módulos do software PJe e, também, na manutenção dos módulos já implementados.
• JBoss Enterprise Application Platform (JBoss): a escolha pelo servidor de aplicações Red Hat JBoss é justificada pela reconhecida posição de destaque, entre a comunidade de desenvolvedores JEE, deste servidor de aplicação que oferece a completa implementação das APIs da plataforma JEE. Além disso, a versão do JBoss denominada EAP (Enterprise Application Platform), em particular, foi a escolhida porque permite a contratação do serviço de suporte da empresa Red Hat. É importante destacar que, o uso do servidor de aplicações JBoss é adotado como o servidor de aplicação padrão do projeto e, para o uso de outro servidor de aplicação diferente, explicaremos em outra seção deste documento as diretrizes de configuração que precisarão ser feitas.
• PostgreSQL: a escolha do SGBD PostgreSQL deve-se pelo fato deste SGBD ser de uso gratuito e open source( isto é, é um software cujo código-fonte está aberto para comunidade), implementar o padrão objeto-relacional com a robustez desejada pelo projeto. Além de, ser um SGBD amplamente utilizado pela comunidade de desenvolvedores de diversas linguagens de programação. É importante destacar que, o uso do SGBD PostgreSQL é adotado como o SGBD padrão do projeto e, para o uso de outro SGBD diferente, explicaremos em outra seção deste documento as diretrizes de configuração que precisarão ser feitas.

Definição da arquitetura de referência

Esta seção e subseções descrevem os detalhes da arquitetura de referência definida para o desenvolvimento do software PJe 2.0 e suas evoluções futuras. Dentre os detalhes, podemos destacar: a forma como a arquitetura foi estruturada/organizada e as responsabilidades da arquitetura. Vale informar que, a arquitetura também poderá ser reutilizada para outros projetos de domínio diferente do PJe.

A arquitetura é formada por 5 camadas lógicas relacionadas entre si conforme apresentamos na Figura 1. Um camada é

Além das camadas, poderá agrupar logicamente outros elementos da arquitetura por de módulos, conforme apresentamos na Figura 2. Um módulo é

Cada camada da arquitetura equivale a um dos particionamentos lógicos dos diversos aspectos tratados pelo software e possuem responsabilidades distintas. Toda camada é logicamente separada da outra e (???????) não está estritamente acoplada com a camada adjacente (???????). A Figura 1 apresenta as camadas da arquitetura e as tecnologias utilizadas em cada uma delas. As responsabilidades de cada camada serão explicadas nas subseções subsequentes e as tecnologias definidas para uso em cada camada serão abordadas em outra seção deste documento.

Camadas e módulos

TODO: apresentar as visões.

Visões da arquitetura

A arquitetura de referência é estruturada nas seguintes camadas:

Camada de Apresentação

Esta camada é responsável por encapsular toda a lógica de apresentação exigida para servir aos clientes que acessam o software. Em resumo, essa lógica funciona assim: interceptar as requisições dos clientes, fornecer um único início de sessão HTTP, conduzir o gerenciamento dessa sessão, controlar o acesso aos serviços de negócio disponíveis, construir as respostas e as entregas aos clientes.

Camada de Serviços

XXXX

Camada de Negócio

yyyy

Boas práticas

Problemas conhecidos e preocupações

Instruções de montagem do ambiente de desenvolvimento

Referências bibliográficas

1. World Wide Web Consortium (W3C) disponível em http://www.w3.org/, último acesso em 26/05/2015.
2. Maven – Welcome to Apache Maven disponível em https://maven.apache.org/, último acesso em 28/05/2015.