ARQUITETURA EM CAMADAS DISCIPLINA: ENGENHARIA DE SOTWARE.
Transcript of ARQUITETURA EM CAMADAS DISCIPLINA: ENGENHARIA DE SOTWARE.
ARQUITETURA EM CAMADASDISCIPLINA: 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
Programas em Java que rodam no servidor Web e que processam pedidos gerando respostas dinâmicas
Java Server pages (JSP) 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 Representam uma conversação transiente com um cliente Quando o cliente termina, a session bean some
Entity Bean 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 Não há callback do servidor para o cliente
GET request Method Para pedir páginas estáticas ou dinâmicas
POST Request Method 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
Para executar aplicações Suporte de deployment
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