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:
comunica_i(CORBA::string nome);
virtual string obter(CORBA::Environment &env);
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 {
readonly attribute string nome;
char obter ( );
void apaga ( );
};
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 {
CORBA :: String m_nome;
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( ) {
comunica_i objeto("arquivo.txt");
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 &)
{
...
return m_nome
}
Obs. m_nome ira' guardar o nome do arquivo e comunicaVar e' um objeto
[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.
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