Antônio Tadeu Maffeis

Maria das Graças J. M. Tomazela

1 Introdução

2Uma Aplicação Educacional disponibilizada via WWW

2.1Problemas na disponibilização da disciplina

3 Implementação

3.1 Estratégias baseadas no Servidor

3.2 Estratégias baseadas no Cliente

3.3 Comparação das soluções baseadas na manutenção do estado da aplicação

3.4 Análise do P-HTTP como uma alternativa de implementação

4 Conclusões

5 Referências

Nos últimos anos os paradigmas de acesso a informação tem mudado bastante, principalmente no que diz respeito a World Wide Web (WWW). Porém, apesar da popularidade da WWW, causada em parte pela facilidade de uso associada a disponibilidade de acesso ao mais variados serviços, tais como acesso a informações independentemente de onde estas se encontrem, trocar de informações através de e-mail, etc., a tendência de se trocar e compartilhar informações remotas não é tão recente.

O projeto ARPANET [Tanen96] é um exemplo disto, onde a preocupação com destruição dos centros de informação dos USA durante a guerra fria, fez com que o departamento de defesa desenvolvesse o projeto que visava a interligação e distribuição das informações e sistemas de defesa por vários pontos do país tornando-os assim menos vulneráveis a eventuais ataques inimigos.

Este projeto foi o precursor de tecnologias que se sedimentaram com o tempo e se tornaram a base para o funcionamento da WWW, dentre elas estão o TCP/IP, que é um protocolo de transporte que teve origem com o ARPANET [Comer91], o FTP (File Transfer Protocol) que é um protocolo de aplicação cujo sua função e fazer a transferência de arquivos de maneira confiável, o Telnet ( Terminal Remoto ), etc. Surgiram vários outros protocolos e aplicações que foram se unindo a família de protocolos TCP/IP, porém somente na década de 90 é que passou a ser utilizada em massa, não somente pelos centros de pesquisa mas também por todas as pessoas que se interessasse em utilizá-la.

Tal disponibilidade somente ocorreu após o surgimento do HTTP ( Hipertext Transport Protocol ), que é um protocolo de nível de aplicação capaz de suportar sistemas de informação hipermídia colaborativa e distribuída [Berners-Lee96], 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 ( Browsers ), acesso hipermídia a diversos protocolos da Internet, como SMTP, NNTP, FTP, Ghopher, WAIS, etc. [Berners-Lee96, Comer91] e obedecer o paradigma pedido/resposta ( o cliente estabelece uma conexão com o servidor e em seguida envia uma solicitação de serviço ao servidor. Este por sua vez analisa a requisição e a responde, finalizando em seguida a conexão.

Apesar de robusto o HTTP foi projetado para suportar transferência de textos (Hipertextos) escritos na linguagem HTML ( Hipertext Mark-up Language ), o que de certa forma não traz impactos maiores para o desempenho da rede de comunicação. Porém muitas foram as mudanças na forma de se utilizar este protocolo, e uma delas é que não somente textos são tratados pelo HTTP. Imagens, som, etc., foram incorporados as informações manipuladas por este protocolo, caracterizando não mais a manipulação de Hipertexto mas sim de Hipermídia [Berners-Lee96].

Alguns problemas surgiram quando as novas mídias passaram a ser manipuladas pelo HTTP. Um deles foi o fato de cada mídia ter uma característica de tráfego diferente [Tanen96] e o HTTP tratá-los todos da mesma forma, dada a natureza stateless (sem estado) [Comer91, Touch97, Touch96] deste protocolo. Outro problema, são os requisitos necessários de algumas aplicações em armazenar determinadas informações a respeito da conexão corrente ou conexões anteriores . Esta característica é conhecida como manutenção do estado.

Existem algumas proposta para se resolver em algum nível estes problemas. O P-HTTP ( Persistent-HTTP ), Dynamic Argument Embedding ( DAE ), Cookies [Iyengar97] e o HTML Forms tentam resolver os problemas acima citados sem alterar as características do HTTP citadas anteriormente.

O P-HTTP tenta resolver o problema na maneira com que o HTTP interage com a camada de transporte da rede, mais especificamente o TCP [Comer91]. Na realidade o P-HTTP tenta contornar a característica stateless do HTTP fazendo com que a conexão seja mantida enquanto estiver sendo utilizada.

Uma das abordagens para resolver a manutenção de estado das aplicações que usa HTTP é o HTML Forms. A característica principal do HTML-Forms é o fato das páginas geralmente serem geradas dinamicamente por um CGI ( Common Gateway Interface ) e submetidas para o cliente ( Browser ). Junto com estas páginas podem ser enviadas variáveis que ficam "escondidas" do usuário e após o form ser preenchido estas variáveis são devolvidas para o servidor, juntamente com as outras que foram digitadas durante a interação do usuário, para serem manipuladas por um outro CGI, que processará as variáveis recebidas gerando outro form em resposta. Logo, através destas variáveis que são enviadas para o servidor com o form a manutenção de estado pode ser garantida.

Uma outra maneira de preservar o estado durante a interação com o HTTP é a utilização dos cookies. Os cookies foram inventados pela Netscape Communication [Iyengar97], contém a descrição das URLs para as quais o estado é válido e é armazenado no cliente.

Por fim, o DAE é uma técnica de manutenção de estado da aplicação que associa estado com conversações. Uma conversação é uma seqüência de comunicações entre um cliente um ou mais servidores na qual o cliente seleciona a próxima página por um link provido pelo servidor [Iyengar97].

Este trabalho tem por objetivo analisar as diversas técnicas de manutenção de estado e discutir possibilidades de implementação destas técnicas em aplicações educacionais. Pretende-se evidenciar a diferença entre a manutenção de estado da conexão ( por exemplo, P-HTTP ) e do estado da aplicação realizado pelos mecanismos citados acima.

Na Seção 2 será apresentado o cenário de uma aplicação educacional. Na Seção 3 será discutido a problemática da preservação de estado na disponibilização da disciplina proposta. Na Seção 4 são apresentadas as diversas propostas de implementação para garantir a manutenção de estado e na Seção 5 são feitas as conclusões deste trabalho.

  2 Uma Aplicação Educacional disponibilizada via WWW

Um cenário proposto em [Delfino98] leva em consideração as seguintes funcionalidades para o desenvolvimento de uma aplicação na área educacional ("Curso sob Medida + Prova Virtual"):

1. Compor as disciplinas

2. Estabelecer Perfil para cada curso ( diferentes visões )

3. Cadastrar atores com diferentes perfis e níveis de acesso

4..Disponibilizar a disciplina/aula ( Relacionamento curso/aulas/disciplinas/tempo máximo )

5. Acompanhar o andamento da disciplina. Fornecer feedback para alunos e professores

6. Aplicar provas

7. Corrigir e pontuar as provas

8. Disponibilizar resultados

A aplicação Aula Virtual foi escolhida para exemplificar os novos requisitos exigidos das aplicações da WWW, em especial a manutenção do estado da aplicação. Esta aplicação é vinculada a uma universidade, no caso a Universidade a Distancia, que fornece cursos na área tecnológica. O aluno de um curso desta universidade (por exemplo: engenharia elétrica), matriculado em uma disciplina qualquer ( por exemplo: MA-101 Cálculo Diferencial e Integral I), poderá remotamente assistir a aula sobre determinado assunto ( por exemplo: limites) no momento que lhe convier; portanto a comunicação é assíncrona. A aula consistirá de documentos hipermídia que permitirão o aluno navegar de forma não-linear [Newcom91]. O corpo geral da disciplina não é específico a nenhum curso em particular, porém as explanações multimídia têm um forte componente específico de cada curso. Por exemplo, a explicação de algum conceito pode se utilizar de casos próprios da futura área de atuação do estudante. Da mesma forma, os exercícios de cada tópico podem ser ajustados para o nível do estudante.

A aplicação é baseada em dois tipos de objetos principais: aluno e disciplina. O objeto aluno possui atributos como nome, identificação, formação anterior, curso atual, disciplinas cursadas, documentos consultados etc.; o objeto disciplina possui os atributos pré-requisitos, critérios de avaliação, recursos necessários (plataforma de hardware e software), ementa, corpo básico ( comum a todos os cursos).

Para suportar a implementação da "Aula Virtual" parte-se inicialmente do modelo de interação, que consiste dos seguintes aspectos:

• aluno deverá realizar a matrícula na(s) disciplina(s) de um curso específico através do preenchimento de um formulário HTML que deverá conter as informações básicas de identificação do aluno ( dados pessoais, curso, disciplina, etc ), a partir daí, estas informações serão enviadas para um servidor, que através de um programa CGI irá validar as informações e montar o perfil inicial do aluno. Este perfil deverá levar em consideração informações referentes ao histórico do aluno ( estas informações poderão ser extraídas de uma base de dados que contenha dados sobre o histórico do aluno, ou as informações de experiências prévias do aluno dentro área da(s) disciplina(s) poderão ser obtida junto com os outros dados ).

• O ato de assistir uma aula se dará assincronamente [Fluckiger95], logo o aluno quando desejar, poderá interagir com o sistema para consultar o material e realizar as atividades propostas. Além de cada atividade, o curso tem um tempo pré-determinado para ser realizado. Neste item, a interação começa com a identificação do aluno, através de seu RA (Registro do Aluno) e sua senha. O servidor receberá as informações e ativará um CGI para validá-las. Após a validação é recuperado o perfil do usuário ( que consiste dos links que ele poderá fazer acesso com base nas informações previamente armazenadas sobre o usuário).

Ficou caracterizado na descrição acima que as informações a respeito do aluno deverão ser conhecidas pelo servidor ( programa CGI que manipula as informações do aluno/curso ) para que este consiga buscar as informações adequadas ao aluno. Este deverá atualizar o perfil do aluno com informações recebidas do cliente, tais como: o resultado de uma avaliação ou se o aluno concluiu um determinado item do material, etc. Logo, dados do perfil devem ficar transitando entre o servidor e o cliente o que requer que estas informações sejam mantidas durante a interação.

O HTTP não suporta naturalmente a manutenção de estado [Iyengar97], faz-se necessária a utilização de abordagens adicionais para prover esta característica. A seguir são discutidas algumas soluções propostas para contornar este problema.

A seguir serão descritas possíveis soluções para a aplicação educacional apresentada acima. O cenário proposto será analisado em relação a suas propostas de implementação: baseada no cliente e baseada no servidor.

Cookies é um mecanismo de armazenamento de estado que se dá no cliente, ou seja, as variáveis de estado e seus valores são armazenados no cliente. Esta informação é associada a um conjunto de URL de tal forma que sempre que é feito acesso a elas os valores das variáveis de estado seguem juntos.

Para funcionamento deste mecanismo é preciso que tanto o servidor quanto o cliente possuam capacidade para trabalhar com cookies. Como não se trata de um dispositivo padrão, pode haver dificuldade para algum cliente ( no nosso cenário, aluno) de realizar a aula virtual por impossibilidade de seu software (browser).

O modo de funcionamento dos cookies, para aula virtual, é o seguinte: o aluno se identifica (nome do usuário, senha), o servidor, através de um programa CGI confere os dados, e envia para o aluno o conjunto de variáveis que constitui o histórico, inicialmente

curso e nível do aluno, bem com seus valores. Isto é feito incluindo-se no arquivo HTML retornado o seguinte cabeçalho:

Set-Cookie:CURSO=EE;NIVEL=grad;path=/cgi-bin;

Este cookie contém os valores das variáveis curso e nível. Toda vez que for feito acesso ao diretório /cgi-bin do servidor, o cookie abaixo será enviado:

Cookie: CURSO=EE;NIVEL=grad

Os formulários HTML são invariavelmente geralmente associados a programas CGI. São os programas CGI que recebem os valores obtidos dos formulários, que consultam a base de dados e que, com o resultado obtido, produzem o documento HTML a ser retornado ao cliente. Portanto, para que haja a manutenção do estado da aplicação, esta informação de estado ( histórico) deve estar dentro do texto HTML recebido pelo cliente. No cenário proposto, quando o aluno identifica-se (nome de usuário, senha), via um formulário HTML, é ativado um programa CGI que verifica os dados na base de dados e produz um documento em que seguem "escondidas" as variáveis de estado. O cliente ao selecionar uma ligação, estará invocando um outro programa CGI com os valores das variáveis de estado embutidos. Para um histórico simplificado, por exemplo, teríamos os valores das variáveis nível e curso.

Pode-se observar que um programa CGI precisa criar ligações já embutindo a informação relativa à manutenção do estado. De maneira semelhante, este programa deve saber, que quando a ligação faz referência a um arquivo estático, qual o arquivo relacionado aos valores de nível e curso selecionados. Este mesmo problema repete-se para todos os programas CGI invocados durante a conversação. De onde se conclui que esta abordagem cria uma sobrecarga na implementação dos programas CGI, bem como na sua manutenção, haja vista que qualquer alteração implica a alteração de vários programas.

A Inclusão Dinâmica de Argumentos (Dynamic Argument Embedding – DAE) mantém o estado da aplicação através da inclusão de argumentos (juntamente com seus valores) nas ligações contidas nos documentos HTML apresentados ao cliente. Estes argumentos são as variáveis de estado que definem o andamento da Aula Virtual. A inclusão é dinâmica porque a alteração dos documentos HTML a serem apresentados aos usuários ocorre dinamicamente.

A DAE baseia-se em dois programas – embed1 e embed2- localizados nos servidores que implementam a Aula Virtual. O programa embed1 recebe como entrada um documento HTML e um conjunto de variáveis de estado e seus valores; em resposta fornece o mesmo documento HTML, porém com as suas ligações alteradas para fazer invocações no servidor ao programa embed2 os parâmetros dessa invocação são os normalmente constantes da ligação mais as variáveis de estado.

Quando o cliente seleciona uma ligação, ele provoca a invocação de embed2 no servidor. O embed2 precede de maneira diferente se a ligação original era associada a um arquivo ou a um programa CGI. SE era um arquivo, ele é simplesmente retornado para o cliente, porém com as suas ligações novamente alteradas por embed1 para invocar embed2; se era um programa CGI, o embed2 invoca o programa CGI com seus parâmetros originais mais as variáveis de estado. A saída, antes de retornar ao cliente, é alterada por embed1.

O algoritmo para preservação do estado para a aplicação Aula Virtual possui os seguintes passos [Ivengar97, Delfino98]:

Aluno fornece sua informação de identificação (nome de usuário, senha ) que é verificada no servidor através da invocação de um programa CGI. Este programa irá consultar a base de dados e retornará como saída um documento HTML e as variáveis de estado que constituem o perfil.

Embed1 modifica saída do programa CGI, alterando as ligações para fazer invocações a embed2. Por exemplo, suponhamos que a saída seja um documento HTML que possua uma ligação exercício da seguinte forma:

<a href=

"http://www.uni-a-distancia.br/cgi-bin/exercicio?no=1">

Tomando como variáveis de estado curso e nível, teríamos a ligação modificada para:

<a href=

"http://www.uni-a-distancia.br/cgi-bin/embed2?url="http://www.uni-a-distancia.br/cgi-bin/exercicio?no=1&curso=EE&nivel=grad">

Passo 3: saída de embed1 é enviada para o cliente.

Documento HTML modificado é enviado para o cliente e apresentado ao aoluno

O aluno seleciona a ligação que provoca a execução de embed2 com os parâmetros no-1, curso=EE e nivel=grad.

Como o primeiro argumento para embed2 é um programa CGI (exercício), então no=1 é argumento original, comma=1 é o argumento separador e curso=EE e nivel=grad são variáveis de estado.

O programa embed2 invoca o programa CGI com o argumento original e as variáveis de estado. A saída resultante, página HTML com o exercício número 1, e as variáveis de estado são passados para embed1.

O programa retorna ao passo 2.

A vantagens e desvantagens das abordagens descritas na seção anterior são discutidas Iyengar [Iyengar97], no que diz respeito aos seguintes aspectos:

O HTML forms podem manter o estado somente quando todas as respostas do servidor são dinamicamente geradas, o que compromete a utilidade deste método para um larga classe de aplicações. DAE e Cookies podem preservar o estado para aplicações que geram páginas HTML de qualquer tipo. No que diz respeito à compatibilidade com o protocolo HTTP, HTML forms e DAE trabalham com qualquer browser e servidor que suportam HTTP, Cookies requerem suporte especial porque não são padrão.

A aplicação Web que cria um cookie deve especificar uma data de expiração do cookie no lugar da data especificada por default. Isto pode acarretar um problema: a data ser definida de forma inapropriada ( muito cedo ou muito tarde). No HTML forms e nos DAE as variáveis de estado são parte integral da aplicação e portanto a data de expiração não precisa ser especificada e, não depende do clock do sistema.

Entretanto em situações em que é desejável que as variáveis expirem enquanto um browser ainda esta vendo páginas correspondentes a aplicação, os cookies manipulam a situação naturalmente, enquanto que para o HTML forms e os DAE esta situação tem que ser manipulada em nível da aplicação.

Cookies têm pouca sobrecarga e resultam em melhor desempenho que as outras duas técnicas. A sobrecarga gerada pelos HTML forms e pelos DAE resultam da invocação de programas CGI para criar cada página.

As três técnicas suportam Secure Socket Layer (SSL) da Netscape, assim as variáveis de estado podem ser encriptadas assim que elas são enviadas pela rede. HTML forms e DAE também suportam Secure HTTP (S-HTTP) da Enterprise Integration Tecnologies.

Com o HTML forms cada formulário dinâmico pode passar variáveis de estado para somente uma URL e, quando necessário, o programa de aplicação pode assegurar que as variáveis de estado foram transmitidas seguramente. Com DAE e cookies, usuários podem freqüentemente continuar a conversação selecionando uma variedade de links hipertexto. DAE pode também converter requisições HTTP automaticamente para requisições SSL para proteger suas variáveis de estado

O protocolo HTTP é um protocolo de transmissão de arquivos sem estado (stateless) porque, para cada transmissão uma nova conexão é estabelecida sem levar em consideração quaisquer conexões anteriores. Portanto, duas transferências de arquivos via HTTP, com origem e destino idênticos, são tratadas como conexões diferentes.

A utilização do HTTP Persistente (P_HTTP) [Touch96] traz melhorias tem relação ao protocolo HTTP pois não encerra as conexões após a transmissão. Desta forma as transferências com mesma origem e mesmo destino podem ser realizadas na mesma conexão, diminuindo a sobrecarga do sistema.

É importante notar que P-HTTP não é uma solução para a manutenção dos estados de uma aplicação porque estes estados são valores de variáveis, ligadas aos programas executados no servidor HTTP, que estão contidas no texto dos documentos HTML transferidos; como o P-HTTP não possui ingerência nos documentos trafegados, nem no servidor, não possui influência na manutenção do estado da aplicação, apenas na manutenção do estado da conexão entre cliente e servidor.

Este trabalho discutiu algumas abordagens para implementação de estratégias para manutenção de variáveis de estado durante o ciclo de vida de uma aplicação WWW. Utilizou-se como exemplo uma aplicação educacional constituída de curso sob medida + prova virtual. Os métodos apresentados foram: DAE, Cookies e HTML-Forms. Apresentou-se ainda uma abordagem para manter o estado das conexões, o P-HTTP.

Apresentou-se uma comparação entre os métodos de manutenção do estado da aplicação – DAE, Cookie e Forms HTML – onde ficou claro que todas apresentam pontos fortes e fracos. Mostrou-se também que os protocolos que procuram manter o estado da conexão (P-HTTP) não são solução para o problema de manutenção do estado da aplicação.

Uma solução interessante seria mesclar DAE e Cookies de forma a manter localmente informações não relevantes e manter no servidor as informações críticas.

[Berners-Lee96] Berners-Lee t. , RFC 1945 (hipertext Transfer Protocol); 1996.

[Comer91] Comer D.; Internetworkin with TCP/IP - ; vol I: principles, protocols and architeture; Prentice-Hall; 1991.

[Fluckiger95] Fluckiger, F.; "Taxonomy of multimedia aplications" in Understanding networked multimedia: Applications and technology, cap 6, pp109-121, Prentice-Hal, 1995.

[Delfino98] Delfino, A . S.; Orosz, J.C.; Picarelli , J.E., Chaim, M.L. e Nogueira, M.F.; Estudo sobre a implementação de um servidor HTTP para a aplicação "curso sob Medida + Prova Virtual"; http://www.dca.fee.unicamp.br/~ricarte/Courses/IA368/1s98/Http/a4.html.

[Iyengar97] Iyengar, A . Dynamic argument embedding: Preserving state on the World Wide Web", IEEE Internet Computing, 1(2):50-56, March/April. 1997.

[Newcom91] Newcomb, S.R., Kipp, N. A ., Newcomb, V.T. The "HyTime"Hypermedia/Time-based Document Structuring Language, Comunications of the ACM, 34(11), pp. 67-83, November, 1991.

[Tanen96] Tanenbaum, A . ; Computer Network, Upper Saddle, NJ:: Prentice-Hall, 1996.

[Touch96] Touch, J.; Heidemann, J.; Obraczka, K.; Anallysis of HTTP Performance; USC/ Information Scientces Institute, August 16, 1996

[Touch97] Touch, J et al.; IEEE/ACM Transatction on Networkin 5 (5):616-630, 1997.