Marcelo Morandini (relator)
Maria Angelica Calixto de A. Cardieri
Maria das Graças Junqueira M Tomazela
Maria Flavia Cunha de Figueiredo Torres
4. Métodos HTTP suportados pelo servidor
5. Uma funcionalidade deste ambiente na qual a preservação de estado é necessária
6. Avaliação da utilização de P-HTTP
Na internet, as comunicações são baseadas em um protocolo TCP/IP [TAN91]. Isso não torna impossível que este protocolo seja implementado sobre outros protocolos na internet ou em qualquer outras redes. Nesses casos, o mapeamento de uma requisição HTTP e as estruturas de resposta sobre as unidades de transporte de dados do protocolo em questão, ficam fora do escopo dessa especificação.
O protocolo HTTP foi originalmente desenvolvido para reduzir as ineficiências do protocolo FTP. A sua finalidade é apresentar uma interação rápida de requisição/resposta sem requisição de estados ao servidor.
O protocolo HTTP é basicamente stateless [IYE97] e uma transação é composta por:
Conexão (connection): O estabelecimento de uma conexão pelo cliente para o servidor - quando utilizando TCP/IP, a porta 80 é a empregada (e conhecida). Porém, outras portas não reservadas podem ser especificadas em um URL (Universal Resource Locator);
Requisição (request): O envio, pelo cliente, de uma requisição de mensagem para o servidor;
Resposta (response): O envio, pelo servidor, da resposta para o cliente;
Fechar (close): O fechamento da conexão por ambas as partes.
Por se tratar de um assunto emergente e que vem sendo cada vez mais empregado, tanto acadêmica quanto comercialmente, o protocolo HTTP se destaca por sua facilidade de uso e por sua abrangência, sendo encontrados diversos estudos propondo melhorias neste protocolo. Dentre esses estudos, destaca-se uma variação no protocolo HTTP que é conhecido como Persistent-HTTP.
A finalidade principal do protocol P-HTTP é atingir o tempo ótimo (isto é, o melhor possível) de transação para seqüências de transações no mesmo servidor. A transação inicial ocorre como no HTTP, mas a conexão não é fechada. Requisições subseqüentes podem ocorrer sem necessidade de se reabrir a conexão.
Dentro do contexto de protocolos para comunicação, está sendo descrito um cenário de um curso virtual, no qual deve-se realizar as provas também de forma remota, enfocando-se um servidor http para apoiar um ambiente educacional. Verifica-se para este ambiente, quais métodos HTTP devem ser implementados, além de se destacar as facilidades e dificuldades que seriam encontradas para se empregar o protocolo P-HTTP.
Este cenário encontra-se descrito
na Seção 2 deste documento, e direcionou a elaboração
das demais Seções.
2. Conceitos Empregados ao Longo do Texto
2.1. Preservação de Estado com HTTP [IYE97]
As comunicações HTTP entre um cliente e um servidor são stateless (sem preservação de estado). Isso significa que toda requisição do cliente para o servidor é tratada independentemente. A informação de conexões prévias não é mantida para uso em conexões futuras.
Existem situações entretanto, que é essencial manter-se informações sobre o estado (state informations) de interações prévias entre o cliente e o servidor. Todos os métodos correntes de se fazer isso representam informações sobre o estado ao assinalar-se valores à variáveis conhecidas como variáveis de estado. Essas variáveis são então passadas para todo programa do servidor que requisitá-las.
Comunicações statefull são aquelas onde a conexão não é fechada e as requisições subseqüentes podem ocorrer sem necessidade de se reabrir a conexão. Isso otimiza bastante o tempo de acesso às páginas necessárias, além de diminuir a carga de trabalho no servidor, que pode ser melhor utilizado.
2.2. HTML forms
Um método comum de se lidar com estados na Web envolve o uso de HTML (HyperText Markup Language) forms [IYE97]. Os servidores respondem aos requisitos do cliente com HTML forms dinamicamente gerados que contenham o estado da informação embutido em variáveis escondidas. Esses HTML forms são tipicamente criados por uma interface comum para programas CGI. As variáveis escondidas são passadas de volta ao servidor após o cliente enviar um form.
Para ilustrar o emprego dos forms, suponha-se que um servidor de comunicações comercial esteja comunicando-se com um cliente. O cliente se identifica com o servidor de modo que o acesso à conta específica seja estabelecida. Uma vez que esta identificação inicial seja feita, o servidor deve manter algumas informações de estado de modo que o cliente não precise se identificar para cada transação. Com HTML forms, o servidor responde à cada requisição do cliente com um form dinamicamente gerado, que contenha a identificação do cliente como um argumento "escondido". Quando o cliente submete cada form, o servidor identifica o cliente a partir do argumento de sua identificação "escondida". Essa informação é passada de volta para estabelecimento da conexão entre o cliente e o servidor [IYE97].
2.3. Argumento Dinâmico Embutido (Dynamic Argument Embedding)
Um Argumento Dinâmico Embutido é uma técnica geral para manter o estado que associa estado com conversação. Uma conversação é uma seqüência de comunicações entre um cliente e um ou mais servidores nos quais o cliente seleciona uma próxima página seguindo um link hipertexto provido por um servidor.
Argumentos Dinâmicos Embutidos modificam links hipertexto para codificar informações ao reescrever um link que invoque um programa especial conhecido como argument embedder, que passa os estados das variáveis para todos os programas CGI.
2.4. Métodos HTTP
O campo de métodos em HTTP
indica o método a ser executado no objeto identificado pela URL.
Os nomes dos métodos são sensíveis ao contexto (diferenciados
por letras maiúsculas e minúsculas). Maiores detalhes encontram-se
na Seção 4.
Tema: Protocolos na Web
Você deverá implementar um servidor http para apoiar um ambiente educacional.
Quais métodos HTTP o seu servidor deveria suportar? Justifique a utilização de cada um deles através de exemplos.
Apresente uma funcionalidade deste ambiente na qual a preservação de estado é necessária neste servidor. Descreva como seria a implementação desta funcionalidade usando dynamic argument embedding.
Considerando a situação apresentada no item acima: P-HTTP (Presistent HTTP) seria uma alternativa de implementação? Justifique sua resposta.
Descrição do cenário: Uma disciplina é ministrada em vários cursos, sendo especialista para um deles.
Terminologia: Universidade é composta por unidades (Faculdades e nstitutos) que são responsáveis por cursos oferecidos (Eng. Computação, Eng. Química). Cada curso possui uma grade curricular com várias disciplinas. Existe intersecção das disciplinas em diferentes cursos, (por exemplo: Cálculo para Engenharia Civil e Eng. de Materiais).
Segurança: Devem ser consideradas em todas as etapas as funcionalidades descritas.
Funcionalidades:
1. Compor as disciplinas (material, exercícios, provas, aulas, grupos de forma distribuída, etc..)
2. Estabelecer perfis para cada curso (definir diferentes visões).
3. Cadastrar atores com diferentes perfis e níveis de acesso (instrutor, monitor, alunos, grupos de forma distribuída).
4. Disponibilizar as discplinas/aulas (relacionamento curso/aulas/disciplinas/tempo máximo).
5. Acompanhar o andamento da disciplina. Fornecer feed-back para alunos e professores.
6. Aplicar prova (testes, dissertativas, etc...)
7. Corrigir e pontuar a prova (pelo próprio sistema, teste; instrutor "ad-hoc"; autocorreção, disponibilizar gabaritos para auto avaliação).
8. Disponibilizar resultados.
4. Métodos HTTP suportados pelo servidor
Dentro do contexto da Primeira Questão
(link) proposta, os seguintes métodos devem ser suportados pelo
servidor que apoiará o ambiente educacional:
As Funcionalidades (link) são as seguintes:
número 6 - Aplicar prova (testes, dissertativas, etc...)
número 7 - Corrigir e pontuar a prova (pelo próprio sistema, teste; instrutor "ad-hoc"; autocorreção, disponibilizar gabaritos para auto avaliação).
Destaca-se, a seguir, a funcionalidade número 6.
Assumimos que qualquer pessoa possa acessar a página do curso, mas o formulário da prova, no caso, só seria apresentado enviando-se Identificação e Senha que serão responsáveis pela determinação do usuário (aluno ou instrutor). Também assumimos que a prova deverá ser respondida questão por questão em ordem crescente de numeração das questões e que o link com as variáveis de estado embutidas é interessante pois preserva-se a variável de estado, não sendo mais necessária a identificação com o servidor.
A partir do fornecimento da Senha, a comunicação passará a ser statefull. O aplicativo que gerencia o preenchimento das questões será o responsável por finalizar a prova sempre que o tempo pré-determinado se esgotar.
O emprego de uma comunicação statefull está na necessidade de diminuir-se o overhead causado pelo tempo de requisição-reconhecimento (request-acknowledge). Com isso, elimina-se a fase de se ficar pedindo informações ao cliente e é agregado ao link a Identificação do aluno que está respondendo às questões da prova (via variáveis de estado).
O algoritmo a seguir apresenta a forma
como seria respondida a prova virtual por um aluno.
| 1 . Acesso à página do Curso
|
stateless |
| 2. Acesso a opção de Provas
|
stateles
|
| 3. Acesso à prova específica
|
stateless
|
| 4. Escolha da opção de prova
(testes, dissertações, etc.)
|
stateless
|
| 5. Fornecimento de Identificação
e Senha
|
stateless
|
| 6. Identificação do usuário
e variáveis de estado são preservados pelo resto da comunicação
|
statefull
|
| 7. Uma questão da prova é
apresentada
|
statefull
|
| 8. A questão é respondida
|
statefull
|
| 9. O form da questão é retornado
ao servidor
|
statefull
|
| 10. No servidor são armazenados
os dados da resposta
|
statefull
|
| 11. Opta-se por continuar ou abandonar
a prova
|
statefull
|
| <se a escolha foi continuar a prova,
retorna ao passo 7>
|
statefull
|
| 12. Finaliza-se a tarefa
|
stateless
|
6. P-HTTP (Presistent HTTP) seria uma boa alternativa de implementação?
O Protocolo P-HTTP tenta evitar um recomeço lento (slow-start restart) para cada nova transação, utilizando uma única conexão para uma seqüência de transações. Infelizmente, gaps suficientemente grandes na chegada das requisições podem causar de qualquer forma este recomeço lento. Ou então, a forma como o Banco de Dados foi definido (distribuido ou centralizado) também pode fazer com que sempre se tenha que encerrar a transmissão para iniciar-se uma outra, em outra localização.
Basicamente, no que tange ao fato do Banco de Dados ser distribuído ou não, existem vantagens e desvantagens da utilização de P-HTTP,
Vantagens
Quando não for um Banco de Dados distribuído, a conexão fica basicamente mantida (isto é, não fechada). Com isso não haveria necessidade de variáveis de estado, e o carregamento das páginas seria mais rápido.
Logo, para este caso, recomenda-se o uso de P-HTTP, principalmente, se as diversas transações entre um único cliente e o servidor forem realizadas concomitantemente.
Desvantagens
Em caso de Banco de Dados distribuído seriam então necessárias diversas conexões para carregar páginas, o que tornaria de qualquer forma necessário o fechamento de uma conexão e a abertura de uma outra.
Neste caso, o uso do protocolo HTTP tradicional
é o recomendado.
Devido ao fato das comunicações entre computadores serem atualmente baseadas em um protocolo TCP/IP, temos que uma excelente abordagem e que vem sendo amplamente utilizada é a implementação do protocolo HTTP.
O mapeamento de uma requisição HTTP e as estruturas de resposta sobre as unidades de transporte de dados são feitos fora do escopo dessa especificação. Este protocolo foi desenvolvido para reduzir as ineficiências do protocolo FTP. Com isso, sua finalidade básica é apresentar uma interação rápida de requisição/resposta sem requisição de estados ao servidor.
Observamos que este protocolo é suficientemente bom e capaz de produzir excelentes resultados quando "navegamos" pela internet diariamente.
Este documento apresentou como um cenário de montagem de um servidor que apóie um ambiente educacional à distância. Uma das funcionalidades deste ambiente é a realização de provas virtuais. Foram apresentados os métodos HTTP e suas utilizações para este ambiente.
Ainda, foi apresentada a forma como são empregadas comunicações statefull e stateless quando um aluno estiver respondendo às questões de uma determinada prova.
Foi analisado também
um protocolo específico, o P-HTTP,
que pode ser uma boa abordagem para solucionar o problema de múltiplas
conexões, visto que o protocolo HTTP após finalizada uma
transação fecha a conexão. Entretanto, este protocolo
não é significativo para casos em que se tenham dados armazenados
de forma distribuída.
[GOS95] Gosling, J., McGilton, H.; "The JAVA Language Environment - A White Paper", Sun Microsystems Computer Company, Out 1995.
[NIE96] Niemeyer, P.; Peck, J.: Exploring JAVA; O’Reilly & Associates Inc., 1996.
[TAN91] Tanenbaum, A. S.; Computer Networks,
Englewood Cliffs, Prentice-Hall, 1991.
Nota: C+
Texto: OK
Metodos http x funcionalidade da aplic.:
.atencao client GET do servidor
isto esta' incorreto na explicacao de GET;
.metodos link e unlink incorretos
Implementacao funcionalidade: ? -> nao apresenta uso do DAE
P-http: ? -> nao relacionou com a funcionalidade descrita.
Last modified: Wed Apr 29 17:48:13 BRA 1998