1. Introdução

2. Definições

3. Cenário

4. Propostas de implementação

5. Justificativas

6. Conclusão

Referência Bibliográficas

1. Introdução

A tecnologia disponibilizada representada pela dupla CORBA/Java, permite a concepção e construção de aplicações para processamento no ambiente da Web, sendo que estas são mais sofisticadas que aquelas produzidas pela tecnologia HTTP/CGI.

CORBA foi projetado para resolver problemas de interoperabilidade entre os componentes da aplicação. Se considerarmos que diferentes programas, objetos, funções, base de dados e outros, como componentes que necessitam de funcionalidades próprias, então o problema é interagir com todos estes componentes.

O CORBA descreve essencialmente como as aplicações de um cliente podem invocar operações no servidor usando os serviços do ORB, sendo que ele é um sistema composto por objetos, interfaces bem definidas que descrevem os serviços abastecidos a outros objetos do sistema.

As interfaces entre os objetos são a chave para o sistema CORBA. O ORB deve permitir que um objeto use outro, até mesmo sendo os dois implementados em linguagens diferentes e executados em máquinas com sistemas operacionais distintos.

Cada objeto CORBA tem uma interface definida em IDL. O ORB transporta as requisições de um objeto para outro e realiza qualquer tradução que seja necessária entre quem chamou e o objeto.

Por outro lado, segundo a referência [1] a linguagem Java é um primeiro passo para a criação de objetos na Web, entretanto não é suficiente. Ela oferece uma grande flexibilidade para o desenvolvimento de aplicações distribuídas, mas não suporta o paradigma cliente/servidor. Portanto, Java precisa ser acrescida por uma infraestrutura com objetos distribuídos, sendo esta a CORBA. Utilizando agora a referência [2], ela coloca que enquanto CORBA está preocupada com a interface e com os componentes da aplicação modelados como objetos, Java lida com a implementação destes objetos. Pelo que foi apresentado, percebe-se que CORBA e Java são ferramentas que se complementam.

Este trabalho apresenta três propostas de arquitetura para implementação na Web, das funcionalidades da aplicação "Curso sob medida + Prova virtual" baseadas nas possibilidades oferecidas pela tecnologia CORBA/Java.

2. Definições

HTML: a Hypertext Markup Language é uma linguagem de hipertextos para disponibilização e publicação de documentos na WWW, que descreve documentos e especifica rótulos (tags) e interrelaciona suas estruturas.

CGI: a Common Gateway Interface é um padrão que determina como os aplicativos externos fazem interface com os servidores Web. A CGI fornece um meio de escrever programas que rodarão no servidor quando forem invocados pelo browser Web cliente por meio de código HTML.

Java: linguagem de programação orientada a objetos.

ORB: Object Request Broker é um mecanismo padrão através do qual objetos distribuídos de software e seus clientes podem interagir. Usando ORB um objeto e seus clientes podem residir no mesmo processo ou em outros diferentes, os quais podem ser executados em diferentes hosts conectados à rede.

CORBA: Commom Object Request Broker Architecture é um padrão para a interoperabilidade entre ambientes heterogêneos. Descreve como uma aplicação cliente pode invocar operações em um servidor de objetos usando os serviços de um intermediário conhecido como ORB.

IDL: Interface Definition Language é uma linguagem declarativa que pode ser usada para especificar as operações que o cliente pode invocar em um objeto. É uma linguagem orientada a objetos com um modelo simples, agindo como uma linguagem universal entre diferentes programas e sistemas. É definida com um nome, uma lista de herança, uma lista de operações e atributos.

O cenário deste trabalho foi desenvolvido e discutido durante as aulas do curso Tópicos em Engenharia de Computação V (IA368F - Tecnologias de Infraestrutura de Informação em Ambientes Colaborativos de Ensino), cuja conclusão consensual de todos os participantes pode ser visto no documento Formato de documentos na Web [4]. Destacam-se abaixo somente as funcionalidades que foram levantadas e que estão envolvidas com a aplicação em estudo.

4. Propostas de implementação

Durante a discussão em grupo do tema, foram levantadas três propostas de arquitetura (todas cliente/servidor) de implementação das funcionalidades. Essas propostas são descritas a seguir:

Cada instituto (unidade acadêmica ou faculdade) com o seu próprio servidor, sendo que este atenderia todas as suas funções, incluindo as atividades de cunho administrativo.

Considere agora cada instituto com o seu próprio servidor, entretanto este atenderia somente as necessidades didáticas, recebendo o nome de Servidor de Unidade Acadêmica (SUA).

Seria necessário também a existência de um servidor que fosse dedicado ao suporte administrativo, realizando todas as tarefas de controle (por exemplo: realizar matrícula, cadastrar usuários, cadastrar senhas, perfil do aluno, disciplinas cursadas, etc), recebendo o nome de Servidor de Suporte Administrativo (SSA).

Nesta proposta novamente cada instituto teria o seu próprio servidor (SUA) e, também, existiria a presença do servidor dedicado às tarefas administrativas (SSA). A diferença, então, seria a existência de um único servidor que somente tratasse dos assuntos relativos a avaliação nomeado de Servidor de Assuntos de Avaliação (SAA).

Note que nestas três propostas seria possível e necessária a comunicação dos servidores com os seus clientes (por exemplo: os alunos) e com todos os demais servidores envolvidos no processo (em algumas situações os servidores terão papel de clientes em relação uns aos outros).

Realizando um levantamento das funcionalidades apresentadas no item anterior com relação a Proposta 03 apresentada acima, identifica-se quais servidores atendem a quais funções. Assim, o Servidor de Suporte Administrativo atenderá as funcionalidades F3 e F9. Agora, o Servidor de Assuntos de Avaliação atenderá a F7 e F8. Em seguida o Servidor de Unidade Acadêmica fornecerá suporte a F1, F2, F5 e F6. Por último, os clientes devem suportar a funcionalidade F4.

Como cada unidade acadêmica possui características diferentes, portanto recursos diferentes são necessários para atender a demanda das diversas aplicações. Por exemplo, o Instituto de Artes necessitaria de recursos de animação, tratamento de cores e outras, enquanto que o Instituto de Letras necessitaria predominantemente de recursos para tratamento de grande volume de textos. Nesse sentido, a padronização não é desejável, pois a natureza da informação tratada (texto, vídeo, som, etc) e a vocação de cada unidade exige a diferenciação. Justifica-se assim a escolha de distribuição de servidores especializados para cada unidade acadêmica.

A segunda distribuição (servidores por funcionalidade) justifica-se devido a busca de facilidade de concepção, construção e manutenção de objetos que disponibilizem serviços semelhantes. Por exemplo, aplicar e corrigir um teste não é muito diferente sendo o teste de Geografia ou Matemática. Basicamente as funções exigidas são a de oferecer uma planilha contendo as opções, comparar respostas escolhidas das questões com um gabarito e, por fim, pontuar segundo pesos pré estabelecidos.

A necessidade da utilização de CORBA/Java é justificada pela presença de tecnologias diferentes, ou seja, plataformas distintas, sistemas operacionais e linguagens de autoria diversificadas e recursos característicos a cada um dos institutos. Dessa maneira, a intenção é fornecer autonomia aos institutos e torná-los independentes. As referências [1], [2] e [3] vão de encontro com o que foi colocado no parágrafo acima, uma vez que elas ressaltam a heterogeneidade e interoperabilidade da união CORBA/Java.

O ambiente da linguagem Java, a World Wide Web e CORBA são tecnologias complementares, que quando empregadas juntas produzem um conjunto de ferramentas que possibilitam o desenvolvimento de aplicações distribuídas com multi-usuários e com funcionalidades sofisticadas.

As propostas de arquiteturas cliente/servidor baseada em critérios de especialização (vocação dos processos e natureza das informações) e funcionalidades comuns, são, como mostram as justificativas levantadas neste trabalho, uma boa alternativa de implementação de aplicações na Web.

[1] Client/server, CORBA/Java-Style em Client/server programming with Java and CORBA, Robert Orfali, Dan Harkey, John Wiley and Sons, 1997.

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

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

[4] Pimenta, Marcia de Fátima, Soares, Marcio Vieira, Formatos de Documentos na Web, Abril 1998, Tópicos em Engenharia de Computação V (IA368F)