1. Introdução

2. Mecanismos de programação na Web

3. Cenário

4. Mecanismos de programação x funcionalidades

4.1 Situação 1

4.2 Situação 2

4.3 Situação 3

4.4 Situação 4

5. Conclusões

5. Comentário dos revisores

Referências

Este documento apresenta uma análise do tema Programação na Web, discutido em plenária no dia 16/04/1998, sob o aspecto de Tecnologias da Infraestrutura de Informação em Ambientes Colaborativos de Ensino, na disciplina Tópicos em Engenharia de Computação V, curso de pós-graduação da Faculdade de Engenharia Elétrica e de Computação da UNICAMP.

A motivação da discussão neste tema foi a proposta da aplicação Curso sob medida e Prova virtual [Granja98][Dagnone98] e as possíveis situações em relação ao local (sala de aula presencial ou virtual) e ao tipo de comunicação entre os participantes (síncrona ou assíncrona) [Fluckger95].

Quanto à programação na Web, estudou-se alguns dos mecanismos atualmente disponíveis, e baseando-se neles, analisou-se a adequação dos mesmos para cada funcionalidade dentro das situações definidas. No final do documento são apresentadas as conclusões sobre a utilização dos mecanismos como solução tecnológica para as diversas situações da aplicação.

A possibilidade de criar dinamicamente páginas HTML na Web, através de programas executados no servidor ou no cliente é denominada programação Web [Raposo98].

As alternativas de programas executados no servidor considerados por este documento são: Common Gateway Interface (CGI) [WDVL97], [Brenner96], Dynamic WebPages in Java (Servlet) [Marchal97], Castanet [Venners96] e no cliente são: Java applets [Campione98] e Java Script [NetCom97].

O Common Gateway Interface (CGI) permite interatividade entre o cliente e o servidor através da World Wide Web (WWW) via Hyper Text Transfer Protocol (HTTP). CGI é um padrão para que programas externos possam interagir com servidores de informação, determinando a maneira como os dados devem ser passados ao programa (a maioria é passada através de variáveis de ambiente) e a maneira que os programas devem gerar a saída para que eles sejam entendidos pelo servidor Web e pelo cliente [Brenner96],[WDLV97]. Quando um usuário seleciona no cliente uma URL que referencia um programa CGI:

1. servidor recebe a requisição e identifica a necessidade de rodar um programa através da extensão do arquivo (.cgi) ou sua localização no servidor (cgi-bin/);
2. servidor inicia o programa e envia para ele as informaçoes em forma de variáveis de ambiente e entrada padrão;
3. o programa processa as informações, incluindo acesso a repositórios de informação ou quaisquer sistema de informação e produz uma saída, incluindo um header para informar ao servidor o tipo de informação que esta sendo produzida;
4. o header e os dados são enviados diretamente ao servidor, que repassa as informações para o cliente em formato interpretável por browsers Web.

O principal benefício do CGI é possibilitar ao cliente buscar a informação de forma transparente e uniforme através da Web [SilveiraJr98] e em real time.

O CGI não impõe restrição quanto ao tipo de linguagem utilizada. Qualquer linguagem pode ser utilizada na criação de programas CGI, desde que o padrão seja seguido e seja possível gerar um executável. A linguagem Perl é a mais utilizada [Brenner96], mas hoje em dia Java também começa a ser muito utilizada devido à sua popularidade [Durante97].

Apesar da transparência e uniformidade de busca à informação através da Web, o CGI possui problemas de ineficiências ocasionados pelo alto overhead em servidores com muito acesso, já que neste caso para cada requisição uma cópia do programa é lançada e disparada. A JavaSoft tem proposto o Java Servlets como padrão alternativo e eficiente ao CGI [Marchal97]. A Application Program Interface (API) Servlet é uma Extensão Java. Extensões Java são pacotes-padrão opcionais. Por serem pacotes-padrão, elas são endossadas pela JavaSoft e amplamente suportadas na indústria. Por serem opcionais, elas não estão disponíveis em toda plataforma.

Um servlet é uma classe Java que implementa uma interface para análise (coleta de valores dos campos) e execução (por exemplo, pesquisa em base de dados, execução de aplicativos) de informação e prepara uma resposta para o cliente. Por serem escritos em Java os servlets podem fazer uso dos recursos (acesso aos Java packages e JavaBeans disponíveis no mercado) e de características de segurança herdadas da linguagem Java; são portáveis pela própria natureza da linguagem e apresentam melhor desempenho do que o CGI (uso de threads para processamento de requisições simultâneas e a exclusão de linguagens puramente interpretadas) [SilveiraJr98].

Um Java Applet é um programa em linguagem Java que pode ser incluído em uma página HTML, assim como é feito com uma imagem. Java Applets são transmitidos para o cliente e executados no mesmo, a cada vez que a página é acessada=2E Eles são transmitidos no formato byte-codes (conjunto de instruções pré-compiladas, semelhantes ao código de máquina, mas sem serem específicas de qualquer processador) que são verificados na máquina do cliente, garantindo a segurança do código recebido.

Para aplicações pequenas e simples, a utilização de applets é recomendada. Para aplicações maiores que demandam espaço em disco, memória, grande processamento local, esbarra-se em retrições de segurança dos applets: applets transmitidos para o cliente através da rede não permitem ler ou escrever arquivos no disco local [Venners96]. Há vários problemas com applets. Um problema associado aos applets é a demora no tempo de carregamento quando a página é acessada, ou seja a transmissão é feita sob demanda. Esse problema é agravado à medida em que os applets aumentam seu tamanho [Venners96].

Para compensar estes problemas relativos à transferência de applets, a Marimba Inc., aprensentou em dezembro de 1996 uma versão beta do produto chamado Castanet [Venners96]. Castanet oferece uma maneira de distribuir uma hierarquia de diretório e arquivos do servidor para o cliente. Programas Java transmitidos como canais (uma hierarquia de diretório e arquivos) não são limitados ao tamanho do applet e consequentemente, não tem problemas com desempenho, pois são transmitidos antes da demanda.

Estando um cliente com programas Java transmitidos como canais, ele envia para o servidor a requisição de atualização de canal. A freqüência da requisição é particular para cada canal, e foi estabelecida pelo desenvolvedor da aplicação. O servidor não mantém nenhum estado que diga qual a versão do canal corrente no cliente. A requisição traz informações que identificam a versão dos arquivos e diretórios correntes no disco local, e a partir disto, o servidor faz uma comparação com a sua versão. Detectando diferenças, o servidor envia uma cópia para o canal do cliente. A atualização do cliente ocorre em unidades de arquivo. Este processo é chamado de atualização diferencial.

Quanto ao JavaScript, ele tem como objetivo permitir ao usuário trabalhar o dinamismo nas suas páginas sem precisar conhecer a linguagem Java, pois está disponível um subconjunto de recursos desta linguagem [NetCom97].  O programa escrito em JavaScript é executado no cliente sem ser trazido ao servidor. Ele está escrito na própria página HTML e o browser deve ter capacidade de interpretar tal programa. O uso de JavaScript não é vantajoso por possuir funcionalidades limitadas ao subconjunto de recursos de Java. Outra vantagem é não exigir muita capacidade de processamento do cliente quando comparado à applets.

Os vários mecanismos de programação na Web apresentados nesta seção, serão considerados pelas próximas seções.

Considerando a proposta da aplicação Curso sob medida e prova virtual, resumiu-se o cenário em:

Na hora da aula, estudante vai a uma sala de aula presencial [Blaitt98] na UMTE onde professor utiliza os mais avançados recursos computacionais para ministrar sua aula sobre o tópico para alunos deste curso.

Na discussão do grupo, considerou-se um ambiente em que:

• cada aluno possui um computador como cliente;
• o instrutor também tem um computador e age como cliente com perfil diferente do aluno;
• o instrutor e os alunos estão na mesma sala e em rede;
• o servidor da aula de Física é o da UMTE.

Foram identificadas as seguintes funcionalidades:

1. Apresentação do problema com recursos multimídia: "Por quê a Lua não cai na Terra?";
2. Aluno "descobre" as forças envolvidas através de um simulador (teoria é apresentada aos poucos...);
3. Busca de dados complementares, para resolver um problema (na Web, com os colegas ou com o instrutor); exemplos: massa da Lua/Terra e distância Terra/Lua;
4. Apresentação para todos de um resultado parcial obtido por um aluno (exemplo; contra-exemplo...)

Foram especificados os sequintes mecanismos para utilização na implementação da aplicação:

• Applets para rodar o simulador do lado do cliente;
• Castanet para otimizar a transferência dos applets no cliente;
• No servidor teria-se Servlets para preservar o estado da aplicação, melhorar o tempo de processamento do servidor (overhead) e gerar dinamicamente páginas HTML.

Durante a discussão plenária, observou-se que a interpretação da Situação 1 pelo grupo foi errônea. Por isso, apresentamos uma nova interpretação, considerando que o instrutor dispõe dos seguintes recursos para ministrar a aula:

• sala de aula convencional;
• quadro negro ;
• tela para projeção;
• um microcomputador conectado à rede da UMTE;
• equipamento de projeção conectado ao microcomputador;
• material didático da aula está disponível no servidor da UMTE de acordo com o perfil do usuário (neste caso, perfil igual a "instrutor de aula de física na Engenharia Eletrica"); lembramos que este material utiliza recursos hipermídia.

Devemos observar que o instrutor opera o recurso computacional e conduz a aula. Ele pode utilizar técnicas pedagógicas baseadas nos conceitos do Construtivismo [Netzke98], estimulando os alunos a construírem o conhecimento sobre o assunto. A utilização de um simulador de forças é um recurso que auxilia na ilustração dos conceitos.

Consideramos que na composição do material didático para o perfil "instrutor de aula de física na Engenharia Eletrica" estes conceitos também foram utilizados porque os recursos hipermídia podem ser organizados de forma a contribuir para isto.

A seguir, apresentamos as funcionalidades identificadas no ambiente citado anteriormente e o(s) mecanismo(s) de programação que poderia ser utilizado para implementação.

1. O instrutor ativa a aplicação Curso Sob Medida e identifica-se.

O computador operado pelo instrutor é o cliente do servidor da UMTE, e Java Applets podem ser utilizados para autenticação do usuário. No servidor, pode-se ter Servlets para solicitar consultas ao banco de dados de atores cadastrados e recuperar o perfil do usuário. Este Servlet precisa ser capaz de preservar este perfil do usuário.

2. A aplicação recupera o material didático para o perfil "instrutor de aula de física na Engenharia Eletrica" e este material é projetado na tela.

Se o instrutor é um ator cadastrado e o servidor conseguiu recuperar o seu perfil, o servidor passa a recuperar o material didádico para este perfil e o envia para o cliente.

Considerarmos que a UMTE irá distribuir o material didático para todas as disciplinas comuns a vários cursos e que o horário das aulas pode coincidir, há possibilidade de ocorrer uma sobrecarga do servidor. Portanto o uso de programa CGI poderia comprometer o desempenho da apresentação da aula. Neste caso, como alternativa, podemos usar Servlets.

Outro problema surge se a atualização do material estiver sendo feita concorrentemente a uma aula, o conteúdo do material pode estar desatualizado. O mecanismo oferecido pelo Castanet pode amenizar este problema, atualizando o material que está no cliente. Observar que o cliente está configurado para solicitar periodicamente ao servidor a verificação de alteração de versão do material.

3. Num detrminado ponto do material, o instrutor apresenta para os alunos a questão motivadora "Por que a Lua não cai na Terra?", seguida de debate em forma de brainstorm.

Neste caso, nenhum recurso computacional é requerido.

4. O instrutor seleciona o simulador de forças que possui recursos multimídia.

A utilização de Java Applets para implementação do simulador oferece diversos recursos de interface com usuário não disponíveis em HTML e também permite o processamento no cliente. Se o applet do simulador for grande, o tempo de transferência pode não ser o desejável. O mecanismo oferecido pelo Castanet pode solucionar este problema, transferindo para o cliente uma única vez. Se houver alteração da versão no servidor, no próximo pedido de verificação que o cliente faz ao servidor, a versão do cliente será atualizada.

5. O instrutor insere valores para os parâmetros do simulador, segundo sugestões dos alunos.

Os Java Applets oferecem recursos para interface com o usuário mais avançados que os formulários HTLM, por isso a opção seria por eles.

6. O simulador processa estes valores e apresenta o resultado, com isso o instrutor consegue, de forma participativa e ilustrativa, que os alunos fixem os conceitos corretamente.

Os Java Applets executam o simulador no cliente, retirando do servidor esta carga de processamento. Neste caso, o seu uso seria o mais o mais adequado.

7. O instrutor pode, em qualquer ponto do material, inserir anotações sobre a aula.

Na hora da aula, estudante conecta-se por computador a um servidor da UMTE ao longo dos 100 minutos de duração da aula sobre o tópico, usando mecanismos adequados ao acompanhamento da apresentação e eventuais interações.

Na discussão do grupo levantou-se a hipótese de duas soluções.

A primeira solução representa o seguinte ambiente:

• aluno assistindo aula: o material estaria disponível para o aluno que, dentro do horário previsto, poderia "assistir" à aula, quando consultaria o material e interpelaria o professor.
• professor (instrutor): estaria disponível durante os 100 minutos da aula para tirar eventuais dúvidas dos alunos, bem como acompanharia o andamento das atividades dos alunos.

Seriam necessárias as ferramentas:

1. CHAT / Mecanismo de visualização do instrutor (individual ou geral)
2. Mecanismos de respostas automático (respostas realizadas pela aplicação)

1. Aplicação para disponibilização das aulas ( textos, figuras, vídeos, som, imagem real time, etc)
2. Ferramenta de Acompanhamento

Os mecanismos de programação propostos para cada ferramenta são:

• ferramentas (a), (c) e (d): Applets Java e Castanet;
• ferramentas (b) e (d): Servlet / Java;

O tempo de duração da aula neste ambiente é o tempo que o instrutor estaria disponível para tirar dúvidas (100 min. previstos). Após este tempo {excedido} o aluno não poderia interagir diretamente como o instrutor (sincronamente).

O tempo restante de aula é informado para o aluno através de uma applet Java. Quando o tempo de aula termina esta applet é encarregada de informar ao aluno que a aula terminou.

Depois a identificação do usuário pela aplicação Curso sob Medida, todos os participantes na ferramenta de comunicação (chat ou qualquer outro mecanismo) são conectados automaticamente.

Para o perfil de usuário igual a instrutor de aula síncrona e remota de Física para Engenharia Elétrica, a aplicação habilita os recursos: disparar cronômetro de controle de tempo de aula e ferramenta de acompanhamento (e.g.: acompanhar o histórico de navegação dos alunos).

Os questionamentos seriam dirigidos ao instrutor através da ferramenta de comunicação. As respostas do instrutor ou de outros alunos também utilizariam os recursos desta ferramenta.

Através da aplicação, aos participantes do curso está disponível uma ferramenta que permite ao usuário fazer questionamentos. Esta ferramente consulta uma base de conhecimentos e responde automaticamente, sem intervenção do instrutor=2E

Neste ambiente identificamos as funcionalidades que seriam suportadas pelas ferramentas acima e comentamos os mecanismos de programação que podem ser utilizados:

1. alunos e instrutor acessam a aplicação Curso sob Medida e identificam-se;

Java Applets podem ser utilizados para autenticação do usuário. No servidor, pode-se ter Servlets para solicitar consultas ao banco de dados de atores cadastrados e recuperar o perfil do usuário. Este Servlet precisa ser capaz de preservar este perfil do usuário. Outra alternativa seria o uso de formulários HTML e programas CGI com mecanismos de preservação do estado da aplicação. Para se manter o mesmo paradigma no desenvolvimento da aplicação, propomos o uso de Java Applets e Servlets.

2. instrutor dispara o cronômetro para início da aula;

Será necessário Java Applet no cliente "instrutor" para solicitar ao servidor "disparar o cronômetro". Isto significa que o Servlet deve executar um programa que atualiza um banco de dados (ou arquivo) a cada minuto. Utilizando os recursos do Castanet, os clientes solicitam (periodicamente) a verificação de alteração de versão do cronômetro e automaticamente são atualizados.

3. aluno acessa material didático, de acordo com o seu perfil;

Como o material pode ser composto de applets de tamanho grande (por exemplo um simulador) e que podem ser buscados em vários pontos do material, o uso de Castanet pode melhorar o tempo de transferência deste material, garantir que o usuário está acompanhando a versão mais recente do material. O uso de Servlet no servidor melhora o tempo de recuperação do material, se o servidor da UMTE é muito acessado.

4. aplicaçao mostra continuamente para o aluno o valor do cronômetro de tempo de aula;

O uso de Java applet que consulta uma página (arquivo) no servidor através dos mecanismos do Castanet terá sua versão sempre atualizada.

5. aluno insere questão no mecanismo de comunicação;

O uso de Java applet que insere uma questão numa página (arquivo) no servidor que armazena questões e respostas. Como todos os outros participantes também têm um Java applet executando que mostra esta mesma página, com os mecanismos do Catanet, frequentemente estará sendo atualizada (via solicitação do cliente da verificação de alteração de versão, numa freqüência pré-definida). Isto possibilita a comunicação através de um mecanismo bem simples. Pode-se enriquecer este mecanismos se pensarmos em mecanismos de visulização dos participantes (câmeras de vídeo) e as questões sendo feitas por voz (microfone e alto-falantes)=2E

6. instrutor ou outro(s) aluno(s) responde(m) questão;

A situação é similar ao item (e).

7. aluno coloca questão no mecanismo de resposta automático e aguarda resposta;

A segunda solução representa o seguinte ambiente:

• aula: diferentemente da solução anterior, a aula é iniciada e apresentada para os alunos, sendo que estes não podem interrompê-la ou mudar a ordem de apresentação dos tópicos. O material e a velocidade de apresentação desta são controlados pelo instrutor. O aluno pode questionar o instrutor a respeito de qualquer questão e se este entender que é necessário discutir o assunto com os alunos, ele pode parar a aula e fazer algum comentário a respeito da questão levantada.
• professor: pode apresentar a aula (expositiva) via algum recurso de vídeo conferência ou pode ter preparado algum mateiral anteriormente e estar apresentando-o com se fosse um filme ou seqüência de slides. Também responde as questões que são apresentadas pelos alunos durante a aula.

As seguintes ferramentas são necessárias:

1. CHAT / Mecanismo de visualização do instrutor (individual ou geral)
2. Aplicação para disponibilização das aulas ( textos, figuras, vídeos, som, imagem real time, etc)

Os mecanismos de programação propostos para as ferramenta são feitos em Java.

 Aqui o instrutor controla o ritmo da aula bem com o tempo de duração, encerrando a aula quando o tempo terminar (respeitando os 100 min.).

A aplicação Curso sob Medida, após a identificação do usuário, conecta automaticamente todos os participantes na ferramenta de comunicação (chat ou qualquer outro mecanismo).

Para o perfil de usuário igual a instrutor de aula síncrona e remota de Física para Engenharia Elétrica, a aplicação habilita o recurso de disparar cronômetro de controle de tempo de aula

Os questionamentos são dirigidos ao instrutor através da ferramenta de comunicação, assim as respostas do instrutor ou de outros alunos.

O instrutor é quem controla a apresentação do material.

Neste ambiente identificamos as funcionalidades que seriam suportadas pelas ferramentas acima e comentamos os mecanismos de programação que podem ser utilizados:

1. alunos e instrutor acessam a aplicação Curso sob Medida e identificam-se;

Similar à Solução 1, item (a).

2. instrutor dispara o cronômetro para início da aula;

Similar à Solução 1, item (b).

3. intrutor acessa material didático, de acordo com o seu perfil e este material é apresentado para os alunos participantes;

O Servlet quando recupera o material didático para o perfil do instrutor, reponde para o cliente "instrutor" e armazena uma cópia deste material recuperado no servidor, modificando-o desabilitando todos recursos de navegação contidos neste material. O cliente "aluno" está executando uma versão deste Java applet do material.

O uso de Castanet garante que o usuário está acompanhando as páginas que o instrutor está posicionado e as alterações que o Servlet fez garantem que o aluno não navega no material.

4. aplicaçao mostra continuamente para o aluno o valor do cronômetro de tempo de aula;

Similar à Solução 1, item (d).

5. aluno insere questão no mecanismo de comunicação;

Similar à Solução 1, item (e).

6. instrutor ou outro(s) aluno(s) responde(m) questão;

O estudante tem a liberdade de cobrir o material relativo a este tópico no momento que lhe for mais oportuno, buscando a informação do servidor de material da UMTE.

Na discussão em grupo, identificou-se as seguintes funcionalidades:

1. identificar aluno, para recuperar seu perfil (curso, histórico, tópico corrente);
2. seleção do material de acordo com o perfil do aluno;
3. composição e disponibilização do material adequado ao aluno;
4. assume-se que o material é dividido em módulos e que ao final de cada módulo é feito um mini-teste para permitir ao sistema definir novos materiais a serem eventualmente disponibilizados ao aluno;
5. manter o acompanhamento do acesso do aluno ao material, bem como de anotações e comentários deste.

Relacionou-se os seguintes Mecanismos Genéricos de Programação:

1. Funcionalidade (a): mecanismos comuns de consulta a um servidor de banco de dados em ambientes distribuídos;
2. Funcionalidade (b): mecanismos de consulta a banco de dados com métodos de IA e tomada de decisão, para definir o conjunto de materiais mais adequado que deverá ser disponibilizado ao aluno. Este conjunto será enviado ao computador do aluno (cliente) para viabilizar as funcionalidades (c), (d) e (e);
3. Funcionalidades (c,d,e): Recebido o conjunto de materiais, a composição destes e posterior apresentação ao aluno é processada localmente no computador do aluno. Assim, é necessário um mecanismo de programação que permita o controle de migração de objetos e da consistência entre objetos no servidor e no cliente (controle de versões). Mecanismos para persistência destes objetos no cliente também são desejáveis. Tais mecanismos estão presentes, em maior ou menor grau, em linguagens de programação orientadas a objetos ou em linguagens para manipulação de BDOO (banco de dados orientados a objetos).

Nas categorias 1, 2 e 3 da seção anterior, podemos escolher as seguintes tecnologias WEB que podem ser usadas como mecanismos de programação:

1. CGI. A funcionalidade (a) é simples e não exige poder de processamento maior daquele oferecido por scripts CGI;
2. SERVLETS. A ativação de uma consulta em um BD do servidor, em que deverão ser utilizadas técnicas não-convencionais como IA, implica em um mecanismo mais poderoso que CGI. O mecanismo de Servlets surge como solução neste caso, pois permite um processamento mais otimizado e, por ser baseado em JAVA, uma linguagem orientada a objetos, pode ser mais adequada a integração com ferramentas de tomada de decisão;
3. CASTANET + SERVLETS. O controle de versões entre servidor e cliente e a possibilidade de alteração de dados localmente (gravação em arquivos ou BD's) nos leva a concluir que estas tecnoligias WEB são mais adequadas para implementar as funcionalidades (c), (d) e (e).

Concluiu-se que Applets JAVA e quaisquer soluções baseadas nestes parecem ser uma boa alternativa para solucionar situações em que o processamento de dados pelo cliente em um ambiente WEB é necessário. Falta no entanto, um mecanismo adequado e padronizado para implementar persistência de objetos do lado do cliente, consistentes com os objetos do lado do servidor.

Nada a acrescentar na análise desta situação.

Estudante conecta-se ao servidor da UMTE manifestando seu interesse no tópico, sendo a informação entregue posteriomente pelo servidor quando disponível ou atualizada.

 a. Conteúdo e infraestrutura já disponíveis no servidor

 b. Funcionalidades a serem implementadas e suas justificativas 

1. Permitir ao aluno escolher um tópico que ainda não está disponível, de modo que o aluno possa receber automaticamente este documento assim que o mesmo estiver disponível.
2. Permitir ao aluno obter informações sobre as alteracões em documento que ele tem localmente. Estas alterações poderiam ser pedidas em relação a um determinada versão de documento armazenada no servidor. Por exemplo: o que foi alterado neste documento que eu tenho localmente até a semana passada. Não em relação ao mais atual, mas em relação ao da semana passada.
3. Permitir ao aluno configurar o mecanismo de atualização de documentos realizada por um mecanismo como o Castanet. Explicando, o Castanet irá atualizar na área do aluno todas as páginas referentes ao tópico que o aluno já abordou, mesmo que o aluno náo tenha percorrido todas as páginas do topico. Talvez fosse interessante se o aluno pudesse selecionar quais destas páginas deveriam ser atualizadas, pois talvez algumas já lidas não lhe interessam,ou senão páginas que mudam praticamente a cada novo acesso, logo realmente precisam ser tomadas sempre do servidor.

c. Implementação da funcionalidade

Nada a acrescentar na análise desta situação.

O presente documento apresentou proposta de implementação de um cenário envolvendo Tecnologia Educacional que poderia ocorrer na UMTE.

As propostas apresentadas utilizariam uma combinação apropriada dos mecanismos de Programação na Web Common Gateway Interface (CGI), Dynamic WebPages in Java (Servlet), Castanet, Java applets e Java Script.

Pode-se dizer que houve um concenso entre os participantes em relação ao uso de Servlets, em situações em que o servidor é muito solicitado e também em situações que necessitam de recursos de programação mais avançados, como por exemplo inteligência artificial. Programas CGI seriam utilizados em situações em que os serviços requeridos fossem acessos a banco de dados relacionais ou em que o servidor não é muito acessado. Do lado do cliente, situações que requerem recursos de interface com o usuário básicos sem necessidade de muito processamento, foram sugeridos os formulários HTML. Em situações que requeriam mais processamento e/ou recursos de interface com o usuário mais avançados (e.g.: simulador de forças), a opção foi por Java Applets. Para melhorar o desempenho de transferência de applets do servidor para o cliente e/ou manter os applets no cliente atualizados, o uso de Castanet foi proposto.

O uso de JavaScript não proposto em nenhuma situação devido às suas limitações de recursos, pois é um subconjunto da linguagem Java, e à necessidade de utilizar um browser Web específico, que saiba interpretá-lo.

 Visualizando as quatro situações propostas como um possível "Ciclo de Vida" de uma aula utilizando infra-estrutura computacional, podemos propor como trabalho futuro, integração destes quatro pacotes para dar suporte as etapas necessárias para o aprendizado de um determinado tema, dentro da abordagem construtivista [Netzke98] que poderia ser: a) instrutor apresenta tema aos alunos; b) instrutor e aluno trabalham tema; c) aluno adequa tema as suas necessidades, seja conteúdo ou momento de aprendizado; d) aluno aprofunda seus conhecimentos de acordo com seus interesses, permitindo assim, o atendimento do aluno mais personalizado.

1. Comentários dos revisões

Gostaríamos de anexar aqui algumas observações - algumas discordâncias - que não pudemos alterar no texto sem mudar toda sua argumentação e estrutura. Estas questões são referentes a: importantes problemas com applets não citados, uma desvalorização excessiva e gratuita do uso de CGI e propostas de uso duvidoso e/ou exagerado de servlets.

Há pelo menos três problemas com uso de applets. Primeiro há a demora na transmissão de um applet grande - já citada. A segundo é uma dificuldade causada pelas inúmeras versões do JDK da Sun, pois pode ocorrer uma diferença entre a versão do JDK utilizado na programação do applet e a versão JDK do browser. Quando a versão do JDK browser for mais antiga, algumas classes do package Java poderão não ser encontradas, de forma que o applet não será executado. Ou seja, applets podem ser uma bela solução na especificação e implementação, mas podem deixar complicados problemas para os usuários, principalmente quando se lembra que estes usuários poderão estar a milhares de quilômetros (uma solução é instalar outro browser). É bom lembrar que o uso da recente versão JDK 1.2 Beta poderá complicar ainda mais o problema. Por último, como o applet é executado no cliente, pode ocorrer problemas relacionado com a capacidade de processamento em máquinas "antigas", como microcomputadores 486.

A desvalorização excessiva do CGI aparece tanto pelo exposto no parágrafo acima quanto pelo uso indevido de servlet mostrado abaixo. CGI continuará por muito tempo como uma solução para a baixa capacidade de processamento dos microcomputadores mais antigos. Como o processamento está centralizado no servidor, basta uma máquina central de maior porte para fazer todo o esquema funcionar (cliente servidor), pois se não há clientes suficientemente poderosos, não há como distribuir o processamento. Além disso, provavelmente ficará mais barato comprar uma grande estação de trabalho do que trocar todo um parque de milhares de microcomputadores obsoletos.

Quanto ao uso de servlets, apesar do nossa relativa experiência com o assunto, ficou um tanto confuso a referência constante ao servlet como uma forma eficiente e alternativa ao CGI no acesso a banco de dados. Não ficou claro porque aplicações Java puro podem muito bem fazer esse acesso de pelo menos duas formas. Através de uma ponte, como é o acesso ao mSQL e ODBC, ou por sockets. Por motivos de segurança estes tipos de conexões só podem ser realizadas através de um programa Java puro. Este pode ser agregado em uma applet se for necessário, mas ambos devem ser provenientes do mesmo servidor onde está a base de dados. Entretanto, até onde vimos na referência bibliográfica [Benoît], o servlet foi criado para trabalhar mais especificamente com geração dinâmica de páginas HTML, ai sim, substituindo CGI, não para acesso a base de dados.

[Benoît] Marchal.Dynamic WebPages in Java: Servlets, Digital Cat's Java Resource Center, November 1997. http://www.javacats.com/US/Articles/servlet.html

[Blaitt98] Blaitt, J., Cardieri, A. CSCW - Suported Cooperative Work, Relatório Final http://www.dca.fee.unicamp.br/~ricarte/Courses/IA368/ls98/Cscw/final.html

[Brenner96] Brenner, S. E., Aoki, E. Introduction to CGI/Pearl, Prelude to CGI, Chapter1, M&T Books, 1996

[Campione98] Campione, M., Walrath, K. Overview of Applets in The Java Tutorial: Object-Oriented Programming for the Internet, 2^nd Ed., ja.soft.com, March 1998

[Dagnone98] Dagnone, C.A.F., Morandini, M., Pimenta, M.F., Torres, M.F=2EC.F Formatos de documentos na Web - XML, http://www.dca.fee.unicamp.br/~ricarte/Courses/IA368/ls98/Xml/c3.html

[Durante97] P. L. Durante. Write CGI Programs in Java. JavaWorld, 2(1) - Jan. 1997. http://www.javaworld.com/javaworld/jw-01-1997/jw-01-cgiscripts.html

[Fluckiger95] Fluckiger, F. Understand networked multimedia: Applications and technology, Capítulo 6 "Taxonomy of multmedia applications", pp.109-121, prentice Hall, 1995

[Granja98] Granja, I., Orosz, J.C.,Picarelli, J.E., Soares, M.V.,Concilio, R. XML, "Diferentes visões de um mesmo dado", http://www.dca.fee.unicamp.br/~ricarte/Courses/IA368/ls98/Xml/d3.html

 [Marchal97] Marchal, B. Dynamic WebPages in Java - Servlet, Digital Cat's Java Resource Center, Nov. 1997

[NetCom97] Netscape Communications Corp. JavaScript Language Specification. 1997 http://www.developer.netscape.com/library/documentation/index.html

[Netzke98] Netzke, J. A., Campos, M. B., Lima, M. F. P. Construtivismo, http://penta/ufrgs.br/~marcia/piaget/constru1.htm , Março, 1998

[Raposo98] Raposo, A.B., Adriano, C. M., Blaitt,J., Schulze, R. S. Programação na Web: Grupo C5, news://news.fee.unicamp.br, grupo fee.posgrad.IA368, 1998

[SilveiraJr98] Silveira Jr., L.G. Grupo a5 - Programação na Web, news://news.fee.unicamp.br, grupo fee.posgrad.IA368, 1998

[Venners96] Venners, B. Java Beyond the browser: The channel metaphor, Java World 1 (10), December 1996

[WDLV97] The Web Developer's Virtual Librabry. CGI: The Common Gateway Interface for Server-side Processing.1997. http://WWW.Stars.com/authoring/CGI