UNIVERSIDADE ESTADUAL DE MARINGÁ
Centro de Tecnologia
Departamento de Informática
Redes de Computadores
A CAMADA DE APLICAÇÃO
Prof.: Mauro Henrique Mulati
A CAMADA DE APLICAÇÃO
Roteiro

A World Wide Web
2
A CAMADA DE APLICAÇÃO
A World Wide Web

Estrutura arquitetônica que permite o acesso a documentos
vinculados espalhados por milhões de máquinas na Internet

Variedade de assuntos

Início em 1989 no CERN, Centro Europeu de Pesquisa
Nuclear

Meio de distribuição de dados sobre física de alta energia

Grupos compostos por membros de vários países

Web nasceu da necessidade de fazer com que esses grupos de
cientistas de diferentes nacionalidades pudessem colaborar uns
com os outros através da troca de relatórios, plantas,
desenhos, fotos e outros documentos

Teia de documentos: Tim Berners-Lee, março/1989

1991: Demonstração pública, navegador modo texto, Texas,
Hypertext'91
3
A CAMADA DE APLICAÇÃO
A World Wide Web
 Atraiu atenção de outros pesquisadores, Marc Andreessen,
University of Illinois


1994: Andreessen fundou a Netscape Communications Corp.


Primeiro navegador gráfico, Mosaic, fevereiro/1993
Clientes, servidores e outros software para Web
96, 97, 98: Guerra do browsers (guerra dos navegadores)

Netscape Navigator

Microsoft Internet Explorer

98: AOL comprou a Netscape

94: CERN e MIT -> acordo criando Wold Wide Web
Consortium (W3C) (www.w3.org)

Padronização

Centenas de universidades e empresas se juntaram ao
consórcio
4
A CAMADA DE APLICAÇÃO
Visão geral da arquitetura

Usuários tem visão de: vasta coleção mundial de documentos, as páginas
Web

Cada página pode conter links (vínculos) para outras páginas em qualquer
lugar do mundo

Idéia de fazer uma página apontar para outra


Agora chamada de hipertexto

Inventada em 1945, Vannevar Bush
Páginas são visualizadas pelo navegador (browser)

Mozilla Firefox, Internet Explorer, Opera, Netscape Navigator, ...

Busca a página solicitada, interpreta seu texto e seus comandos de formatação
e exibe a página, formada de modo apropriado na tela
5
A CAMADA DE APLICAÇÃO
Visão geral da arquitetura

Hiperlinks: strings de texto p/
outros links

Destacados

Links já visitados são
marcados
(a) Uma página Web
(b) A página à qual se chega com
um clique em Department of
Animal Psychology
6
A CAMADA DE APLICAÇÃO
Visão geral da arquitetura
As partes do modelo da Web
7
A CAMADA DE APLICAÇÃO
Visão geral da arquitetura :: O lado cliente

O navegador segue o hiperlink e busca a página

Hiperlink incorporado precisa de um meio p/ nomear qualquer
outra página na Web


URL (Uniform Resource Locator)

http://www.abcd.com/products.html

Protocolo: http

Nome DNS da máquina em que a página está localizada:
www.abcd.com

Nome do arquivo que contém a página: products.html
Usuário clica em um hiperlink: navegador executa uma série
de etapas em ordem para buscar a página
8
A CAMADA DE APLICAÇÃO
Visão geral da arquitetura :: O lado cliente

http://www.itu.org/home/index.html

1. O navegador determina a URL (verificando o que foi selecionado)

2. O navegador pergunta ao DNS qual é o endereço IP de www.itu.org

3. O DNS responde com 156.106.192.32

4. O navegador estabelece uma conexão TCP com a porta 80 em
156.106.192.32

5. Em seguida, o navegador envia um comando solicitando o arquivo
/home/index.html

6. O servidor www.itu.org envia o arquivo /home/index.html

7. A conexão TCP é encerrada

8. O navegador exibe todo o texto de /home/index.html

9. O navegador busca e exibe todas as imagens que o arquivo contém
9
A CAMADA DE APLICAÇÃO
Visão geral da arquitetura :: O lado cliente

Linha de status do navegador

Para exibir uma página, navegador deve conhecer seu
formato -> HTML

Navegador:

Basicamente:
interpretador de HTML

Recursos p/ facilitar
navegação
10
A CAMADA DE APLICAÇÃO
Visão geral da arquitetura :: O lado cliente

Páginas contêm

Texto comum, hipertexto

Ícones, desenhos, mapas, fotografias


Cada um pode estar vinculado a outra página
Nem todas as páginas contêm HTML

PDF, GIF, JPEG, MP3, vídeo MPEG, ou qualquer outro tipo

HTML pode se vincular (e chegar) a qualquer um deles

Em vez de interpretadores para uma coleção de arquivos

Quando um servidor retorna página, retorna informação adicionais

Tipo MIME, text/html e outros tipos internos: exibidos diretamente

Se tipo MIME não for interno, utiliza visualizados associado
 Plug-ins: módulo de código, extensão do navegados, acesso pág.
 Interface do plug-in, interface do navegador
11
A CAMADA DE APLICAÇÃO
Visão geral da arquitetura :: O lado cliente
 Aplicação auxiliar
 Programa completo executado como um processo separado
 Não pode oferecer interfaces nem usar serviços do navegador
 Aplicações auxiliares podem usar tipo MIME application
 application/pdf, application/msword
 image/x-photoshop, audio/mp3
 Programa se registra
 Navegador abre arquivos locais (extensão, MIME, inf. Arquivo)
 .exe; shell scripts -> vírus
(a) Um plug-in de navegador
(b) Uma aplicação auxiliar
12
A CAMADA DE APLICAÇÃO
Visão geral da arquitetura :: O lado servidor

Navegador segue URL ou hipertexto

Nome DNS a ser pesquisado (entre http:// e a barra seguinte)

Com o IP, navegador, conexão TCP porta 80, servidor

Envia comando restante URL (nome arquivo)

Servidor retorna arquivo

Etapas (em essência)


1. Aceitar uma conexão TCP de um cliente (um navegador)

2. Obter o nome do arquivo solicitado

3. Obter o arquivo (do disco)

4. Retornar o arquivo ao cliente

5. Encerrar a conexão TCP
Problema: solicitação -> acesso ao disco

Não mais solicitações por segundo do que o n.º de acessos a disco
13
A CAMADA DE APLICAÇÃO
Visão geral da arquitetura :: O lado servidor

Cache na memória: n mais recentemente usados

Multithread: front end e k módulos (todos do mesmo processo)

Front end pode ser eliminado: cada módulo tenta adquirir suas
próprias solicitações -> necessário protocolo bloqueio,e.conflitos

Um servidor Web multithreaded com um front end e módulos de processamento
14
A CAMADA DE APLICAÇÃO
Visão geral da arquitetura :: O lado servidor

Um ou mais módulos bloqueados (esperando disco), outros
módulos podem estar trabalhando outras solicitações

Vários discos: k módulos, k discos


Throughput máximo de k vezes maior que 1 thread e 1 disco
Único thread e k discos: possível, mas código complicado

Servidores Web fazem mais que apenas aceitar nomes de
arquivos e retorná-los

Etapas:
15
A CAMADA DE APLICAÇÃO
Visão geral da arquitetura :: O lado servidor

1. Resolver o nome da página Web solicitada


Nome de arquivo vazio

Expandir para nome padrão

Navegador -> idioma padrão

Servidor -> selecionar página no idioma, se disponível

Convenções
Verificar identidade do cliente
3. Executar o controle de acesso no cliente



2. Autenticar o cliente


http://www.cs.vu.nl
Verificar se há restrições sobre atender ou não: identidade e localização
4. Executar o controle de acesso na página Web

Verificar restrições de acesso da página

.htacess -> poderá restringir acesso ao arquivo a domínios específicos

Ex.: Usuários dentro da empresa
16
A CAMADA DE APLICAÇÃO
Visão geral da arquitetura :: O lado servidor

5. Verificar o cache

6. Buscar a página solicitada no disco


7. Determinar o tipo MIME para incluí-los na resposta


Lidar com várias leituras de disco ao mesmo tempo
Através de extensão, primeiras palavras, arquivo configuração, outras fontes
8. Cuidar de diversas tarefas

Como elaboração de um perfil de usuário ou
obtenção de estatísticas

9. Retornar a resposta ao cliente

10. Criar uma entrada no log do servidor

Mais tarde, logs podem ser pequisados
Ex.: Ordem em que pessoas acessam as páginas
17
A CAMADA DE APLICAÇÃO
Visão geral da arquitetura :: O lado servidor

Muitas solicitações por segundo -> CPU não será capaz, independente de
quantidade de discos em paralelo

Adicionar outros nós (computadores)

Possivelmente com discos replicados

Grupo de servidores (server farm)

Front end -> dispersa solicitações por várias CPUs, reduzir carga sobre comp.

Cada uma pode ter vários threads e pipelines como antes

Problema: não há cache compartilhado -> solicitação e subsequente ->nó
Um grupo de servidores (server farm)
18
A CAMADA DE APLICAÇÃO
Visão geral da arquitetura :: O lado servidor

Outro problema: Conexão TCP termina no front end, resposta tem que
passar pelo front end

(
Handoff de TCP

O ponto final é repassado ao nó

Feito de modo transparente para o cliente
(a) Seqüência normal de msgs. de solicitação/resposta
(b) Seqüência quando é usado o handoff de TCP
19
A CAMADA DE APLICAÇÃO
Visão geral da arquitetura :: URL


Mecanismo de nomenclatura e localização de páginas

1. Qual é o nome de página?

2. Onde a página está localizada?

3. Como a página pode ser acessada?
Solução escolhida identifica as páginas de uma forma que
resolve todos os três problemas

A cada página é atribuído um URL (Uniform Resource
Locator), nome universal de página

Protocolo (esquema)

Nome DNS da máquina em que a página está

Nome que indica a página especifica (normalmente um nome de
arquivo na máquina onde ele reside)
20
A CAMADA DE APLICAÇÃO
Visão geral da arquitetura :: URL

http://www.cs.vu.nl/video/index-en.html

Protocolo: http

Nome DNS do host: www.cs.vu.nl

Nome do arquivo: video/index-en.html

Relativo ao diretório Web padrão em cs.vu.nl

Atalhos para nomes de arquivos


Nulo: home page inicial

Diretório: index.html
http://www.cs.vu.nl/~ast


~user/ poderia ser mapeado no dir. WWW de user e depois no
index.html
Hipertexto: texto ativado a ser exibido e a URL da página destino
21
A CAMADA DE APLICAÇÃO
Visão geral da arquitetura :: URL

Texto é selecionado

Navegador procura o nome do host usando DNS

De posse do IP, navegador estabelece conexão TCP com host

Através dessa conexão, ele envia o nome do arquivo usado o
protocolo especificado e a página é recebida
Alguns URLs comuns
22
A CAMADA DE APLICAÇÃO
Visão geral da arquitetura :: URL

Antes da Internet: USENET -> 30000 newsgroups

Protocolo news usado para chamar um artigo de notícias como se fosse uma
página Web

NNTP (News Network Transfer Protocol)



Se baseia no SMTP
Gopher: Mais velho que a Web

Conceitualmente semelhante à Web, mas só aceita texto, não imagens

Obsoleto
URLS: Não só navegar na Web

FTP, notícias, Gopher, e-mail, telnet

Integrando todos os acessos à Internet em um só programa
23
A CAMADA DE APLICAÇÃO
Visão geral da arquitetura :: Ausência de estados e cookies


Basicamente a Web não tem estados

Não existe nenhum conceito de sessão de login

O navegador envia uma solicitação a um servidor e recebe de
volta um arquivo
Problemas:

Web sites restritos, clientes precisam se registrar

E-commerce (comércio eletrônico)


Carrinho de compra
Portais Web personalizados, Yahoo e Google

Configurar página inicial

Como saber o usuário?

Pelo IP -> não funciona:
 Usuários em computadores compartilhados, NAT
24
A CAMADA DE APLICAÇÃO
Visão geral da arquitetura :: Ausência de estados e cookies

Netscape criou uma técnica denominada cookies (RFC 2109)

Cliente solicita página Web, servidor fornece informações
adicionais

Podem incluir um cookie, um pequeno arquivo ou string (com 4
KB no máximo)

Navegadores armazenam em um diretório de cookies, a menos
que usuário tenha desativado

Cookies são arquivos ou strings, não programas executáveis

Cookie pode conter até 5 campos
Alguns exemplos de cookies
25
A CAMADA DE APLICAÇÃO
Visão geral da arquitetura :: Ausência de estados e cookies

Domain: de onde veio o cookie, navegadores devem confirmar

Cada domínio pode armazenar no máximo 20 cookies por cliente

Path: Caminho na estrutura de diretórios do servidor, partes da árvore de
arquivos do servidor que podem usar o cookie, / -> árvore toda

Content: nome=valor -> Conteúdo do cookie

Expires: Quando expira, se ausente -> descartará ao terminar, cookie nãopersistente. Se preenchido, cookie persistente

Secure: Navegador só deve retornar o cookie a um servidor seguro


E-commerce, transações bancárias, outras aplicações seguras
Como cookies são usados?

Antes de o navegador enviar uma solicitação de página a algum Web
site, ele confere se não há cookie para este domínio. Se sim, todos os
cookies gerados por esse domínio são incluídos na msg. de solicitação

Ao receber, servidor interpreta como desejar
26
A CAMADA DE APLICAÇÃO
Visão geral da arquitetura :: Ausência de estados e cookies

toms-casino.com, cookie p/ identificar cliente

Quando cliente entrar para apostar novamente, navegador
enviará cookie, para servidor saber quem ele é



joes-store.com, carrinho de compras

Clica sobre produto e servidor monta um cookie contendo o n.º
de itens, o código p/ enviar de volta ao cliente

No final, cookie é enviado, e servidor sabe o que foi adquirido
aportal.com, portal Web


Hábitos de apostas
Pode ter até 4 KB, p/ preferências do usuário
Cookies em beneficio do servidor:

Quantos visitantes distintos ele recebeu e quantas páginas cada
um percorreu
27
A CAMADA DE APLICAÇÃO
Visão geral da arquitetura :: Ausência de estados e cookies


Primeira entrada, cookie c/ Counter=1

Cliques subseqüentes farão o cookie ser enviado de volta ao serv.

O contador é incrementado e devolvido p/ o cliente
Abusos

Cookies devem voltar apenas ao site que os enviou

Hackers, bugs, capturar cookies
 Alguns sites de e-commerce colocam nros. cartão crédito no
cookie
28
A CAMADA DE APLICAÇÃO
Visão geral da arquitetura :: Ausência de estados e cookies

Navegadores podem rejeitar cookies

Problemas com Web sites legítimos

Softwares para eliminar cookies

Inspecionam cada cookie que chega, dependendo das opções
fornecidas pelos usuários. Ex.: Web sites confiáveis

Navegadores modernos têm controles internos sobre cookies

Por ex., Mozilla Firefox
29
A CAMADA DE APLICAÇÃO
Documentos Web estáticos

Base da Web é transferência de páginas do servidor para o
cliente

Forma mais simples, páginas Web são estáticas

Arquivos em servidores esperando o momento de serem
recuperados
30
A CAMADA DE APLICAÇÃO
Documentos Web estáticos :: HTML

Páginas Web são escritas em HTML (HyperText Markup
Language)

Texto, gráficos, e ponteiros para outras páginas Web

Linguagem de marcação, descreve como os documentos serão
formatados

Navegador só precisa entender os comandos de marcação

Qualquer navegador Web deve poder ler e reformatar qualquer
página Web

Pode ter sido feita: 1600x1200 com 24 bits de cores

Exibida: 640x320 com 8 bits

Tags (comandos de formatação): <html> e </html>

Strings entre tags são chamados diretivas: <b> texto </b>

Alguns tags tem parâmetros (com nomes, chamados atributos)

<img src=”abc” alt=”foobar”>
31
A CAMADA DE APLICAÇÃO
Documentos Web estáticos :: HTML

Documentos HTML escritos em ISO 8859-1 Latin-1

Teclados que aceitam apenas ASCII, seqüência de escape para
caracteres especiais, como é o caso de à

Começam com & e terminam com ;

&nbsp; produz espaço
&grave; produz à

Os sinais <, > e & só podem ser expressos por &lt; &gt; e &amp;

Cabeçalho -> título

Cabeçalhos -> hn

<b> e <i>

Listas; <ul> não ordenada; <ol> ordenada; <li> itens da lista

<br>, <p> e <hr>; delimitação entre seções

<img> em linhas
32
A CAMADA DE APLICAÇÃO
Documentos Web estáticos :: HTML
(b)
(a) O código HTML correspondente a um exemplo de página Web
(b) A página formatada
33
A CAMADA DE APLICAÇÃO
Documentos Web estáticos :: HTML
Uma seleção de tags comuns de HTML. Algumas podem ter outros parâmetros
34
A CAMADA DE APLICAÇÃO
Documentos Web estáticos :: HTML

Hiperlink: <a> (âncora) e </a>

<a href=”http://www.nasa.gov”> NASA's home page</a>

<a href=”http://www.nasa.gov”><img src=”shuttle.gif” alt=”NASA”></a>

A tag <a> pode usar um parâmetro name para incluir um hiperlink,
dessa forma pode-se fazer referência a ele dentro da página
35
Documentos Web estáticos ::
HTML


HTML 4.0

Acessibilidade

Linguagem de scripts (permitir
conteúdo dinâmico)
Folhas de estilo

Estilos lógicos

<dn> definição

<em> ênfase fraca

<strong> ênfase forte

<var> variáveis de programa

São definidos na folha de estilo,
referida no início de cada página

Mudar <strong> de itálico 14 p/
negrito 18 é fácil
(a) Uma tabela HTML (b) Uma possível interpretação dessa tabela
36
A CAMADA DE APLICAÇÃO
Documentos Web estáticos :: Formulários

HTML 1.0: comunicação em um sentido
Usuários podiam acessar páginas, difícil enviar informações
sentido inverso
 Formulários na HTML 2.0













Tag <input>
Campos em branco
Caixas de seleção
Mapas ativos
Botão submit
<form> e </form>
Tipo de caixa de entrada: text
Botões de rádio (alternativas)
Checkbox
<select> e </select>
Password
Textarea
37
A CAMADA DE APLICAÇÃO
Documentos Web estáticos ::
Formulários

Botão submit


Informações do usuário são
enviadas de volta a máquina
que forneceu o formulário
Navegador reúne
informações em uma única
linha longa e envia
(b)
38
A CAMADA DE APLICAÇÃO
Documentos Web estáticos :: Formulários

& p/ separar campos

+ p/ representar espaço
Uma resposta possível do navegador ao servidor com informações fornecidas
pelo usuário
39
A CAMADA DE APLICAÇÃO
Documentos Web estáticos :: XML e XSL
 HTML não fornece estrutura para páginas Web e mistura o
conteúdo com a formatação

Estruturar páginas

Separar o conteúdo da formatação

Ex.: programa de pesquisa em busca do melhor preço p/ um
CD precisa analisar muitas páginas Web procurando pelo
título e preço do item


Web em HTML é muito difícil um programa descobrir
W3C -> aperfeiçoamento p/ HTML

Permitir que páginas Web sejam estruturadas p/ processamento
automatizado

XML (eXtensible Markup Language) descreve o conteúdo Web de
uma forma estruturada

XSL (eXtensible Style Language) descreve a formatação de modo
independente do conteúdo
40
A CAMADA DE APLICAÇÃO
Documentos Web estáticos :: XML e XSL


Define uma estrutura chamada
book_list

Título

Autor

Ano
Autor poderia ter sido:
<author>
<firstLname> Andrew </firstLname>
<lastLname> Tanenbaum </lastLname>
</author>

Subcampos

Define uma lista contendo 3 livros

Nada diz sobre como exibir
na tela

Necessário: book_list.xsl,
que é uma folha de
estilos que informa como
exibir a página
Uma página Web simples em XML
41
A CAMADA DE APLICAÇÃO
Documentos Web estáticos :: XML e XSL
Uma folha de estilos em XSL
42
A CAMADA DE APLICAÇÃO
Documentos Web estáticos :: XML e XSL

Declarações necessárias

<html> e <body>

<th>, </th>


Especificação mais rígida que HTML
A declaração: <xsl:for-each select=”book_list/book”> é
análoga a uma instrução for em C

Faz o navegador iteragir pelo corpo do loop em <xsl:for-each>,
uma iteração para cada loop

Cada iteração fornece como saída 5 linhas:

<tr>, o título, o autor, ano e </tr>

Resultado da interpretação é igual se a folha contivesse a tabela
em linha

Nesse formato, programas podem analisar o arquivo XML e
encontrar com facilidade livros publicados depois de 2000
43
Documentos Web estáticos :: XML e XSL

Diferença ideológica

Objetivo original da HTML

Especificar estrutura do documento, e não sua aparência



Porém, muitos projetistas queriam controle absoluto da aparência


<font face=”helvetica” size=”24” color=”red”> Deborah's Photos</font>
Meios p/ controlar posicionamento na tela


<h1> Debora's Photo </h1>
Não diz o tipo da fonte, a cargo do navegador
Não é portável, resolução de tela diferente
XML p/ outros fins
Como linguagem de comunicação entre programas aplicativos
 SOAP (Simple Object Access Protocol)




Modo de executar RPC entre aplicações de modo independente da
linguagem e do sistema
Cliente elabora solicitação como msg. XML e envia ao servidor usando
HTTP, servidor devolve resposta como msg. XML formatada
Aplicações em plataformas diferentes podem se comunicar
44
A CAMADA DE APLICAÇÃO
Documentos Web estáticos :: XHTML

Novas demandas: Dispositivos sem fio, PDAs

Memória limitada em comparação com navegadores com heurísticas
para lidar com páginas Web sintaticamente incorretas

Após, HTML 4 linguagem exigente

XHTML(eXtended HyperText Markup Language) em vez de HTML 5

HTML 4 reformulada em XML


Tags como <h1> não têm significado associado, é necessário definição no
arquivo XSL
6 diferenças principais e várias secundárias em relação à HTML 4

Páginas XHTML e navegadores devem obedecer estritamente o
padrão

Todas as tags e atributos em letras minúsculas

<HTML> e <img SRC=”pic001.jpg”> não são válidas em XHTML
45
A CAMADA DE APLICAÇÃO
Documentos Web estáticos :: XHTML

Tags de fechamento são obrigatórias; <p> e </p>

As que não têm fechamento natural:
 <br>, <hr>, <img>
 / precedendo >
 <img src=”pic001.jpg” />

Atributos devem estar entre aspas:



<img src=”pic001.jpg” height=”500” />
e não <img src=”pic001.jpg” height=500 />
Tags aninhadas corretamente

<center><b> Vacation Pictures </b></center>

E não <center><b> Vacation Pictures </center></b>
Todo documento deve especificar seu tipo de documento
Mais informações: www.w3.org
46
A CAMADA DE APLICAÇÃO
Documentos Web dinâmicos

No início da Web, o conteúdo era estático (apenas arquivos)

Nos últimos anos, conteúdo se tornou cada vez mais dinâmico

Gerado por demanda em vez de ser armazenado em disco

Geração do conteúdo pode se dar no lado do servidor ou no
lado do cliente
47
A CAMADA DE APLICAÇÃO
Documentos Web dinâmicos :: Geração dinâmica de páginas
do lado servidor


Considere o uso de formulários: clica no botão submit

É enviado msg. ao servidor, indicando que contém conteúdo de um formulário,
juntamente com os campos que o usuário preencheu

Não é o nome de um arquivo a ser retornado

Preciso que msg. seja entregue a um programa ou script para processamento

Em geral, processamento envolve utilização das informações fornecidas p/
pesquisar registro no BD do servidor e gerar uma página HTML personalizada
que será enviada de volta ao cliente
Ex.: e-commerce

Usuário termina de escolher produtos

Navegador retornar cookie com carrinho de compras

Algum programa ou script no servidor tem de ser invocado p/ gerar página HTML em
resposta

Pode conter lista de itens no carrinho e último end. entrega conhecido e solicitação
p/ confirmar as informações e especificar o método de pagamento
48
A CAMADA DE APLICAÇÃO
Documentos Web dinâmicos :: Geração dinâmica de páginas
do lado servidor
 Caminho tradicional

CGI (Common Gateway Interface)

Interface padronizada p/ permitir que servidores Web se
comuniquem com programas e scripts de back end que possam
aceitar a entrada (ex., de formulários) e gerar páginas HTML em
resposta

Back ends podem ser scripts em Perl

Reside no diretório cgi-bin, visível no URL

Python pode ser usado
Etapas no processamento das informações de um formulário HTML
49
A CAMADA DE APLICAÇÃO
Documentos Web dinâmicos :: Geração dinâmica de páginas
do lado servidor
 Ex.: www.tgpc.com p/ registrar-se on-line

Link: clique aqui para registrar seu produto

Link aponta p/ um script Perl:

www.tgpc.com/cgi-bin/reg.perl

Sem parâmetros, script envia página HTML c/ form. registro

Usuário preenche e clica em submit

É enviado de volta a esse script uma msg. que contém os
valores preenchidos

Script de Perl analisa os parâmetros, cria uma entrada no BD
p/ novo cliente e envia de volta uma página HTML fornecendo
nro. de registro e telefone da assistência técnica

Não é o único modo de lidar com formulários, mas é comum
50
A CAMADA DE APLICAÇÃO
Documentos Web dinâmicos :: Geração dinâmica de páginas
do lado servidor
 Outra forma: incorporar pequenos scripts em páginas HTML,
executados pelo próprio servidor p/ gerar a página

PHP (acrônimo recursivo p/ PHP: Hypertext Preprocessor)

Servidor tem que reconhecer PHP

Esperam extensão .php

Tag <?php ... ?>

Em geral navegadores enviam algumas informações junto c/
suas solicitações (e quaisquer cookies aplicáveis), inseridas na
variável HTTP_USER_AGENT

www.abcd.com/test.php -> informa ao usuário que navegador,
linguagem e SO está usando
Um exemplo simples de página HTML
com PHP incorporado
51
A CAMADA DE APLICAÇÃO
Documentos Web dinâmicos :: Geração dinâmica de páginas
do lado servidor
 PHP -> indicado p/ manipulação de formulários e é mais
simples que script CGI

52
A CAMADA DE APLICAÇÃO
Geração dinâmica de páginas
do lado servidor

Item incomum: action.php

Deve ser invocado p/ tratar os
parâmetros, depois que o usuário
tiver preenchido e enviado o form.

Pág. exibe exibe duas caixas de texto

Form. transmitido, servidor analisa o
string enviado

Começa a processar o arquivo
action.php como uma resposta

São executados os comandos PHP

Tratamento de formulários
extremamente simples com PHP

PHP é uma poderosa linguagem de
programação orientada p/ formar a
interface entre a Web e BD servidor



Variáveis, strings, arrays e maioria
das estruturas de controle em C
Instruções de E/S mais eficientes
que printf
Código fonte aberto e disponível
gratuitamente e funciona bem com o
Apache
(a) Uma página Web contendo um
formulário
(b) Um script PHP p/ manipular a saída do
formulário
(c) Saída do script quando as entradas são
Isabela e 24
53
A CAMADA DE APLICAÇÃO
Documentos Web dinâmicos :: Geração dinâmica de páginas
do lado servidor
 Até agora: scripts da CGI e PHP incorporado

JSP (JavaServer Pages) semelhante ao PHP, exceto que
parte dinâmica é escrita em Java; .jsp

ASP (ActiveServer Pages): versão da Microsoft p/ PHP e
JavaServer Pages


Escolha é mais ligada a política pois:


Utiliza linguagem de scripts patenteada da Microsoft, o Visual
Basic Script; .asp
PHP, JSP e ASP são comparáveis em linhas gerais
A coleção de tecnologias p/ gerar conteúdo durante a
execução às vezes é chamada de HTML dinâmica
54
A CAMADA DE APLICAÇÃO
Documentos Web dinâmicos :: Geração dinâmica de páginas
do lado cliente
 Scripts CGI, PHP, JSP, ASP resolvem



O problema de manipular formulários e

interações com BD

Geram HTML como resultado
Não podem:

Responder a movimentos do mouse

Interagir diretamente com os usuários
Para isso:

Necessário scripts incorporados em páginas HTML executadas
na máquina do cliente

A partir da HTML 4, scripts são permitidos

Tag <script>

A linguagem de scripts mais popular p/ o lado cliente é o JavaScript
55
A CAMADA DE APLICAÇÃO
Documentos Web dinâmicos :: Geração dinâmica de páginas
do lado cliente
 JavaScript: linguagem de scripts

Muito livremente inspirada em algumas idéias da linguagem de
programação Java

De nível muito alto

Ex.: Em uma única linha é possível mostrar uma caixa de diálogo,
aguardar a entrada de texto e armazenar o string resultante em
uma variável

Ideal p/ projetar páginas interativas

Porém, não é padronizada e muda com rapidez -> difícil
portabilidade
56
A CAMADA DE APLICAÇÃO
Documentos Web dinâmicos :: Geração dinâmica de páginas
do lado cliente

Form. que pede nome e
idade

Declaração do botão de
envio e instrução que
ele contém

Informa que o
navegador deve
invocar o script
response quando
houver um clique
em um botão e
repassá-lo ao
formulário como um
parâmetro
57
A CAMADA DE APLICAÇÃO
Documentos Web dinâmicos :: Geração dinâmica de páginas
do lado cliente
 Declaração da função do JavaScript response no início do
arquivo HTML

Vai extrair campo name do formulário e armazenar na variável
person, sob a forma de um string

Extrai campo age, converte esse valor em um inteiro usando a
função eval, soma 1 ao valor e armazena o resultado em years

Um seguida, abre um documento p/ saída, executa quatro
operações writeln e fecha o documento

O documento é um arquivo HTML, o navegador exibe então o
documento na tela
58
A CAMADA DE APLICAÇÃO
Documentos Web dinâmicos :: Geração dinâmica de páginas
do lado cliente
 Usos de JavaScript e PHP (ou JSP e ASP) são
completamente diferentes

PHP (ou JSP e ASP): Quando é necessária interação remota

JavaScript: Interação c/ usuário no computador cliente

Páginas com PHP e JavaScript
(a) Geração de script do lado servidor com o PHP
(b) Geração de script do lado cliente com o JavaScript
59
A CAMADA DE APLICAÇÃO
Documentos Web dinâmicos :: Geração dinâmica de páginas
do lado cliente

JavaScript é uma linguagem completa como C ou Java

Grande quant. de recursos p/ páginas Web: gerenciar janelas, quadros,
definir e obter cookies lidar com formulários e manipular hiperlinks

Um programa em JavaScript p/ calcular e imprimir fatoriais
60
A CAMADA DE APLICAÇÃO
Documentos Web dinâmicos :: Geração dinâmica de páginas
do lado cliente

JavaScript também pode acompanhar a movimentação do mouse sob
objetos na tela

Muda figura ou menu aparece
Uma página Web iterativa que responde ao movimento do mouse
61
A CAMADA DE APLICAÇÃO
Documentos Web dinâmicos :: Geração dinâmica de páginas
do lado cliente
 Miniaplicativos (applets): são pequenos programas em Java
que foram compilados p/ uma máquina virtual chamada JVM
(Java Virtual Machine)



<applet> e </applet>

Interpretados por navegadores compatíveis com a JVM

Pelo fato de os miniaplicativos serem interpretados em vez de
executarem diretamente, interpretador pode evitar que eles se
comportem mal
Controles ActiveX, da Microsoft: programas compilados em
linguagem de máquina e executadas no hardware bruto

Mais rápidos e mais flexíveis que miniaplicativos Java

Menos portabilidade
Regra geral: JavaScript é mais fácil de escrever,
miniaplicativos Java são executados com rapidez e controles
ActiveX são os mais rápidos de todos
62
A CAMADA DE APLICAÇÃO
Documentos Web dinâmicos :: Geração dinâmica de páginas
do lado cliente

Todos os navegadores implementam a mesma JVM

Não há dois navegadores que implementam a mesma versão do
JavaScript

Miniaplicativos são mais portáveis
As diversas maneiras de gerar e exibir conteúdo

Geração de conteúdo dinâmico pode ser do lado do cliente


As páginas Web podem ser escritas em XML e depois convertida em HTML, de
acordo com o arquivo XSL
Plug-ins e aplicações auxiliares podem ser usadas p/ exibir conteúdo em
63
uma variedade de formatos
A CAMADA DE APLICAÇÃO
HTTP

Protocolo de transferência utilizado em toda a World Wide
Web é o HTTP: HyperText Transfer Protocol

Especifica as msgs. Que os clientes podem enviar aos
servidores e que resposta eles receberão

Cada interação consiste um uma solicitação ASCII, seguida por
uma resposta (RFC 822 semelhante ao MIME)

Todos os servidores e todos os clientes devem obedecer a esse
protocolo (RFC 2616)

Tópicos

Conexões

Métodos

Cabeçalhos de mensagens

Exemplo de utilização do HTTP
64
A CAMADA DE APLICAÇÃO
HTTP :: Conexões

Modo habitual: navegador estabele conexão TCP com porta
da 80 da máquina servidora

Procedimento não é exigido formalmente

TCP: nem navegadores nem servidores tem que se preocupar
com msgs. Perdidas, duplicadas, longas ou confirmações


Tratados pela implementação do TCP
HTTP 1.0: Depois que conexão era estabelecida

Uma única solicitação era enviada e uma única resposta era
devolvida, então a conexão TCP era encerrada


Somente texto HTML era adequado
Após alguns anos: página Web continha ícones, imagens, etc.

Estabelecer conexão p/ transportar um único ícone se tornou muito
dispendioso
65
A CAMADA DE APLICAÇÃO
HTTP :: Conexões

HTML 1.1: Conexões persistentes

Estabelecer conexão TCP, enviar solicitação, obter resposta

E depois, enviar solicitações adicionais e receber respostas
adicionais

Amortizando o custo da instalação e da liberação do TCP por
várias solicitações

O overhead relativo devido TCP é muito menor por solicitação

Também é possível transportar as solicitações por pipeline

Enviar a solicitação 2 antes de chegar a resposta à solicitação 1
66
A CAMADA DE APLICAÇÃO
HTTP :: Métodos
 HTTP projetado p/ Web, mas é mais geral que o necessário

Visando futuras aplicações orientadas a objetos

São aceitas operações chamadas métodos, diferente da simples
solicitação de uma página Web

Essa generalidade permitiu o SOAP

Cada solicitação consiste em uma ou mais linhas de texto ASCII


Primeira palavra da primeira linha o nome do método solicitado

Para acessar objetos gerais, também poderiam estar disponíveis
métodos adicionais específicos de objetos

Case sensitive
Método GET solicita ao servidor que envie a página (ou objeto,
no caso mais genérico)

Página é codificada em MIME de forma adequada

GET nomearq HTTP/1.1

Nomearq indica o recurso (arquivo)
67
A CAMADA DE APLICAÇÃO
HTTP :: Métodos


HEAD: solicita apenas o cabeçalho da msg.

Pode ser usado p/ obter data da última modificação da página

P/ indexação ou teste de validade
PUT: Inverso ao GET: em vez de ler, grava páginas

Criação de conjunto de páginas Web em servidor remoto

O corpo da solicitação contém a página

Pode ser codificada usando o MIME


Content-Type e cabeçalho de autenticação: mostrar que chamador
tem permissão
POST: Semelhante ao PUT, também transporta um URL

Em vez de substituir os dados existentes, os novos dados são
anexados

Muito usado p/ enviar dados do cliente para o servidor
68
A CAMADA DE APLICAÇÃO
HTTP :: Métodos

DELETE: Exclui a página

Permissão e autenticação

Não há garantias que foi bem-sucedido


O arquivo subjacente pode ter um modo que impeça o servidor
HTTP de modificá-lo ou excluí-lo
TRACE: Serve para depuração

Instrui um servidor a enviar de volta uma solicitação

Quando solicitações não estão sendo processadas corretamente
e o cliente deseja saber qual solicitação o servidor recebeu de
fato

CONNECT: Não é usado atualmente, uso futuro

OPTIONS: Fornece um meio p/ que o cliente consulte o
servidor sobre suas propriedades ou sobre as de um arquivo
específico
69
A CAMADA DE APLICAÇÃO
HTTP :: Métodos

Toda solicitação obtém uma resposta que consiste:

Uma linha de status

Informações adicionais (Página Web ou parte dela)
Os métodos internos de solicitações HTTP
70
A CAMADA DE APLICAÇÃO
HTTP :: Métodos

Código de status de 3 dígitos informando se a solicitação foi atendida, e se não, por que não

1.º dígito: divide respostas em 5 grandes grupos importantes

1xx raramente são usados na prática

2xx solicitação tratada com sucesso


3xx Informam ao cliente que ele deve procurar em outro lugar


URL diferente ou próprio cache
4xx solicitação falhou devido a um erro do cliente


Conteúdo, se houver, está sendo retornado
Solicitação inválida ou página inexistente
5xx servidor tem im problema

Erro em seu código ou por sobrecarga temporária
Os grupos de respostas de código de status
71
A CAMADA DE APLICAÇÃO
HTTP :: Cabeçalhos de mensagens

A linha de solicitação (ex. método GET)

Podem ser seguidas por linhas adicionais com mais informações

Cabeçalhos de solicitação -> podem ser comparadas a parâmetros
de uma chamada de procedimento

As respostas também podem ter cabeçalhos de resposta

Alguns cabeçalhos podem ser usados em um ou outro sentido

User-Agent: permite ao cliente informar o servidor sobre seu
navegador, SO, e outras propriedades

Cabeçalhos Accept: Informam ao servidor que o cliente está
disposto a aceitar, caso tenha uma repertório limitado

1.º: Que tipos MIME (ex. text/html)

2.º: Conjunto de caracteres (ISO-8859-5 ou Unicode-1-1)

3.º: Métodos de compactação (ex. gzip)

4.º: Idioma natural (servidor pode ter opções)
72
A CAMADA DE APLICAÇÃO
HTTP :: Cabeçalhos de mensagens

Host: identifica o servidor. Retirado da URL

É obrigatório, pois alguns IP podem servir vários nomes DNS,
meio servidor de identificar o host a entregar a solicitação

Authorization: necessário p/ páginas protegidas

Cookie: é usado por clientes p/ retornar ao servidor um cookie
enviado anteriormente e por alguma máquina no domínio do
servidor

Date: ambos os sentidos, hora e data q msg. foi enviada

Upgrade: facilitar a transição p/ uma versão futura

Server: permite saber quem o servidor é

Content-*: propriedade da página que está enviando

Last-Modified: quando a página foi modificada pela última vez
73
A CAMADA DE APLICAÇÃO
HTTP :: Cabeçalhos de mensagens

Location: servidor informa que cliente deve tentar outro URL

Se página tiver sido deslocada

Vários URLs se refiram a mesma página

Accept-Ranges: disponibilidade do servidor de trabalhar com
solicitação parcial de páginas

Set-Cookie: é a forma como os servidores enviam cookies aos
clientes

Espera-se que o servidor grave o cookie e o devolva em
solicitações subseqüentes ao servidor
74
A CAMADA DE APLICAÇÃO
HTTP :: Cabeçalhos de mensagens
Alguns cabeçalhos de mensagens HTTP
75
A CAMADA DE APLICAÇÃO
HTTP :: Exemplo e utilização do HTTP
 HTTP é ASCII


Pessoa em um terminal e servidores Web
Conexão TCP para a porta 80 no servidor
Telnet www.ietf.org 80 > log
GET /rfc.html HTTP/1.1
Host: www.ietf.org
close

Comandos estabelecem conexão telnet (isto é, TCP) p/ porta
80 no servidor Web da IETF

Resultado redirecionado p/ arquivo log

GET: identifica arquivo e protocolo

Host: cabeçalho obrigatório

Linha em branco: indica ao servidor que não existem mais
cabeçalhos de solicitação

Close: fecha a conexão
76
A CAMADA DE APLICAÇÃO
HTTP :: Exemplo e
utilização do HTTP

Arquivo log

3 primeiras linhas, programa
telnet

HTTP/1.1: resposta da IETF,
disposta a usá-lo

Cabeçalhos e depois
conteúdo

ETag: identificador exclusiva
de página relacionado ao
armazenamento no cache

X-Pad: um cabeçalho não
padronizado
O início da saída de www.ietf.org/rfc.html
77