Introdução
Aspectos referentes a implementação do Servidor HTTP
Implementação da preservação de estado no servidor proposto
Análise do P-HTTP com uma alternativa na implementação do servidor proposto
Conclusões

Apêndice
Referências

Atualmente a WWW tem se tornado rapidamente um serviço popular e esta popularidade se dá pela facilidade e robustez com que o HTTP fornece serviços de hipermídia colaborativa [1,6] na Internet.

  O HTTP (Hipertext Transport Protocol) é um protocolo de nível de aplicação capaz de suportar sistemas de informação hipermídia colaborativa e distribuída [6], onde suas principais características são: propiciar um mecanismo de busca de informação simplificado; enviar as mensagens em um formato similar aos utilizados pelo correio eletrônico na Internet, o MIME ( Multipropose Internet Mail Extensions ); permitir ,através de agentes, acesso hipermídia a diversos protocolos da Internet, como o SMTP, NNTP, FTP, Gopher, WAIS, etc.; obedecer o paradigma de pedido/resposta ( o cliente estabelece uma conexão com o servidor; em seguida envia uma solicitação de serviço; o servidor a analisa e a responde, finalizando em seguida a conexão ).

Porém, apesar de popular no mundo do WWW, o HTTP apresenta vários problemas em suas implementações. A preservação do estado e os fatores relacionados ao desempenho na transferência de informações tem sido alvo de pesquisas. Soluções como "Dynamic Argument Embedding" [2] e o persistent HTTP (P-HTTP) [3, 4, 5] tentam resolver tais problemas sem alterar as características do HTTP acima citadas.

O Dynamic Argument Embedding [2], implementa uma solução para manter informações, que são necessárias em uma aplicação, em variáveis de estado no cliente (browser), fazendo com que quando o cliente solicite uma transação, o servidor possa conhecer o valor destas variáveis e consiga otimizar o seu trabalho (por exemplo, possa fazer um acesso personalizado a alguma informação).

  Já o P-HTTP [ 3, 4, 5] tenta resolver um problema que está na maneira com que o HTTP interage com a camada de transporte na rede, mais especificamente o TCP [7]. A cada transferência de informações (páginas HTML, figuras, etc.), o HTTP estabelece uma conexão com o TCP e quando esta transferência termina a conexão é desestabelecida.

Desta maneira existe um sobrecarga causada pelo estabelecimento da conexão a cada transferência de informações realizada pelo HTTP [3]. A proposta do P-HTTP é que após uma transferência a conexão seja mantida, diminuindo assim a sobrecarga causada pelo estabelecimento de conexão. Os impactos desta solução no mundo da Web está fora do escopo deste documento, para mais informações veja [3, 4, 5].

  Este trabalho propõe-se a descrever alguns aspectos da implementação de um servidor HTTP que deverá dar suporte a um ambiente educacional, conforme o cenário proposto e que serão descritos no apêndice. Serão descritos os métodos que deverão ser implementados no servidor e que deverão atender às funcionalidades previstas para o sistema, bem como será discutida a necessidade de preservação de estado na atividade de disponibilização das disciplinas/aulas ( atividade 4 proposta no cenário) e como deverá ser a implementação utilizando Dynamic Argument Embedding. Por fim, será discutido a viabilidade de utilização do P-HTTP neste servidor.

No cenário proposto, existem oito funcionalidades (vide apêndice) que devem ser observadas e que o servidor deverá dar suporte. Baseado nisto, identificou-se a necessidade de se ter um conjunto de métodos que serão suficientes para dar suporte a qualquer aplicação educacional desenvolvida dentro do escopo previsto no cenário.

  No caso da primeira funcionalidade que é compor as disciplinas, podemos enumerar os seguintes métodos: a.) GET: este método será utilizado nas consultas realizadas por parte dos instrutores e pessoas que estarão colaborando na composição da disciplina, ao material de apoio; b.) PUT: utilizado na elaboração dos documentos, dando assim possibilidade dos instrutores ou revisores do material, conseguirem corrigir ou alterar o conteúdo de um documento; c.) DELETE: será utilizado caso alguma informação necessite ser removida do servidor; um exemplo da utilização deste método seria a eliminação de versões antigas de documentos, que não necessitem ser mantidas no(s) servidor(es); d.) LINK: será utilizado pelo servidor para relacionar documentos; um exemplo seria a colocação de referências no documento, identificando para as pessoas que tenham acesso àquela página, onde podem encontrar mais detalhes a respeito do assunto que está sendo tratado; e.) UNLINK: será utilizado para desfazer os relacionamentos entre documentos; na avaliação do material, os instrutores podem reestruturar os documentos e a relação destes com outros objetos; f.) POST: pode ser utilizado para criação de novos objetos, como por exemplo: criação de novos documentos a partir de um documento já existente, o qual poderá ser utilizado pelos instrutores posteriormente; ou criação de uma mensagem no news ou mail, facilitando a troca de informações entre os autores do material; g.) CHECKIN/CHECKOUT: poderão ser utilizados para bloquear/desbloquear o acesso a determinados documentos que estão em processo de construção ou alteração.

  A segunda funcionalidade, estabelecer perfis para cada curso, poderá ter suporte dos seguintes métodos: a.) LINK/UNLINK: quando o usuário entra na página e identifica-se, os dados deverão ser enviados para um CGI, o qual analisará o perfil deste, retornando as páginas ( "links" ) que poderão ser utilizados por ele (acesso personalizado). No caso do UNLINK, relacionamentos entre páginas que já estão estabelecidos poderão ser desfeitos para personalizar o acesso ao usuário (aluno).

  A terceira funcionalidade, que é cadastrar atores com diferentes níveis de acesso, poderá ser implementada usando os seguintes métodos: a.) GET: possibilitar aos interessados ter acesso ao formulário de cadastramento e b.) PUT: será utilizado para solicitar ao servidor a execução de um CGI, que irá receber os dados digitados no formulário como parâmetros e atualizará base de dados de usuários do sistema criando assim uma identificação para aquele usuário.

A quarta funcionalidade, disponibilizar as disciplinas/aulas, deverá suportar os seguintes métodos: a.) PUT/GET: permitir aos usuários terem acesso ao material do curso bem como elaboração de algumas atividades (exercícios, notas sobre determinado assunto, ou realizar perguntas sobre alguma questão); b.) POST: para disponibilizar aos alunos a possibilidade deles poderem enviar e trocar mensagens via news, mail, etc., fazendo com que estes troquem experiências ou possam questionar os instrutores a respeito de um determinado assunto; .c.) TEXTSEARCH: disponibilizar aos alunos um mecanismo de pesquisas de "strings" nas páginas.

A quinta funcionalidade, que é acompanhar o andamento da disciplina e fornecer "feed-back" para os alunos e professores, poderá ser suportada pelos métodos: a.) POST: divulgação do resultados e troca de comentários e questões através do news ou mail; criação de novas páginas onde serão colocadas as notas de aula comentários sobre atividades realizadas; b.) GET: consulta ao material divulgado; c.) PUT: necessário para a atualização das páginas com comentários sobre as atividades e notas dos exercícios.

  A próxima funcionalidade, aplicar prova, será auxiliada pelos seguintes métodos: a.) PUT: durante a execução da prova, o aluno deverá elaborar as respostas e posteriormente atualizá-las no servidor, isto poderá ocorrer pela ativação de um CGI ou atualização de uma simples página HTML no servidor; e b.) GET: este método será necessário para o aluno obter o formulário da prova com as questões;

  A penúltima funcionalidade descrita no cenário, corrigir e pontuar a prova, terá suporte dos métodos, a.) GET: este método será necessário para disponibilizar as avaliações para correção por parte dos instrutores; b.) PUT: será necessário para executar um CGI que realizará a correção ( correção pelo sistema ); ou disponibilizar a colocação de anotações e das notas nas provas ( campos do formulário de prova destinados anotação de observações da nota da prova ).

E na última funcionalidade, disponibilizar resultados, temos: a.) PUT: permitir aos professores a divulgação dos resultados; e b.) GET: permitir aos alunos consultar os resultados (notas).

Dentre todas funcionalidades apontadas no cenário (apêndice), ficou evidenciado que todos os ítens que envolvem interação do aluno, seja na execução de uma aula ou prova, podem se beneficiar da preservação de estado. Isto é evidente porque a interação do aluno com a disciplina deve ser especializada: conforme a disciplina e o curso que este se inscreveu, ele terá acesso a um material diferente. Logo, o servidor deve guardar as informações sobre quais páginas ou "links" estarão disponíveis a cada aluno em cada ponto do material, devendo se feito isto durante todo o tempo que o aluno navegar pelo material.

  Baseado nisto, foi escolhida para analise a funcionalidade 4 (Disponibilizar as disciplinas/aulas), por se entender que a interação do aluno com o material deverá ser personalizado, isto é, o aluno de uma disciplina deverá ter acesso ao material específico para aquela disciplina. Sendo assim, informação com RA, Nome, Disciplina e Curso podem ser mantidas em variáveis de estado, que ajudarão ao servidor identificar qual parte do material estará disponível para um determinado aluno, de forma que este não precise se identificar a cada nova parte de material que venha a ser consultada.

Dada a necessidade de preservação de estado na implementação da funcionalidade 4, a sua implementação utilizando Dynamic Argument Embedding [2] pode ser descrita como uma seqüência de passos, como segue: no primeiro instante, o aluno irá se identificar digitando o seu RA; estas informações são passadas para o servidor que ativa um CGI para validar o aluno e recuperar seu perfil. Após o CGI ter recuperado as informações do aluno, estas informações são passadas a um outro CGI que é responsável por identificar quais "links" e páginas o aluno pode ter acesso. Identificando as informação que o aluno pode ter acesso, o CGI devolve as informações e os "links" personalizados, mais as variáveis de estado que identificam o aluno para o cliente (browser). Quando o aluno desejar fazer outro acesso ao servidor, as informações das variáveis de estado ( RA, Nome, Disciplina, etc.) mais o recurso que ele deseja ter acesso serão passados para o servidor, este por sua vez não precisa mais identificar perfil do aluno uma vez que estas informações estão nas variáveis de estado enviada junto com a requisição, logo o CGI responsável pela identificação do aluno simplesmente analisa as informações das variáveis de estado e chamada o CGI responsável por personalizar o acesso do aluno, devolvendo assim as informações requisitadas cpnforme o perfil do aluno.

  Note que na segunda interação do aluno nenhuma busca necessitou ser realizada, uma vez que as variáveis de estado já continham informações que identificavam o perfil do aluno.

HTTP [1, 6] é implementado sobre o TCP [7], que é um dos protocolos da família TCP/IP [7]. O fato do protocolo HTTP não guardar os estados associados a transferência de dados com um mesmo servidor, associado com a maneira com que o TCP [7] manipula a sobrecarga na rede ( mecanismo "slow-start" ) contribuem para prejudicar a performance das aplicações sobre o HTTP.

  A utilização do HTTP Persistente (P-HTTP) [3, 4, 5] ajuda a melhorar o panorama descrito acima. Isto porque o P-HTTP, ao contrário do HTTP, não encerra as conexões após a transmissão podendo assim outras transferências serem realizadas pela mesma conexão. Logo, transferências seguidas de arquivos, imagem, som, etc., podem se beneficiar desta característica do P-HTTP.

  Outra vantagem da utilização de P-HTTP é que por se manter a conexão aberta com o servidor, este pode se utilizar deste fato para controlar o estado das transferências de dados com o cliente, tornado desnecessários mecanismos como o "Dynamic Argument Embedding", analisado na seção anterior.

  Um fator que deve influenciar de modo negativo o desempenho do P-HTTP é o aspecto da localidade temporal [5], isto é, quando os acessos realizados não são ao mesmo servidor, a vantagem de ser ter uma conexão permanente traz poucos benefícios para a aplicação, um vez que a cada novo servidor que se tenha acesso uma nova conexão deverá ser estabelecida, e o problema do tempo de estabelecimento de conexão continua. Outro ponto é que o aumento de conexões abertas pode influenciar também no desempenho da rede.

  Também deve ser observado que existe um problema na interação entre o TCP e o HTTP que prejudica o desempenho das aplicações, e que o P-HTTP não consegue melhorar satisfatoriamente [3].

Este trabalho enfocou alguns aspectos da implementação de um servidor HTTP que deverá dar suporte a um ambiente educacional. (conforme o proposto no cenário especificado no apêndice). O foco principal foi a especificação dos métodos que deveriam ser implementados no servidor para dar suporte ao ambiente proposto, e como a preservação de estado utilizando Dynamic Argument Embedding ajudaria a implementação da atividade 4, Disponibilizar as disciplinas/aulas (apêndice). Por fim foi feita uma análise do P-HTTP como uma solução para melhorar o desempenho do servidor proposto.

 Cenário: Uma disciplina é ministrada em vários cursos, sendo especialista para cada um deles.

 Terminologia: Universidade é composta por unidades (Faculdades e Institutos) 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 interseção das disciplinas em diferentes cursos, (por exemplo cálculo para Eng. Civil e Eng. Materiais).

 Segurança: Deve ser considerada 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. Cadastra atores com diferentes perfis e níveis de acesso (instrutor, monitor. alunos, grupos de forma distribuída).

4. Disponibilizar as disciplinas/aulas (relacionamento curso/aulas/disciplinas/tempo máximo)

5. Acompanhar o andamento da disciplina. Fornecer "feed-back" para alunos e professores.

6. Aplicar provas (testes, dissertativas, etc.)

7. Corrigir e pontuar a prova (pelo próprio sistema, testes; instrutor "ad-hoc"; auto-correção, disponibilizar gabaritos para auto avaliação)

8. Disponibilizar resultados.

[1] Berners-Lee, Tim; Basic HTTP as defined in 1992; Internet Draft, 1992

[2] Iyengar, Arun; Dynamic Argument Embedding; IEEE Internet Computing, 1(2):50-56, March/April 1997

[3] Touch, Joe et. al.; Analisys of HTTP Performance; USC/Information Sciences Institute, August 16, 1996

[4] Heidemann, John; Performance Interactions Between P-HTTP and TCP Implementations; USC/Information Sciences Intitute

[5] Touch, Joe et. al; IEEE/ACM Transactions on Networking 5(5):616-630

[6] Berners-Lee, Tim ;RFC 1945 (Hipertext Transfer Protocol); 1996

[7] Comer, Douglas; Internetworking With TCP/IP - Volume I; principles, protocolos, and architeture; Prentice-Hall; 1991

Comentários dos instrutores:

Nota: B

Texto: OK
Metodos http x funcionalidade da aplic.: OK
Implementacao funcionalidade: superficial
P-http: rever paragr. 3
Conclusoes: OK

Bom trabalho !

Last modified: Wed Apr 29 17:44:49 BRA 1998