Este documento apresenta uma análise do tema "tecnologias de distribuição: Web e CORBA", discutido em plenária nos dias 28 e 30/04/1998.
Assim como no tema anterior - "Programação na Web" ([Santos 98]) - a motivação da discussão foi a proposta da aplicação "Curso sob Medida e Prova Virtual" ([Dagnone 98], [Granja 98], [Pimenta 98]). Na presente discussão, no entanto, foi analisada a utilização da tecnologia de objetos distribuídos (CORBA, mais especificamente) para a implementação da referida aplicação.
Resumidamente, o curso sob medida deve ser capaz de prover ao aluno uma versão "personalizada" de um curso disponível na Web, de acordo com o perfil do mesmo. Um exemplo de utilização dessa aplicação seria na adaptação de uma disciplina básica aos vários cursos universitários que a incluem em sua grade curricular. Seria possível, por exemplo, disponibilizar a disciplina Física I para alunos de Engenharia Elétrica, enfocando tópicos diferentes daqueles que seriam enfocados para alunos de Física. As funcionalidades dessa aplicação seriam ([Pimenta 98]): composição das disciplinas, estabelecimento de perfis para cada curso definindo diferentes visões, cadastro de "atores" com diferentes perfis e níveis de acesso (professores, alunos, monitores, etc), disponibilização das disciplinas/aulas, acompanhamento do andamento da disciplina e fornecimento de feed-back para alunos e professores.
A aplicação também deve fornecer "provas virtuais", i.e., as avaliações são feitas de maneira online pelos alunos e as respostas são enviadas para serem corrigidas pelo professor ou são corrigidas automaticamente (no caso de prova de múltipla escolha). As provas também podem ser adaptadas ao perfil do aluno. Maiores detalhes sobre esta aplicação podem ser encontrados nas referências citadas anteriormente.
Na próxima seção será
feita uma breve revisão da arquitetura CORBA, enfocando principalmente
sua integração com a Web. Na Seção
3 serão analisadas as propostas de implementação
da aplicação "curso sob medida e prova virtual" definidas
pelos vários grupos. Na Seção 4
serão analisados os resultados das plenárias, onde quatro
situações foram estudadas (aula síncrona, presencial
ou não e aula assíncrona, presencial ou não) e possíveis
arquiteturas foram propostas. Ainda na mesma seção serão
apresentados os resultados da segunda plenária, onde críticas
às arquiteturas propostas foram feitas e novas arquiteturas idealizadas.
As conclusões finais desse relatório serão apresentadas
na Seção 5.
2. Tecnologias de Distribuição na Web
Das discussões anteriores referentes às tecnologias Web disponíveis para um cenário de Curso sob Medida com Prova Virtual, ficou patente a necessidade de um mecanismo que facilitasse a distribuição das informações disponibilizadas no curso e que permitisse que estas informações fossem processadas principalmente na máquina cliente, retirando grande parte deste processamento dos servidores. Evidentemente, a consistência das informações entre cliente e servidor seria mantida. O grande desafio estava em se ter uma infraestrutura que permitisse não só a distribuição do dados, mas a integração destes de modo uniforme e independente da plataforma e tecnologia de implementação usadas nos servidores.
Applets Java surgiram como uma solução para a implementação
da distribuição de processamento. Para permitir a integração
das informações distribuídas foi analisada a arquitetura
CORBA, que será discutida a seguir.
A OMG (Object Management Group) é um consórcio internacional de indústrias de software cujo objetivo é fornecer um modelo de arquitetura comum, para permitir interoperabilidade e portabilidade de aplicações distribuídas orientadas a objetos, através de plataformas heterogêneas (hardware e sistema operacional).
Para isto a OMG desenvolveu um modelo conceitual de objetos e uma arquitetura
de referência denominada OMA (Object Management Architecture).
Esta arquitetura, mostrada na Figura 1 consiste de
5 componentes, que definem em um alto nível de abstração
as várias necessidades para computação distribuída
orientada a objetos.
O núcleo da OMA é o ORB (Object Request Broker), que gerencia toda a comunicação ente componentes da arquitetura, permitindo aos objetos interagirem em um ambiente heterogêneo e distribuído, independente das plataformas nas quais estes objetos residem e das técnicas usadas para implementá-los. Para executar suas tarefas, o ORB utiliza os Serviços de Objetos, responsáveis pela gerência dos objetos (criação, controle de acesso, monitoração de localização de objetos, etc.). As Facilidades Comuns (common facilities), Interfaces de Aplicação e Interfaces de Domínio contêm funcionalidades mais próximas do usuário final, como por exemplo: executar tarefas específicas a um domínio de aplicação (e.g., domínio financeiro ou médico) ou gerenciamento de impressão.
A tecnologia utilizada por ORB's é conhecida como CORBA ([Baker97], [Keahey97], [Schmidt97], [Vinosky97], [Yang96]), que especifica um framework para comunicação transparente entre objetos de aplicação. O projeto de CORBA é baseado no Modelo de Objetos OMG. Este modelo define a semântica comum de objetos pela especificação das características externamente visíveis de objetos de uma forma padrão e independente da implementação.Neste modelo, clientes requisitam serviços de objetos através de uma interface bem definida, especificada através da IDL (Interface Definition Language). Um cliente acessa um objeto executando uma requisição.
A especificação CORBA define uma arquitetura de interfaces
consistindo de 3 componentes: interface para cliente, interfaces para implementação
de objetos, e o núcleo ORB (Figura 2).
A funcionalidade básica do Núcleo ORB consiste em passar requisições dos clientes para as implementações dos objetos em que são invocados. Para fazer uma requisição, um cliente pode se comunicar com o ORB através de um stub IDL ou através da Interface de Invocação Dinâmica - DII (Dynamic Invocation Interface). O stub representa o mapeamento entre a linguagem de implementação no cliente e o ORB. A DII permite que o cliente especifique requisições para objetos cuja definição e interface eram desconhecidas ao cliente em tempo de compilação.
O ORB então transfere a requisição para a implementação
do objeto (up-call), através de um esqueleto IDL ou
uma interface dinâmica - DSI (Dynamic Skeleton Interface).
O esqueleto IDL é a contra-partida do stub IDL e a DSI permite
entregar requisições do ORB a uma implementação
de objeto que não tinha conhecimento do tipo de objeto em tempo
de compilação. Diversos fabricantes podem ter sua implementação
de CORBA, sendo portanto necessário um padrão para que estes
diferentes ORB's possam interagir. Para permitir esta interoperabilidade,
a OMG definiu a arquitetura de Interoperabilidade ORB. Esta arquitetura
define a existência de domínios, um conjunto
de objetos separados de todos os outros por razões quaisquer (implementação,
administração, etc). Desta forma, objetos de diferentes domínios
precisam de um mecanismo de mapeamento entre domínios, mecanismo
este denominado bridging (ponte). Este mecanismo é especificado
através de um protocolo denomindao GIOP (General Inter-ORB Protocol)
que serve como um protocolo comum para a definição de pontes.
Em particular, o protocolo IIOP (Internet Inter-ORB Protocol) é
uma das variantes do GIOP, usado quando o transporte na rede é feito
em TCP/IP.
Deve-se observar que CORBA consiste na definição de uma arquitetura que facilita a interoperabilidade entre objetos distribuídos em uma aplicação, independente de sua plataforma ou tecnologia de implementação, permitindo que aplicações possam ser definidas a partir de componentes de diferentes procedências ou de diferentes fabricantes. No entanto, a necessidade cada vez mais presente em ambientes distribuídos em migrar componentes de um programa para diferentes máquinas não é atendida por CORBA. Esta necessidade torna-se patente quando observamos aplicações ambientadas na Web.
Para este problema, a solução com applets Java ([Santos98], [Orfali97]) tem sido gradativamente adotada em aplicações distribuídas, ambientadas na Web ou não. Assim, esforços recentes têm se desenvolvido no sentido de integrar CORBA e Java, posto que são tecnologias complementares para a solução do problema mencionado ([Curtis97], [Evans97], [Morgan97], [Rosenberg97],): Java permite a criação de objetos e sua distribuição, enquanto que CORBA permite a integração destes objetos com os demais componentes da aplicação distribuída.
Dentre as principais características desta integraçcão estão ([Evans97]):
A principal proposta colocada na primeira fase de discussões foi a de um Curso sob Medida, com o oferecimento de provas virtuais durante o curso. Das discussões em grupo ocorridas em 23/04/98 constatou-se que a solução para o problema passava pela adoção de applets Java e extensões como servlets como solução para a implementação da distribuição da informação e processamento pelos clientes que acessavam o material do curso. CORBA entraria como solução para a integração destes componentes, visto que eles poderiam estar localizados em diferentes servidores em uma rede de computadores (não necessariamente no servidor principal do curso).
A partir desta situação, foram definidos novos grupos que trabalharam sobre o mesmo cenário discutido em [Santos98] e [Pimenta98]:
Na UMTE (Universidade com Montes de Tecnologias Educacionais)
, um estudante do curso de Engenharia Elétrica precisa assistir
uma aula de Física I sobre o tópico "movimento acelerado".
Dentro deste novo cenário, foram analisadas pelos grupos quatro
situações distintas, conforme definidas em [Magalhães98].
O resultado destas discussões será analisado na próxima
seção.
4. Paradigmas para o uso de tecnologia computacional em ambientes educacionais
Nesta seção serão apresentadas quatro situações em que a tecnologia de objetos distribuídos pode ser utilizada para a implementação de ambientes educacionais. As duas primeiras situações ilustram o caso síncrono, sendo que na primeira a aula é presencial e na segunda a aula é remota. A terceira situação retrata uma aula assíncrona presencial, enquanto a última situação retrata uma aula assíncrona não-presencial. Ao final, serão analisadas propostas para a criação de um ambiente de aula síncrona (juntando as duas primeiras situações) e de um ambiente de aula assíncrona (juntando as duas últimas situações).
4.1. Situação 1 - Aula Síncrona Presencial
Cenário
Na hora da aula, estudante vai a uma sala de aula presencial na UMTE onde professor utiliza os mais avançados recursos computacionais para ministrar sua aula sobre o tópico para alunos deste curso. O professor é o único agente que manipula diretamente as tecnologias disponíveis. A interação pessoal, unicamente possível em aulas presenciais é valorizada.
Proposta
A proposta do grupo se baseou em um "mini-cenário" onde o instrutor dispõe de vários recursos para ministrar a aula: sala de aula convencional, quadro negro, tela de projeção, microcomputador, equipamento de projeção conectado ao micro e material didático da aula utilizando de recursos hipermídia, disponível nos servidores da UMTE de acordo com o perfil do usuário (neste caso, o usuário seria o professor). O instrutor projeta a aula na tela e pode "navegar" pelo material didático. Em determinado momento, ele pode carregar por exemplo uma simulação onde ele insere parâmetros sugeridos pelos alunos, de forma participativa, objetivando chegar em um conceito correto sobre o assunto. No exemplo citado, a aula seria de Física para Engenharia e a simulação envolveria a relação de gravitação entre a Lua e a Terra para responder a pergunta "Por que a Lua não cai sobre a Terra?". Além disso, a aplicação deveria permitir ao instrutor fazer anotações nos diversos pontos da aula.
A arquitetura proposta consiste de 3 servidores:
A proposta acima retrata de maneira correta o cenário proposto, mas algumas observações podem ser feitas.
A primeira observação diz respeito ao fato de não ter ficado claro o papel do terceiro servidor (chamado de servidor de dados sobre a disciplina). É citado na proposta que este servidor armazena metadados e informações gerais sobre as disciplinas oferecidas (identificação, código, sala de aula, prédio, turma e informações adicionais). No entanto, questionamos a necessidade deste servidor, já que estes dados poderiam estar armazenados no servidor de conteúdo. Essa idéia é reforçada pelo fato de nenhum dos serviços mencionados ter sido implementado no referido servidor.
Outra questão que pode ser levantada é relacionada ao caráter estático da aula em relação ao material didático. É impossível ao professor trazer qualquer material novo para ser apresentado durante a aula e inseri-lo no contexto do curso sem que este material tenha sido previamente colocado no servidor de conteúdo. Este problema poderia ser eliminado com a criação de alguns stubs para a inserção de "applets de última hora".
A maior crítica que fazemos a esta proposta, no entanto, está
relacionada a uma falta de aprofundamento no uso da ditribuição
de objetos para a implementação da aplicação.
Não está claro, por exemplo, se os objetos que compõem
a disciplina estão distribuídos ou não e nem como
ocorreriam as interações entre usuários, dados e serviços
distribuídos. É nossa opinião que a proposta foi apresentada
em um nível de abstração um pouco mais alto que o
esperado. Tentando suprir esta falha da proposta apresentada, esquematizamos
na Figura 3 como a arquitetura proposta poderia ser
implementada utilizando CORBA.
4.2. Situação 2 - Aula Síncrona Não-Presencial
Cenário
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. O estudante pode assim acompanhar remotamente a aula que está sendo ministrada pelo professor, o qual pode fazer uso das tecnologias computacionais no suporte à sua apresntação. A interação é possível unicamente através dos computadores, o que abre a possibilidade de utilizar mecanismos auxiliares de coordenação de mensagens e acesso aos dados.
Proposta
O grupo propôs um cenário composto por três elementos:
um servidor do instituto, um servidor do laboratório (onde o professor
ministra a aula) e os clientes (computadores dos alunos, que acessam a
aula remotamente). Como alternativa, o grupo citou um quarto elemento,
que seria um servidor da administração geral da Universidade,
mas optou por não incluí-lo efetivamente no cenário
proposto.
O servidor do instituto armazena dados comuns a todas as aulas (material didático básico e banco de dúvidas, por exemplo) e dados administrativos (alunos matriculados, professores responsáveis pelas disciplinas, notas, presenças, etc). O servidor do laboratório, por sua vez, armazena dados específicos da aula que está sendo ministrada (e.g., material extra e "perfil" da aula -- i.e., se a aula pode ser interrompida ou não, se pode ser gravada, etc.). O servidor do laboratório também é responsável por enviar o vídeo da aula em tempo-real para os alunos. A idéia da proposta é ter um servidor de laboratório para cada disciplina, descongestionando o servidor central do instituto, que só seria acessado no início da aula para descarregar o material básico no servidor do laboratório e para consultas no banco de dúvidas. O banco de dúvidas serviria para fazer uma "pré-filtragem" das dúvidas dos alunos. Antes de interromper a aula para consultar o professor, o banco de dúvidas verificaria se ele tem como respondê-la. A aula só seria interrompida se o banco não tivesse como responder ao aluno ou se o aluno não ficasse contente com a resposta automática do banco.
A Figura 4 ilustra como os dados e serviços
estariam distribuídos entre os elementos do ambiente proposto.
Em alguns casos, seria necessário que os clientes atuassem como servidores e vice-versa. Um exemplo dessa situação seria no caso do aluno querer enviar seu workspace para o professor. Esse é um dos aspectos que o grupo apresenta como vantagens da utilização de CORBA na implementação.
As funcionalidades e o relacionamento entre os serviços e elementos
do cenário são esquematizados na Figura 5.
Análise
A proposta apresentada para a segunda situação chegou em um nível de detalhes um pouco maior que a da situação anterior. No entanto, acreditamos que ela também não tenha chegado ao nível de detalhamento esperado no que diz respeito à implementação utilizando CORBA. Esse problema foi de certa forma justificado pelo grupo, que alegou que no nível de abstração da arquitetura do ambiente não faz diferença onde os objetos que implementam os serviços estão localizados, pois CORBA fornece transparência na distribuição.
Outra observação que podemos fazer sobre essa proposta diz respeito à não inclusão definitiva do servidor administrativo no ambiente. Acreditamos que seria melhor acrescentar este servidor, retirando do servidor do instituto serviços e dados administrativos (dados dos alunos, professores, notas, etc.). Desse modo, teríamos uma similaridade com a proposta da primeira situação: os servidores administrativos seriam semelhantes nos dois casos, e o servidor do instituto aqui seria equivalente ao servidor de conteúdo na proposta da primeira situação (maiores detalhes sobre a junção das duas primeiras situações serão vistos na próxima seção).
A questão mais polêmica na proposta do grupo, no entanto, diz respeito ao servidor do laboratório. A idéia do laboratório como servidor pode ser substituída pela idéia do servidor como aplicação, utilizando dados armazenados no servidor do instituto (e/ou no servidor administrativo) através de requisições a serviços destes servidores. Uma vantagem que esta idéia traria seria a centralização dos dados da disciplina, evitando possíveis duplicações e inconsistências. A sobrecarga dos servidores que fornecem dados durante a aula pode ser evitada, sem perder a unidade conceitual da proposta, utilizando proxies [Luotonen 94] para reduzir a constante requisição de dados. É importante notar que a utilização do conceito de laboratório como aplicação requer quase que obrigatoriamente uma abordagem cliente-servidor baseada no paradigma CORBA, principalmente devido às inversões de papéis entre clientes e servidores frequentemente necessárias.
Apesar da discussão acima, o que ficou claro é que nesta situação, diferentemente da situação 1, há a necessidade de algum elemento intermediário entre o servidor do instituto (ou servidor de conteúdo) e os clientes. Esse elemento agiria como descongestionador do servidor do instituto, distribuidor dos dados para os clientes e intermediador na necessária inversão de papéis entre clientes e servidores.
4.3. Situações 1
+ 2 - Aula Síncrona
Cenário
Na UMTE há uma sala de aula, onde o professor possui computador, datashow, câmera, e todo o equipamento necessário para ministrar a aula. Os alunos poderão estar presentes nesta sala de aula (conectados ou não a micros individuais), mas também podem se conectar remotamente (a aula em áudio/vídeo, o material didático, simulações, etc chegam até o computador dele). O importante nesse cenário é que é o professor quem controla a aula, i.e., controla o que está sendo mostrado, as interrupções para responder dúvidas, etc.
Proposta
Conforme comentado anteriormente, uma proposta que uniria as duas anteriores seria a utilização de dois servidores: um servidor administrativo e um servidor de conteúdo. No primeiro servidor encontram-se os dados dos professores (perfis), os dados dos alunos matriculados em cada disciplina, as notas, as presenças e outros dados que dizem respeito à administração do curso. No servidor de conteúdo encontram-se todas as ferramentas e dados que compõem a disciplina (simulações, applets, ferramentas de shared workspace, etc).
O material didático do servidor de conteúdo é enviado para o computador do professor antes do início da aula. Esse material poderia ser, citando o exemplo da Seção 4.1, uma simulação usando parâmetros sugeridos pelos alunos. O professor também pode adicionar algum material adicional no seu próprio computador (uma nova simulação, por exemplo). O aluno que assiste a aula na sala pode ter acesso a este material na tela do seu computador ou através do telão da sala. O aluno conectado remotamente recebe todo esse material em seu computador, além do vídeo da aula ministrada em tempo-real.
Para evitar a sobrecarga dos servidores (especialmente o de conteúdo)
durante a apresentação da aula, foi sugerida a criação
de um (ou vários) proxy entre os clientes e os servidores.
Além de evitar a sobrecarga nos servidores, este proxy faria a distribuição
dos "objetos" da disciplina (por exemplo, ele determinaria que o vídeo
da aula deve ser enviado apenas para os clientes remotos, e não
para os localizados na sala de aula). Aliado à flexibilidade do
CORBA, o proxy também administraria o envio de informação
dos clientes para os servidores, realizando a já comentada inversão
de papéis. A Figura 6 ilustra a arquitetura
proposta.
O grupo considerou a tecnologia Java/CORBA adequada para a implementação pelos seguintes motivos:
A proposta de união das situações 1 e 2 se baseou na semelhança entre as duas propostas iniciais (servidores de conteúdo e administrativo) e tentou superar os problemas existentes em cada uma delas (por exemplo, acrescentando a possibilidade de adicionar material extra e tratando o servidor de laboratório da situação 2 como um proxy). Acreditamos que esta proposta tenha sido um avanço em relação às duas anteriores, porém mantemos a opinião de que faltou um maior aprofundamento na discussão de como CORBA poderia ser efetivamente usado nesse ambiente (em outras palavras, acreditamos que fosse necessário sair do nível de arquitetura para um nível um pouco mais baixo, em direção à implementação).
4.4. Situação 3 - Aula Assíncrona Presencial
Cenário
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. O uso das tecnologias deixa de ser demonstrativo, passando a ser interativo. Todas as comunicações são assíncronas, mas não são restritas a comunicações entre aluno e professor.
Proposta
A proposta do grupo definiu 3 componentes básicos:
A proposta retrata de modo adequado o cenário proposto, podendo ainda ser melhorada em alguns pontos.
Primeiramente, um aspecto que poderia ser melhorado é o de permitir que alguns tópicos do material apresentado pudessem ser também ser selecionados pelo aluno, não dependendo apenas do perfil. O cenário proposto inicialmente não exclui este tipo de interação.
Outro ponto importante diz respeito ao detalhamento da forma com que
CORBA, applets Java e CGI são usados para executar as funcionalidades
definidas. A proposta foi superficial neste aspecto e as figuras apresentadas
não são muito claras. Na verdade, esta situação
se aproxima bastante da situação esquematizada na Figura
3 , bastando acrescentar a parte que representa o scripit CGI produzindo
o perfil do aluno.
4.5. Situação 4
- Aula Assíncrona Não-Presencial
Cenário
Estudante conecta-se ao servidor da UMTE manifestando seu interesse
no tópico, sendo a informação entregue posteriormente
pelo servidor quando disponível ou atualizada. Por exemplo, pela
manhã o estudante define (possivelmente com o auxílio de
interações com o servidor de cursos) sobre quais tópicos
e sob qual enfoque o material desejado deverá versar. À noite,
ao retornar do trabalho, o estudante irá estudar o material que
está disponível localmente, podendo acontecer de nem todo
o material ter sido ainda preparado e entregue pelo servidor.
Proposta
A proposta define as seguintes funcionalidades:
O primeiro objeto é uma aplicação Java denominada GerenteAluno e que fica ativa na área de acesso do aluno em uma máquina da rede. Este objeto manipula a base de dados local e provê métodos para receber requisições das applets de interface, e dados do servidor de cursos. O segundo objeto é uma aplicação multithreaded chamada ServidorCursos, executada no servidor externo responsável em recuperar o material dos tópicos. Ele também é responsável pela autenticação do aluno no sistema.
A proposta define ainda dois applets Java (SelectTopics e IndexTopics) que seriam ativados através de um browser e que são responsáveis pela interação com o aluno, permitindo a este escolher os tópicos a serem recuperados e, posteriormente, acessar o material transmitido pelo servidor de curso e que ficou armazenado na base de dados local.
Análise
A proposta retrata de modo adequado o cenário proposto, embora não deixe claro alguns aspectos da implementação.
A relação entre os applets e os servidores não
está clara: são os servidores que tomam a iniciativa de enviar
informação para os applets (e.g., o servidor de curso é
que ativa um método do applet no cliente responsável em receber
a lista de tópicos)? O servidor envia uma página HTML
com o applet, sendo que esta página foi gerada via CGI/Servlet?
4.6. Situações 3 + 4 - Aula Assíncrona
Cenário
Estudante conecta-se ao servidor da UMTE manifestando seu interesse no tópico, no momento em que lhe for conveniente. O estudante escolhe se deseja visualizar o material naquele momento, baseado em sua evolução dentro do tópico, ou se deseja que a informção seja entregue posteriormente.
Proposta
O novo cenário consistiu na junção direta das situações 3 e 4. Assim, permite-se que o aluno, uma vez identificado perante o servidor de disciplinas, escolha se deseja que a disciplina seja disponibilizada de acordo com seu perfil ou se deseja escolher ele mesmo os tópicos. Seja a partir do perfil, seja por escolha direta do aluno, é estabelecida uma lista de tópicos pelo servidor de disciplinas, que então executa a busca dos materiais pertinentes, tornando-os disponíveis para serem acessados pelo cliente. Este indica se quer visualizar o curso naquele instante ou se quer fazê-lo posteriormente. Neste último caso, o cliente ativa um processo "daemon" que se encarrega de receber os dados do servidor a medida que este vai disponibilizando o material encontrado.
As funcionalidades seriam as mesmas definidas nas situações 3 e 4, tendo sido detalhada uma forma de implementação usando CORBA para a funcionalidade Busca de material a partir de um conjunto de tópicos.
Análise
A proposta apresentada não deixou claro quais as funcionalidades do novo cenário. Por exemplo, a busca de material a partir de um conjunto de tópicos não era uma funcionalidade das situações 3 e 4 originais.
O nível de detalhamento apresentado para a implementação nesta proposta poderia ter sido mais esquemática, mostrando através de uma figura a relação entre primitivas Java e CORBA no caso da funcionalidade apresentada.
O padrão CORBA já é hoje em dia considerado o padrão de facto para aplicações envolvendo a tecnologia de objetos distribuídos. Java, por sua vez, também se tornou a tecnologia mais poderosa para programação na Web. Por isso, quando se fala em incorporar a tecnologia de objetos distribuídos à Web é natural pensar na integração Java/CORBA. É dentro deste contexto, ainda pouco explorado relativamente, que esse trabalho se insere.
O objetivo principal foi utilizar mais uma vez a aplicação "curso sob medida e prova virtual", propondo possíveis implementações para os cenários porpostos utilizando a tecnologia CORBA/Java. Com esse estudo, é possível fazer uma comparação com a implementação utilizando recursos para a manutenção de estado do HTTP [Chaim98] e utilizando recursos existentes para a programação na Web (e.g., CGI, applets, servlets) [Santos98].
O que pudemos observar neste trabalho em comparação com os anteriores foi que neste não ficou muito claro como CORBA e Java podem ser utilizados para implementar as funcionalidades definidas. Em outras palavras, a discussão ficou mais próxima do nível da arquitetura do ambiente do que do nível de implementação. Acreditamos que isso se deve ao fato de CORBA ser um assunto menos conhecido e mais complexo que os anteriores, além de que os artigos lidos para a discussão [Baker97], [Evans97] e [Orfali97] apresentam apenas uma visão geral de CORBA e sua integração na Web, sem entrar em detalhes de implementação.
No entanto, a discussão deixou bem clara para todos os participantes a importância da integração de CORBA na Web, pois ela trará vantagens desejadas, tais como: manutenção de estado da conexão, transparência na distribuição, inversão de papéis entre clientes e servidores e independência de plataforma e linguagem para a implementação dos objetos.
[Baker97]
Baker, S.; Cahill, V. & Nixon P. Bridging boundaries: CORBA in perspective
IEEE Internet Computing, 1(5):52-57, September/October 1997
[Chaim98]
Chaim, M.L. e Evangelista, S.R.M. Implementação de
Aplicações que
requerem a Manutenção de Estados das Aplicações
na WWW.
Relatório de IA 368 F.
[Curtis97]
Curtis, D. Java, RMI and CORBA, in CORBA
WhitePapers,
Object Management Group, 1997
[Dagnone98]
Dagnone, C.A.F. et al. Formatos de documentos na Web - XML.
Relatório de IA 368 F.
[Evans97]
Evans, E. and Rogers, D. Using Java applets and CORBA for multi-user
distributed applications. IEEE Internet Computing, 1(3):43-55, May-June
1997
[Granja98]
Granja, I. et al. XML, Diferentes visões de um mesmo dado.
Relatório de IA 368 F.
[Keahey97]
Keahey, K. A Brief Tutorial on CORBA, in CORBA
for Beginners,
Object Management Group, 1997
[Luotonen94]
Luotonen, A. and Altis, K. World-Wide Web Proxies.
First International World-Wide Web Conference - May 94.
[Magalhães98]
Magalhães, L.P. e Ricarte, I.L.M. IA368 - Tecnologias da Infraestrutura
de Informação em Ambientes Colaborativos de
Ensino. Disciplina do Curso
de Pós-graduação do DCA/FEEC/Unicamp, 1998.
[Morgan97]
Morgan. B : CORBA meets Java, JavaWorld
2(10), October 1997
[Orfali97]
Orfali, R. and Harkey, D. : Client/server, CORBA/Java-Style.
In Client/server programming with Java and CORBA,
John Wiley and Sons,1997
[Pimenta98]
Pimenta, M.F. e Soares, M.V. Formatos de Documentos na Web.
Relatório de IA 368 F.
[Rosenberg97] Rosenberg, J. When to use CORBA, Javology 2(3), April-May 1997
[Santos98]
dos Santos, A. D. e Schulze,R. S. Programação na
Web - Relatório Final.
Relatório de IA 368 F.
[Schmidt97]
Schmidt, D. Overview of CORBA, in CORBA
for Beginners,
Object Management Group, 1997
[Vinoski97]
Vinoski, S. CORBA: Integrating Diverse Applications Within Distributed
Heterogeneous Environments, IEEE Communications Magazine,
Feb. 1997.
[Yang96]
Yang, Z and Duddy, K. CORBA: A Platform for Distributed Object Computing.
Report of Distributed
Systems Group. Information System Institute,
Technical University of Vienna.
1996.