ARQUITETURA EM
CAMADAS
DISCIPLINA: ENGENHARIA DE SOTWARE
Arquitetura centralizada


Dominantes até década de 80 como
arquitetura corporativa
Problema básico: interface não amigável
Arquitetura em 2 camadas

Sistemas em camadas surgiram para:





Melhor aproveitar os PCs da empresa
Oferecer sistemas com interfaces gráficas amigáveis
Integrar o desktop e os dados corporativos
Em outras palavras, permitiram aumentar a
escalabilidade de uso de Sistemas de Informação
Os primeiros sistemas cliente-servidor eram de duas
camadas


Camada cliente trata da lógica de negócio e da UI
Camada servidor trata dos dados (usando um SGBD)
Arquitetura em 3 camadas

A arquitetura cliente/servidor em 2 camadas sofria
de vários problemas:



Falta de escalabilidade (conexões a bancos de dados)
Enormes problemas de manutenção (mudanças na lógica
de aplicação forçava instalações)
Inventou-se a arquitetura em 3 camadas

Camada de apresentação (UI)
Camada de aplicação (business logic)

Camada de dados



Problemas de manutenção foram reduzidos,
pois mudanças às camadas de aplicação e de
dados não necessitam de novas instalações no
desktop
Observe que as camadas são lógicas

Fisicamente, várias camadas podem executar na
mesma máquina

Quase sempre, há separação física de máquinas
Arquitetura em 3/4 camadas Web-Based


A arquitetura em 3 camadas original sofre de
problemas:
Às vezes, continua-se a chamar isso de 3
camadas porque as camadas Web e Aplicação
freqüentemente rodam na mesma máquina
(para pequenos volumes)
Arquitetura distribuída em n camadas

Os problemas remanescentes:




Não há suporte a Thin Clients (PDA, celulares, smart cards, quiosques, ...)
pois preciso usar um browser (pesado) no cliente
Dificuldade de criar software reutilizável: cadê a componentização?
Fazer aplicações distribuídas multicamadas é difícil.
REQUISITOS:





Implementar persistência (impedance mismatch entre o mundo OO e o
mundo dos BDs relacionais)
Implementar tolerância a falhas com fail-over
Implementar gerência de transações distribuídas
Implementar balanceamento de carga
Implementar resource pooling



As empresas não querem contratar PhDs para
implementar sistemas de informação!
O truque é introduzir middleware num
servidor de aplicação que ofereça esses
serviços automaticamente
Além do mais, as soluções oferecidas (J2EE,
.Net) são baseadas em componentes
A Arquitetura J2EE




Componentes de Aplicação
Aplicações J2EE são compostas de
componentes
Para nós, um componente é uma unidade
auto-contida de software que pode ser
composta numa aplicação em tempo de
projeto (sem compilação)
Componentes J2EE são escritos em Java
Componentes J2EE na Camada de
Apresentação

Os seguintes componentes podem existir na
camada de apresentação:

"Application client" (cliente não-Web)



Tipicamente usa Swing como User Interface (UI)
Também chamado "Console Application"
Applets
Componentes J2EE na Camada Web

Componentes da camada Web podem incluir vários módulos,
incluindo:


Páginas HTML/XML estáticas
Servlets


Java Server pages (JSP)



Programas em Java que rodam no servidor Web e que processam
pedidos gerando respostas dinâmicas
Templates HTML mais fáceis de criar, mas contendo "scriplets" (trechos
em Java) para a geração de conteúdo dinâmico
São convertidas em servlets quando acessadas pela primeira vez
JavaBeans

Componentes tradicionais em Java que podem ser usados em servlets e
JSPs
Componentes J2EE na Camada de
Aplicação


Componentes da camada de aplicação são chamados Enterprise Java Beans
(EJB)
Há vários tipos de EJBs:

Session Beans



Entity Bean


Representam uma conversação transiente com um cliente
Quando o cliente termina, a session bean some
Representam dados persistentes gravados num banco de dados (tipicamente uma
linha de uma tabela)
Message-Driven Bean




Uma combinação de um session bean com um Listener de mensagem Java Message
Service (JMS)
Permite que um componente de aplicação (o message bean) receba mensagens
assíncronas
Isso significa que podemos acoplamento muito fraco entre pedaços da aplicação:
importante quando máquinas remotas estão envolvidas e podem nem estar no ar, ou
pelo menos, poderão não responder de forma síncrona a chamadas remotas
Não falaremos desse tipo de Bean nesta disciplina

As camadas podem ter vários nomes:

Apresentação, interface, cliente
Web
Aplicação, Business

Dados, Enterprise Information System (EIS)


Introdução a Containers Web


Tipos de Clientes
Há dois tipos básicos de clientes:

Clientes tipo "Aplicação"



Arquitetura em 2 camadas
São instalados em cada desktop
Clientes Web




Browser como cliente universal fornecendo a interface
com o usuário (UI)
Uso de HTML (talvez com Javascript ou DHTML),
ou XHTML ou XML/XSL para definir as telas
Uso de HTTP ou HTTPS como protocolo
A lógica de negócio (Business Logic) roda no servidor

J2EE permite criar aplicações Web
dinâmicas (com conteúdo dinâmico)

J2EE provê Web Containers e duas API
para escrever aplicações

API servlets

API Java Server Pages (JSP)
O Protocolo HTTP

O cliente inicia a conversa pedindo uma página


GET request Method


Para pedir páginas estáticas ou dinâmicas
POST Request Method


Não há callback do servidor para o cliente
Para pedir páginas dinâmicas
Formulários em páginas HTML podem usar o método
GET ou POST
Containers Web e Aplicações Web


Aplicações Web rodam no servidor
Para fazer aplicações no servidor, previsamos de:


Um modelo de programação e uma API
Suporte de runtime no servidor


Suporte de deployment


Para executar aplicações
Para instalar aplicações no servidor e customizá-las
J2EE oferece:

Web Components

Java Servlets e Java Server Pages

Web Applications


Uma coleção de servlets, páginas JSP, outras
classes, bibliotecas e recursos estáticos tais
como páginas HTML, XML, etc.
Um Web Container



Para hospedar aplicações Web
Essencialmente uma JVM com API especial
de servlets e suporte para JSP
O container é responsável pelo ciclo de vida
dos componentes Web (inicialização,
chamada, destruição, ..)
Servlets

Servlets permitem que a lógica de aplicação seja
embutida no processo request-response



Um servlet é um programa Java que roda do lado servidor
e que estende a funcionalidade do servidor Web
A API de servlets provê um framework simples para
construir aplicações em servidores Web que dão suporte a
servlets
Exemplos de servidor Web que dão suporte a
servlets





Tomcat do projeto Apache
GlassFish
Inprise Application Server da Borland
iPlanet Application Server da Sun
Servidores completos J2EE grátis tais como JBoss

Internet Information Server (IIS) da Microsoft não
tem suporte a Web Containers


Use Tomcat, JRun ou ServletExec como plug-in no IIS
Quando o Web server entende que uma URL deve
ser atendida por um Web Container, ele passa o
controle para o container



Este container decide qual Web Application deve executar
Quando é um servlet, o container controla a execução do
servlet
Através da API de servlets, o servlet pode acessar a
informação do Request, fornecer uma Response, etc.
Java Server Pages


O uso de templates JSP é melhor pois deixa o Web Designer
com possibilidade de criar as páginas
JSP é uma extensão da tecnologia de servlets






Uma página JSP contém código HTML (ou XML)
Tags especiais ou "scriplets" especiais são embutidos no HTML para
execução para produzir o conteúdo final
A página JSP é traduzida para um servlet automaticamente pelo
servidor J2EE
O servlet é compilado (apenas uma vez)
A partir daí, o servlet é executado para gerar o conteúdo dinâmico
Observe que, depois que a página JSP foi transformada em servlet, a
situação é idêntica à execução de um servlet