Aplicações Multicamadas

Agosto, 2008

Oscar A. Konno Sampaio

As aplicações empresariais geralmente são implementadas utilizando a

arquitetura multicamadas. Cada camada é composta de vários
componentes de software que possuem uma interface bem definida para se
comunicar com outros componentes ou com serviços oferecidos pelo
middleware.

Arquitetura Multicamadas – é uma arquitetura de software em que o

aplicativo é dividido em várias camadas, onde cada camada é responsável
por um determinado aspecto ou funcionalidade como apresentação, lógica
de negócio, persistência, etc.

Middleware – é um sistema de software que faz a mediação entre outros

softwares. É utilizado para mover informações entre programas ocultando
do programador diferenças de protocolos de comunicação, plataformas e
dependências do sistema operacional. É geralmente constituído por
módulos dotados de APIs de alto nível que proporcionam a sua integração
com as aplicações e interfaces de baixo nível que permitem a sua
independência relativamente ao dispositivo. Seu objetivo é mascarar a
heterogeneidade e fornecer um modelo de programação mais produtivo
para os programadores de aplicativos. É composto por um conjunto de
processos ou objetos em um grupo de computadores, que interagem entre
si de forma a implementar comunicação e oferecer suporte para
compartilhamento de recursos a aplicativos distribuídos.

Porque utilizar a arquitetura multicamadas

Desacoplamento
Nas aplicações monolíticas, a lógica de negócios, apresentação e controle
estão normalmente interligadas, apresentando um alto acoplamento. Isto
normalmente se torna um problema desde que alterações em um
componente impactam em muitos outros, necessitando que sejam feitas
validações de grandes partes do sistema mesmo para pequenas alterações.
Outro efeito desse alto acoplamento é a dificuldade de se reutilizar o código.

Nas aplicações implementadas em camadas, os diferentes aspectos são

implementados separadamente, forçando o desacoplamento e permitindo a
reusabilidade dos vários componentes.

Distribuição do processamento
As aplicações empresariais normalmente necessitam ter seu processamento
distribuído entre vários hardwares, seja por necessidade de escalonar o
processamento ou pela distribuição geográfica.
No entanto o processamento distribuído introduz complexidade no
desenvolvimento de sistemas. Os middlewares permitem que os sistemas
sejam desenvolvidos sem que o desenvolvedor necessite se preocupar com
os detalhes como localização e sincronização do acesso aos recursos,
comunicação, protocolos envolvidos, etc.

Componentização
O desenvolvimento em multicamadas é feito pela construção de
componentes de software.

Um componente consiste de uma porção de software com uma interface

(forma de se comunicar com o mesmo) bem definida, e com funcionalidade
pre definida.

Componentes podem ser utilizados para compor componentes maiores. São

como peças que podem ser combinadas para formar componentes maiores.
Essas peças podem ser reutilizadas ou substituídas por outras equivalentes
conforme a necessidade de desenvolvimento.

Camadas
De uma forma geral podemos dividir um aplicativo em 6 camadas:

Camada de apresentação – cliente

Fornece uma interface para o usuário final. O cliente pode ser ‘magro’
(browser por exemplo – IE, Firefox, Opera, etc.), gordo (um aplicativo
rodando na máquina do usuário) ou algo entre os dois extremos.

Camada de apresentação – servidor

Fornece para a camada de apresentação no cliente os dados, tais como
páginas HTML, necessários para gerar a interface com o usuário.

Camada de lógica de negócios – servidor

Inclui os métodos de negócio por trás da aplicação. Consiste das ações que
governam a dinâmica do negócio (workflow). Pode ser visto como os verbos
de uma aplicação.

Ex.: cadastrar clientes, efetuar compra, enviar mercadoria, confirmar

pedido, etc.

Camada de modelo de domínio

Consiste do modelo de dados utilizado para representar os diferentes
atores e entidades envolvidos no negócio. P.ex. clientes, fornecedores,
pedido, produto, etc. São utilizados pela camada de lógica de negócios.
Podem ser vistos como os ‘substantivos’ de uma aplicação.
Camada de persistência
Responsável por persistir os dados do aplicativo, ou seja, os dados (modelo)
manipulados pela camada de lógica de negócios necessitam ser salvos em
um meio físico como um banco de dados. A responsável por isso é a camada
de persistência.

Camada de integração
Permite conectar a aplicação a outros sistemas. Ela permite a integração
com sistemas legados, banco de dados, outros sistemas que necessitam
participar da lógica de negócios, ou mesmo com partes do aplicativo
separados por grandes distâncias geográficas.

Plataforma JEE
A plataforma Java Enterprise Edition é a plataforma Java para o
desenvolvimento de aplicações empresariais utilizando a arquitetura de
multicamadas. O JEE corresponde ao JSE para aplicações empresariais.
1
Em JEE um aplicativo consiste de componentes que interagem entre si e
são gerenciados por um servidor de aplicativo.

O servidor de aplicativos é o núcleo da plataforma JEE, é ele que fornece

a infra-estrutura básica para o desenvolvimento e execução de um
aplicativo empresarial. Consiste de um software onde são hospedados os
componentes responsáveis por implementarem as diversas camadas do
aplicativo – lógica de negócios, componentes web (apresentação) - e
fornece serviços que permitem a persistência e interação com outros
aplicativos.

Os componentes devem implementar uma interface padronizada para que o

container (outro nome dado ao servidor de aplicativo) possa se comunicar
com o mesmo e gerenciar o seu ciclo de vida. Da mesma forma, os serviços
fornecidos pelo container, são utilizados pelos aplicativos hospedados no
servidor através de uma interface bem definida.

1
O JSE (Java Standard Edition) é a plataforma para desenvolvimento de aplicativos
em Java no desktop, os aplicativos desenvolvidos em JSE são normalmente auto-
suficientes e não dependem de uma infra-estrutura externa para que seja
executado. O JSE fornece funcionalidades como acesso a disco, entrada/saída,
bibliotecas básicas, acesso a banco de dados, funções matemáticas e interface
gráfica.
Camada de Apresentação Cliente
A camada de apresentação no cliente pode ser de três tipos: clientes web,
applets e aplicativos clientes.

Clientes Web
Um cliente web é composto de duas partes:

1 ) Páginas web dinamicamente geradas codificadas por uma linguagem de

marcação (XML, HTML, etc). Estas páginas são normalmente geradas por
componentes na camada de apresentação no servidor.

2) Um browser que monta visualmente a página recebida do servidor.

Os clientes web são também chamados de cliente magro. Normalmente não

acessam banco de dados, não executam lógica de negócios nem se
comunicam com outros aplicativos (exceto o servidor). Todo o trabalho é
efetuado no lado servidor, ficando o cliente responsável apenas por
apresentar os dados.

Atualmente com a utilização cada vez maior de tecnologias como Ajax e

Flex, muito da lógica de controle está migrando do servidor para o cliente,
mas a lógica de negócios e interação com outros aplicativos ainda são
rodados no servidor.
Applets
Uma pagina recebida do servidor pode incluir um applet encapsulado. Um
applet consiste de um pequeno aplicativo Java que é executado na maquina
virtual Java do browser web. Um applet está sujeito a normas de segurança
para impedir que efetue operações indevidas na máquina cliente.

Aplicativo cliente
Um aplicativo cliente roda em uma máquina cliente e fornece uma interface
para o usuário interagir com o sistema. A interface pode ser desde
interfaces gráficas (GUI) sofisticadas até interfaces em linhas de comando.

O aplicativo cliente normalmente acessa diretamente a camada de negócios

do aplicativo e são muitas vezes chamados de clientes gordos – por
implementarem toda a lógica de interação com o usuário.

Camada de Apresentação Servidor

Na camada de apresentação no servidor, os componentes que
implementam o aplicativo são desenvolvidos na forma de páginas JSP
(incluindo JSF) e servlets. Estes componentes são hospedados por um
container WEB, que é responsável por receber as requisições do cliente WEB
e repassar para processamento pelos componentes do aplicativo. Estes
componentes, a partir da interação com outras camadas, obtém ou alteram
dados, e geram páginas em uma linguagem de marcação (HTML ou XML)
que é enviada para o cliente.

Além das páginas JSP e servlets, o container web pode fornecer páginas,
imagens e outros recursos estáticos, que não são considerados
componentes web.
Observar que a comunicação entre as camadas da web e lógica de negócios
é feita pela passagem de objetos Java Beans2.

Lógica de Negócios
A lógica de negócios em uma aplicação JEE é implementada em
componentes EJB. EJB’s são componentes de softwares gerenciados pelo
container EJB. Fisicamente, os EJB’s podem estar no mesmo servidor em que
se encontra o container web, em outro servidor ou distribuidos em vários
servidores. O container EJB se encarrega da comunicação entre os vários
EJBs e o desenvolvedor não precisa se preocupar com os detalhes de como
se dá a comunicação entre eles ou da localização dos mesmos.

Modelo de Negócio
O modelo do negócio é implementado em classes Java Beans chamadas
entities. Estas classes são persistidas (camada de persistência) através de
uma API de persistência, o JPA, que se encarrega de efetuar as operações
(insert, update, delete) no banco de dados. Para isso estas classes são
anotadas com informações sobre como elas devem ser mapeadas no banco
de dados.

Containers JEE
Uma aplicação multicamadas é normalmente extremamente difícil de
escrever, principalmente se tivermos de nos preocupar com os detalhes de
baixo nível como: controle transacional, gerenciamento de estado,
multithread , processamento concorrente, controle de acesso aos recursos,
etc. Na plataforma Java, o container JEE cuida de todos estes detalhes,
deixando para o desenvolvedor apenas o trabalho de implementar a lógica
de negócios e apresentação através dos componentes que serão
hospedados nele.

Todos os componentes que formam os aplicativos JEE “vivem” dentro de um

container. Para que eles possam ser executados necessitam ser montados
em um módulo JEE e hospedados no container. A este processo de
instalação do módulo no container chamados de deploy.

O processo de montagem do módulo JEE inclui também a configuração do

mesmo de forma a informar como o container deve tratar aquele módulo no
que se refere a aspectos como segurança, gerenciamento de transações,
localização (como encontrar os componentes do módulo), acesso a recursos
como banco de dados, mecanismos de comunicação etc.

2
Java Beans são objetos Java que possuem 2 caracteristicas: possuem um
construtor padrão (sem argumentos) e as propriedades são acessados através de
métodos getters e setters.
Tipos de Containers JEE

Servidor de Aplicativos JEE

É o aplicativo servidor de uma plataforma JEE. Ele contem containers EJB e
WEB. Exemplos de servidores de aplicativos JEE são o JBoss, Glassfish, etc.

Container Enterprise JavaBean (EJB)

Gerencia a execução de componentes EJB de uma aplicação JEE. O container
EJB roda dentro de um servidor de aplicativo JEE.

Container WEB
Gerencia a execução de páginas JSP e servlets de uma aplicação JEE. Os
contêiner Web rodam dentro de um servidor JEE.

Montagem e deploy de aplicações JEE

Os aplicativos JEE são empacotados em unidades padronizadas para
instalação em um servidor JEE. Cada unidade deve conter:

• Componentes (EJBs, JSP, Servlets, Applets, etc) – consistem de classes

Java (EJB, Servlets) devidamente anotadas e que implementam as
interfaces exigidas para o tipo de componente. Os páginas JSP são
páginas que utilizam tags JSP ou JSF que são compiladas em classes
Java para depois serem executadas.

• Recursos como páginas html, imagens, etc.

• Descritores de instalação que descreve o seu conteúdo (opcional)

Os componentes, recursos e descritores devem ser distribuídos em uma
estrutura de arquivos definida pela especificação JEE. Para fazer o deploy,
esta estrutura de arquivo deve ser empacotada (jar) em um arquivo que
será colocado dentro do servidor de aplicativo.

No caso de um módulo WEB, o arquivo deve ser nomeado com a extensão

WAR (Web archive) e no caso de um módulo EJB em um arquivo EAR

JEE API e Serviços

A plataforma JEE disponibiliza vários serviços que podem ser utilizados pelos
componentes de uma aplicação. Estes serviços são acessíveis via uma
interface de aplicativo (API) padrão.

Serviço de Diretorios - JNDI – Java Naming and Directory Interface,

fornece a base para a localização de recursos em um ambiente JEE. Os
recursos (banco de dados, componentes, outros serviços, etc.) são
registrados no JNDI utilizando um nome. Este nome é utilizado como uma
chave para localizar o recurso quando necessário.

Segurança – JAAS – Java Authentication and Authorization Service , o

modelo de segurança do JEE permite configurar o acesso aos componente
web, ejbs ou recursos do sistema.

Controle Transação – JTA - Java Transaction API, o modelo transacional do

JEE permite especificar relações entre os métodos de forma a fazê-los
participarem de transações (ACID). É possível utilizar tanto a abordagem via
configuração como programável.

Comunicação – o JEE implementa por baixo dos panos a conectividade

entre os vários componentes participantes do aplicativo corporativo,
escondendo as complexidades inerentes a distribuição do processamento.

Enterprise Java Beans

Os EJBs são os componentes fundamentais para a implementação da lógica
de negócios em uma aplicação JEE.

Um EJB possui como características:

• Pode ser acessível remotamente (processamento distribuído)

• É gerenciado pelo container que controla a sua criação, utilização e

deleção. O container pode utilizar um pool3 de ejbs para atender as
solicitações dos diversos clientes.

• Gerenciamento de transações – o container EJB suporta o controle

declarativo de transações que permite implementar o
comportamento transacional por configuração ao invés de se
codificar.

• Segurança – o container EJB pode cuidar dos detalhes de

autenticação e autorização de acesso aos recursos de forma
declarativa (por configuração) , liberando o desenvolvedor dos
detalhes ou da implementação do mecanismo de segurança.

3
Um pool consiste de uma técnica de gerenciamento de recurso. Os recursos
disponíveis em uma aplicação gerencial (banco de dados, ejbs, servlets, etc.) são
compartilhados por vários clientes que utilizam estes recursos. Para otimizar a
utilização dos mesmos, ao invés de criar um recurso para cada solicitação – o que
leva tempo, pois para isso é necessário alocar e inicializar o mesmo – o container
cria um conjunto (pool) de recursos e vai utilizando conforme a demanda. Depois de
utilizado o recurso volta ao pool e pode ser reutilizado novamente por outro cliente.
Caso o numero de solicitações exceda o numero de objetos disponíveis no pool o
container aloca novos objetos para suprir a demanda.
Tipos de Enterprise Java Beans

Session EJB
Um session bean é requisitado por um cliente com o propósito de executar
uma operação da lógica de negócios. O nome session (sessão) se refere ao
fato da instancia do bean ficar disponível durante uma sessão e não
sobrevive a uma queda ou desligamento do servidor. Um session bean pode
ser utilizado para modelar qualquer funcionalidade da lógica de negócios da
aplicação.

Existem 2 tipos de session beans:

Statefull session bean – o container salva o estado do bean

(propriedades do mesmo) entre requisições do cliente. Um exemplo
típico de statefull EJB é um carrinho de compras em um aplicativo de
loja web.

Stateless session bean – não mantém registro do estado de

solicitações anteriores. Ele pode ser utilizado para efetuar operações
atômicas como criar um pedido por exemplo.

Os session beans podem ser requisitados tanto localmente quanto

remotamente via Java RMI (o desenvolvedor não precisa se preocupar com
os detalhes desse acesso remoto, ele trabalha como se estivesse utilizando
um objeto local). Um session bean do tipo stateless também pode ser
acessado via web service.

Message Drive Beans (MDB)

Como os session beans, o MDB processa operações da lógica de negócios.
Entretanto, o Message Beans diferem dos Session Beans na forma como é
feita sua requisição. Em um MDB as requisições não são feitas diretamente
o bean, ao invés disso, as requisições são enviadas como mensagens para
um servidor de mensagens (daí o nome Message Drive Beans). Este servidor
se encarrega de entregar a mensagem ao bean para que este a processe.

A execução da requisição ocorre de forma assíncrona, ou seja, o cliente não

precisa esperar para que a requisição seja processada. Caso o bean a qual
se destina a mensagem esteja inacessível no momento em que o cliente
enviou a requisição, o servidor de mensagem armazena a solicitação e a
envia quando o bean estiver disponível novamente.
Bibliografia
The Java EE 5 Tutorial – Sun Microsystem, 2006.

Panda, Debu; Rahman, Reza; Lane, Derek. EJB 3 in Action. Manning, 2007.

Sriganesh, Rima; Brose, Gerald; Silverman, Micah. Mastering Enterprise

JavaBeans 3.0. Wiley, 2006.

Schincariol, Merrick; Keith, Mike. Pro EJB 3 – Java Persistence API.

Apress, 2006.

Crawford, Willian; Kaplan, Jonathan. J2EE Design Patterns. O’Reilly, 2003.

Alur, Deepak; Crupi, John; Malks, Dan. Core J2EE Patterns: Best
Practices and Design Strategies. 2nd Edition. Prentice Hall, 2003.