Tecnologias de distribuição: Web e CORBA

Alunos:
    Christian M. Adriano     Ra 931594 (Relator)
    Alberto B. Raposo        Ra 946152
    Jefferson Blaitt               Ra 973528
    Raquel S. Schulze          Ra 956289
Este documento é o resultado das discussões realizadas nos dias 22.04.98.O assunto consiste em uma revisão da arquitetura de software proposta na reunião de grupos sobre o tema  Programação na Web considerando agora a utilização de objetos distribuídos via CORBA. O material base está disponível nas referências.
 

Tópicos:

1. Introdução

2. Mecanismo distribuído de programação Web

3.Funcionalidades do ambiente proposto

4.Implementação das funcionalidades

5.Conclusão

1. Introdução

Abordaremos neste trabalho o uso da tecnologia de distribuição de recursos/CORBA para implementar o curso sob medida + prova virtual. Forneceremos as mesmas funcionalidades que especificamos utilizando o mecanismo de servlets/CGI no nosso  trabalho  Programação na Web(grupo C5) . Na próxima seção explicaremos como funciona o mecanismo cliente-servidor utilizando applets e a arquitetura CORBA. Na seção 3 temos a relação de funcionalidades para o ambiente proposto. As implementações de cada funcionalidade  estão na seção 4 acompanhadas de uma análise dos benefícios encontrados.
 

 

2. Mecanismo distribuído de programação Web

O mecanismo básico consiste em requisições feitas a métodos de objetos remotos, a partir destas requisições são enviados os dados tanto na direção do cliente como do servidor. No presente mecanismo estes dados serão recebidos por applet em vez serem enviados na forma de uma página HTML como no mecanismo anterior. Para uma explicação passo a passo do desenvolvimento de um aplicativo veja o paper [3] , para visualizar o funcionamento do mecanismo veja em  [4].
Com uso da tecnologia de distribuição de objetos CORBA observamos que teríamos ganhos no processo de desenvolvimento e acréscimo de funcionalidades além de algumas melhorias de desempenho para a aplicação. Ressaltamos os ganhos em transparência no uso de recursos suportados por objetos remotos e  melhoria de interoperabilidade, que entendemos como sendo para o cliente uma visão mais local do aplicativo. Explicando melhor este último ponto, temos que na abordagem anterior através de servlets ficava sempre evidente ao cliente os momentos em que eram realizadas requisições por recursos remotos, as quais se consumavam pela submissão de um form HTML devidamente preenchido e o conseguinte retorno de uma nova página HTML. Utilizando chamadas a métodos de objetos remotos através da infraestrutura definida na especificação CORBA, podemos tornar as requisições transparentes sempre que  necessário.
Outro ponto forte neste novo modelo cliente-servidor é o uso de applets, distribuindo parte do processamento para os clientes. O uso de applets já havia sido proposto no trabalho anterior, porém agora temos a possibilidade de fazer com que estes applets utilizem recursos disponibilizados remotamente.
 

3. Funcionalidades do ambiente proposto

 Aqui temos uma retomada das funcionalidades que foram relatadas no ambiente anterior. Estas funcionalidades vêm a atender os requisitos de personalização do material e prover os recursos necessários ao acompanhamento do estudo tanto por parte do aluno como de seu instrutor.

Podendo assim serem estabelecidas nove funcionalidades para o ambiente:

1. Composição das disciplinas através de material, exercícios, provas, etc. (Processo de co-autoria.)
2. Estabelecimento de perfis para cada curso, definindo diferentes visões.
3. Cadastramento de usuários com diferentes perfis e níveis de acesso (instrutor, monitor, alunos).
4. Disponibilização do material.
5. Acompanhamento do andamento da disciplina.
6. Fornecimento de feed-back para alunos e professores.
7. Aplicação de provas.
8. Correção das provas e cálculo das notas.
9. Disponibilização dos resultados para eventuais consultas.
 

4.Implementação das funcionalidades

 

 1.Composição da disciplina

O autor entraria primeiramente em uma página de autoria. Esta página viria acompanhada de  um applet de suporte a autoria, o qual teria as seguintes atribuições:
 
  • Autenticar o autor;
  • Fornecer uma estrutura visual de um índice de todo o material disponível;
  • Permitir selecionar qual tópico será editado;
  • Permitir definir qual a visão que se terá sobre este tópico (i.e.: com/sem as anotações, penúltima versão, com/sem referências, visão de terminado perfil,etc) ;
  • Envia pedido e recebe este material em uma ferramenta de edição.
  • Edita o material, logo este applet poderia ter todas as ferramentas necessárias a edição, ou este poderia chamar um aplicativo local de edição.

    •  
    Para tentar contornar o peso em carregar e enviar um applet muito grande, podemos ter este applet repartido em vários, sendo os maiores instalados previamente na área do cliente. Outra solução que pode ser usada em conjunto é o caching feito pelo CASTANET.

    Vemos que com esta solução não teríamos mais as trocas de páginas do mecanismo servlet/CGI. Isto torna a aplicação mais transparente para o cliente, dando-lhe uma visão do ambiente mais  de "desktop" que se aproxima das aplicações locais.
     

    2. Estabelecimento de perfis

    Aqui teríamos benefícios em interface, pois devido ao uso de um applet a definição de um perfil e posterior envio estariam integradas dentro da mesma aplicação. Dependendo da complexidade de caracterização deste perfi, teríamos justificado um mecanismo mais rebuscado a partir de ferramentas visuais de um applet.
     Exemplo: No momento de definir quais tópicos de uma matéria envolveriam determinado perfil, o applet faz uma análise do perfil que está sendo construído, sugerindo tópicos e apontando possíveis falhas, como falta de determinado tópico pré-requisito.

    O applet teria as seguintes atribuições:
     

  • Autenticar o usuário;
  • Recebimento da estrutura completa do curso;
  • Ferramenta de seleção de tópicos e visualização dos já selecionados (como um shopping basket);
  • Análise concorrente da atividade;
  • Envio do perfil para armazenamento no servidor.

    • Em comparação com o mecanismo servlet/CGI, não seria viável prover as funcionalidades de acompanhamento da
    confecção do perfil sem a  possibilidade de ser realizado um processamento local em conjunto com chamadas a métodos em objetos remotos.
     

    3.Cadastro de Usuários

    Como temos afirmado que entre os benefícios que justificariam o uso da tecnologia de distribuição está o grau de complexidade da aplicação, neste caso de cadastro de usuários não seria necessário um mecanismo tão rebuscado. Portanto, de modo a manter o padrão de desenvolvimento, utilizariamos também um applet como interface para envio dos dados de um novo usuário ou alteração de dados já existentes. Os ganhos estariam talvez em uma melhor interface, porém seria pefeitamente e talvez até mais eficiente o uso do mecanismo de servlet/CGI para esta funcionalidade.
     

    4 e 5.  Disponibilização do Material e Acompanhamento da Disciplina

    Estas duas funcionalidades estariam dentro de um mesmo applet. Isto se deve a eliminação da necessidade de troca sucessivas de páginas a cada requisição feita ao servidor.
    Teríamos aqui um applet que mostraria graficamente o conteúdo já percorrido. Poderíamos ter também um mecanismo de tutor inteligente, veja paper [7], informando conteúdos correlatos, tópicos já alterados pelo autor como modificação de links e conteúdos.

    O applet teria as seguintes atribuições:
     

  • Autenticar o usuário;
  • Visualização do material em um ambiente próprio (browser);
  • Visualização dos trechos já percorridos;
  • Tutor inteligente;
  • Buscas sobre o material.

    • A ferramenta de acompanhamento do material para o professor seria semelhante, expandida para o monitoramento de qualquer aluno. Seria necessário o acréscimo de algumas funcionalidades, como saber em que ponto do material encontra-se determinado aluno ou  a turma em média.
     

    6. Feedback

    Seria composto pelo já especificado monitoramento das atividades dos alunos e pelo acréscimo de ferramentas de comunicação. Estas estariam na própria interface do applet anterior em forma de ícones ou botões, que ativariam as ferramentas de comunicação já existentes (e_mail, news, chat, etc).
     

    7 e 8. Prova

    Seria suportado por um único applet. A correção poderia ser feita no cliente para o caso de uma prova de múltipla escolha. Teríamos mais uma vez um ganho na interface com o usuário. Quanto ao mecanismo de segurança utilizaríamos o mecanismo de autenticação do JDK1.1, ver paper[2].
    O applet teria as seguintes atribuições:
  • Autenticação do usuário;
  • Visualização da prova;
  • Marcação de tempo;
  • Correção local se for prova de múltipla escolha;
  • Envio das resposta;
  • Recebimento de uma certificação de realização da prova.

    • Para o professor teríamos um applet "escaninho",  que mostraria ao professor as provas a serem corrigidas (caso elas não sejam de múltipla escolha).
     

    9. Disponibilização dos resultados

     Aqui teríamos um applet gráfico que consulta objetos remotos, os quais fornecem os resultados através de consulta a um banco de dados.
    Justificamos aqui o uso do mecanismo applet/CORBA pelo fato de termos que receber as repostas via applet e não na forma de uma página HTML, de modo a realizar processamentos locais sobre estes dados, como mostrar em formatos diferentes, selecionar um sub-conjunto dos mesmos e alterá-los para posterior envio.
     

    5.Conclusão

    Aqui tomamos uma posição radical de implementar todas as funcionalidades utilizando o novo mecanismo java applets/CORBA, a intenção foi com isso mostrar os grandes benefícios proporcionados e bem como questionar os pontos onde o peso e inadequação da tecnologia sugeririam um integração com o mecanismo de servlets/CGI visto no trabalho anterior. Pensamos que questões de modelamento e implementação de um "curso sob medida"  e "prova virtual"  realimentarão decisões acerca de qual tecnologia deve ser utilizada em cada funcionalidade. Procurando definir os compromissos que devem ser seguidos, vemos primeiramente a complexidade das atividades a serem realizadas localmente, a eficiência na transmissão de volumes grandes de códigos e por conseguinte o peso da interpretação deste código localmente.
     

    Referências

    [1] David Curtis: "Java, RMI and CORBA", Object Management Group, 1997

    [2] Eric Evans, Daniel Rogers: "Using Java applets and CORBA for multi-user distributed applications" , IEEE Internet Computing 1(3):43-55, May-June 1997

    [3] Morgan. B :"CORBA meets Java ", JavaWorld 2(10), October 1997
     
    [4] Orfali, R.; Harkey, D. : "Client/server, CORBA/Java-Style em Client/server programming with Java and CORBA", John Wiley and Sons,1997

    [5] Sean Baker, Vinny Cahill, Paddy Nixon : "Bridging boundaries: CORBA in perspective ", IEEE Internet Computing, 1(5):52-57, September/October 1997

    [6] Jeremy Rosenberg ," When to use CORBA ", Javology 2(3), April-May 1997

    [7] Marcelo Miranda Coelho, "Definição de um módulo hipermídia adaptativo para integrar sistemas tutores inteligentes", Instituto Tecnológico da Aeronáutica, http://www.comp.ita.cta.br/~coelho/paper.html

    Página atualizada em 27. 04. 98