Mdulo 6

Programao WEB

Lio 1
Introduo Programao WEB

Verso 1.0 - Nov/2007

JEDITM

Autor Daniel Villafuerte Equipe Rommel Feria John Paul Petines

Necessidades para os Exerccios

Sistemas Operacionais Suportados NetBeans 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 Hardware Nota: IDE NetBeans com resoluo de tela em 1024x768 pixel Sistema Operacional Microsoft Windows Linux Solaris OS (SPARC) Solaris OS (x86/x64 Platform Edition) Mac OS X Processador 500 MHz Intel Pentium III workstation ou equivalente 500 MHz Intel Pentium III workstation ou equivalente UltraSPARC II 450 MHz AMD Opteron 100 Srie 1.8 GHz PowerPC G4 Memria 512 MB 512 MB 512 MB 512 MB 512 MB HD Livre 850 MB 450 MB 450 MB 450 MB 450 MB

Configurao Recomendada de Hardware Sistema Operacional Microsoft Windows Linux Solaris OS (SPARC) Solaris OS (x86/x64 Platform Edition) Mac OS X Processador 1.4 GHz Intel Pentium III workstation ou equivalente 1.4 GHz Intel Pentium III workstation ou equivalente UltraSPARC IIIi 1 GHz AMD Opteron 100 Series 1.8 GHz PowerPC G5 Memria 1 GB 1 GB 1 GB 1 GB 1 GB HD Livre 1 GB 850 MB 850 MB 850 MB 850 MB

Requerimentos de Software NetBeans 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

JEDITM

Colaboradores que auxiliaram no processo de traduo e reviso

Acio Jnior Alexandre Mori Alexis da Rocha Silva Allan Souza Nunes Allan Wojcik da Silva Angelo de Oliveira Aurlio Soares Neto Bruno da Silva Bonfim Carlos Fernando Gonalves Denis Mitsuo Nakasaki Emanoel Tadeu da Silva Freitas Felipe Gacho Jacqueline Susann Barbosa Joo Vianney Barrozo Costa Luciana Rocha de Oliveira Luiz Fernandes de Oliveira Junior Marco Aurlio Martins Bessa Maria Carolina Ferreira da Silva Massimiliano Giroldi Mauro Cardoso Mortoni Paulo Oliveira Sampaio Reis Pedro Henrique Pereira de Andrade Ronie Dotzlaw Sergio Terzella Thiago Magela Rodrigues Dias Vanessa dos Santos Almeida Wagner 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 Especial
John Paul Petines Criador da Iniciativa JEDITM Rommel Feria Criador da Iniciativa JEDITM

Programao WEB

JEDITM

1. Objetivos
Bem-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

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

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
Resposta do servidor (contm o documento requisitado ou um cdigo de erro caso nada seja encontrado)

Servidor processa as repostas com base nas requisies do cliente

Mquina rodando um Browser

Requisio do cliente (contm o nome e o endereo de um item que o cliente est procurando) Mquina rodando um WEB Server
Figura 1: Funes do Servidor e do Cliente

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

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

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
9

Programao WEB

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 WEB

A 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.

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

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

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 ocupemse 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.

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

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

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 WEB

Para 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.
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
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

JEDITM

8. Exerccio
Responda 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

JEDITM

Parceiros que tornaram JEDITM possvel

Instituto CTS Patrocinador do DFJUG. Sun Microsystems Fornecimento de servidor de dados para o armazenamento dos vdeo-aulas. Java Research and Development Center da Universidade das Filipinas Criador da Iniciativa JEDITM. DFJUG Detentor dos direitos do JEDITM nos pases de lngua portuguesa. Banco do Brasil Disponibilizao de seus telecentros para abrigar e difundir a Iniciativa JEDITM. Politec Suporte e apoio financeiro e logstico a todo o processo. Borland Apoio internacional para que possamos alcanar os outros pases de lngua portuguesa. Instituto Gaudium/CNBB Fornecimento da sua infra-estrutura de hardware de seus servidores para que os milhares de alunos possam acessar o material do curso simultaneamente.

Programao WEB

16