From: Adriana Delfino dos Santos
Newsgroups: feec.posgrad.IA368F
Subject: Resumo A4: Protocolos na Web
Date: Fri, 03 Apr 1998 12:01:53 -0300
Organization: CNPTIA/EMBRAPA
Resumo - Protocolos na Web
Grupo A4
Adriana Delfino dos Santos, João Carlos Oroz, José Estevão Picarelli,
Marcos LordelloChaim, Maria Fernanda (Relatora)
Cenário:
"uma disciplina é ministrada em vários cursos, sendo especializada para
cada um deles".
Funcionalidades
As funcionalidades descritas para o ambiente educacional proposto são:
1. Compor as disciplinas (materiais, 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 disciplinas/aulas (relacionamento
curso/aulas/disciplinas/tempo máximo).
5. Acompanhar o andamento da disciplina. Forncer feedback para alunos e
professores.
6. Aplicar prova (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.
Métodos HTTP x Funcionalidades Ambiente Educacional
- GET: (1) (2) (3) (4) (5) (6) (7) (8);
- CHECKOUT: (1) (2) (3);
- POST: (1) (2) (3) (5) (6) (7);
- PUT: (1) (2) (3) (7);
- CHECKIN: (1) (2)
- DELETE: (1) (2) (3) (7).
Implementação de funcionalidade com Dynamic Argument Embedding
Funcionalidade: (4)
Cliente: Para iniciar a aula o aluno se identifica (userID e password).
Servidor: Recebe a identificação do aluno, consulta o cadastro de atores
e preenche as variaveis de estado da aplicação (perfil do curso= eng.
eletrica e nível do aluno= graduação). Devolve a relação das aulas
disponíveis + variaveis de estado da aplicação.
Cliente: O aluno seleciona a aula que ele deseja assistir.
Servidor: Recebe aula solicitada + variaveis de estado da aplicação.
Recupera a aula de acordo com as variáveis de estado da aplicação.
Devolve a aula recuperada + variaveis de estado da aplicação.
Cliente: O aluno seleciona um link para "exercícios" na página da aula.
Servidor: Recebe solicitação de link para exercícios + variaveis de
estado da aplicação. Recupera exercício de acordo com as variaveis de
estado da aplicação. Devolve exercício + variaveis de estado da
aplicação.
Persistent HTTP
Este mecanismo não é adequado para a solução do problema pois ele
preserva o estado da conexão em uma conversção e não o estado da
aplicação que em conversação.
From: Antonio Tadeu Maffeis
Newsgroups: feec.posgrad.IA368F
Subject: Grupo B4 - Protocolos na WEB
Date: Fri, 03 Apr 1998 13:35:31 -0800
Organization: Antonio Tadeu Maffeis
Grupo B4: Antonio Tadeu, Armando, Jefferson, Raquel S.
Atividade: Implementação de um servidor http para apoiar um ambiente
educacional ( com base no ambiente proposto em 31/3/98 )
---------->Para suportar as atividades que serão desenvolvidas na aplicação
proposta, o grupo chegou a conclusão que um servidor deveria suportar os
seguintes métodos:
Para dar suporte à funcionalidade 1: Compor as disciplinas ( material,
exercícios, provas, aulas, grupos de forma distribuída, etc.)
Métodos:
- GET: este método será utilizado nas consultas ao material por
parte dos instrutores e pessoas que estarão colaborando na elaboração e
avaliação do material da disciplina;
- 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;
- 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);
- LINK: será utilizado pelo servidor para relacionar documentos; um
exemplo seria a colocação de referências no documento, identificando às
pessoas que tenham acesso àquela página, onde podem encontrar mais detalhes
a respeito do assunto que está sendo tratado;
- 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, sendo assim a utilização do
UNLINK seria necessária;
- 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.
- CHECKIN/CHECKOUT: utilizado para bloquear/desbloquear o acesso a
determinadas páginas que estão em processo de construção;
Para dar suporte à funcionalidade 2: Estabelecer perfis para cada curso
(definir diferentes visões)
Métodos:
- 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 acessados 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).
Para dar suporte à funcionalidade 3: Cadastrar atores com diferentes perfis
e níveis de acesso ( instrutor monitor, alunos, grupos de forma
distribuída).
Métodos:
- GET: possibilitar aos interessados ter acesso ao formulário de
cadastramento;
- 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;
Para dar suporte à funcionalidade 4: Disponibilizar disciplinas/aulas
(Relacionamento curso/disciplinas/tempo máximo)
Métodos:
- 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);
- POST: para os alunos enviarem questões para serem discutidas para
um servidor news
- TEXTSEARCH: disponibilizar o recurso de pesquisas de
"strings" nas páginas;
Para dar suporte à funcionalidade 5: Acompanhar o andamento da
disciplina. Fornecer Feed-back para os alunos e professores.
- POST: divulgação do resultados no news, criação de páginas novas
para serem colocadas notas sobre aulas e atividades realizadas (professor);
- GET: consulta ao material divulgado
- PUT: necessário para a atualização das páginas com comentários
sobre as atividades e notas dos exercícios
Para dar suportar à funcionalidade 6: Aplicar provas (teste,
dissertativas, etc...)
Métodos:
- PUT: durante a execução da prova, o aluno deverá elaborar as
respostas e posteriormente atualizá-las no servidor;
- GET: necessário para o aluno obter o formulário de prova com as
questões;
Para dar suporte à funcionalidade 7: Corrigir e pontuar a prova ( pelo
próprio sistema, testes; instrutor ad-hoc; auto-correção,
disponibilizar gabaritos para auto avaliação ).
Métodos:
- GET: disponilizar resultados para os alunos; diponibilizar
avaliações para correção dos instrutores;
- PUT: executar CGI para realizar correção ( correção pelo sistema
); disponibilizar anotações e colocação das notas nas provas ( campo de um
formulário destinado para colocação da nota );
Dar suporte à funcionalidade 8: Disponibilzar resultados
Métodos:
- PUT: permitir aos professores a divulgação dos resultados;
- GET: permitir aos alunos consultar os resultados (notas).
---------->O grupo chegou a conclusão que todas as funcionalidades que
auxiliam o monitoramento das atividades dos alunos poderiam se beneficiar
da preservação de estado. Logo as funcionalidades 4, 5 e 6 se encaixam
nesta categoria, porém, discutiremos especificamente a atividade 4 (
Disponibilizar disciplinas/aulas).
OBS.:A funcionalidade será implementada no servidor usando a seqüência de
passos identificados na figura. 2 [Dynamic Argument Embedding].
Quando o aluno for iniciar uma aula, ele se identificará digitando, por
exemplo, o RA e a sigla da disciplina do qual deseja ter acesso ao
material. Estas informações são enviadas para o servidor (solicitando a
execução de um CGI) que faz uma busca numa base de dados e identifica o
perfil do usuário, define os links (páginas, recursos, etc) que o
aluno poderá ter acesso e associa variáveis de estado ao link que eles
podem utilizar, devolvendo os links alterados, para o cliente. O objetivo
de tal procedimento é que o aluno tenha acesso a cada parte do material,
mas contenha refências para a próxima página que será utilizada.
----------->No item final, a utilização do P-HTTP seria interessante porque
no caso de transferência de grande volumes de informação do servidor para o
cliente as conexões não teriam que ser estabelecidas a cada transferência,
seriam permanentes. Logo, o tempo de transferência e acesso às informações
com este perfil ( grande volume de informações, voz, imagem, etc) poderiam
ser beneficiadas.
Porém, quando as informações estiverem distribuídas pela rede
(páginas em servidores diferentes) está técnica não trará grandes melhorias
no desempenho do sistema. Logo se as informações estão em pontos distintos
dad rede, sempre deverão ser estabelecidas novas conexões para que a o
servidor possa ter acesso a elas. Outro ponto não favorável, é que o
aumento das conexões é um fator limitante de performance, uma vez que a
banda de passagem será dividida por entre as conexões ativas.
From: Luciana Meneghel
Newsgroups: feec.posgrad.IA368F
Subject: Resumo do Tema Protocolos na WEB - Grupo C4
Date: Thu, 02 Apr 1998 16:48:58 -0300
Organization: Faculdade de Engenharia Eletrica e da Computacao - UNICAMP
Jose Roberto, Luciana, Raquel C., Ricardo T., Rossano.
1. Metodos HTTp que o servidor deveria suportar:
Metodos Funcionalidades
GET - 1,2,3,4,5,6,7,8
HEAD - 1
CHECKOUT - 6
PUT - 3,6
DELETE - 1,3,6,8
POST - 1
LINK - 1,2,4
UNLINK - 1,6
CHECKIN - 6
TEXTSEARCH - 1
Os numeros referentes as funcionalidades estao descritos no papel
recebido em aula para a execucao das tarefas.
2. A funcionalidade a qual necessita a preservacao de estado e Aplicacao
de Prova Virtual.
Implementacao:
1 - o cliente chama um programa CGI.
2 - o programa CGI passa as saidas e as variaveis de estado para um
modulo A.
3 - o modulo A modifica os links para chamar um modulo B.
4 - a saida do modulo A e enviada para o cliente.
5 - o cliente seleciona um link que chama o modulo B.
6 - o modulo B busca um arquivo HTML ou chama um programa CGI.
7 - o modulo B envia sua saida e mais variaveis de saide para o modulo
A.
3 - Sim. Na aplicacao da prova virtual, o carregamento de cada pagina
seria mais rapido.
From: Daniela Barbetti
Newsgroups: feec.posgrad.IA368F
Subject: Resumo Grupo D4 - Protocolos na Web
Date: Fri, 03 Apr 1998 14:10:47 -0300
Organization: UNICAMP - Centro de Computacao
Grupo D4: Alberto, Christian, Daniela e Marcelo
-------------------------------------------------
Questões:
1) Quais métodos http um servidor deveria suportar ? Jusitifque
a utilização de cada um deles através de exemplos.
- GET: receber dados e fazer busca (obrigatório em qq servidor);
- HEAD: importante para acessar a informação sobre um documento
(evita sobre carga da rede);
- CHECKOUT/CHECKIN: importante no trabalho colaborativo
por exemplo, para fazer anotações (trava/libera documento);
- SHOW METHOD: descrição de alguma funcionalidade do servidor.
(não conseguimos enxergar nenhuma funcionalidade);
- PUT: utilizado em ambiente colaborativo onde várias pessoas podem
atualizar documentos (Ex: vários autores). Tomar devidos cuidados
com segurança;
- DELETE: permite ao aluno apagar páginas de comentários de sua pro-
priedade em ambiente colaborativo (análise: benefício x segurança);
- POST: é essencial para criar novos documentos associados a do-
cumentos já existentes; mecanismos de anotação; lista de discussão;
news; alteração de documento durante a edição (autoria);
- LINK/UNLINK: necessário para implementar o POST;
- TEXT SEARCH: util para fazer busca utilizando uma string no
documento. É uma alternativa mais baixo nível em contra partida
a um cgi/script;
- SPACE JUMP: alternativa para ferramentas tipo image map.
Já existe uma implementação na camada de aplicação (sem
necessidade de implementação);
- SEARCH: refinamento do TEXT SEARCH. Mecanismo de busca
mais flexível, não baseado em string;
2) Apresente uma funcionalidade deste ambiente na qual a preservação
de estado é necessária nesse servidor. Descreva como seria a implemen-
tação desta funcionalidade usando dynamic argument embedding.
1.a) Preservação da identificação do aluno evitando uma nova checagem
do usuário quando ele solicitasse novas páginas;
2a.) Registro do tempo da prova: no momento em que o aluno inicia a
prova o horário é armazenado em uma variável de estado. Ao final,
essa informação será repassada ao professor.
Implementação:
- link para a prova;
- quando clicado nesse link dispara um cgi (DAE);
- a partir desse momento o aluno poderá navegar pelas páginas da
prova sempre mantendo o registro do tempo inicial;
- ao término da prova o aluno ativará um link "fim de prova"
que chamará outro cgi responsável pelo envio ao professor
das respostas do aluno e informações sobre o tempo gasto na prova;
- esse programa poderá ser utilizado para enviar ao aluno uma
notificação que incluirá nota (no caso de prova múltipla escolha),
tempo gasto e outras informações pertinentes.
3) Considerando a situação apresentada no item acima: P-HTTP
seria uma alternativa de implementação ? Justifique sua resposta.
Nao. O P-HTTP não é uma alternativa ao DAE.
From: Firmiano Ramos Perlingeiro
Newsgroups: feec.posgrad.IA368F
Subject: Resumo: Protocolos na Web
Date: Fri, 03 Apr 1998 10:04:43 -0300
Organization: Faculdade de Engenharia Eletrica e da Computacao - UNICAMP
Grupo: Ivan, Tilli, Firmiano e Valmir
Sumario:
1. Metodos HTTP x Aplicacao na area de educacao
2. Preservacao de estados: descricao da implementacao de uma
funcionalidade usando Dynamic Argument Embedding
3. P-HTTP: Uma alternativa para implementacao ?
1. Metodos HTTP x Aplicacao na area de educacao:
Metodos de operacao que podem ser desempenhadas por um determinado
objeto. Quando nos referimos ao protocolo http, um metodo e executado,
quando for requisitado por um objeto identificado por uma URL.
Os metodos sao: GET, CHECKOUT, PUT, DELETE, POST, LINK, UNLINK, CHECKIN.
As funcionalidades sao: composicao do material, diferentes visoes,
relacionamento do material, ligacao entre as partes, correcao, acesso,
disponibilizacao entre outras.
2. Preservacao de estados: Descricao da implementacao usando Dynamic
Argument Embedding:
A preservacao dos estados e uma necessidade em sistemas que precisam
flexibilidade no acesso dos dados. Na aplicacao discutida, ha a
necessidade de constante acesso e atualizacao da base de dados. Neste
caso o Dynamic Argument Embedding, permite sua implementacao.
3. P-HTTP: Uma alternativa para a implementacao:
O P-HTTP e uma alternativa para se melhorar o desempenho do HTTP sobre o
protocolo de transporte TCP, sendo uma das alternativas existentes.
O grupo.
From: Leo Pini Magalhaes
Newsgroups: feec.posgrad.IA368F
Subject: Grupo F4: Protocolos na WEB (fwd)
Date: Fri, 03 Apr 1998 18:07:27 -0300
Organization: Faculdade de Engenharia Eletrica e da Computacao - UNICAMP
IA368 - Topicos em Engenharia de Computacao V
Protocolos na Web: Resumo do tema sugerido
Grupo F4: Ricardo, Carlos, Marcio e Sergio
Apresentamos aqui uma proposta de um servidor http projetado para atuar
em ambientes educacionais. Tres pontos de interesse tem lugar:
- Metodos http suportados;
- Funcionalidade na qual a preservacao de estado e necessaria;
- Uso do P-HTTP na implementacao: justificar seu emprego ou sua ausencia
De modo simplificado, os seguintes metodos http serao utilizados:
GET: para obter dados da pagina desejada, que pode conter informacoes
sobre uma aula, uma prova, etc.
CHECKOUT e CHECKIN: necessarios para se efetuar uma especie de "controle
de versao". Um exemplo seria a disciplina ministrada por dois professores
que desejam fazer alteracoes numa mesma pagina ou prova.
PUT: usado em provas e exercicios, e responsavel pelos novos conteudos a
serem colocados em determinados periodos.
DELETE: tira links "vencidos" ou "proibidos": gabaritos, provas
passadas, exercicios antigos, etc.
LINK e UNLINK: metodos usados para estabelecer ou nao conexoes a outros
objetos. No nosso exemplo, podemos conectar aulas as respectivas
referencias.
POST: presta-se a manutencao de documentos em co-autoria: revisoes,
correcoes e comentarios de provas.
TEXTSEARCH: usamos para encontrar assuntos, palavras ou ideias numa aula
ou prova.
SPACEJUMP: semelhante ao metodo anterior, mas mais abrangente, pois
podemos procurar por imagens ligadas as explicacoes associadas.
Estabelecidos os metodos, discutimos agora uma das funcionalidades
oferecidas na qual a preservacao de estado e necessaria. A disponibilizacao de
resultados pode ser abordada como uma estrategia que se serviria desse conceito de
preservacao: entrando-se uma vez na pagina apropriada com a identificacao e a
senha, toda a consulta a notas e resultados poderia ser feita de uma so vez
para quaisquer disciplinas escolhidas, sem a necessidade de re-entrada de
dados a cada nova pesquisa. A unica restricao e que se deve estar na mesma secao
de uso do browser para isso.
Por fim, podemos dizer que o uso do P-HTTP nao se justifica em nossa
aplicacao, uma vez que o volume de dados em trafego e muito pequeno e nao necessita
de recursos avancados de processamento que necessitem dessa filosofia.
From: Marcelo Morandini
Newsgroups: feec.posgrad.IA368F
Subject: Resumo do Tema Protocolos na WEB - Grupo G4
Date: Fri, 03 Apr 1998 10:46:15 -0300
Organization: Fundacao Centro Tecnologico para Informatica - CTI
Grupo G4: Marcelo Morandini, Márcia de Fátima Pimenta, Maria Angelica
Calixto de A. Cardieri, Maria das Graças Junqueira M Tomazela, Maria
Flavia Cunha de Figueiredo Torres
Respostas:
PRIMEIRA QUESTÃO
Os métodos HTTP que o servidor deva suportar são os seguintes:
GET: significa recuperar todos os dados identificados pela URI, de modo
que a URI se refira ao processo de produção de dados, ou a um script no
qual pode ser rodado tal processo. São esses dados que serão retornados,
e não o texto fonte do script ou do processo.
Exemplo de utilização do GET: obter a Identificação e a Senha do usuário
(aluno ou instrutor) que utilizará o sistema.
PUT: especifica que os dados na seção corpo serão armazenados na URL
fornecida. Esta URL já deve ser existente. O novo "contest" do documento
será a parte de dados da reuisição. POST deve ser usada ara a criação de
novos documentos.
Exemplo de utilização do PUT: colocar os dados disponíveis. Esses dados
podem, por exemplo, ser as respostas de uma questão da prova.
SEGUNDA QUESTÃO
1. As Funcionalidades são as de número 6 e 7. Destacaremos a
funcionalidade número 6 - Aplicar prova (testes, dissertativas, etc...)
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. 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, pois estamos considerando que a prova será respondida questão
por questão em ordem crescente de numeração das questões com tempo
estipulado. 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.
A necessidade 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).
TERCEIRA QUESTÃO
Existem vantagens e desvantagens da utilização de P-HTTP, basicamente no
que tange ao fato do Banco de Dados ser distribuído ou não.
Vantagens:
Quando não for um Banco de Dados distribuído, a conexão fica basicamente
mantida (ié, não fechada). Com isso não haveria necessidade de variáveis
de estado, e o carregamento das páginas seria mais rápido.
Desvantagens
Em caso de Banco de Dados distribuído seriam então necessárias diversas
conexões para carregar páginas.
From: "Flavia Torres"
Newsgroups: feec.posgrad.IA368F
Subject: HTTP - Armazenamento dos dados no cliente
Date: Wed, 8 Apr 1998 08:36:27 -0300
Organization: Faculdade de Engenharia Eletrica e da Computacao - UNICAMP
Pessoal,
Estive pensando numa forma de armazenar os dados do cliente na máquina
do próprio cliente e não numa base de dados no servidor e achei que um
aplicativo do tipo das carteiras eletrônicas (ou "Wallets") seria uma
solução.
As "Wallets" são pequenos aplicativos que armazenam os dados pessoais de
um cliente (nome, cartão de crédito, endereço, etc) numa base de dados local
para a realização de compras via Internet.
No caso dos alunos poderia existir uma carteirinha eletrônica com sua
identificação e perfil. Para garantir a segurança e integridade dos dados,
eles poderiam ser criptografados. Assim só as pessoas autorizadas teriam
acesso a eles.
O que vocês acham?
Flávia
From: Armando Luiz Nicolini Delgado
Newsgroups: feec.posgrad.IA368F
Subject: Plenária HTTP - Grupo 3
Date: Wed, 08 Apr 1998 10:16:52 -0300
Organization: Departamento de Informatica - UFPR
Plenária sobre HTTP
Conclusões do Grupo 3
Membros: Armando, Ivan, Jefferson, A. Tadeu, L.. Gonzaga, Valmir, Marcio
Baseado na proposição do problema, o grupo assumiu que existe no
servidor um banco de dados em que são definidas as classes "disciplina",
"alunos" e "perfil", este como uma subclasse de "disciplina".
Os objetos da classe "alunos" possuem os seguintes atributos: nome,
ident. acadêmica, senha, histórico, docs acessados, doc corrente,
disciplina corrente, formação. O atributo "histórico" é multi-valorado e
assume como valor uma lista com disciplinas já cursadas. O atributo "docs
acessados" é uma lista de hiperdocs já acessados pelo aluno e que tem como
objetivo manter o histórico de navegacão do aluno pelos docs da disciplina.
Os objetos da classe "disciplina" representam o conteúdo principal da
disciplina, comum a todos os perfis, possuindo os seguintes atributos:
conteúdo, pré-requisitos, pós-requisitos. Os objetos da subclasse
"perfil" herdam os atributos de "disciplina" e ainda possuem os
atributos: formação e conteúdo do perfil.
Com estas informacões, o servidor, de posse dos dados de um aluno,
seleciona o documento básico adequado ao aluno (em função dos atributos
"histórico", "docs acessados", "pré-requisitos" e "disciplina corrente") e
seleciona os perfis adequados ao aluno (em função dos atributos "formação",
"docs acessados" e "histórico"). Os perfis seriam combinados com o
documento básico através de links normais ou com mecanismo do tipo "show
embed" do XML.
Nesta abordagem, seria possível ainda, em função dos valores de
"hitórico" e "docs acessados" apresentar perfis diferentes daqueles que
normalmente seriam apresentados ao aluno.
Como exemplo de uma sessão de trabalho, temos:
1. Cliente acessa página de Educação a Dist=E2ncia da Universidade;
2. Servidor apresenta página/form pedindo Identificação do aluno e senha
(já previamente cadastrados no servidor);
3. Após validação do aluno, servidor pede para este indicar a disciplina
que deseja cursar;
4. Servidor recupera na base de dados os atributos do aluno, do conteúdo
básico da disciplina e dos perfis disponíveis para a disciplina escolhida;
5. Obter na base de dados os conteúdos associados ao perfil do aluno
6. Compor o documento mestre a ser apresentado ao aluno. Este documento
é composto pelo conteúdo básico da disciplina (objeto da classe disciplina)
combinado com os conteúdos dos perfis subordinados a este objeto;
7. Apresenta documento ao aluno no cliente. Aluno navega pelo documento
seguindo links e tudo o mais;
8. Utilizar mecanismos de variáveis de estado (e.g. "dynamic argument
embedding") para armazenar o histórico de navegação do aluno;
9. Quando o aluno quer parar, sinaliza no cliente. Servidor anota o
documento corrente nos dados do aluno e encerra a seção.
From: José Estevão Picarelli
Newsgroups: feec.posgrad.IA368F
Subject: Um pouco de arquitetura - manutenção do estado
Date: Thu, 09 Apr 1998 11:05:58 -0300
Organization: PUC-Campinas
Na plenária de 07.04 (HTTP) foi discutido que para o artificio DAE
(Dynamic Argument Embedding) funcionar , todos os servidores que
participam da aplicação deveriam ter o algoritmo implementado. Acredito
que isto restringiria a utilização dos recursos da Web (por exemplo
acessar uma informação em um servidor que não tenha o algoritmo
implementado). Acredito que (por intuição e bom senso) isto poderia ser
solucinado através de um servidor tipo "centralizado" ou "driver" que
trataria de alterar todos os links (embed1) para com que as requisições
pudessem sempre "passar por ele" sevidor (ele seria o verdadeiro cliente
a esses servidores "sem o algoritmo" e não o cliente/aluno).
Este chute está muito fora?
Estevão
From: "Silvio"
Newsgroups: feec.posgrad.IA368F
Subject: Re: Um pouco de arquitetura - manutenção do estado
Date: 9 Apr 1998 15:26:15 GMT
Organization: Faculdade de Engenharia Eletrica e da Computacao - UNICAMP
Estevão,
O próprio tema da discussão era "projetar um servidor HTTP para implementar
a aplicação Cruso + Aula virtual". Se o curso exigir mais de um servidor,
todos
vão ter que implementar o algoritmo que possibilita a manutenção do estado,
seja através forms HTML, cookies ou DAE. Ademais, a centralização exigiria
uma maior coordenação para garantir a manutenção dos links sem esquecer
do aumento do "overhead" adicional no servidor centralizado.
Sílvio e Chaim.
From: "Silvio"
Newsgroups: feec.posgrad.IA368F
Subject: Estrutura do Relatório Final - HTTP
Date: 9 Apr 1998 15:06:41 GMT
Organization: Faculdade de Engenharia Eletrica e da Computacao - UNICAMP
Prezado Grupo,
Aqui vai a estrutura do relatório final do tema "Protocolos na Web":
Introdução
Cenário
Neste item, pretendemos incluir a descrição detalhada do cenário da
funcionalidade "Curso Virtual", enfocando as sugestões apresentadas
na plenára, a saber:
(1) Estado da aplicação associado a um histórico, ou seja, as
variáveis de estado poderão ser alteradas no decorrer da interação
do aluno-usuário -"freqüência" do curso.
Este histórico será obtido em função de atributos dos objetos aluno,
disciplina, perfil etc. Estes atributos, por exemplo, seriam, em relação ao
objeto aluno,
nome, identificação, formação anterior, curso atual, disciplinas
cursadas, documentos acessados etc; com relação ao objeto
disciplina, teríamos os atributos pré-requisitos, disponibilidade (vagas,
semestre de oferecimento), forma de avaliação, recursos necessários
(plataforma HW & SW), ementa, corpo básico (comum a todos os
cursos).
Entretanto, o histórico fará uso de apenas uma parte dos atributos
durante a interação, inclusive podendo mudar o elenco de variáveis
de estado. (Sugestão do Grupo 3 - Armando Delgado et. al.).
2. Estratégias de Implementação
No tocante à implementação, pretendemos analisar o cenário proposto
em relação duas alternativas possíveis de implementação:
(1) baseado no cliente: Cookies (e outras sugestões: (Wallets?);
(2) baseado no servidor: formulários HTML; Dynamic Argument Embedding.
Sempre tendo em mente a idéia de que, mesmo na alternativa
baseada no servidor, é importante analisar estratégia que
misturem as duas abordagens, isto é, o cliente deve ter
um papel ativo, tanto em processamento como em armazenamento
de dados. (Sugestão: Maria Angélica e Raquel Schulze).
3. Estudo de Caso
Aqui pretende-se indicar um aplicação existente e como ela se adaptaria
para o problema do "Curso sob medida" e como poderia se beneficiar das
estratégias propostas na Seção 2.
4. Conclusões
5. Bibliografia
PS: Gostaríamos de mais informações a respeito de:
- Wallets (qual a diferença entre Wallets and Cookies?);
- Agentes Inteligentes (não entendemos onde eles poderiam se encaixar).
Sílvio e Chaim
From: "Flavia Torres"
Newsgroups: feec.posgrad.IA368F
Subject: Re: Estrutura do Relatório Final - HTTP
Date: Thu, 9 Apr 1998 13:55:09 -0300
Organization: Faculdade de Engenharia Eletrica e da Computacao - UNICAMP
Pessoal,
Eu acho que existe uma boa diferença entre cookies e Wallets. As Wallets
são plug-ins em ActiveX ou JavaScript. Sua interface com o usuário é através
de páginas HTML. Os cookies são linhas contendo um número limitado de dados
dentro de um arquivo com vários outros cookies.
Assim como os cookies, nas wallets também existe o risco dos dados serem
apagados, pois esses se encontram na máquina do cliente. Mas os cookies
armazenam informações sobre o browser que está conectado e não exatamente
sobre a pessoa que está acessando. Se um outro usuário sentar na minha
máquina e usar o meu browser, pelo cookie, a identificação será referente a
mim, "proprietário da máquina". Com o uso das Wallets, cada usuário pode ter
sua própria carteira, mesmo que vários deles estejam usando a mesma máquina.
Informações podem ser encontradas no site da Microsoft:
http://www.microsoft.com/ie/ie40/features/?/ie/ie40/features/sec-mswallet.ht
m Apesar da explicação ser voltada para o comércio eletrônico da para ter
uma idéia geral do funcionamento e mecanismos de uma carteira eletrônica.
Tenho mais material sobre isso, mas como tive que formatar meu HD tenho
muita coisa compactada espalhada pelos servidores e está difícil organizar
tudo novamente. Se for preciso posso tentar localizar.
Por favor, corrijam-me se estiver errada.
Flávia
From: Adriana Delfino dos Santos
Newsgroups: feec.posgrad.IA368F
Subject: P-HTTP - comentarios
Date: Mon, 13 Apr 1998 13:22:58 -0300
Organization: CNPTIA/EMBRAPA
Pessoal,
Pelos relatórios dos grupos, estão divergentes as opiniões sobre
o P-HTTP ser ou não uma alternativa ao Dynamic Argument Embedding(DAE).
Utilizando-se P-HTTP, em geral, consegue-se otimizar o tempo de
transação para seqüência de transações para o mesmo servidor,
principalmente quando uma página contém imagens embutidas. E,
utilizando-se o DAE, consegue-se preservar o estado da aplicação.
Na minha opinião, P-HTTP não é uma alternativa ao DAE, pois os dois
métodos atendem diferentes propósitos. Por isso, ambos os métodos
poderiam ser usados pelo servidor HTTP que está sendo especificado.
Minha conclusão está no caminho certo?
Adriana
From: Marcos Lordello Chaim
Newsgroups: feec.posgrad.IA368F
Subject: Re: P-HTTP - comentarios
Date: Mon, 13 Apr 1998 13:34:40 -0300
Organization: Faculdade de Engenharia Eletrica e da Computacao - UNICAMP
Pessoal,
Minha opiniao e' a mesma da Adriana (por acaso nos estavamos
no mesmo grupo!). No relatorio final, fazemos a diferenca
entre manutencao do estado da "conexao" e manutencao do
estado da "aplicacao", e assumimos que P-HTTP nao e' uma
alternativa para a manutencao do estado das aplicacoes.
Se alguem possui um argumento contra isto, por favor,
manifeste-se.
Chaim
From: "Silvio"
Newsgroups: feec.posgrad.IA368F
Subject: Versão intermediária: Protocolos Na World Wide Web
Date: 13 Apr 1998 22:52:53 GMT
Organization: Faculdade de Engenharia Eletrica e da Computacao - UNICAMP
Pessoal,
Esta é versão preliminar do relatório final sobre Protocolos na
world Wide Web. Por favor, leiam e critequem.
Chaim e Silvio.
----------------------
Protocolos na World Wide Web
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].
A última abordagem é a Inclusão Dinâmica de Argumentos (DAE – Dynamic
Argument Embedding). O 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 enfoque
(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.
4. 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 um única alternativa – cookies;
já em relação à segunda, há duas alternativas – formulários HTML e DAE.
4.1 Estratégias baseadas no Cliente
4.2 Estratégias baseadas no Servidor
a) Formulário HTML
b) DAE
A Inclusão Dinâmica de Argumentos (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, daí o nome
Inclusão (Embedding). Estes argumentos são as variáveis de estado que
definem o andamento da Aula Virtual. A inclusão é dinâmica porque,
semelhantemente aos formulários HTML, 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 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 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 [Iyengar97, Delfino98]:
passo 1: Aluno invoca programa CGI que verifica identificação.
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 base de dados e retornará como saída um documento
HTML e as variáveis de estado que constituem o histórico. As informações
básicas do histórico são o curso e nível do aluno, mas podem incluir outras
informações como documentos consultados.
passo 2: programa CGI passa saída de seu processamento e as variáveis de
estado para embed1.
Embed1 modifica saída do programa CGI, alterando as ligação 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 (valor igual a "EE" representando
Engenharia Elétrica) e nível (valor igual a "grad" de graduação), 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&comma=1&curso=EE&nivel=grad">
passo 3: saída de embed1 é enviada para o cliente.
Documento HTML modificado é enviado para o cliente e apresentada ao aluno.
passo 4: aluno seleciona ligação exercício.
O aluno seleciona a ligação que provoca a execução de embed2 com os
parâmetros no=1, curso=EE e nivel=grad.
passo 5: embed2 traz arquivo HTML ou invoca programa CGI.
Como o primeiro argumento para embed2 é um programa CGI (exercício), então
no=1 é o 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 3.
5. 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;
Quando a estrutura do material didático, tem-se:
Curso montados como documentos multimídia;
Curso cooperativo;
Curso com palestras;
Curso com ou sem provas;
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 4. 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" receberá as instruções finais, juntamente com a
"password" e um programa de "e-mail" especialmente projetado para permitir
a realização de trabalhos cooperativos.
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". Observe que as notas do aluno ficam armazenados
no servidor.
Este curso especificamente abrange todos os 7 itens listados anteriormente.
Ele 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 são palestras transmitidas pela internet em datas
específicas. Após um conjunto de aulas e palestras, o aluno está habilitado
a fazer um exame.
Referências biliográ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.
[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.
[WLH 98] http://www.utexas.edu/world/lecture
From: Adriana Delfino dos Santos
Newsgroups: feec.posgrad.IA368F
Subject: Re: Versão intermediária: Protocolos Na World Wide Web
Date: Wed, 15 Apr 1998 18:12:06 -0300
Organization: CNPTIA/EMBRAPA
Silvio e Chaim,
Gostei da linguagem (simples, clara e objetiva) utilizada para descrever os
conceitos.
Sobre esta versão preliminar, segue abaixo alguns comentários.
Adriana
Silvio escreveu:
> Protocolos na World Wide Web
>
> 1. Introdução
>
>
> 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.
>
A numeração das seções do documento não estão de acordo com a numeração citada neste
trecho da introdução.
> 2. Cenário de uma aplicação educacional
> (...)
> 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 enfoque
> (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.
>
>
Este "histórico" é definido na seção 2, mas não é discutido na seção 3 (estratégias
parasolução do problema). Na minha opinião poderia-se falar um pouco sobre ele, talvez
na propria seção 3.
Se a questão do histórico for tratada nos itens que não constavam da versão
preliminar,
por favor, desconsidere minha observação.
> O algoritmo para preservação do estado, para a aplicação Aula Virtual
> possui os seguintes passos [Iyengar97, Delfino98]:
>
para não "apanhar" do esposo, meu sobrenome oficial é Santos, A. D. e não Delfino,
A.S.
> 5. Estudo de Caso
> (...)
> Quando o sistema acusar o
> pagamento, um "e-mail" receberá as instruções finais (...)
>
>
Não entendi esta funcionalidade. Talvez o texto precise ser mais claro.
> [Delfino98] Delfino, A. S., Orosz, J. C., Picarelli, J. E.,
>
Corrigindo: Santos, A.D.
Subject: Novos Protocolos na Web
Date: Tue, 14 Apr 1998 12:41:49 -0300
From: Firmiano Ramos Perlingeiro
Organization: Faculdade de Engenharia Eletrica e da Computacao - UNICAMP
Newsgroups: feec.posgrad.IA368F
Prezados Colegas:
Meu trabalho no seminario sera novos protocolos na Web, estou fazendo
uma pesquisa bibliografica sobre o assunto.
Caso alguem conheca alguma referencia sobre o tema, ou um link na Web,
ficarei grato.
Firmiano
ricarte@dca.fee.unicamp.br
Last modified: Thu Apr 23 12:54:54 BRA 1998