Sumário:

1. Introdução

Nos primórdios da comunicação de computadores, a maior preocupação era com a transferência de dados: mensagens (correio eletrônico) e informação (dados para porgramas). Estávamos em plena guerra fria; era importante que, no caso de uma "guerra quente", a destruição de um ponto não inviabilizasse a comunicação entre todos os computadores, mantendo em operação os sistemas de defesa norte-americana (e.g.: sistema balístico). Neste contexto é que foi desenvolvida a ARPANET – rede de computadores precursora da Internet – que interligava computadores de universidades e do Departamento de Defesa [Tanen96].

Diante da explosão da Internet através da World Wide Web (WWW), causado pelo seu acesso pelo cidadão comum, uma gama maior de aplicações passaram a ser requisitadas. Essas novas aplicações requerem um grau maior de sofisticação, exigindo que a comunicação entre cliente e servidor extrapole a simples transferência de arquivos. Entre os exemplos de aplicações neste novo contexto incluem-se o comércio virtual e a educação à distância.

Todavia, a plataforma em que foi desenvolvida a ARPANET continua sendo utilizada pela WWW: o protocolo de comunicação TCP/IP (Transport Control Protocol/Internet Protocol) e os protocolos de transferência de arquivos (FTP – File Transfer Protocol – e, mais recentemente, HTTP – HyperText Transfer Protocol[Berners-Lee92]). O protocolo FTP foi desenvolvido para realizar transferências de arquivos sobre a plataforma TCP/IP. Trata-se de um protocolo confiável e baseado em conexão [Touch96]; porém, com a desvantagem de requer a abertura de um canal exclusivo de comunicação para transferir requisições de arquivos e um segundo canal para a transferência dos arquivos em si. O protocolo HTTP, por sua vez, utiliza um único canal de comunicação para transferir tanto requisições como arquivos. Note-se, então, a diferença entre o FTP e o HTTP. O primeiro mantém a conexão para tráfego de requisições, de modo que são mantidas as variáveis (e.g.: taxa de transmissão etc.) estabelecidas na primeira conexão; já o HTTP procede como se cada transferência fosse uma conexão distinta, não utilizando qualquer informação das transferências anteriores. Por isso, o HTTP é um protocolo sem estado (stateless) [Touch96, Iyengar97]; porém, neste sentido, o conceito de estado refere-se ao conjunto de variáveis da conexão.

As aplicações implementadas sobre a base tecnológica da WWW utilizam protocolo HTTP (devido a sua maior eficiência na transferência de arquivos) como plataforma de comunicação para transferência de documentos escritos em linguagem HTML (HyperText Mark-up Language). O fato de utilizarem o HTTP implica que estas aplicações possuem as limitações intrínsecas deste protocolo. Uma dessas limitações diz respeito ao fato de as conexões via HTTP não armazenarem informações relevantes de conexões anteriores, pois são conexões sem estado.

Porém, as novas aplicações exigidas para a WWW requerem que informações relevantes sejam mantidas durante várias conexões. Por exemplo, as aplicações de comércio virtual exigem que as informações a respeito do comprador sejam mantidas durante toda a interação do cliente (aqui no sentido comercial do termo!) com a loja virtual. As aplicações deste tipo em operação na WWW se valem de artifícios para manter os valores dessas variáveis (chamadas de variáveis de estado) durante toda a aplicação.

Um desses artifícios são os formulários HTML. Normalmente, em resposta ao preenchimento de um formulário HTML, é invocado no servidor um programa CGI (Common Gateway Interface) que produz em resposta um documento HTML que é retornado ao cliente. As variáveis de estado seguem codificadas nos campos do formulário HTML e no documento HTML retornado pelo servidor. A limitação desta abordagem encontra-se no fato de que é sempre necessário gerar dinamicamente um documento HTML como resposta, não se prestando para a situações em que a resposta ao cliente é um arquivo HTML estático [Iyengar97].

Outra solução são os chamados Cookies inventados pela Netscape Communications. Os cookies consistem em dados que são armazenados no cliente que associam valores de variáveis de estado a URLs (Universal Resource Locator). Sempre que o cliente faz acesso as estas URLs, os valores das variáveis de estado contidas no cookies são incluídos na transmissão para o servidor. Uma das desvantagens deste mecanismo é o fato de exigir que tanto o servidor como o cliente tenham capacidade para aceitar cookies, pois é uma extensão não padronizada ainda [Iyengar97]. Solucao semelhante sao os wallets propostos pela MicroSoftware Corp. [Wallet 98].

A última abordagem é a Inclusão Dinâmica de Argumentos (DAE – Dynamic Argument Embedding). A DAE é uma solução semelhante aos formulários HTML. O cliente preenche um formulário que é enviado para o servidor; o servidor invoca um programa CGI que produz um documento HTML; este documento, antes de ser retornado para o cliente, tem as suas ligações (links) alteradas para sempre invocar um programa (chamado embed2) no servidor acrescido das variáveis de estado com seus respectivos valores. O embed2 procede 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 a suas ligações novamente alteradas para invocar embed2 com as variáveis de estado; se era um programa CGI, o embed2 invoca o programa CGI com seus parâmetros originais mais as variáveis de estado; igualmente a saída, antes de retornar ao cliente, é alterada. Note-se que as variáveis de estado são mantidas pela constante alteração das ligações para invocar embed2 tendo como parâmetros as variáveis cujos valores devem permanecer constantes. Esta abordagem possui como grande desvantagem o fato de ser centrada no servidor.

Este documento tem como objetivo discutir as possibilidades de implementação de aplicações que envolvem a manutenção do estado da aplicação na WWW. Pretende-se evidenciar a diferença entre a manutenção do estado da conexão (implementado por alguns protocolos) e do estado da aplicação, realizados pelos mecanismos aqui discutidos.

A Seção 2 irá apresentar o cenário de uma aplicação de cunho educacional cuja característica requer a manutenção do estado durante toda a aplicação. Na Seção 3, serão analisadas as estratégias para a solução deste problema. A análise de uma aplicação real semelhante existente na WWW é descrita na Seção 4. As conclusões são discutidas na Seção 5.

2. Cenário de uma aplicação educacional

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 à Distância (Uni-a-distancia) que fornece cursos predominantemete na área tecnológica. O aluno de um curso da Uni-a-distancia (e.g.: engenharia elétrica), matriculado em uma disciplina qualquer (e.g.: MA-101 Cálculo Diferencial e Integral I), poderá remotamente assistir a aula sobre determinado assunto (e.g.: limites) no momento que melhor lhe convier; portanto, a comunicação é assíncrona [Fluckiger95, Delfino98]. 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. De igual maneira, 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, disponibilidade (vagas, semestre de oferecimento), critério de avaliação, recursos necessários (plataforma de hardware e software), ementa, corpo básico (comum a todos os cursos).

A interação aula virtual começa com a identificação do aluno. Este procedimento dar-se-á através de um formulário HTML. A verificação das informações básicas de identificação (nome de usuário, senha) permitirá o acesso do aluno às aulas da disciplina. A partir deste momento, a interação é governada por um conjunto de variáveis de estado definidas como histórico. As variáveis básicas que constituem o histórico são o curso e o nível do aluno; porém, no decorrer da conversação (seqüência de comunicações entre um cliente e um ou mais servidores em que o cliente seleciona a próxima página através de ligações fornecidas pelo servidor [Iyengar97]), o conjunto de variáveis definido pelo histórico pode ser alterado. Por exemplo, o aluno somente poderá realizar uma aula depois de fazer corretamente um determinado exercício ou ter consultado uma certa seqüência de documentos. Assim, observe-se que, apesar da particularização inicial definida pelo curso e nível do aluno, que determina o perfil (exemplos e exercícios direcionados para área de atuação) que a disciplina terá, outras variáveis vão aumentando ou diminuindo o conjunto histórico na medida que a aula virtual vai se desenrolando.

Um requisito dessa aplicação é que ela deve trazer para o cliente o máximo de operações possível, desde que não comprometam o desempenho e a segurança do sistema. Assim, informações de configuração (e.g.: layout de páginas, fonte) devem permanecer no cliente; e mesmo as variáveis de estado, quando possível.

3. Estratégias de Implementação

A seguir descreveremos as possíveis soluções para a aplicação educacional apresentada acima. O cenário proposto será analisado em relação a duas propostas de implementação: baseada no cliente e baseada no servidor. Com relação à proposta baseada no cliente temos as alternativas cookies e wallets; em relação à segunda, também duas alternativas – formulários HTML e DAE.

3.1 Estratégias baseadas no Cliente

3.2 Estratégias baseadas no Servidor

• passo 1: Aluno invoca programa CGI que verifica identificação.

• passo 2: programa CGI passa saída de seu processamento e as variáveis de estado para embed1.

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

• passo 4: aluno seleciona ligação exercício.

• passo 5: embed2 traz arquivo HTML ou invoca programa CGI.

3.3 Estado da Conexão versus Estado da Aplicação

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.

Se por um lado esta solução é fácil de implementar, por outro, é ineficiente quando várias transmissões com origem e destino idênticos ocorrem em seqüência. Para solucionar este problema, foi proposta uma alteração do protocolo HTTP chamada P-HTTP (Persistent HyperText Transfer Protocol) [Touch96]. A principal característica do protocolo P-HTTP é possibilitar a manutenção da conexão realizada com um dado servidor HTTP permitindo que várias transações se deêm sem a necessidade de estabelecimento reiterado de um canal de conexão. Ou seja, a primeira conexão com o servidor é utilizada para as várias trocas de dados. Estes dados, por sua vez, são documentos HTML [Delfino98].

Observe-se 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.

4. Estudo de Caso

A Universidade do Texas, UT, gerencia um projeto de cursos à distância denominado World Lecture Hall (WLH) [WLH 98]. O WLH é um sítio que contém links para cursos criados por outras instituições de ensino. Além dos links, o WLH possui formulários para cadastramento de cursos e um mecanismo para procura de cursos específicos. Em outras palavras, o WLH é um sítio que é acessado por instrutores e alunos no processo de oferecimento e busca de cursos à distância.

O WLH oferece cursos em 77 diferentes áreas ( por exemplo, anatomia, história, economia, inglês, agricultura. matemática, computação etc.), estando cadastrados de 15 a 50 cursos para cada área. Cada cursos possui a sua própria organização, isto é:

• Curso pago ou não;
• Curso com ou sem limites de participantes (alunos);
• Curso com ou sem data de início e termino;

Quanto à estrutura do material didático, tem-se:

• Curso montados como documentos multimídia;
• Curso cooperativo (exige a realização de trabalhos de forma cooperativa);
• Curso com palestras (transmissão de palestras pela WWW em horários pré-estabelecidos);
• Curso com ou sem provas;

Para exemplificação, considere o curso Introdução à Internet cadastrado na área de informática. O curso em questão é pago e limitado a 30 alunos. No processo de cadastramento, o aluno preenche um formulário sobre os seus dados pessoais e acadêmicos. A confirmação da matrícula é feita via e-mail. Após o recebimento da confirmação, o aluno deve providenciar o pagamento do curso. Novamente, um formulário deve ser preenchido com os dados do cartão de crédito do interessado. Quando o sistema acusar o pagamento, um e-mail será enviado ao aluno com as instruções finais, juntamente com a password e um programa de e-mail, especialmente projetado para permitir a realização de trabalhos cooperativos.

Este curso pode ser visto como tendo duas partes. A primeira é um documento hipermídia que pode ser estudado assincronamente, obedecendo a um prazo máximo. A segunda parte é composta de palestras transmitidas pela internet em datas específicas. Após o aluno completar um conjunto específico de aulas e palestras, ele estará habilitado a fazer um exame.

Por uma questão de simplificação, será analisado o próprio ambiente do WLH e um de seus cursos (Introdução à Internet) com respeito a utilização das estratégias da sessão 3.

Como foi descrito anteriormente, o WLH armazena links para mais do que 2000 diferentes cursos distribuídos em 77 áreas. Este emaranhado de cursos é uma dificuldade para que o aluno realmente encontre um curso de seu interesse. Pois, por exemplo, existem vários cursos, dentro de uma mesma área, com o mesmo título e com pré-requisitos diferentes. Caso o WLH fornecesse algum mecanismo para cadastramento do perfil do aluno, este facilitaria em muito o trabalho de seleção de cursos. Observe-se que este perfil poderia ser utilizado para "propor" cursos que aluno nem pensaria em fazer, por exemplo, Introdução à Astronomia para aficionados em ficção científica. Isto só seria possível, naturalmente, se o perfil contivesse campos de outros interesses acadêmicos ou mesmo um hobby. Este perfil deveria ser armazenado na máquina do cliente para não degenerar os objetivos principais do WLH. Pode-se introduzir também o conceito de histórico, que incluiria, além do perfil, os últimos cursos "freqüentados", notas, etc.

O curso em questão, Introdução à Internet, já utiliza uma estratégia para preservação de algumas variáveis de estado. Os dados cadastrais do aluno e alguns dados do curso ficam armazenados no servidor, enquanto os dados relacionados com "user-id", a última aula realizada e a data de início e término do curso são armazenados localmente, via cookie. Note que apenas os dados armazenados localmente podem ser descritos como variáveis de estado. Este mecanismo tem como desvantagem exigir que tanto o servidor como o cliente tenham capacidade para aceitar cookies. Este problema poderia ser resolvido utilizando-se da abordagem proposta no DAE.

Uma outra questão que poderia ser beneficiada com a adoção do perfil do estudante, é a montagem de cursos a distância. Pode-se citar ,como exemplo, os cursos de inglês oferecidos. Observa-se que os cursos (por exemplo, redação) são todos estruturados independentemente uns dos outros. Isto, além de acarretar uma duplicação de esforços, pois alguns abordam tópicos correlatos, não utiliza informações específicas do aluno para a montagem de um curso sob medida. É claro que no caso específico dos cursos oferecidos pela WLH não é fácil a adoção de um perfil para a montagem dos cursos, uma vez que os cursos, muitas vezes semelhantes, são oferecidos por instituições independentes. Mas, mesmo assim, nada impede que esta estratégia seja adotada de forma mais local.

5. Conclusão

Este documento discutiu as possibilidades de implementação de estratégias para manutenção dos valores de certas variáveis (variáveis de estado) durante o ciclo de vida de uma aplicação WWW. Na realidade as aplicações que precisam manter os valores das variáveis de estado durante várias conexões se utilizam de artifícios para a manutenção dos valores destas variáveis. 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.

As quatro abordagens discutidas foram: formulários HTML gerados dinamicamente, cookies , wallets e a Inclusão Dinâmica de Argumentos (DAE). Entre estas, as mais interessantes são os cookies e o DAE. Os cookies são armazenados localmente, o que pode ser uma vantagem para alguns tipos de aplicações. A DAE, por outro lado, é centralizada no servidor. Com relação ao aspecto desempenho, a solução cookie é a mais eficiente visto que não induz nenhum overhead ao servidor enquanto a DAE, mesmo possuindo um overhead menor que os formulário HTML, provoca a execução no servidor dos programas embed1, embed2 e programas CGI. No aspecto segurança, ambas as soluções permitem a transferência segura (criptografada) dos dados, sejam eles cookies ou variáveis de estado. Os cookies podem sofrer o acesso não autorizado na máquina cliente do aluno; de maneira semelhante, os documentos HTML podem sofrer o mesmo problema se o browser utilizar uma área de cache.

Uma solução interessante seria mesclar as duas soluções, mantendo localmente informações não relevantes (como a configuração do aluno – fonte de letra, folha de estilo etc.), utilizando uma solução baseada no servidor para manutenção de informações críticas.

Ademais, foi determinado um cenário de uma aplicação educacional com as respectivas estratégias de implementação. Por fim, foi apresentado um estudo de caso com a introdução de alguns dos aspectos estipulados para o cenário da aplicação educacional.

Referências bibliográficas

[Berners-Lee92] Berners-Lee, T. HTTP: A protocol for networked information, Internet Draft, 1992.

[Fluckiger95] Fluckiger, F. "Taxonomy of multimedia applications" in Understanding networked multimedia: Applications and technology, Capítulo 6, pp.109-121, Prentice-Hall, 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/ls98/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, Communications of the ACM 34(11), pp.67-83, November 1991

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

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

[Wallet 98] http://www.microsoft.com/commerce/wallet

[WLH 98] http://www.utexas.edu/world/lecture