Mdulo 6Programao WEB

Lio 1Introduo Programao WEB

Verso 1.0 - Nov/2007

JEDITM

AutorDaniel Villafuerte

EquipeRommel FeriaJohn Paul Petines

Necessidades para os ExercciosSistemas Operacionais SuportadosNetBeans IDE 5.5 para os seguintes sistemas operacionais:

Microsoft Windows XP Profissional SP2 ou superior Mac OS X 10.4.5 ou superior Red Hat Fedora Core 3 Solaris 10 Operating System (SPARC e x86/x64 Platform Edition)

NetBeans Enterprise Pack, poder ser executado nas seguintes plataformas: Microsoft Windows 2000 Profissional SP4 Solaris 8 OS (SPARC e x86/x64 Platform Edition) e Solaris 9 OS (SPARC e

x86/x64 Platform Edition) Vrias outras distribuies Linux

Configurao Mnima de HardwareNota: IDE NetBeans com resoluo de tela em 1024x768 pixel

Sistema Operacional Processador Memria HD Livre

Microsoft Windows 500 MHz Intel Pentium III workstation ou equivalente

512 MB 850 MB

Linux 500 MHz Intel Pentium III workstation ou equivalente

512 MB 450 MB

Solaris OS (SPARC) UltraSPARC II 450 MHz 512 MB 450 MB

Solaris OS (x86/x64 Platform Edition)

AMD Opteron 100 Srie 1.8 GHz 512 MB 450 MB

Mac OS X PowerPC G4 512 MB 450 MB

Configurao Recomendada de Hardware

Sistema Operacional Processador Memria HD Livre

Microsoft Windows 1.4 GHz Intel Pentium III workstation ou equivalente

1 GB 1 GB

Linux 1.4 GHz Intel Pentium III workstation ou equivalente

1 GB 850 MB

Solaris OS (SPARC) UltraSPARC IIIi 1 GHz 1 GB 850 MB

Solaris OS (x86/x64 Platform Edition)

AMD Opteron 100 Series 1.8 GHz 1 GB 850 MB

Mac OS X PowerPC G5 1 GB 850 MB

Requerimentos de SoftwareNetBeans Enterprise Pack 5.5 executando sobre Java 2 Platform Standard Edition Development Kit 5.0 ou superior (JDK 5.0, verso 1.5.0_01 ou superior), contemplando a Java Runtime Environment, ferramentas de desenvolvimento para compilar, depurar, e executar aplicaes escritas em linguagem Java. Sun Java System Application Server Platform Edition 9.

Para Solaris, Windows, e Linux, os arquivos da JDK podem ser obtidos para sua plataforma em http://java.sun.com/j2se/1.5.0/download.html

Para Mac OS X, Java 2 Plataform Standard Edition (J2SE) 5.0 Release 4, pode ser obtida diretamente da Apple's Developer Connection, no endereo: http://developer.apple.com/java ( necessrio registrar o download da JDK).

Para mais informaes: http://www.netbeans.org/community/releases/55/relnotes.html

Programao WEB 2

JEDITM

Colaboradores que auxiliaram no processo de traduo e revisoAcio JniorAlexandre MoriAlexis da Rocha SilvaAllan Souza NunesAllan Wojcik da SilvaAngelo de OliveiraAurlio Soares NetoBruno da Silva BonfimCarlos Fernando Gonalves

Denis Mitsuo NakasakiEmanoel Tadeu da Silva FreitasFelipe GachoJacqueline Susann BarbosaJoo Vianney Barrozo CostaLuciana Rocha de OliveiraLuiz Fernandes de Oliveira Junior Marco Aurlio Martins BessaMaria Carolina Ferreira da Silva

Massimiliano GiroldiMauro Cardoso MortoniPaulo Oliveira Sampaio ReisPedro Henrique Pereira de AndradeRonie DotzlawSergio TerzellaThiago Magela Rodrigues DiasVanessa dos Santos AlmeidaWagner Eliezer Roncoletta

Auxiliadores especiais

Reviso Geral do texto para os seguintes Pases:

Brasil Tiago Flach Guin Bissau Alfredo C, Bunene Sisse e Buon Olossato Quebi ONG Asas de Socorro

Coordenao do DFJUG

Daniel deOliveira JUGLeader responsvel pelos acordos de parcerias Luci Campos - Idealizadora do DFJUG responsvel pelo apoio social Fernando Anselmo - Coordenador responsvel pelo processo de traduo e reviso,

disponibilizao dos materiais e insero de novos mdulos Rodrigo Nunes - Coordenador responsvel pela parte multimdia Srgio Gomes Veloso - Coordenador responsvel pelo ambiente JEDITM (Moodle)

Agradecimento EspecialJohn Paul Petines Criador da Iniciativa JEDITMRommel Feria Criador da Iniciativa JEDITM

Programao WEB 3

JEDITM

1. ObjetivosBem-vindo a este curso de programao WEB. Comearemos com uma ampla introduo, pois interesse das companhias (empresas) e dos programadores, conhecer sobre programao para a WEB.

Ao final desta lio, o estudante ser capaz de:

Descrever como funciona a WEB

Definir a arquitetura do tipo Cliente-Servidor

Entender sobre o protocolo HTTP

Definir o bsico sobre a arquitetura Java EE

Saber o que so Servlets e Java Server Pages

Programao WEB 4

JEDITM

2. Porque migrar para WEB?

2.1. Ambiente de Tecnologia Neutra

Um dos principais benefcios em aplicaes para a Internet, que a Internet um ambiente de tecnologia neutra. A comunicao em qualquer aplicao na WEB feita atravs de protocolos populares (HTTP/FTP), que no requerem que o usurio nem o cliente tenham qualquer sistema operacional em particular instalado em sua mquina ou seja desenvolvida em uma linguagem de programao especfica. Tudo que os clientes necessitam de um navegador WEB (denominado Browser), o acesso a aplicao e qualquer sistema operacional. Isto traz diversas possibilidades dentro de uma ampla gama de aplicaes baseadas na WEB.

2.2. Facilidade de distribuio e atualizao

Visto que o navegador WEB o nico programa instalado que os usurios iro necessitar, no h necessidade de fornecer programas adicionais atravs de CDs ou outra mdia. Assim, como no existe a necessidade do usurio repassar uma seqncia de instalao, possivelmente demorada, o que ser necessrio o local e acesso a aplicao na internet, e tudo estar pronto para funcionar.

Outro benefcio de se ter o cdigo binrio exato do programa, que residir em um nico servidor acessvel, ao invs de instalado no computador do usurio, pois evita-se possveis problemas comuns relatados com atualizaes de programas, tais como a necessidade de checar periodicamente novas verses de programas. O problema de conseguir novas atualizaes dos programas e eliminado completamente. O usurio no precisa ser informado sobre uma atualizao do programa; tudo que ser necessrio atualizar o cdigo no servidor WEB e, automaticamente, todos os usurios iro usufruir da nova verso.

Programao WEB 5

JEDITM

3. Arquitetura Cliente-Servidor

3.1. Cliente Pesado e Cliente Magro

Uma aplicao WEB um tipo de aplicao que faz uso da chamada estrutura Cliente-Servidor. Neste tipo, um programa cliente conecta a um servidor para acessar informaes que necessita para completar as tarefas que os usurios desejam para realizar. H os que so chamados clientes magros, e os que so chamados clientes pesados.

Clientes magros so os que contm apenas o mnimo necessrio para que o usurio execute o sistema. Em geral, apenas uma casca. Todos as regras de negcio, dados, exceto os que so fornecidos pelo usurio, residem dentro de um servidor.

Clientes pesados so os que contm, alm de uma interface, alguns, se no muitos, dos processos de regra de negcio requeridos pelas tarefas especficas dos usurios.

3.2. Arquitetura Cliente-Servidor na viso WEB

Na definio acima, podemos citar que o cliente utilizado para aplicaes WEB so os que ns chamamos de clientes magros. O programa cliente, um navegador, neste caso, apenas uma interface que o usurio utiliza para realizar tarefas. Tudo mais, como os dados que o usurio precisa para operar num determinado fluxo lgico de execuo do programa, reside no servidor. De uma perspectiva mais focada na WEB, estas so as funes do servidor e do cliente:

3.2.1.Servidor WEB

O servidor recebe uma requisio do cliente atravs do navegador WEB e retorna uma resposta. Qualquer requisio vinda de um cliente inclui o nome e o endereo do item que o cliente est procurando, assim como, qualquer dado fornecido pelo usurio. O servidor assimila a requisio, a processa e retorna uma resposta dos dados procurados pelo cliente ou exibe um cdigo de erro indicando que o item requisitado no existe no servidor.

3.2.2.Cliente WEB

da responsabilidade do navegador prover ao usurio uma interface para exibir a resposta fornecida pelo servidor. Quando o usurio emite uma requisio para o servidor, por exemplo, buscar um documento ou submeter um formulrio, o navegador deve enviar esta requisio de modo que o servidor possa entender.

Uma vez que o servidor finalizou o processo requisitado e enviou uma resposta, o navegador, que recebeu os dados requeridos da resposta do servidor, mostra a pgina resultante ao usurio.

Programao WEB 6

Figura 1: Funes do Servidor e do Cliente

Servidor processa as repostas com base nas requisies do cliente

Mquina rodando um WEB Server

Mquina rodando um Browser

Requisio do cliente (contm o nome e o

endereo de um item que o cliente est procurando)

Resposta do servidor (contm o documento requisitado ou um cdigo de erro caso nada seja

encontrado)

JEDITM

4. HTML

4.1. Como o browser sabe o que deve ser exibido ao usurio?

A maioria dos sites WEB no tem apenas um contedo simples de texto. Ao invs disso, emprega grficos ou tem formas que acessam dados.

4.2. Como o navegador sabe o que dever exibir?

A resposta reside em HTML, que so as iniciais para Hypertext Markup Language. HTML pode ser pensado como um conjunto de instrues para um navegador WEB que define como apresentar contedo para o usurio. um padro aberto, atualizado pela W3C ou a World Wide Web Consortium. Sendo este um padro aberto, qualquer um pode acess-lo. Isto tambm significa que os navegadores so desenvolvidos sobre esse padro. Isso significa que todos os navegadores sabem o que fazer quando se deparam com HTML, embora alguns navegadores mais antigos possam ter problemas em interpretar algumas pginas que foram escritas usando novas verses de HTML que foram criadas aps o desenvolvimento destes.

Programao WEB 7

JEDITM

5. HTTP

5.1. Definio

HTTP significa Hypertext Transfer Protocol. um protocolo de internet de rede de comunicaes com caractersticas especficas da WEB, que funciona no topo de duas outras camadas de protocolo, TCP e IP.

TCP um protocolo que responsvel por garantir que um arquivo enviado atravs de uma rede de comunicaes seja entregue completamente e com sucesso no destino. IP um protocolo que encaminha parte dos arquivos de um ponto para outro no seu destino.

O HTTP utiliza estes dois protocolos para ter certeza de que as requisies e respostas sero entregues corretamente ao final de cada pacote transferido.

O protocolo HTTP usa uma seqncia Requisio/Resposta (Request/Response): um cliente HTTP abre uma conexo e envia uma mensagem de requisio para um servidor HTTP. O servidor, ento, retorna uma mensagem resposta, geralmente contendo o recurso que foi requerido. Aps a entrega da resposta o servidor fecha a conexo fazendo uso de um protocolo stateless HTTP (no mantm qualquer informao de estado sobre a conexo).

O formato das mensagens Requisio/Resposta semelhante e orientado. Ambos os tipos de mensagem consistem em:

Um cabealho inicial Zero ou mais cabealhos adicionais Uma linha em branca (CRLF) O corpo de mensagem (opcional). Ex. Um arquivo, dado ou servio

5.2. Requisies HTTP

Requisies de um cliente para o servidor contm a informao sobre o tipo de dado que o usurio necessita. Um dos itens de informao encapsulados no HTTP Request a item method. Isto diz ao servidor como que este tipo de requisio est sendo feita, e como o resto da mensagem do cliente est formatada. H dois mtodos que sero encontrados: GET e POST.

5.3. Mtodo GET

o mtodo mais simples que usado principalmente para requisitar um recurso qualquer de um servidor, como uma pgina WEB, um arquivo de imagem grfica, um documento, etc.

O mtodo GET tambm pode ser utilizado para enviar dados para o servidor, embora isto tenha suas limitaes. A quantidade de caracteres que podem ser encapsulados em uma requisio GET limitada, ento, para as situaes onde muitas informaes precisam ser enviadas para o servidor, provvel que nem todas as mensagens sobrevivero.

Outra limitao do mtodo GET no envio dos dados. Os dados enviados utilizando este mtodo so simplesmente anexados URL enviada ao servidor.

Por enquanto, pense na URL como um nico endereo que enviado ao servidor. Denota o destino ao qual ser enviada a requisio. Um dos problemas encontrados neste mtodo so as muitas URLs que podem ser exibidas na barra de navegao dos navegadores. Isto significa que dados confidenciais, tais como senhas ou informaes do contato, sero expostas para qualquer pessoa.

A vantagem em se utilizar o mtodo GET para enviar dados para o servidor que a URL pode ser gravada como um bookmarker pelo navegador. Isto significa que o usurio pode simplesmente selecionar o item desejado e acess-lo em vez de ter que passar por todo o processo novamente. Vale ressaltar que isto tambm pode ser perigoso, se a facilidade do bookmarker no algo que os usurios deveriam ter.

Aqui est o que a URL criada com uma GET Request pode parecer:

Programao WEB 8

JEDITM

http://jedi-master.dev.java.net/Servlets/NewsItemView?newsItemID=2359&filter=true

O item antes do sinal de interrogao (?) representa a URL original da requisio (neste caso http://jedi-master.dev.java.net/Servlets/NewsItemView). Tudo aps, so os parmetros ou dados que so enviados juntos para o servidor. Olharemos mais atentamente para esta segunda parte. Estes so os parmetros adicionados pela requisio:

newsItemID=2359&filter=true

Em requisies GET, parmetros so codificados com pares nomes e valores. No so enviados valores excedentes de dados para o servidor sem que este conhea especificamente seus nomes. Os pares nomes e valores so codificados como:

name=value

Alm disso, caso exista mais de uma srie de parmetros, estes sero separados utilizando o smbolo &. Neste caso, os nomes dos parmetros que estudamos so newsItemID e filter, e os valores 2359 e true, respectivamente.

5.4. Mtodo POST

Outro mtodo de requisio utilizado o POST. Este tipo de requisio utilizada de tal forma que as solicitaes ao navegador podem se tornar complexas, isto , para que o usurio, atravs do navegador, possa enviar muitos dados para o servidor. Formas complexas so geralmente envidas utilizando requisies POST, assim como, tambm, formas simples.

Uma diferena aparente entre os mtodos GET e POST o modo como eles enviam dados para o servidor. Como declarado antes, o mtodo GET simplesmente anexa os dados URL enviada. O mtodo POST, por outro lado, esconde os dados dentro do corpo da mensagem enviada. Quando o servidor recebe a requisio e determina que ela uma POST, procurar no corpo da mensagem pelos dados.

5.5. HTTP response (Resposta HTTP)

O HTTP response do servidor contm o cabealho e o corpo da mensagem, de maneira semelhante ao HTTP request. utilizado um conjunto diferente de cabealhos. Os cabealhos contm informaes sobre a verso do protocolo HTTP que o servidor est vendo, assim como tambm o tipo de contedo que escondido dentro do corpo da mensagem. O valor para o tipo de contedo chamado de MIME-type. Informa ao navegador que a mensagem contm um HTML, imagem ou outros tipos de contedo.

5.6. Pginas Dinmicas ou Estticas

O tipo de contedo que pode ser oferecido por um servidor WEB pode ser esttico ou dinmico. Contedo esttico o contedo que no modificado. Este tipo de contedo geralmente no executa nada quando o servidor acessado e criado durante sua requisio. Quando estes contedos so enviados atravs da resposta do servidor, so enviados exatamente o mesmo contedo armazenado no servidor. Exemplos de contedos estticos incluem artigos de jornal arquivados, fotos de famlia, ou uma cpia de um documento.

O contedo dinmico, por outro lado, muda de acordo com a requisio do cliente. Tais aplicaes no servidor acessam este tipo de contedo seguindo um modelo pr-determinado, de acordo com o documento a ser enviado.

Este modelo ento preenchido de acordo com os parmetros enviados pelo usurio e retornam ao cliente. suficiente dizer que pginas dinmicas tem muito mais flexibilidade e tem mais utilidade que as pginas estticas. Aqui esto cenrios onde o contedo dinmico ser a nica que ir atender s necessidades do usurio.

A pgina WEB baseada em dados submetidos pelo usurio. Por exemplo, os resultados das pginas de pesquisa so gerados deste modo. Programas que processam

Programao WEB 9

JEDITM

pedidos e sites de comrcio fazem isto muito bem.

Dados mudam freqentemente. Uma pgina com a previso do tempo ou novas notcias atualizadas constantemente podem construir a pgina dinamicamente, talvez retornando a uma pgina previamente construda se ela ainda estiver atualizada.

A pgina WEB utiliza informaes de um banco de dados. Realizado pelo acesso e busca ao banco de dados da empresa.

importante perceber que o servidor WEB sozinho no tem capacidade de apresentar contedo dinmico. Os servidores WEB precisaram separar das aplicaes as informaes que iriam armazenar informaes pertinentes ao cliente (tais como dados coletados em formulrios) dentro do depsito de pginas. No se pode esperar que, a partir de um formulrio, ter os dados do cliente, quando submetidos ao servidor, este conhecer automaticamente o que dever ser feito com estes dados.

Estamos, agora, no ponto da discusso onde podemos, explicitamente, apontar que esta a questo principal das aplicaes WEB e formam a base para o nosso curso.

Neste curso iremos nos voltar, primeiramente, s tecnologias baseadas em Java para criar aplicaes WEB. Mais especificamente, faremo um uso excessivo de bibliotecas fornecidas a nvel de especificao.

Programao WEB 10

JEDITM

6. Java EE Viso sobre a camada WEBA plataforma Java EE foi criada para o desenvolvimento de aplicaes corporativas (baseada em componentes). O modelo de aplicao utilizada para esta plataforma chamado Modelo de Aplicao Multi-Camadas Distribudas, ou, simplesmente, multi-tier. O aspecto de distribuio deste modelo simplesmente significa que a maior parte das aplicaes programadas e desenvolvidas com esta plataforma em mente podem ter diferentes componentes instalados em diferentes mquinas. A parte multi-tier significa que as aplicaes so concebidas visando a separao entre as camadas dos vrios componentes importantes da aplicao. Um exemplo de uma aplicao multi-tier uma aplicao WEB: a camada de apresentao (representada pelo navegador), a camada de lgica de negcio (o programa que reside no servidor WEB), e a camada de dados (a base de dados que ir armazenar e gerenciar os dados da aplicao) so distintamente separadas, entretanto so necessrios para se criar uma aplicao para o usurio.

Um dos nveis na plataforma Java EE, como previamente mencionado a web-tier. Este nvel destinado a camada que interage com o navegador para criar o contedo dinmico. Existem duas tecnologias dentro desta camada: Servlets e JavaServer Pages JSP.

6.1. Servlets

A tecnologia Servlet foi a resposta inicial de Java para acrescentar a funcionalidade adicional aos servidores que utilizavam o modelo requisio/resposta. Possui a habilidade de ler dados contidos na requisio (request) passada ao servidor e gerar uma resposta dinmica baseada nestes dados.

Servlet no necessariamente limitada as situaes baseadas em HTTP. Como declarado antes, so aplicveis para qualquer caso que utilize o modelo requisio/resposta. As situaes baseadas em HTTP so, atualmente, o uso desta tecnologia. Ento, Java forneceu uma verso de classes especficas que implementam as caractersticas de HTTP.

6.2. JavaServer Pages

Uma das desvantagens de se utilizar a tecnologia de classes Servlets para gerar uma resposta ao cliente, que primeiro essa resposta deve ser formatada em HTML para ser reenviada. J que que Servlets so simplesmente classes em linguagem de Java, produzem resultados de modo semelhante a que outras classes Java fariam: atravs da impresso de caracteres em formato String pelo canal de sada, neste caso a HTTP response. Entretanto, HTML pode se tornar bastante complexo e ser muito difcil codificar HTML atravs do uso de uma String. Alm disso, o emprego de recursos grficos dedicados e pginas WEB programadas para ajudar na parte esttica das

Programao WEB 11

Figura 2: A camada WEB da plataforma Java EE (Imagem do documento J2EE Tutorial)

JEDITM

pginas difcil. Estaramos supondo que a equipe de desenvolvimento deva ter um bom conhecimento de Java.

Deste modo surgiu a tecnologia JavaServer Pages. A JSP se parece com HTML, tendo acesso a todas as habilidades dinmicas das classes Servlets atravs do uso de scripts e linguagem de expresso. Visto que se parece muito com HTML, os projetista podem se concentrar no simples formato HTML e realizar as modificaes necessrias e permite que os desenvolvedores ocupem-se do contedo dinmico.

6.3. Continer

O conceito central de qualquer aplicao Java EE o continer. Todo componente Java EE, inclui componentes WEB (Servlet ou JSP) que dependem da existncia de um continer. Sem o continer apropriado, no seriam executados.

Talvez outro modo de explicar isto seria pensar sobre o modo normal de execuo dos programas Java. Programas Java, para serem executados, devem ter um mtodo principal definido. Isto marca o comeo da execuo do programa, sendo este mtodo processado quando o programa executado na linha de comando.

Como veremos mais tarde, a classe Servlet, no tm um mtodo principal definido. E se existe algum definido (bad programming design) este no marca o comeo da execuo do programa. Quando o usurio faz uma requisio HTTP (http request) para uma classe Servlet, seu mtodo no chamado diretamente.

Em vez disso, o servidor passa a requisio no para a classe Servlet, mas para o continer na qual a Servlet est inserida. O continer o nico responsvel pela chamada ao mtodo apropriado na Servlet, dependendo do tipo de requisio do usurio.

6.4. Vantagens fornecidas pelo continer

Suporte de comunicaes. O continer passa todo cdigo necessrio para a Servlet para se comunicar com o servidor WEB. Sem o continer, desenvolvedores precisariam escrever o cdigo

Programao WEB 12

Figura 3: Contineres da plataforma Java EE (Imagem do documento J2EE Tutorial)

JEDITM

que iria criar uma conexo socket do servidor para a Servlet e vice-versa e ainda deveria gerenciar como eles falam um ao outro a cada momento.

Gerenciamento do Ciclo de Vida. O continer conhece o que se passa na vida de suas classes Servlets desde seu carregamento, instalao, inicializao e recolhimento pelo Garbage Collector.

Suporte a mltiplas tarefas. O continer controla a funo de criar uma nova thread a cada momento que uma requisio para a classe Servlet realizada. NOTA: o continer NO ser responsvel pelas thread de sua Servlet.

Declarao de Segurana. Um continer suporta o uso de um arquivo de configurao XML que pode repassar diretivas de segurana para sua aplicao WEB sem precisar de um cdigo complexo qualquer dentro do Servlet.

Suporte JSP. Pginas JSP, para funcionarem, devem ser transformadas em uma classe Java (Servlet). O continer controla a tarefa de traduzir as pginas JSP para uma classe Servlet, compilar e executar.

Programao WEB 13

JEDITM

7. Estrutura Bsica de uma aplicao WEBPara um determinado continer reconhecer sua aplicao como aplicao WEB vlida, esta deve se adequar a uma estrutura especfica de diretrio conforme a figura a seguir.

Figura 4: Estrutura do Directrio de uma aplicao Java WEB

A figura mostra a estrutura do diretrio requisitado pelo continer para que sua aplicao seja reconhecer. Alguns pontos relativos a esta estrutura so:

1. A Pasta Raiz (contm a aplicao) no precisa ser nomeada como Pasta Raiz. Pode ser, qualquer nome que se deseje, embora seja altamente recomendado que o nome desta pasta seja o nome da sua aplicao.

2. Qualquer outra pasta pode ser criada dentro desta estrutura do diretrio. Por exemplo, para desenvolvedores que desejam organizar seus contedos, devem ser criadas pastas dentro da pasta inicial para organizar os arquivos.

3. As letras maisculas na pasta META-INF e WEB-INF so intencionais e obrigatrias assim como as letras minsculas nas pastas classes e lib. No seguir o formato correto em qualquer destas pastas resultar que sua aplicao no ser capaz de localizar seus contedos.

4. Todo contedo da pasta WEB-INF no ser visto a partir do navegador (por exemplo, acessando seu endereo). O continer automaticamente gerencia isto, ou seja, para o navegador, esta pasta no existe. Este mecanismo protege suas fontes confidenciais, como classe de arquivos Java, as configuraes de aplicaes, entre outros. O contedo desta pasta, somente pode ser acessado pela aplicao.

5. Deve existir um arquivo chamado web.xml dentro da pasta WEB-INF. Mesmo que, por exemplo, sua aplicao WEB tenha apenas contedo esttico e no faa uso de classes Java ou arquivos externos, o continer ainda ir requerer que sua aplicao tenha estes dois itens.

Programao WEB 14

Contm HTML, imagens, e outros contedos estticos, e JSPs

Contm meta-information sobre suas aplicaes (opcional)

Contm todas as pastas que no sero vista no navegador

Contm classes de arquivos servlets criados para a sua aplicao

Contm arquivos JAR de bibliotecas que podem ser utilizadas pela aplicao

Arquivo XML que armazena as configues da aplicao

JEDITM

8. ExerccioResponda s seguintes questes:

Que tipo de arquitetura as aplicaes WEB usam? Quem so os participantes de tais estruturas e o quais so suas funes?

Qual o tipo de linguagem utilizada para indicar ao navegador como apresentar contedo para o usurio?

HTTP um protocolo de conexo stateful ou stateless?

Quais so os dois mtodos HTTP Request mais utilizados? E como eles so diferentes? Quando melhor usar um ao invs do outro?

Qual componente absolutamente necessrio para ser possvel executar aplicaes WEB?

Quais so os elementos no opcionais da estrutura de diretrios da aplicao WEB?

Qual o nome do arquivo XML utilizado para configurar aplicaes WEB? Em qual diretrio pode ser encontrado?

Qual pasta contm os arquivos JAR das bibliotecas usadas pelas aplicaes?

Qual pasta ir conter os arquivos de classe Java usados pelas aplicaes?

Programao WEB 15

Mdulo 6Programao WEB

Lio 2Classes Servlets

Verso 1.0 - Nov/2007

JEDITM

1. ObjetivosUma Servlet uma classe Java usada para estender a capacidade dos servidores que hospedam aplicaes acessadas via modelo de programao Requisio/Resposta. uma classe Java que implementa a interface Servlet e aceita requisies que vm de outras classes Java, clientes Web ou outros Servlets, gerando, ento, respostas.

As Servlets tambm so conhecidas como HTTP Servlet. Isto porque os Servlets so comumente usados com o HTTP atualmente, no h um protocolo cliente-servidor especfico.

Para iniciar o uso das Servlets ser necessrio ter conhecimentos sobre programao Java, conceitos sobre cliente-servidor, HTML bsico e HTTP (HyperText Transfer Protocol). Para criar uma Servlet ser necessrio importar para a nossa classe Java as classes de extenso padres que esto dentro dos pacotes javax.Servlet e javax.Servlet.http.

O pacote javax.servlet contm a estrutura bsica de Servlet, enquanto que o pacote javax.Servlet.http utilizado como uma extenso da tecnologia para as Servlets que realizam requisies HTTP.

Ao final desta lio, o estudante ser capaz de:

Obter uma viso geral da arquitetura Servlet

Conhecer o ciclo de vida de uma Servlet

Manipular requisies e respostas

Configurar, empacotar e distribuir uma aplicao WEB

Conhecer os parmetros de aplicaes WEB

Programao WEB 4

JEDITM

2. Conceitos Iniciais

2.1. Viso Geral da Arquitetura Servlet

Antes da tecnologia Servlet, o meio mais comum de adicionar funcionalidades a um servidor WEB era atravs do uso de CGI (Common Gateway Interface ou Interface de Entrada Comum). CGI fornece uma interface do servidor para uma classe externa permitindo que esta invoque o servidor a tratar as requisies do cliente. Porm, o CGI foi desenhado de forma que cada chamada para um recurso CGI fosse criado um novo processo no servidor; informao significante para a classe passada para este processo utilizando entradas padres e variveis de ambiente. Uma vez completada a requisio, o processo terminado, devolvendo o recurso ao sistema. O problema que incorre neste tipo de abordagem que isto impe pesadas requisies aos recursos do sistema limitando o nmero de usurios que a aplicao pode atender ao mesmo tempo.

A Tecnologia Servlet foi projetada para contornar este problema inerente ao CGI e prover aos desenvolvedores uma soluo robusta em Java para criar aplicaes WEB. Ao invs de criar um processo peso-pesado no servidor a cada requisio do cliente, com Servlets h somente um processo para todas as requisies: o processo solicitado pelo continer da Servlet para executar. Quando uma nova requisio chega, o continer cria somente uma pequena thread para executar a Servlet.

Servlets tambm so carregados em memria somente uma vez, ou seja, o continer carrega-os em memria na inicializao do servidor ou na primeira vez que o Servlet for requisitado para atender a um cliente, diferente do CGI, que para cada requisio do cliente carrega e descarrega os dados da classe em memria. Uma vez carregado em memria, est pronto para tratar as requisies dos clientes.

2.2. Primeira vista sobre Servlet

O cdigo a seguir mostra a estrutura de uma Servlet bsica que trata as requisies GET, assim como exibe o tradicional exemplo 'Hello World'.

import java.io.*;import javax.servlet.*;import javax.servlet.http.*;public class HelloServlet extends HttpServlet { public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { //"request" utilizado para ler os dados do formulrio HTML dos cabealhos // HTTP (um exemplo so os dados digitados e submetidos) // e outros dados que podem ser obtidos a partir da requisio do cliente. // "response" para especificar a linha e o cabealho de resposta do HTTP // (exemplo: especificar o tipo do contedo, definir cookies). // Tambm contm mtodos que permitem ao Servlet gerar respostas para // o cliente. PrintWriter out = response.getWriter(); out.println(" Hello Page"); out.println("Hello World!"); out.println(""); //"out" para enviar o contedo para o browser. }}

A primeira parte do cdigo trata da importao das classes em java.io (para PrintWriter, etc.), javax.Servlet e javax.Servlet.http. Os pacotes javax.servlet e javax.servlet.http fornecem

Programao WEB 5

JEDITM

interfaces e classes para escrever as Servlets (contm as classes HttpServlet, HttpServletRequest e HttpServletResponse).

Por extenso da HttpServlet, herda os mtodos que so automaticamente chamados pelo servidor dependendo de certas condies que sero explicadas mais frente. Por polimorfismo por overriding destes mtodos podemos fazer com que nossa Servlet execute a funcionalidade que quisermos.

Neste caso, o mtodo herdado do HttpServlet que sobrepomos o mtodo doGet. Simplificando, ele o mtodo que invocado pelo continer sempre que uma requisio GET feita de uma Servlet em particular. Relembrando do mdulo anterior, navegao de site, recuperao de documento, visualizao de pginas so exemplos de requisies GET. Logo, sempre que um usurio quiser ver a resposta da nossa Servlet deve invocar uma requisio GET.

Ao visualizarmos o cdigo veremos que o mtodo doGet utiliza dois parmetros: um objeto HttpServletRequest e um objeto HttpServletResponse. No obstante, estes objetos vm de encontro com as necessidades do desenvolvedor. So criados e mantidos por um continer e so simplesmente passados no momento que este continer chama o mtodo doGet. A respeito disso, o mtodo doGet e outros mtodos, que sero discutidos depois, so similares ao mtodo public statis void main(Strings[] args) que utilizamos em classes Java baseadas em linhas de comando. No ser criado um array de String para passarmos com o mtodo; pois j foi realizado pelo ambiente de execuo.

Os objetos HttpServletRequest e HttpServletResponse atendem aos desenvolvedores atravs das seguintes funcionalidades:

O objeto HttpServletRequest fornece acesso a todas as informaes a respeito das requisies do cliente incluindo todos os parmetros que so colocados nos cabealhos de requisies HTTP, mtodos de requisies HTTP, entre outros.

O objeto HttpServletResponse contm todos mtodos necessrios utilizados pelos desenvolvedores para produzir respostas que sero enviadas de volta ao cliente. Isto inclui mtodos para definir o cabealho de resposta HTTP, declarar respostas do tipo MIME, bem como mtodos de recuperao de instncias de classes Java I/O as quais podemos utilizar diretamente para produzir a sada.

Voltando ao cdigo, vemos que, com a exceo dos comentrios, existem muitas linhas que usamos para executar a funcionalidade de exibir "Hello World!" ao usurio. Uma dessas linhas :

PrintWriter out = response.getWriter();

e mltiplas chamadas para o mtodo out.println(). Por enquanto, pensemos no objeto out como quem leva nosso texto de sada para o browser do cliente. Com isto em mente, fcil ver como mltiplas chamadas ao mtodo out.println() produz o seguinte contedo:

Figura 1: Sada do HelloServlet

Programao WEB 6

JEDITM

2.3. Testando o exemplo Servlet

At agora vimos a exibio de uma sada em uma Servlet exemplo. Para iniciarmos a abstrao da implantao e configurao de Servlets faremos fazer uso de uma ferramenta automatizada disponibilizada por uma IDE. A IDE que utilizaremos utilizar em nosso exemplo o Sun Studio Enterprise 8, que livre para os membros do Sun Developer Network. Possui suporte completo para a tecnologia Servlets e especificaes JSP, bem como outras caractersticas adicionais.

Daqui para frente assumiremos que o Enterprise 8 foi instalado com sucesso em seu computador.

Antes de tudo, para o nosso Servlet exemplo, precisaremos criar um novo projeto de aplicao WEB. Para fazer isto, na barra de menu, selecione New -> Project. Na tela que aparece em seguida, selecione a categoria Web. Na direita, escolha New Web Application.

A tela seguinte ir solicitar detalhes de nosso projeto. Para nosso primeiro teste com Servlets usaremos como nome "FirstServletProject" (Project Name), e utilizaremos os valores padres para os outros campos.

Figura 2: Criando um Novo Projeto de Aplicao Web

Aps criar um novo projeto WEB, a tela ser semelhante a figura a seguir:

Programao WEB 7

JEDITM

Figura 3: Novo Projeto de Aplicao Web

Para adicionar a nossa Servlet aplicao, pressione o boto direito do mouse na opo Source Packages, selecione New -> Servlet. Se a Servlet no aparecer no menu, ento selecione New -> File/Folder. Na tela seguinte, selecione a categoria Web e depois Servlet.

Figura 4: Adicionando Servlet para a aplicao

Programao WEB 8

JEDITM

A IDE ir mostrar uma srie de telas que questionaro sobre os detalhes da Servlet a ser criada. Na primeira tela, em Class Name digite FirstServlet. Em Package digite jedi.Servlet.

Figura 5: Modificando o nome da classe e o nome do pacote

Na tela que segue, mantenha os valores padres e ento pressione o boto Finish e isto ir resultar conforme a figura a seguir.

Figura 6: Servlet criada

Programao WEB 9

JEDITM

Podemos perceber que a IDE criou e parcialmente implementou o mtodo processRequest. Se clicarmos na caixa com um sinal de soma na parte esquerda inferior veremos que o processRequest simplesmente um mtodo que chamado pelos mtodos doGet e doPost. Isto significa que o contedo do mtodo processRequest forma a base da funcionalidade de nosso Servlet.

Primeiro, removeremos todo o contedo do mtodo processRequest. Ento, copiaremos a nossa Servlet exemplo para dentro do mtodo doGet.

Figura 7: Novo mtodo processRequest

Para executar, pressione Shift + F6. A IDE ir ento empacotar, instalar e invocar a Servlet e automaticamente chamar o navegador WEB.

Programao WEB 10

JEDITM

3. Ciclo de Vida da Classe ServletUma Servlet gerenciada atravs de um ciclo de vida bem definido descrito nas especificaes Servlet. O ciclo de vida do Servlet descreve como ele carregado, instanciado, inicializado, requisitado, destrudo e finalmente coletado (retirado de memria garbage collection). O ciclo de vida de um Servlet controlado pelo continer em que ele instalado.

O ciclo de vida da Servlet permite ao continer resolver os problemas de endereamento e performance do CGI e as preocupaes com segurana da API de programao de um servidor baixo-nvel. Um continer deve poder executar todas as Servlets em uma nica JVM (Java Virtual Machine Mquina Virtual Java). Por esta razo, as Servlets podem eficientemente compartilhar dados entre si e evitar que uma acesse os dados particulares de outra. As Servlets podem tambm permitir persistncia entre requisies como objetos instanciados, utilizando assim menos memria do que processos completamente empacotados.

Figura 8: Ciclo de vida da Servlet

A figura mostra os principais eventos na vida de uma Servlet. importante notar que para cada um destes eventos h um mtodo que ser invocado pelo continer.

3.1. Instanciao

Neste estgio, a classe Servlet carregada para a memria e uma instncia criada pelo continer.

Por padro, um continer pratica o que chamamos de lazy loading (carregamento tardio). Utilizando este mtodo, uma classe Servlet carregada para a memria, instanciada e inicializada somente depois que uma requisio for feita. Isto diminui o tempo de inicializao da aplicao, entretanto significa tambm que haver um pouco de atraso associado primeira requisio de cada Servlet. Se este comportamento for indesejvel, cada Servlet deve ser configurada para ser carregada juntamente com a aplicao. Isto ser discutido posteriormente quando abordarmos o descritor de carregamento.

Como podemos ver na figura, uma Servlet passa pela fase de instanciao somente uma vez durante seu ciclo de vida. Isto significa que o atraso associado ao seu carregamento em memria acontece somente uma vez. Isto mostra a vantagem desta sobre outras tecnologias.

O mtodo relevante que o continer ir chamar neste estgio ser o construtor. No recomendado que se coloque qualquer cdigo no construtor. A maioria das funcionalidades que os desenvolvedores querem adicionar aos construtores envolvem definio de objetos ou inicializao

Programao WEB 11

JEDITM

de variveis. Servlets possui uma fase separada para este tipo de atividade.

3.2. Inicializao

Nesta fase, Servlet primordial para o uso na aplicao. Assim como a fase de instanciao, uma Servlet passa por este estgio somente uma vez. Isto s ocorre aps a fase em que nosso objeto inicializado ao ser chamado pela Servlet.

O mtodo que chamado pelo continer neste ponto o mtodo init(). A assinatura completa do mtodo apresentada abaixo.

public void init(ServletConfig config)

Como podemos ver, este mtodo tem um parmetro: uma instncia do objeto ServletConfig. Este objeto contm informaes sobre a configurao da Servlet bem como fornece meios para que a Servlet acesse informaes da aplicao e seus recursos.

Como mencionado anteriormente, qualquer cdigo de configurao ou inicializao no deve ser colocado na rea do construtor, em vez disso, deve ser colocado dentro do mtodo init. Se um desenvolvedor implementar este mtodo, importante que realize uma chamada ao super.init(config). Isto garante que a ao de inicializao padro da Servlet seja executada e que sua configurao seja apropriadamente definida.

Aps a inicializao, a Servlet estar apta a receber as requisies dos clientes.

Este mtodo somente ser chamado novamente quando o servidor recarregar a Servlet. O servidor no pode recarregar uma Servlet at que esta seja destruda atravs do mtodo destroy.

3.3. Pronta

Esta a fase quando uma Servlet est no auge do seu ciclo de vida. Nesta, a Servlet pode ser chamada repetidamente pelo continer para prover sua funcionalidade.

O mtodo chamado pelo continer nesta fase service() e possui a seguinte assinatura: public void service(ServletRequest req, ServletResponse res)

Os objetos ServletRequest e ServletResponse passados para este mtodo provem mtodos para extrair informao das requisies dos usurios e mtodos para gerar as respostas.

Um detalhe importante a ser observado, o continer realiza repetidas chamadas ao mtodo service usando threads separadas. Geralmente, h somente uma instncia ativa da Servlet consumindo espao em memria e atendendo s diversas requisies. Esta outra vantagem que o Servlet Java possui tambm uma das principaisrazes porque uma Servlet (e o seu mtodo service) projetado para conter um thread-safe.

Para Servlets especficos HTTP (Servlets estendendo HttpServlet), os desenvolvedores no devem implementar o mtodo service diretamente. Ao invs disto, devem implementar qualquer um dos seguintes mtodos:

public void doGet(HttpServletRequest req, HttpServletResponse res)public void doPost(HttpServletRequest req, HttpServletResponse res)public void doPut(HttpServletRequest req, HttpServletResponse res)public void doTrace(HttpServletRequest req, HttpServletResponse res)

Cada um destes mtodos corresponde a um mtodo HTTP especfico (GET, POST, ...). O mtodo apropriado ento chamado quando o Servlet recebe a requisio HTTP.

J que a maioria das chamadas HTTP, que os desenvolvedores devem se preocupar, so dos mtodos GET ou POST, Servlets podem implementar doGet, doPost ou ambos.

3.4. Destruio

Em algumas ocasies, quando o continer ficar sem memria ou detectar que a quantidade de

Programao WEB 12

JEDITM

memria livre possui pode gerar algum problema, o continer tentar liberar memria destruindo uma ou mais instncias da Servlet. Qual ser removida determinado pelo continer e o desenvolvedor no tem controle direto.

Um continer poder liberar uma instncia da Servlet como parte de seu processo de desligamento.

Quando a Servlet est para ser removida de um gerenciamento do continer, ela est na fase de destruio. O mtodo chamado pelo continer, antes de realizar isto, o destroy(). Aqui, na nossa Servlet deveria ser codificado para explicitamente liberar os recursos utilizados (ex. Conexes com o Banco de Dados).

3.5. Garbage Collection

Esta fase do ciclo de vida de uma Servlet equivalente a de qualquer outro objeto Java. Relembrando que esta fase ocorre antes que um objeto seja retirado da memria. Os desenvolvedores no tm controle direto quando isso ir ocorrer.

O mtodo do objeto chamado nesta fase o finalize().

Programao WEB 13

JEDITM

4. Manipulando Requisies e RespostasO principal objetivo de uma Servlet prover contedo dinmico para o usurio. Por definio, o contedo dinmico muda em resposta a diversas condies. Exemplos dos quais so as requisies especficas de usurio, a hora, temperatura.

Para dar a Servlet acesso aos dados de uma requisio, esta provida em uma instncia do objeto ServletRequest que esconde estes detalhes. Servlets baseados em HTTP possuem uma subclasse, HTTPServletRequest, que prov mtodos adicionais para obter informao especfica do HTTP, como informao sobre cookies, detalhes de cabealhos, entre outros.

4.1. Dados e Parmetros de Formulrio

4.1.1.Mtodo request.getParameter

Um dos cenrios que freqentemente requer mais frequentemente contedo dinmico quando queremos que nossa aplicao responda aos dados do usurios apresentados em um formulrio.

Veja o exemplo seguinte:

Figura 9: Entrada do Nome do Usurio

Dado o seguinte formulrio, mostrado na figura anterior, que obtm o nome do usurio, queremos produzir uma resposta customizada para qualquer nome submetido.

Para este e outros cenrios similares, Java prov o mtodo getParameter no objeto HttpServletRequest. Este mtodo possui a seguinte assinatura:

public String getParameter(String parameterName)

Este mtodo obtm o nome do parmetro que desejamos obter e retorna o valor da String que representa este parmetro.

Abaixo segue um cdigo exemplo que obtm o nome do usurio e d sada em um simples cumprimento, seguido pelo HTML usado para mostrar o formulrio.

public class GetParameterServlet extends HttpServlet { protected void doPost(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { // retorna o valor solicitado pelo usurio String userName = request.getParameter("userName"); // retorna um objeto PrintWriter e utiliza-o para a mensagem de sada PrintWriter out = response.getWriter(); out.println(""); out.println("HELLO AND WELCOME, " + userName + "!"); out.println(""); out.close(); }}

Temos a seguir, o cdigo para HTML exemplo utilizado para mostrar o formulrio:

Programao WEB 14

JEDITM

Halloa! Enter user name:

Ao entrar com o valor "JEDI" no formulrio, obtemos o seguinte resultado:

Figure 10: Sada do GetParameterServlet

4.1.2.Mtodo request.getParameterValues

Existem momento que necessitamos recuperar dados de um formulrio com mltiplos elementos com o mesmo nome. Neste caso, usando apenas o mtodo getParameter descrito anteriormente, ser retornado apenas o valor do primeiro elemento com aquele nome. Para recuperar todos os valores, usamos o mtodo getParameterValues:

public String[] getParameterValues(String parameterName)

Este mtodo similar ao que acabamos de discutir. Tambm recebe o nome do parmetro que queremos recuperar o valor. Desta vez, ao invs de uma nica String, retorna um array de Strings.

Este um exemplo:public class GetParameterValuesServlet extends HttpServlet { protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletExceptionm IOException{ String paramValues[] = request.getParameterValues("sports"); StringBuffer myResponse = new StringBuffer(); PrintWriter out = response.getWriter(); out.println("Your choices"); out.println("Your choices were : "); for (int i = 0; i < paramValues.length; i++) { out.println(""); out.println(paramValues[i]); } out.println(""); }}

A seguir, temos o cdigo para o HTML usado para mostrar o formulrio:

Choice selection What sports activities do you perform? Biking

Programao WEB 15

JEDITM

Table Tennis Swimming Basketball Others

Figure 11: Recuperando dados de um formulrio com mltiplos elementos

Se as opes Biking", "Table Tennis", e "Swimming" fossem escolhidas, a sada seria:

Figure 12: Sada do GetParameterValuesServlet

4.1.3.request.getParameterNames

Algumas vezes necessitamos que a Servlet conhea o nome de um ou mais parmetros do formulrio sem ter que codific-los dentro do Servlet. Neste caso, podemos usar o mtodo

Programao WEB 16

JEDITM

getParameterNames.public Enumeration getParameterNames()

O objeto Enumeration que este mtodo retorna contm todos os nomes de parmetros contidos nesta requisio do usurio.

4.2. Recuperando a informao da URL de Requisio

Relembrando, uma requisio HTTP composta pela seguintes partes:http://[host]:[porta]/[caminhoDaRequisio]?[queryString]

Podemos recuperar os valores atuais de cada uma destas partes da requisio do usurio chamando alguns mtodos do objeto HttpServletRequest.

Host request.getServerName() Porta request.getServerPort() Caminho da Requisio em Java, o caminho da requisio dividida em 2

componentes lgicos : Contexto o contexto de uma aplicao WEB. Pode ser recuperado chamando

request.getContextPath() Informao do caminho o resto de uma requisio depois do nome do

contexto. Pode ser recuperado chamando request.getPathInfo() Query String request.getQueryString()

Ento, por exemplo, com uma URL de requisio:http://www.myjedi.net:8080/HelloApp/greetUser?name=Jedi

Se chamarmos os mtodos mencionados, os seguintes resultados sero exibidos:

request.getServerName() www.myjedi.netrequest.getServerPort() 8080request.getContextPath() HelloApprequest.getPathInfo() greetUserrequest.getQueryString() name=Jedi

4.3. Informao de Cabealho

Informao do cabealho pode ser recuperada pela Servlet chamando os seguintes mtodos em HttpServletRequest:

getHeader(String nome) retorna o valor do cabealho especificado como um String. Se o cabealho especificado no existir, este mtodo retorna null.

getHeaders(String nome) similar ao getHeader(). Entretanto, ele recupera todos os valores do cabealho especificado como um objeto Enumeration.

getHeaderNames() - este mtodo retorna os nomes de todos os cabealhos includos na requisio HTTP como um objeto Enumeration.

getIntHeader(String nome) retorna o valor de um cabealho especificado como um int. Se o cabealho especificado no existir na requisio, o mtodo retorna -1.

getDateHeader(String nome) retorna o valor de um cabealho especificado como um valor long que representa um objeto Date. Se o cabealho especificado no existir, este mtodo retorna -1. Se o cabealho no puder ser convertido em um objeto do tipo Date, este mtodo lana uma IllegalArgumentException.

Programao WEB 17

JEDITM

4.4. Gerao da Sada

Em todos os exemplos anteriores, conseguimos gerar sadas dinmicas para o usurio. Fizemos isto usando mtodos do objeto HttpServletResponse.

At agora, usamos o mtodo getWriter. Este mtodo retorna um objeto PrintWriter associado com nossa resposta para o usurio. Para ajudar a colocar as coisas na perspectiva correta, devemos lembrar que o objeto System.out que usamos regularmente para dar sada no contedo para o console tambm uma instncia do objeto PrintWriter. Ou seja, eles se comportam quase da mesma maneira: se voc tiver uma instncia do objeto PrintWriter, simplesmente chame os mtodos print ou println para gerar a sada.

O cdigo da nossa primeira classe Servlet ser visto a seguir com o cdigo de sada em negrito.import java.io.*;import javax.Servlet.*;import javax.Servlet.http.*;public class HelloServlet extends HttpServlet { public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { // objeto "out" utilizado para enviar o contedo para o browser PrintWriter out = response.getWriter(); out.println(" Hello Page"); out.println("Hello World!"); out.println(""); }}

Outros mtodos importantes no objeto HttpServletResponse so:

setContentType informa ao navegador do cliente o tipo MIME da sada que ele ir receber. Todo o contedo que geramos at agora foi HMTL. Poderamos facilmente enviar outros tipo de contedo como JPEG, PDF, DOC, XLS, etc. Para contedo que no texto, os mtodos print do objeto PrintWriter que estamos usando at agora so insuficientes. Para gerar sada no textual, fazemos uso de outro mtodo.

getOutputStream este mtodo recupera uma instncia do objeto OutputStream associado com nossa resposta para o usurio. Com o OutputStream, podemos usar os objetos e mtodos padro de E/S Java para produzir todos os tipos de sada.

Abaixo segue um cdigo exemplo que ir gerar um arquivo JPG contido em uma aplicao web para o usurio.

public class JPEGOutputServlet extends HttpServlet { public void doGet(HttpServletRequest request, HttpServletResponse response) { // definir um array de byte para armazenamento dos dados byte bufferArray[] = new byte[1024]; // retornar o ServletContext que ser utilizado para o retorno ServletContext ctxt = getServletContext(); // informar ao browser que est enviando uma imagem response.setContentType("image/gif"); // criar o objeto de sada em stream que ser produzida ServletOutputStream os = response.getOutputStream(); // criar o objeto de recurso para o input stream InputStream is = ctxt.getResource("/WEB-INF/images/logo.gif").openStream(); // ler o contedo do recurso de escrita e gerar a sada int read = is.read(bufferArray); while (read != -1) { os.write(bufferArray);

Programao WEB 18

JEDITM

read = is.read(bufferArray); } // fechar os objetos utilizados is.close(); os.close(); }}

Programao WEB 19

JEDITM

5. Configurao, Empacotamento e DistribuioEm todos os exemplos realizados, usamos as ferramentas da IDE Sun Enterprise Studio 8 para facilitar os detalhes da configurao, do empacotamento e da instalao da aplicao WEB. Iremos agora, aprofundar estes detalhes.

5.1. Configurao da Aplicao WEB

A especificao Servlet, define um arquivo XML chamado web.xml que atua como um arquivo de configurao para as aplicaes WEB. Este arquivo chamado de descritor de distribuio.

FirstServlet jedi.Servlet.FirstServlet FirstServlet /FirstServlet 30 index.jsp

Temos acima um exemplo do arquivo web.xml utilizado no projeto FirstServlet. Usaremos como ponto de partida na explorao deste arquivo.

NOTA: O arquivo web.xml da aplicao WEB construda pela IDE, pode ser encontrado expandindo a aba de Arquivos de Configurao na View -> Project.

Esta linha utilizada como elemento raiz do arquivo de configurao e como uma declarao das informaes necessrias (at seus atributos), para o continer poder reconhecer o arquivo como um arquivo descritor vlido.

Cada instncia deste elemento define uma Servlet para ser usada pela aplicao. Possui os seguintes nodes filhos:

- Um nome lgico fornecido pelo desenvolvedor que ser usado para todas as referncias futuras para a Servlet.

- O nome da classe Servlet completamente qualificado.

Opcional. Tendo uma entrada e valor para este elemento, informa ao continer que a Servlet deve ser construda e inicializada durante o incio do continer ou aplicao, ultrapassando o lento carregamento do cdigo. O valor para este elemento um nmero que dita o ordem de carregamento comparando ao de outras Servlets.

Programao WEB 20

JEDITM

Cada instncia deste elemento define um mapeamento para uma Servlet. Possui os seguintes nodes filhos:

- O nome lgico da Servlet para ser mapeado. Deve ser definido previamente no arquivo descritor.

- A URL utilizada para que esta Servlet seja mapeada. O valor /*, far com que todas as solicitaes da aplicao seja redirecionada para seu Servlet. No exemplo dado, a URL /FirstServlet. Isto significa que todas as solicitaes de URL para http://[host]:[port]/FirstServletProject/FirstServlet ser manipulado por FirstServlet.

Lembre-se que todas as definies de Servlet devem ser fornecidas antes de adicionar quaisquer Servlet-mappings.

Este elemento define os detalhes do gerenciamento da configurao da seo.

Este elemento define um componente WEB que ser automaticamente carregado se o usurio entrar com uma solicitao para o servidor sem especificar um recurso em particular. Por exemplo, uma solicitao para http://[host]:[port]/FirstServletProject originar o arquivo aqui definido para ser carregado.

Mais de um arquivo pode ser especificado nesta lista. Somente o primeiro arquivo visvel para o continer WEB ser carregado.

5.2. Empacotando a Aplicao da WEB

Observaremos novamente a estrutura de uma aplicao WEB como indicada pela especificao Servlet:

Figura 13: Estrutura do Diretrio de uma aplicao Java WEB

A aplicao pode ser instalada em um servidor fazendo uso de um arquivo de WAR (WEB ARchive). Arquivos WAR so o mesmo que JAR (Java ARchive); contm o cdigo de aplicao comprimido utilizando o formato ZIP.

5.2.1.Gerando arquivos WAR a partir de projetos existentes no Sun Studio Enterprise

muito simples produzir o arquivo WAR contendo nossa aplicao web a partir de um projeto existente no Sun Studio Enterprise 8. Basta pressionar o boto direito do mouse no nome do projeto em Project view, e selecionar Build Project. A IDE ento proceder o empacotamento da aplicao.

Programao WEB 21

Contm HTML, imagens, outros contedos estticos, e JSP

Contm informaes sobre a aplicao (opcional)

Contm pastas que no sero vistas no navegador

Contm classes Servlets criadas para a aplicao

Contm arquivos de bibliotecas (JAR) que podem ser utilizadas pela aplicao

Arquivo XML que armazena as configuraes da aplicao

JEDITM

Figura 14: Empacotando o projeto

A IDE informar se a operao de construo foi bem sucedida, e o local onde o arquivo WAR foi criado.

Figura 15: Construo com sucesso

Programao WEB 22

JEDITM

5.2.2.Usando um arquivo de construo Ant para empacotar a aplicao

Alm de usar uma IDE para empacotar a aplicao da WEB, podemos tambm fazer uso de uma ferramenta de construo para automatizar a compilao e o processo de empacotamento.

Uma ferramenta de construo que possui uma ampla utilizao chamada Apache Ant. um projeto de cdigo aberto da Apache Software Foundation, e seu download pode ser realizado no endereo http://ant.apache.org.

Basicamente, Ant l em um arquivo de construo (chamado build.xml). Este arquivo de construo composto de targets (alvos), as quais essencialmente definem atividades lgicas que podem ser executadas pelo arquivo de construo. Estes targets so por sua vez, compostos de uma ou mais tarefas que definem os detalhes de como os targets realizam suas atividades.

Requisitos do arquivo de construo:

Deve ser locado na Raiz do Projeto de acordo com a estrutura do diretrio recomendado pela Apache Software Foundation para desenvolvimento de aplicao WEB.

Adicionalmente, deve existir tambm um diretrio lib na Raiz do Projeto que conter todas dependncias JAR da aplicao.

Deve existir um arquivo chamado build.properties no mesmo diretrio que o roteiro de construo e deve conter valores para as seguintes propriedades:

app.name nome da aplicao / projeto

appserver.home o diretrio de instalao da instncia Sun Application Server 8.1

Segue a estrutura de diretrio recomendado para desenvolvimento de aplicao web:

Figura 16: Estrutura de diretrio recomendada para o desenvolvimento de aplicao WEB

Esta estrutura de diretrio foi projetada para ser distinta da estrutura de diretrio exigido pela especificao Servlet. A Apache recomenda por possuir as seguintes vantagens:

O contedo de diretrio de fonte so mais facilmente administrados, deslocado, ou aprovado se a verso de desenvolvimento no misturada.

O controle de cdigo de fonte mais fcil de administrar em diretrios que contenham s arquivos de fonte (nenhuma classe compilada, etc.).

Os arquivos que compem a distribuio da aplicao mais fcil selecionar quando a hierarquia de desenvolvimento for separada.

Pode ser difcil compreender primeira vista. Para ajudar a compreenso, todo os requisitos para compilar e empacotar nosso exemplo FirstServlet fornecido na pasta samples/FirstServlet.

Para realizar o empacotamento de uma aplicao usando esta estrutura, execute a seguinte instruo (no mesmo diretrio contendo o arquivo de construo).

ant dist

Esta instruo chamar o target dist no arquivo de construo, o qual gerar o arquivo WAR e o colocar no diretrio dist. Este arquivo WAR pode, ento, ser carregado no continer usando as ferramentas administrativas oferecidas pelo continer.

Programao WEB 23

Contm a aplicao em uma estrutura de diretrio conhecida pelo continer.

Localizao do arquivo WAR

Documentao que usada pelo time de desenvolvedores

Arquivos fonte Java

Contedo da aplicao (HTML, JSP), base da raiz do documento do projeto

Contm arquivos de configurao como o descritor de desenvolvimento (web.xml), descritores de biblioteca de tags, etc.

JEDITM

5.3. Desenvolvimento em Servidor

Os continers Servlet geralmente contm ferramentas administrativas que podem ser usadas para desenvolver aplicaes WEB. Neste momento, veremos os passos exigidos para desenvolver o arquivo WAR gerado no aplicativo Sun Application Server 8.1.

Primeiro passo, execute o log-in no console administrativo. Isto pode ser acessado atravs da seguinte URL em seu navegador: http://localhost:[ADMIN_PORT] onde ADMIN_PORT a porta configurada durante a instalao para manipular os assuntos administrativos.

Figure 17: Instalando um arquivo WAR

Segundo, selecione a aba Web Aplications, no painel esquerda Pressione o boto Deploy encontrado no painel direita Na tela seguinte, pressione o boto Browse para selecionar o arquivo WAR para instalar Pressione o boto Next encontrado na parte superior direita Pressione o boto de Finish na prxima tela Parabns, sua aplicao foi instalada

Programao WEB 24

JEDITM

6. Servlet e Parmetros de Aplicao

6.1. ServletConfig e Parmetros de Inicializao da Servlet

O objeto da classe ServletConfig passado para uma Servlet especfica durante sua fase de inicializao. Usando isto, uma Servlet pode recuperar informaes especficas para si mesmo (parmetros de inicializao). A Servlet tambm pode ganhar acesso a uma instncia do objeto de ServletContext usando o objeto da classe ServletConfig.

Os parmetros de inicializao so de grande uso, especialmente quando lidamos com informaes que podem variar com cada desenvolvimento da aplicao. Alm disso, fornecendo dados para a Servlet como parmetros, evitamos a codificao desses parmetros diretamente na Servlet, permite aos desenvolvedores a habilidade de mudar o comportamento da Servlet sem ter que recompilar o cdigo.

Podemos adicionar parmetros de inicializao para a Servlet especificando-os na definio do deployment descriptor do Servlet. A seguir, temos uma amostra:

...

FirstServlet jedi.Servlet.FirstServlet debugEnabled true

...

As tags e informam ao continer que estamos comeando e terminando a definio de parmetro, respectivamente. define o nome do parmetro, e define seu valor.

Para ter acesso aos parmetros da Servlet, devemos primeiro obter o acesso ao seu objeto ServletConfig, que pode ser feito recuperado solicitando ao mtodo getServletConfig(). Aps isso, o valor de parmetro poder ser recuperado atravs de uma String chamando o mtodo getInitParameter() e fornecendo o valor de como o parmetro.

public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { ServletConfig config = getServletConfig(); String isDebugEnabled = config.getInitParameter("debugEnabled"); if (isDebugEnabled.equals("true") { ...}

A amostra de cdigo acima ilustra o procedimento.

6.2. ServletContext e Parmetros de Aplicao

O objeto de ServletContext informa a Servlet o acesso ao contexto de aplicao.

Pense sobre o contexto de aplicao como a rea na qual as aplicaes se movem. Esta rea fornecida pelo continer para cada aplicao WEB. Com cada contexto da aplicao sendo diferente uma do outra, uma aplicao no pode acessar o contexto de outra aplicao.

Ter acesso a este contexto importante, porque atravs deste, a Servlet pode recuperar parmetros da aplicao. possvel tambm armazenar dados que podem ser recuperados por quaisquer componentes na aplicao.

Do mesmo modo que parmetros de inicializao podem ser fornecidos para Servlets individuais, eles tambm podem ser fornecidos para uso pela aplicao inteira.

Programao WEB 25

JEDITM

databaseURL jdbc:postgresql://localhost:5432/jedidb

O cdigo acima exemplifica como adicionar diferentes parmetros de aplicao. O elemento XML usado aqui . Cada instncia de tal elemento define um parmetro para uso pela aplicao inteira. e trabalham da mesma maneira que a tag .

NOTA: Novamente, lembre-se que a especificao restrita quanto a ordenao de seus elementos dentro do descritor de desenvolvimento. Para manter o arquivo web.xml vlido, todas as entradas devem ser localizadas ANTES de quaisquer entradas .

O procedimento para recuperar os valores dos parmetros bem parecido com o utilizado para recuperar os parmetros de Servlets especficas. uma instncia de ServletContext que a Servlet deve manipular. Isto pode ser recuperado chamando o mtodo getServletContext() de uma instncia do objeto ServletConfig da Servlet.

public void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { ServletContext ctxt = getServletConfig().getServletContext(); String jdbcURL = ctxt.getInitParameter("databaseURL"); // cdigo customizado setURL(jdbcURL); ...}

6.3. Resumo

A tecnologia Servlets so a soluo Java para a produo de contedo dinmico para a WEB em resposta a tecnologia CGI.

Servlets possui vrias vantagens sobre CGI, incluindo uma reduzida na rea de ocupao de memria e menos despesa para cada solicitao.

Uma Servlet est completamente administrada pelo seu continer. O nico cdigo necessrio para os desenvolvedores a funcionalidade da implementao.

Para criar Servlets, os desenvolvedores devem criar subdivises de classe de HttpServlet e seus lugares de implementaes funcionais em quaisquer dos mtodos, doGet ou doPost.

Detalhes de pedido podem ser recuperados por HttpServletRequest, e mtodos geradores de resposta podem ser acessados por HttpServletResponse. Estes so passados como parmetros para doGet e doPost.

Para instalar Servlets no continer WEB, necessrio criar arquivos WAR. Este processo de empacotamento pode ser automatizado por qualquer IDE ou pelo uso de uma ferramenta de construo.

Descritores do desenvolvimento so partes essenciais da aplicao. Eles devem ser localizados no diretrio de aplicao WEB-INF e seguir determinadas regras.

Parmetros podem ser fornecidos pela aplicao usando o descritor de desenvolvimento e recuperado usando os mtodos em instncias ServletConfig ou ServletContext.

Programao WEB 26

JEDITM

7. Exerccios

7.1. Perguntas sobre o Ciclo de Vida da Servlet

Responda s seguintes perguntas sobre as fases da Servlet:

1. Quais so as 5 fases do ciclo de vida de uma Servlet?

2. Quais so os mtodos associados a cada fase do ciclo de vida de uma Servlet?

3. Por que o cdigo colocado no mtodo service de uma Servlet precisa ser thread-safe?

4. Quando uma Servlet destruda?

5. Quantas vezes o cdigo colocado dentro do mtodo init() do Servlet pode ser chamado? E o cdigo dentro do mtodo service()?

6. Caso a Servlet estenda a classe HttpServlet, quais mtodos adicionais poderemos implementar para produzir a funcionalidade necessria?

7.2. Exerccios de Manipulao de Requisio/Gerao de Resposta

1. Dado o seguinte formulrio:

Enter number 1 : Enter number 2 :

Crie uma Servlet chamado AddServlet que ir recuperar 2 nmeros dados pelo usurio, adicione-os, e gere o resultado.

2. Dado o seguinte formulrio:

Menu Which food items do you want to order? Sundae P 20 Reg. Burger P 25 Dessert Pie P 15 Rice Meal P 70

Programao WEB 27

JEDITM

Crie uma Servlet chamado MenuSelectionServlet que ir recuperar as selees feitas pelo usurio, adicionar os seus valores, e retornar o resultado computado para o usurio.

7.3. Perguntas sobre implementao

1. Identifique o elemento no arquivo web.xml que ser responsvel por:

a) Conter o nome lgico usado para se referir a uma Servlet.b) Ser o elemento root do arquivo de configurao.c) Definir um mapeamento entre uma Servlet e uma solicitao do usurrio.

2. Reorganize as seguintes informaes no ordem correta de seu aparecimento dentro de um arquivo XML:

session-configservletservlet-mappingwelcome-file-list

3. Suponha termos uma Servlet cujo nome TrialServlet, crie um mapeamento de modo que TrialServlet ser chamada para cada pedido:

http://[host]/[context]/myExerciseServlet.

4. O que so arquivos WAR?

5. Dado um projeto WEB existente em nossa IDE, como um arquivo WAR pode ser gerado?

Programao WEB 28

Mdulo 6Programao WEB

Lio 3Classes Servlets Avanadas

Verso 1.0 - Nov/2007

JEDITM

1. ObjetivosNa lio anterior, reparamos como as classes Servlets podem ser utilizadas pelos desenvolvedores Java para receber requisies de clientes e produzir respostas dinamicamente. Tambm vimos como distribuir Servlets empacotando-as em arquivos WAR e carregando-as no continer WEB.

Ao final desta lio, o estudante ser capaz de:

Redirecionar respostas

Identificar o escopo dos objetos

Utilizar sesses e rastreamento de sesso

Utilizar Filtros

Programao WEB 4

JEDITM

2. Redirecionamento de RespostaExistem casos onde queremos que a servlet tenha somente a responsabilidade de fazer algum processamento inicial e deixe a gerao do contedo a alguma outra entidade.

Suponhamos que seja obtido do usurio algum valor e o apresentemos com diversas vises baseadas no valor. Digamos tambm que tenhamos um site que, aps processar a entrada do usurio, apresente diferentes pginas dependendo do perfil do usurio no sistema. Colocar toda a gerao de contedo para todas as pginas em uma nica servlet pode torn-la no gerencivel. Nestes casos, seria melhor a servlet redirecionar a gerao da sada.

Existem dois modos que podemos utilizar para realizar esse redirecionamento.

Atravs do objeto RequestDispatcher

Atravs do mtodo sendRedirect() encontrado no objeto HttpServletResponse

2.1. RequestDispatcher

possvel obter uma instncia do objeto RequestDispatcher invocando o seguinte mtodo:public RequestDispatcher getRequestDispatcher(String path)

Este mtodo pode ser encontrado no objeto HttpServletRequest.

O parmetro String que este mtodo recebe a localizao da pgina HTML, JSP ou a servlet para a qual se queria disparar a requisio. Uma vez com a instncia do objeto RequestDispatcher, existe a opo de se invocar um dos seguintes mtodos:

public void include(ServletRequest req, ServletResponse res)public void forward(ServletRequest req, ServletResponse res)

Ambos mtodos pegam o contedo produzido no local especificado e torna-o parte da resposta da servlet para o usurio. A principal diferena entre eles que, o mtodo forward faz com que a pgina alvo tenha toda a responsabilidade de gerar a resposta, enquanto que o include s incorpora o contedo da pgina alvo. Utilizando o mtodo include, pode-se adicionar outro contedo a reposta ou mesmo incluir outra pgina alvo.

Para ilustrar a diferena entre os dois, so apresentadas duas Servlets abaixo. O cdigo virtualmente idntico. A primeira faz o uso do mtodo include enquanto a segunda faz uso do mtodo forward.

public DispatchServlet extends HttpServlet { protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { response.setContentType("text/html"); PrintWriter out = response.getWriter(); out.println("Error occurred during login request processing"); RequestDispatcher rd = request.getRequestDispatcher("/login.html"); rd.include(request, response); } } public DispatchServlet extends HttpServlet { protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { response.setContentType("text/html"); PrintWriter out = response.getWriter(); out.println("Error occurred during login request processing"); RequestDispatcher rd = request.getRequestDispatcher("/login.html"); rd.forward(request, response); } }

Ambas servlets definidas acima usam uma pgina denominada login.html para formar a base da

Programao WEB 5

JEDITM

sada dos dados. A definio desta pgina segue abaixo:Login Page User name : Password :

Ao executar a primeira Servlet, a que utiliza o mtodo include, a seguinte sada gerada:

Figura 1: Sada de DispatchServlet utilizando o mtodo include

Executando a segunda Servlet temos o seguinte resultado:

Figura 2: Sada de DispatchServlet utilizado mtodo forward

Dos cdigos praticamente idnticos, temos duas sadas diferentes. Ao utilizar o mtodo include, a mensagem que enviada para o usurio antes de se chamar o mtodo. Este no o caso para a sada do mtodo forward onde a mensagem apresentada antes da chamada do mtodo no se tornar parte da sada.

Com o mtodo forward, todo o contedo do buffer da resposta limpo antes da chamada do mtodo, e depois a resposta imediatamente enviada. Nenhum contedo pode ser adicionado. Com o mtodo include, todo o contedo colocado no buffer de resposta mantido antes e depois da chamada do mtodo.

Programao WEB 6

JEDITM

Utilizando-se o mtodo include, possvel que a servlet apresente a sada de diferentes fontes de uma s vez. tambm permitido concatenar mensagens a outro contedo esttico. Tome-se o seguinte exemplo:

public LoginServlet extends HttpServlet { protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { RequestDispatcher rd = null; // recupera os parmetros do formulrio do usurio String loginName = request.getParameter("loginName"); String password = request.getParameter("password"); User user = null; // cria o JavaBean implementando a funcionalidade de autenticao UserService service = new UserService(); user = service.authenticateUser(loginName, password); if (user == null) { // gera a mensagem de erro response.setContentType("text/html"); PrintWriter out = response.getWriter(); out.println("User does not exist with given login and/or password"); // retorna para a pgina de login do usurio rd = request.getRequestDispatcher("/login.html"); rd.include(request, response); out.close(); } else { // armazena o objeto User na sesso HttpSession session = request.getSession(); session.setAttribute(ApplicationConstants.USER_OBJECT, user); // constri a resposta a partir de mltiplos componentes HTML rd = request.getRequestDispatcher("/header.html"); rd.include(request, response); rd = request.getRequestDispatcher("/mainContent.html"); rd.include(request, response); rd = request.getRequestDispatcher("/footer.html"); rd.include(request, response); } }

Como o mtodo include somente adiciona contedo de outra fonte e no envia a resposta aps sua chamada, podemos utiliz-lo repetidamente. Utilizando este princpio, a classe LoginServlet apresentada acima capaz de criar uma resposta contendo trs pginas diferentes.

2.2. sendRedirect

A outra forma de redirecionar a sada de uma entidade fora de uma servlet o mtodo sendRedirect. Este mtodo tem a seguinte assinatura e pode ser encontrado no objeto HttpServletResponse:

public void sendRedirect(String relativePath)

O parmetro que o mtodo recebe um String que representa o caminho para a pgina alvo a ser redirecionada para o usurio. A chamada a este mtodo instrui o browser para enviar outra requisio HTTP para a pgina alvo especificada.

Isto torna a pgina alvo a nica entidade responsvel por gerar o contedo que, de certa forma, de resultado similar ao se utilizar o mtodo forward do objeto RequestDispatcher discutido anteriormente. Contudo, a requisio reenviada apresenta diversas diferenas prticas comparadas ao mtodo forward:

Programao WEB 7

JEDITM

A URL no browser reflete o alvo especificado. Isto torna do mtodo sendRedirect no desejvel caso no se queira que o usurio esteja ciente do redirecionamento.

Como efetivamente uma nova requisio, os dados armazenados no objeto da requisio so descartados. Os parmetros fornecidos pelo usurio, se existirem, devem ser resubmetidos caso a pgina alvo necessite destes. Os dados que estiverem armazenados no objeto request devem ser mantidos de alguma forma. Caso contrrio, sero perdidos.

recomendado ento que o mtodo include seja utilizado para permitir sada a partir de diversas fontes. O mtodo forward deveria ser utilizado no redirecionamento para componentes cujo contedo seja gerado de forma dinmica (ex: Servlets e JSPs), enquanto que o mtodo sendRedirect deveria ser utilizado no redirecionamento para componentes que gerem contedo esttico.

Programao WEB 8

JEDITM

3. Objetos de EscopoA especificao servlet nos apresenta quatro escopos onde os dados podem ser armazenados, de forma que possam ser compartilhados entre os componentes. Eles esto listados abaixo em ordem crescente de visibilidade:

Pgina O escopo de pgina definido para ser o escopo de uma pgina JSP simples. As variveis declaradas dentro da pgina so visveis somente nela e deixaram de ser visveis uma vez que o servio da pgina for finalizado. O objeto associado a esse escopo o objeto PageContext.

Requisio O escopo de requisio definido pela requisio simples proveniente do cliente. Os dados que so armazenados neste escopo so visveis a todos componentes WEB que manipulam a requisio do cliente. Aps a requisio do cliente ter sido finalizada, ou seja, o cliente recebeu uma resposta HTTP e finalizou a conexo com o servidor, todos os dados armazenados dentro deste escopo no so mais visveis.

O objeto associado a este escopo o objeto HttpServletRequest. As instncias deste objeto esto prontamente disponveis s Servlets como parmetros que podem ser obtidos nos mtodos de servio invocados pelo continer atravs da requisio do cliente.

Sesso Este o escopo que abrange uma sesso com o cliente. Esta sesso se inicia quando o cliente acessa a aplicao pela primeira vez e finaliza quando o usurio realiza o logout do sistema ou a partir de um timeout definido no servidor. Os dados deste escopo esto visveis a todos componentes WEB que o cliente utilizar durante este intervalo. Os dados de uma sesso de usurio, contudo, no esto visveis para outros usurios.

O objeto associado com este escopo o objeto HttpSession. Uma instncia deste objeto pode ser obtida utilizando o mtodo getSession() do objeto HttpServletRequest.

Aplicao Este escopo abrange toda a aplicao. Os dados armazenados neste escopo so visveis a todos os componentes, independente de requisio de usurio ou sesso que os estejam manipulando, e dura at a aplicao ser finalizada.

O objeto associado com esse escopo o objeto ServletContext. Como citado anteriormente, ele pode ser obtido atravs da chamada do mtodo getServletContext() do um objeto ServletConfig vlido.

3.1. Armazenando e Recuperando Dados do Escopo

Todos os objetos do escopo mencionados acima contm mtodos comuns para recuperar e armazenar dados neles. Para armazenar os dados, utilize o mtodo:

public void setAttribute(String chave, Object valor);

O parmetro String que o mtodo recebe armazenar o Objeto associado a a este valor. Para recuperar os dados posteriormente, passar a mesma chave como parmetro para o mtodo:

public Object getAttribute(String chave);

Se no houver objeto a ser recuperado para uma dada chave, o valor null retornado pelo mtodo. Alm disso, como o tipo de retorno Object, fica a cargo do desenvolvedor fazer o casting para a classe apropriado e realizar checagem de tipo.

Para remover um atributo do escopo, simplesmente invoque o mtodo removeAttribute() e passe a chave do atributo como parmetro.

3.2. Cenrio de Exemplo

Vamos analisar o seguinte cenrio: a aplicao dever exibir os detalhes de uma pessoa a partir de seu personalID. Este personalID ser fornecido pelo usurio. Para promover a manutenibilidade, o componente que recuperar os detalhes pessoais ser separado do componente que exibir as informaes para o usurio. Estes dois componentes faro a

Programao WEB 9

JEDITM

comunicao utilizando o armazenamento de dados e as estruturas disponveis no escopo de requisio.

public PersonalDataRetrievalServlet extends HttpServlet { protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { // recupera o parmetro personalID informado pelo usurio String personalID = request.getParameter("personalID"); // cria o objeto de negcios que manipula uma implementao para obteno de // dados para um dado id. DataService service = new DataService(); // recupera o objeto person que contm os detalhes necessrios Person person = service.retrievePersonalDetails(personalID); // armazena os dados no escopo requisio utilizando uma chave request.setAttribute(ApplicationConstants.PERSON, person); // forward da requisio para o componente que exibir os detalhes RequestDispatcher dispatcher = request.getRequestDispatcher("/DisplayServlet"); dispatcher.forward(request, response); } } public DisplayServlet extends HttpServlet { protected void doGet(HttpServletRequest request, HttpServletResponse response) throws ServletException, IOException { // recupera o objeto Person que contm os detalhes Person person = (Person) request.getAttribute(ApplicationConstants.PERSON); // constri a resposta baseado nas informaes StringBuffer buffer = new StringBuffer(); buffer.append("Personal Info"); buffer.append("Details : "); buffer.append("Name : "); buffer.append(person.getName()); buffer.append(" Address : "); buffer.append(person.getAddress()); buffer.append(""); // exibe a resposta response.setContentType("text/html"); PrintWriter out = response.getWriter(); out.println(buffer.toString()); out.close(); } }

O cdigo para o objeto DataService e o objeto Person no so listados aqui com suas implementaes porqu no so relevantes para nosso exemplo. O que o exemplo acima mostra como armazenar os dados de um objeto em uma servlet e como recuperar os mesmos dados a partir de outra servlet que possui acesso ao mesmo escopo.

Seguem algumas notas sobre o exemplo. Primeiro, a segunda servlet foi capaz de recuperar os dados da requisio porqu ela parte da mesma requisio. Se fosse usado o mtodo sendRedirect() como meio de redirecionamento de controle da servlet, o mtodo getAttribute() retornaria null j que o mtodo sendRedirect() teria feito com que o browser enviasse outra requisio. Isto efetivamente acabaria com o tempo de vida da requisio, e com os objetos armazenados dentro dela.

Segundo, recomendado que as chaves utilizadas para armazenar e recuperar os dados estejam

Programao WEB 10

JEDITM

disponveis para a aplicao como constantes, conforme o exemplo acima. Isto assegura que a mesma chave seja utilizada para armazenamento e recuperao, reduzindo a possibilidade de erros que possam ser encontrados durante o desenvolvimento.

Programao WEB 11

JEDITM

4. Rastreabilidade e Gerncia de SessoRecordemos que o protocolo HTTP foi projetado para ser um protocolo conectado, sem estado. Quando um browser enviar uma requisio para o servidor, ele abre uma conexo, envia uma requisio HTTP, consome a resposta HTTP, e ento fecha a conexo. Como cada requisio de um browser efetivamente enviada por diferentes conexes a cada vez, e o servidor no sabe dos clientes que o esto acessando, o problema da manuteno do estado para uma transao de um usurio em particular um problema a ser enfrentado.

Uma soluo para este problema o servidor manter o conceito de uma sesso de usurio. Com uma sesso, o servidor capaz de reconhecer um cliente no meio de mltiplas requisies. Com este caracterstica, o servidor consegue agora ser capaz de manter o estado para um cliente.

Para tal sesso existir, o browser cliente deve ser capaz de enviar dados para o servidor alm da requisio HTTP padro. Estes dados permitem ao servidor identificar qual usurio est realizando a requisio, e manter seu estado conciso. Existem 3 solues tpicas para esse problema: cookies, URL-rewriting (reescrita de URL) e campos ocultos no formulrio.

4.1. Mtodos Tradicionais para manter o Estado da Sesso

4.1.1.Cookies

Cookies so pequenas estruturas de dados utilizados pelo servidor WEB que entregam dados para o browser cliente. Estes dados so armazenados pelo browser e, e em algumas circunstncias, o browser retorna os dados de volta ao servidor WEB.

Ao utilizar cookies, os Servlets podem armazenar identificadores das sesses que podem ser utilizados para identificar o usurio como um participante de uma sesso em particular. Aps o identificador ser gerado, ele armazenado num objeto Cookie, e enviado de volta ao browser cliente para ser armazenado. Este objeto Cookie pode ento ser obtido toda vez a partir do objeto da requisio para determinar se o usurio est em determinada sesso.

Abaixo segue um trecho de cdigo sobre como utilizar Cookies para rastreamento de sesses nas Servlets:

... // gerar um novo session ID para o usurio String sessionID = generateSessionID(); // criar novo mapa que ser utilizado para armazenar os dados a serem mantidos na sessoHashMap map = new HashMap(); // recuperar um mapa utilizado como continer para as informaes do usurioHashMap containerMap = retrieveSessionMaps(); // adicionar o novo mapa criado no mapa contendo todas as informaes de sesso containerMap.put(sessionID, map); // criar o cookie que ser armazenado no browser Cookie sessionCookie = new Cookie("JSESSIONID", sessionID); // adicionar o cookie resposta e pedir ao browser para armazen-lo response.addCookie(sessionCookie); ...

Para obter o MAP contendo os dados da sesso, as Servlets obtm o Cookie contendo o ID da sesso, e ento obtm o HashMap apropriado utilizando o identificador da sesso como uma chave.

Embora os Cookies sejam uma boa soluo para o rastreamento, seu uso requer que os desenvolvedores manipulem diversos detalhes, como:

gerar um id nico para a sesso de cada usurio,

Programao WEB 12

JEDITM

recuperar o Cookie apropriado do Browser que contm o Session ID e

definir um tempo apropriado para a expirao do Cookie.

Alm dos detalhes acima, um problema com a utilizao de Cookies que alguns usurios desabilitam o suporte a Cookies no Browser por questes de segurana. So necessrias abordagens alternativas.

4.1.2.URL Rewriting (Reescrita de URL)

Nesta abordagem, o Browser cliente concatena um Session ID nico ao fim de cada requisio que ele faz ao servidor. Este Session ID pode ento ser lido, e a informao apropriada ao usurio recuperada.

Esta outra boa soluo que funciona mesmo se o usurio desabilitar o uso de Cookies. Contudo, existem dois problemas associados com essa abordagem. Primeiro, o servidor deve assegurar que cada Session ID que ele fornece seja nico. Segundo, a aplicao completa deve ser escrita de forma que o Session ID concatenado a todos os Links/URLs apontem para a aplicao. Qualquer requisio que no inclua o Session ID no seria considerada parte da sesso e no teria acesso s informaes especficas da sesso.

4.1.3.Campos ocultos no fomulrio

Nesta a