Tópicos em Engenharia de Computação V

 

Tema: Tecnologias de Distribuição: Web e Corba

 

Grupo:

Antonio Tadeu Maffeis RA 973529

Maria Angélica C. de Andrade Cardieri RA 819815 (Relator)

Maria das Graças J. M. Tomazela RA 961384

Maria Flávia Cunha F. Torres RA 974430

Márcia de Fátima Pimenta RA 984229

 

 

1. Introdução

 

Este relatório descreve a partir de um cenário voltado ao ambiente educacional, uma arquitetura de software que utilize objetos distribuídos com Corba. Esta arquitetura deve permitir a implementação de algumas funcionalidades requeridas neste cenário denominado "Curso sob Medida e Prova Virtual" .

 

 

2. Conceituação

A Web caminha cada vez mais para compartilhar aplicações e informações distribuídas em ambientes de computação heterogêneos. No entanto, esta distribuição impõe a necessidade de suporte a alguns aspectos tais como controle de concorrência, falha no acesso a algum componente, independência de software etc.

 

Surge portanto a necessidade de um middleware que torne os problemas da distribuição transparentes aos usuários e desenvolvedores.

 

Corba [2] é uma tecnologia que essencialmente descreve como aplicações clientes podem chamar operações de objetos do servidor usando os serviços de um intermediário denominado ORB (Object Request Broker). Através do ORB objetos de software distribuídos e seus clientes podem interagir. Usando ORB um objeto e seu cliente podem residir no mesmo processo ou em processos diferentes os quais podem ser executados em diferentes servidores conectados através de uma rede.

 

Corba também provê uma linguagem de definição de Interface (IDL) , que consiste em uma linguagem que pode ser usada para especificar operações que um cliente pode invocar sobre os objetos[4]. A abordagem tradicional de Corba não explora a WWW[1].

 

Java oferece grande flexibilidade para o desenvolvimento de aplicações distribuídas mas não suporta atualmente o paradigma cliente/servidor. Para isto Java necessita de uma infraestrutura de objetos distribuídos. Neste contexto podemos visualizar os benefícios da junção Corba e Java provendo uma plataforma eficiente para aplicações na Web.

 

3. Benefícios trazidos à Web com a utilização de CORBA

 

A utilização de CORBA e Java podem trazer diversas vantagens em comparação com a utilização da tradicional abordagem que utiliza o CGI. A seguir nós destacamos os principais benefícios trazidos com a utilização da tecnologia CORBA[1]:

· CORBA evita o "gargalo" do CGI - a utilização de CORBA permite que o lado cliente invoque métodos diretamente em um servidor. O cliente passa os parâmetros diretamente usando stubs pré-compilados, ou os gera usando serviços de invocação dinâmica CORBA. Pode-se invocar qualquer método com interface IDL e não apenas os definidos por HTTP. Outra característica interessante é a possibilidade de utilização de argumentos tipados (estruturados), em programas CGI os argumentos são passados como variáveis de ambiente, isto significa que são interpretados sempre como cadeia de caracteres .Com CGI deve-se iniciar uma nova instância de um programa toda vez que um applet invoca um método no servidor; com CORBA isto não é necessário. Além disso CGI não mantém estado entre as invocações do cliente , mas CORBA mantém.

· CORBA provê uma infra-estrutura escalonável de servidor para servidor - Servidores de objetos podem se comunicar usando CORBA ORB. Estes objetos podem rodar em múltiplos servidores de forma a prover balanceamento de carga para as requisições do cliente. O ORB pode enviar a requisição para o primeiro objeto disponível e adicionar mais objetos conforme a demanda aumenta. Em contraste aplicações CGI devem responder a centenas de requisições, mas não podem distribuir a carga através de múltiplos processos ou processadores.

· CORBA estende Java com uma infra-estrutura de objetos distribuídos - Atualmente applets Java não podem invocar métodos remotos, CORBA permite que os applets java se comuniquem com objetos distribuídos escritos em diferentes linguagens. CORBA fornece também um rico conjunto de serviços de objetos distribuídos - suporte a metadados, transações, segurança, persistência. Com CORBA os clientes JAVA e applets podem invocar uma ampla variedade de operações com interface IDL definidas no servidor; os clientes HTTP estão restritos a um limitado conjunto de operações.

Um sistema de controle de versões VICS [3] ( Version and Integration Control System) desenvolvido na Universidade do Texas foi desenvolvido utilizando a abordagem CGI e posteriormente foi re-implementado utilizando Java e CORBA. Esta nova implementação comprovou as vantagens descritas acima. Além disso evidenciou-se outras vantagens que serão resumidamente descritas a seguir:

· Flexibilidade de projeto e desenvolvimento - Com CGI a definição de uma operação remota é acoplada à definição de sua interface correspondente, pois ambos estão embutidos em um tag HTML FORM, esta abordagem não permite a execução de outras tarefas no cliente, mesmo que isto seja mais apropriado. Com Java/CORBA não existe relacionamento entre operações remotas e interface do usuário, todas as capacidades do cliente são explicitamente implementadas em um applet java, permitindo ao cliente executar qualquer tarefa, como por exemplo validação de valores de entrada.

· Facilidade de manutenção - Mudanças em um form HTML devem ser manualmente efetivadas no programa CGI correspondente. Uma aplicação usando Java/Corba possui facilidade de manutenção pois a interface de operações remotas IDL faz com que mudanças possam ser automaticamente propagadas para o cliente e para o servidor.

· Interface com o usuário mais intuitiva - A utilização de programas CGI limita o desenvolvedor a usar componentes HTML para a entrada de dados; a abordagem CORBA permite ao desenvolvedor criar novos componentes através de componentes já existentes. Além disso a utilização de CORBA dá ao desenvolvedor um amplo controle sobre o lay-out dos componentes de interface

· "Responsiveness" - Em uma aplicação CGI uma atualização dirigida pelo usuário para uma janela GUI requer uma requisição remota completa, em contraste tal atualização, quando utilizando um Java applet, pode ser manipulada diretamente no cliente. Outro problema com a abordagem CGI é que o browser pode desativar uma operação remota que demora muito tempo, mas com uma operação CORBA de um applet Java o browser não tem controle sobre a requisição e não pode desativa-la.

Vamos propor a seguir a arquitetura apropriada para contemplar as diversas funcionalidades de um curso sob medida, tendo em vista os benefícios que podem ser trazidos pela utilização de CORBA com Java.

 

4. Arquitetura e Funcionalidades

 

1. Compor as disciplinas através de material, exercício, provas e aulas, de forma distribuída, aplicando ou não técnicas de grupo.

2. Estabelecer perfis para cada curso definindo diferentes visões.

 

O mecanismo HTTP/CGI não tem estrutura para objetos distribuídos. Java praticamente também não suporta infraestrutura de objetos distribuídos[1]. O servidor consegue distribuir algumas das funções para o cliente na forma de applets mas utiliza ainda o mecanismo HTTP/CGI.

 

A utilização de CORBA nestas funcionalidades facilita a implementação da estrutura de objetos distribuídos provendo o acesso ao material que irá compor a disciplina, o qual pode estar distribuído em ambientes heterogêneos. Neste caso o front-end permanece uma página HTML com o Browser.

 

Com CGI teremos o problema de que toda vez que um applet invocar um método no servidor, uma nova instância do programa CGI é iniciado. Com CORBA isto não acontece [1].

 

Outro ponto a favor de Corba é a manutenção do estado entre requisições do cliente. A necessidade de manutenção de estado se justifica pelo fato de que na composição do curso, baseada em um perfil, o autor pode necessitar de diversas conexões com o servidor, para por exemplo, acessar um link e verificar se é realmente interessante inclui-lo ou mesmo acessar a base de dados para acrescentar este perfil. Com a manutenção de estado informações relevantes de conexões anteriores são armazenadas.

 

 

3. Cadastrar atores com diferentes perfis e níveis de acesso (instrutor, monitor, alunos, grupos de estudo)

 

Esta funcionalidade consiste em registrar em uma base de dados as informações correspondentes ao perfil do usuário. Isto poderia ser implementado via CGI. Porém se considerarmos um cenário mais sofisticado, onde um aluno possa possuir perfis diferentes para cada curso como por exemplo: ele pode ser aluno no curso de doutorado e instrutor da graduação, então o local onde se armazenam os perfis podem estar espalhados em ambientes heterogêneos. Nesta caso a implementação Java/Corba garantirá o acesso aos objetos remotos.

 

Neste caso a identificação do usuário poderia ser implementada por um módulo desenvolvido em Corba/Java.

 

4. Disponibilizar as disciplinas/aulas.

A utilização de Corba nesta funcionalidade traz como vantagem garantir a atualização em caso de alteração da informação. O uso do Castanet poderia diminuir o overhead no servidor, porém traz o problema de atualização de módulos após a demanda ter sido realizada para o cliente.

 

Se as aulas utilizarem recursos multimídias, Corba facilita a integração de diferentes objetos. Esta abordagem também é válida se considerarmos que o acesso ao material da disciplina pode gerar um processamento complexo e que muitas vezes pode exigir certa inteligência.

 

 

 

5. Acompanhar o andamento da disciplina

 

O proposto no trabalho anterior era o preenchimento de um questionário com perguntas gerais sobre o tema abordado. Neste caso o CGI é uma abordagem adequada pois trata-se de uma aplicação com requisições simples [3].

 

 

6. Fornecer Feed-Back para alunos e professores.

 

Utilizará e-mails caso se utilize da comunicação aluno-instrutor. Este feed-back pode ser incrementado com a possibilidade de fornecer um histórico ao aluno dos tópicos da disciplina por ele acessados. Neste caso poderá ser utilizado um formulário HTML /CGI.

 

7. Aplicar Provas, testes etc.

 

Considerando o caso em que as questões serão apresentadas uma a uma ao aluno, Corba seria o indicado pois garante a preservação do estado necessária durante a interação aluno-prova.

 

O fato das applets possuirem características multithreads, permite-nos imaginar uma prova aplicada de maneira inteligente, através de um "mecanismo inteligente" que a cada questão finalizada verifica se esta foi respondida corretamente enquanto o aluno responde a próxima. Neste caso o mecanismo inteligente ("prova Inteligente") poderia propor uma nova questão sob o tema que o aluno não respondeu corretamente porém em um nível mais simplificado. Isto seria uma forma de medir o grau de conhecimento do aluno (superficial, aprofundado). O formato final da prova personalizada seria armazenado em uma base de dados.

 

 

 

8. Corrigir e pontuar a prova pelo próprio sistema através de testes, instrutor ad-hoc, auto-correção (disponibilizar gabaritos para auto-avaliação).

 

No caso mais simples, em que a prova é em forma de teste e que a correção é apresentada apenas quando todos os alunos tiverem terminado a prova, o CGI é uma abordagem adequada, pois um gabarito poderá ser comparado com a prova através de um programa CGI.

 

Se as provas forem dissertativas a utilização de Corba poderá ser mais interessante pois mantém o estado. A manutenção de estado é importante neste caso porque o mecanismo de correção poderá exigir diversas pesquisas a bases de dados para correção e pontuação.

 

Corba também é indicado para o caso sugerido acima da "prova inteligente" pois esta torna-se personalizada para cada aluno, portanto há necessidade de um processamento mais complexo muitas vezes envolvendo bases de dados distribuídas.

 

 

9. Disponibilizar resultados para eventuais consultas.

 

O resultado poderia ser acessado somente pelo aluno que fez a prova, mediante identificação. Neste caso HTML/CGI será suficiente para apresentar o gabarito ao usuário no caso da prova simples em forma de teste.

 

No caso da "prova inteligente" como citado no item anterior, haverá a necessidade de acesso a base de dados para acesso a correção personalizada. A abordagem CORBA seria portanto a mais indicada.

 

 

 

5. Conclusão

 

A escolha de uma arquitetura depende do tipo de requerimentos que a funcionalidade apresenta. Neste relatório consideramos que a abordagem CGI será mais conveniente para situações mais simples em que a interação do usuário gera requisições de baixo processamento. Já a abordagem CORBA/Java foi utilizada para requisições mais sofisticadas que envolvem necessidade de acesso remoto a objetos distribuídos pela WWW.

 

 

6. Bibliografia

 

[1] - Robert Orfali, Dan Harkley

Java and CORBA - Cap. 3

Cliente /Server Corba Java Style

[2] - Sean Backer and Vinny Cahill and Paddy Nixon

Bridging Boundaries: Corba in Perspective

IEEE Internet Computing - 1997

 

[3] - Eric Evans and Daniel Rogers.

Using Java Applets and Corba for Multi-User Distributed Apllications

IEEE Internet Computing

 

[4] - Wolfgang Emmerich

An Introduction to OMG/CORBA

ACM 1997