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