Boas Práticas no Desenvolvimento Java Enterprise
Dicas e práticas que fazem a diferença no seu projeto Java EE 

Atualmente, com a grande adoção da plataforma Java Enterprise (conhecida como J2EE) por muitas empresas, de variados segmentos de negócio, nasce a necessidade do uso de boas práticas conhecidas para a plataforma Java Enterprise, além daquelas registradas no JavaBlueprints™, com o intuito de garantir as qualidades funcionais e não-funcionais de sistemas e aplicações construídas usando a Java2 Enterprise Edition. Este artigo orientará arquitetos, projetistas e desenvolvedores no uso de um conjunto de diversas boas práticas para atingir tais qualidades.

Atualmente, com a escassez de recursos tecnológicos, a diminuição de investimentos em TI e o alto índice de “turn-over” de pessoal nas equipes de análise, desenho e desenvolvimento, e implantação de sistemas, se faz necessário a adoção de um manual tecnológico de boas práticas e padrões para Java/J2EE, visando garantir os prazos de implantação sem diminuir a qualidade do software e facilitando a sustentação em ambiente de produção.
Este artigo tem como objetivo reunir e compartilhar experiências em Java/J2EE adquiridas ao longo de 5 anos, buscando a padronização no uso e implementação de componentes de software baseados em Java/J2EE, seguindo as boas práticas da tecnologia Java, da plataforma J2EE e de ambientes de Servidores de Aplicação J2EE.

Boas Práticas de Arquitetura

Os motivos pelos quais uma aplicação Java Enterprise tem problemas de performance, segurança, escalabilidade, e outros, são os mesmo motivos pelos quais aplicações no ambiente MainFrame ou Client/Server têm esses problemas, ou seja, má definição da arquitetura de software geralmente espremida por prazos absurdos de implantação e por falta de levantamento e refinamento de requisitos não-funcionais como: segurança, confiabilidade, disponibilidade e escalabilidade.

O ambiente Java Enterprise por ser um pouco mais complexo que seus primos, exige que aplicações baseadas nessa plataforma tenham um processo de arquitetura melhor elaborado e realizado, e que realmente suporte às qualidades não-funcionais de um software.
Um sistema ou aplicação baseada na plataforma Java Enterprise deve ser componentizada para quebrar a complexidade de construção, desde o Cliente (ClientTier) até os Recursos de Dados (ResourceTier).

Pesquisas, estudos e a vivência do mercado de desenvolvimento apontam que uma implementação ruim no máximo prejudicará a performance e dificultará a manutenção do sistema. Entretanto, uma arquitetura mal concebida e mal elaborada prejudicará cronicamente a performance, escalabilidade, estabilidade e confiabilidade. Ou seja, no desenvolvimento corporativo “enteprise-class” o processo de elaborar, testar e validar uma arquitetura para os sistemas é tão ou mais importante que a própria implementação.

Padrões de Arquitetura

Uma aplicação ou sistema J2EE obrigatoriamente deve ser construído em n-camadas e cada camada tem uma responsabilidade específica.

Experiências de mercado coletadas de empresas de todos os segmentos como: indústria, comércio, financeiro, e-commerce, e outros, têm encontrado equilíbro entre o custo, prazo e qualidade de aplicações Java adotando o modelo cinco-camadas (five-tier model), sendo as camadas propostas e padronizadas dentro da plataforma J2EE no JavaBlueprints™.

Responsabilidade das camadas:

. Client-Tier: exibir os componentes da interface gráfica com o usuário, fornecer os mecanismos   de entrada e saída de dados;

. Presentation-Tier: tratar as ações do usuário e controlar a lógica da apresentação;
. Business-Tier: suportar os componentes que realizam os serviços e processos de negócio;
. Integration-Tier: fornecer serviços de infra-estrutura à camada de negócio;
. Resource-Tier: fornecer o acesso e controle a dados, integrações, conexões. Mensageria, etc.

Para garantir que o modelo de arquitetura seja seguido e verificado, devem ser adotados padrões de semântica para os nomes de todos os componentes, pacotes e classes, respeitando sua camada e responsabilidade, como os padrões do GoF ou J2EE Design Patterns.

Geralmente, para cada tipo de componente, adotamos no nome da classe um sufixo que representa sua responsabilidade e no pacote representamos a qual domínio de negócio e qual camada ele faz parte. Por exemplo:

banco.geral.database.ClienteDAO
banco.geral.ejb.ClienteBean
banco.geral.delegate.ClienteDelegate

Ou seja, os padrões de semântica permitem que os arquitetos, desenvolvedores e projetistas identifiquem rapidamente em qual camada o componente está e qual responsabilidade ele deve desempenhar.

Leia o artigo completo na revista MUNDOJAVA, já nas bancas!

Arquitetura de Camadas em Java EE
Princípios e padrões para a plataforma Java EE

O que são Camadas? Camadas são o mesmo que MVC? Por que não usar Value Objects? O que usar para implementar as tais Camadas? Descubra conceitos, padrões e más práticas arquiteturais para separar as responsabilidades da sua aplicação em Camadas.


A eterna luta pela qualidade no software vem há anos produzindo padrões e técnicas para a construção de sistemas com menos defeitos e de manutenção mais fácil e simples. Ainda na “época de ouro” do Projeto Estruturado de Sistemas foram definidas duas métricas básicas para um módulo de software: Coesão e Acoplamento. Coesão é a medida em que os componentes de um módulo estão relacionados, se eles têm responsabilidades em comum ou se foram apenas agrupados por acaso. Acoplamento diz respeito à independência entre componentes, a medida do impacto que a alteração da implementação de um componente tem sobre outros. Componentes, neste caso, podem ser entendidos como classes em um pacote, linhas de código em um método, responsabilidades de uma classe ou qualquer coisa neste sentido.

A aplicação dessas métricas não está restrita a objetos, trechos de código ou atributos, elas também são aplicadas à arquitetura de uma aplicação. O uso de Camadas (Layers) é um Padrão Arquitetural que ajuda na tarefa de separar responsabilidades, promovendo baixo acoplamento e alta coesão em um sistema.

O objetivo deste artigo é descrever este padrão e apresentar técnicas que ajudam na implementação das Camadas mais comuns: Apresentação, Aplicação, Negócios e Persistência.

O que são Camadas?

Um exemplo clássico de Camadas é o modelo utilizado pelo protocolo TCP/IP (baseado no modelo OSI) mostrado na figura 1.

Cada Camada tem sua responsabilidade. A Camada de Rede não precisa conhecer a implementação da Camada de Enlace de Dados. Tanto faz se a Rede Utiliza Ethernet, Wi-fi, Token Ring, PPP ou qualquer outro protocolo, desde que a implementação cuide das responsabilidades que lhe são devidas. Um outro exemplo, mostrado na figura 2, é uma aplicação Java EE comum.

Nesse caso, a sua aplicação roda num Servidor de Aplicações (como o Jakarta Tomcat ou JBoss). Este por sua vez roda em uma Máquina Virtual Java, que roda sobre um Sistema Operacional, que por sua vez roda sobre o hardware. Para sua aplicação, não importa se o sistema operacional é Windows ou Linux, se a JVM é da Sun ou da Bea, mas costuma importar qual é o servidor de Aplicações utilizado. Da mesma forma, a JVM precisa saber em qual Sistema Operacional está rodando porque sua implementação varia de acordo com esse. A JVM não tem necessidade alguma de saber se está sendo utilizada para rodar um Servidor de Aplicações ou um jogo feito em Java, para ela tanto faz.

Partindo desses exemplos, vamos conceituar Camadas:

Camadas são divisões lógicas de componentes agrupados por responsabilidades em comum.

Isso significa dizer que uma Camada irá agrupar classes, pacotes e outros componentes que possuam responsabilidades em comum. As classes responsáveis por uma determinada funcionalidade serão agrupadas em uma Camada. Essa separação promove a coesão na medida que classes relacionadas estão juntas, e evita o acoplamento porque a comunicação entre Camadas é feita de maneira controlada.

Idealmente, Camadas se comunicam apenas com Camadas adjacentes.

Nem sempre este princípio pode ser seguido, mas o ideal é que assim como na pilha TCP/IP mostrada, as Camadas se comuniquem apenas com as Camadas vizinhas. No exemplo, a Camada de Aplicação se comunica apenas com a Camada de Transporte, ela nunca fará contato direto com outra Camada.

Nos sistemas modernos, existem dois tipos de Camadas: Físicas e Lógicas. Normalmente as Camadas Físicas são chamadas em inglês de tiers enquanto as lógicas são conhecidas como layers. Isso não é uma regra e em português usa-se a mesma palavra para ambas. Não existe relação predefinida entre Camadas Lógicas e Físicas num sistema, uma Camada Física pode hospedar diversas Camadas Lógicas ou uma Camada Lógica pode se espalhar por diversas Camadas Físicas.

Como qualquer técnica, o uso de Camadas têm vantagens e desvantagens. Algumas das vantagens das Camadas:

. reduzem complexidade: agrupam componentes e simplificam a comunicação entre eles;
. reduzem dependência/acoplamento: a regra de comunicação evita dependências diretas entre   componentes de Camadas diferentes;
. favorecem a coesão: componentes de responsabilidades relacionadas são agrupados;
. promovem reusabilidade: camadas podem ser reutilizadas em outros sistemas ou podem ser   substituídas;
. é um Padrão Arquitetural conhecido: facilita a comunicação e entendimento entre   desenvolvedores.

E entre as desvantagens:

. limitadas pela tecnologia: algumas regras precisam ser quebradas por limitações tecnológicas;
. apenas complicam um sistema muito simples: não é qualquer sistema que exige o uso de   Camadas;
. possibilidade de overdose: muitos arquitetos acabam criando Camadas demais e tornando a   aplicação extremamente complexa.

Camadas Físicas

Uma camada física é formada por objetos em um sistema distribuído que se comunicam. Não estamos falando de objetos Java (instâncias de uma classe) aqui, a palavra “objeto” no vocabulário de Sistemas Distribuídos é utilizada para os elementos do sistema: servidores, clientes, equipamentos de rede, etc. O agrupamento destes objetos, forma as Camadas Físicas em um sistema.

Geralmente, Camadas Físicas são utilizadas para melhorar a administração do sistema e aumentar a escalabilidade. Segurança também pode ser um motivo forte ao se decidir por essa arquitetura. Por exemplo, poderíamos ter como Camada Física um grupo de servidores de Bancos de Dados, ou como Camada Física web um conjunto formado por load-balancers e máquinas com servidores Web que se comunicam com uma Camada formada por servidores onde estão as regras de negócio do sistema.

Elementos que formam Camadas Físicas podem ser, entre outros:

. JVMs (mesmo que sejam duas JVM rodando numa mesma máquina);
. Servidor;
. Computador Pessoal;
. Servidor de Aplicações;
. CPU;
. Dispositivo móvel (celular, PDA, etc.).

Leia o artigo completo na revista MUNDOJAVA, já nas bancas!