Grupo 3 e 4


Armando Delgado
Carlos D.
Marcio
Maria das Gracas
Valmir
Maria Angelica
Jose Carlos
Rossano
Luciana M.
Marcia
Raquel Cristina (Relatora)


Cenário

O novo cenário consiste na junção direta das situações 3 e 4. Ao analizarmos com atenção, as principaisdiferenças entre as duas situações iniciais são:

1. Forma de definição dos tópicos: os tópicos usados para obter o material a ser disponibilizado ao aluno são selecionados pelo próprio aluno (situação 4) ou definidos automaticamente em função do "perfil" do aluno (i.e., histórico de navegação + histórico acadêmico + tipo de audiência);

2. Forma com que o material é disponibilizado ao aluno: o conjunto de material relativo aos tópicos selecionados é apresentado imediatamente (situação 3) ou o material encontrado é apresentado após algum tempo (situação 4). Assim, o novo cenário permite 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. Uma vez definida a lista de tópicos, o servidor de disciplinas 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.


Funcionalidade

Esta operacão, por envolver materiais que podem estar em diversos locais de uma rede de computadores, será implementada utilizando CORBA, como segue abaixo.

"Busca de material a partir de um conjunto de tópicos "

Para o processo cliente fazer a requisição dos documentos pretendidos, ele chama uma rotina [1] stub correspondende ao objeto e a operação pretendida.

Exemplo do stub, no arquivo comunica_i.h :

public:

O ORB localiza o código da implementação, transmite os parâmetros e transfere o controle para implementação de objeto através de uma [2] IDL específica do objeto.

Exemplo da IDL, no arquivo comunica.idl :

Interface comunicacao {

};

Obs. O processo cliente desconhece a estrutura interna do objeto, porque somente é necessário o contato com a sua interface.

Ao executar o serviço solicitado, a implementação do objeto acessa os serviços providos pelo ORB através de um [3] adaptador de objeto, o BOA (Basic Object Adapter).

Exemplo de um adaptador de objeto, no arquivo comunica_i.h :

class comunica : public comunicaBOAImpl {

Esse adaptador será responsável por ativar / desativar a implementação do objeto, por manter o registro das implementações, pela invocação de métodos e segurança da interação entre os elementos envolvidos.

O objeto é disponibilizado no servidor. Este objeto será o nome de uma base de dados, que guarda o conteúdo efetivo do material que será disponibilizado.

Exemplo:

int main( ) {

O construtor comunica_i, implementado no arquivo comunica_i.h, é então invocado pela chamada do servidor.

Exemplo:

comunica_i:: comunica_i(CORBA::String nome);

O cliente obtém uma referência do objeto do servidor, através da invocação do método Obter, no arquivo comunica_i.h.

Exemplo no arquivo cliente.c :

x = comunicaVar -> obter( );


Exemplo no arquivo comunica_i.h :

CORBA::String comunica_i::obter(CORBA::Environment &)
{

}

Obs. m_nome ira' guardar o nome do arquivo e comunicaVar e' um objeto


Notas

[1] Os stubs são rotinas geradas na compilação da descrição da interface do objeto, disponíveis na forma de rotinas de biblioteca e chamadas como procedimentos normais de uma linguagem de programação.

[2] Uma IDL é uma linguagem de definição do CORBA, simplesmente declarativa, sem definição de variáveis ou algoritmos. Nela existem apenas os tipos, constantes, e operações necessárias para especificar uma interface de objeto.

[3] O adaptador de objetos é a interface através da qual uma implementação acessa as funções do ORB. Pode existir um adaptador de objetos ou dois ao mesmo tempo, dependendo da implementação.


Referência

CORBA - Common Object Request Broker Architeture
Frank Siqueira
LCMI - Laboratório de Controle de Microinformática
Depto de Engenharia Elétrica - Universidade Federal de Santa Catarina