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