Sistemas de Objetos Distribuídos - Projeto

Segundo Semestre de 2000

Prof. Francisco Reverbel

. Descrição Geral
. Etapas
. Metas
         
. Prazos
. Registro das Equipes

Descrição Geral

Vamos construir uma "versão enxuta" de um sistema que mantém registros distribuídos por vários servidores. Os registros serão objetos CORBA cuja interface é Record. Um Record contém um conjunto de pares (nome, valor). Esses pares são os atributos do registro. Eis um exemplo de registro: 

    titulo          alien
    ano             1979
    diretor         ridley scott
    com             sigourney weaver
    com             harry dean stanton
    com             yaphet kotto
As linhas acima representam os atributos do registro. A primeira coluna traz o nome do atributo e a segunda o valor. Um registro pode ter vários atributos com o mesmo nome. (O registro acima tem três atributos com o nome "com".) Todo registro tem um atributo chave especificado na criação do registro. (O atributo chave do registro acima é o título, que aparece destacado.) O nome do atributo chave é único dentro do registro, ou seja, nenhum outro atributo do registro pode ter o mesmo nome que o atributo chave.

Cada servidor implementará um objeto RecordSet, que é essencialmente uma coleção de Records. Um registro de um RecordSet é univocamente identificados por seu atributo chave. Em outras palavras: num RecordSet não podem existir dois registros com nomes iguais e valores iguais no atributo chave.

As definições (em IDL) das interfaces Record e RecordSet encontram-se no arquivo sod.idl. Use-o sem fazer alteração nenhuma. Para que os programas escritos pelas diferentes equipes funcionem em conjunto, é crucial que todos se baseiem nas mesmas definições de interfaces.

Etapas

Numa primeira etapa os servidores implementados pelas várias equipes serão isolados. Cada servidor implementará um objeto RecordSet com os registros mantidos localmente pelo servidor.

Na segunda etapa os servidores deixam de ser isolados. Cada servidor implementará dois objetos RecordSet:

O conjunto de registros local é o mesmo da primeira etapa. O conjunto de registros global é uma "união" dos conjuntos de registros locais dos vários servidores. O usuário que roda um programa cliente e se conecta ao servidor S tem acesso não só aos registros locais mantidos pelo servidor S, mas também aos registros locais dos demais servidores registrados no serviço de nomes. A idéia é fazer isso com um mínimo de alterações no programa cliente. Mesmo estando conectado a um dado servidor, o cliente poderá ver um "conjunto de registros virtual" que corresponde à "união" de todos os conjuntos locais. Estamos colocando entre aspas a palavra "união", por que não se trata de uma simples união de conjuntos: dois ou mais registros locais com o mesmo atributo chave geram um só registro global.

Exemplificando: os dois registros locais abaixo geram um só registro global.

Metas

Cada equipe de projeto escreverá um "programa servidor" e um "programa cliente".

O Servidor

O programa servidor implementará as interfaces descritas descritas no arquivo sod.idl. Na primeira etapa não será implementado o conjunto de registros global (o globalRecordSet será null).

O Cliente

O programa cliente será usado para exercitar o sistema. Ele deve permitir que o usuário:

Fique à vontade para definir como seu programa cliente vai interfacear com os usuários. O único requisito é que a interface com o usuário permita que o sistema seja exercitado da forma descrita acima. Em particular, o programa cliente deve possibilitar que um usuário crie (de modo razoavelmente conveniente) registros globais cujos atributos estejam distribuídos por vários servidores.

Provavelmente o mais fácil é escrever um cliente com uma interface tipo linha de comando. Uma possibilidade é um cliente "linha de comando" que mantenha duas variáveis:

Tal cliente apresentaria um prompt e ficaria esperando comandos do usuário. Ele aceitaria comandos como:

local Faz o cliente se conectar a outro servidor e passa a trabalhar com o RecordSet local desse servidor. Este comando recebe o nome de um servidor, obtém do serviço de nomes uma referência para o objeto Server correspondente, e deste objeto obtém uma referência para o conjunto de registros local do Server. Este conjunto de registros passa a ser o RecordSet corrente.
global Faz o cliente se conectar a outro servidor e passa a trabalhar com o RecordSet global fornecido por esse servidor. Este comando recebe o nome de um servidor, obtém do serviço de nomes uma referência para o objeto Server correspondente, e deste objeto obtém uma referência para o conjunto de registros global do Server. Este conjunto de registros passa a ser o RecordSet corrente.
addrec Adiciona um registro ao RecordSet corrente. Recebe o atributo chave do novo registro, que passa a ser o Record corrente.
getbykey Busca um registro por atributo chave. A busca é efetuada no RecordSet. Se encontrado, o registro passa a ser o novo registro corrente.
all Lista os (atributos chaves) de todos os registros do repositório corrente.
findone Lista os (atributos chaves dos) registros do RecordSet corrente que contém algum dos atributos de uma lista especificada.
findall Lista os (atributos chaves dos) registros do RecordSet corrente que contém todos os atributos de uma lista especificada.
addattr Adiciona um atributo ao registro corrente.
attrs Mostra todos os atributos do registro corrente e indica qual deles é o atributo chave do registro.
quit Encerra a execuçao do cliente.

A lista acima tem a finalidade de ilustrar como um cliente "linha de comando" poderia funcionar. Tome-a como uma sugestão (provavelmente incompleta), que pode ser seguida ou não. Se você tiver gás para escrever um cliente com uma interface com o usuário mais elaborada e amigável (GUI), vá em frente!

Prazos

. Etapa 1: 22 de novembro
. Etapa 2: 13 de dezembro

Registro das Equipes

O projeto será desenvolvido em equipes de um ou dois alunos. As equipes devem se registrar com o professor, via email, até o dia 10 de novembro.

. Equipes registradas:
  1. Nélio Alves Pereira Filho (nalvesp@linux.ime.usp.br)
    Ricardo Koji Ushizaki (riko@linux.ime.usp.br)

  2. Marcelo Luis Vinagreiro (mlv@linux.ime.usp.br)
    Wu Chen Lung (wlung@linux.ime.usp.br)

  3. Marcelo Gulfier (marcelo.gulfier@br.abnamro.com)
    Marcos Kazuo Higuti (marcos.kazuo.higuti@br.abnamro.com)

  4. Carlos Futino Barreto (futino@ime.usp.br)
    Robson Augusto Siscoutto (siscouto@ime.usp.br)

  5. Jeferson Roberto Marques (jmarques@linux.ime.usp.br)
    Roberto Speicys Cardoso (speicys@linux.ime.usp.br)

  6. Alex Pires de Camargo (acamargo@linux.ime.usp.br)
    Leonardo Marques Alves de Pinho (lmap@linux.ime.usp.br)

  7. Claudia Lúcia Suyama (clsuyama@uol.com.br)

  8. Alexis Sakurai Landgraf Carvalho (alexis@cecm.usp.br)

  9. José Kazuo Ikai (jikai@linux.ime.usp.br)

  10. Marcelo Nunes de Carvalho (marcelon@ime.usp.br)

  11. Charlie Yukio Nakagawa (charlie@linux.ime.usp.br)
    Marcos Tatsuo Yamamoto (mty@linux.ime.usp.br)

  12. Jacques Salo Zweiman (kiko@linux.ime.usp.br)
    Ricardo Bueno Cordeiro (rbc@linux.ime.usp.br)

  13. Daniel Imamura (dimam@agestado.com.br)
    Herbert Yutaka (yutaka@agestado.com.br)

  14. Márcio Oikawa (koikawa@ime.usp.br)
    Gustavo Tadao Okida (gtadao@ime.usp.br)

  15. Fábio Grezele (fg@ime.usp.br)
    Flávio Régis de Arruda (regis@linux.ime.usp.br)

  16. Lourival Paulino da Silva (loupaul@ime.usp.br)

  17. Edgard Pevidor de Miranda (epevidor@imejr.ime.usp.br)

  18. Roberto José Giordano Barra (giord@uol.com.br)

Valid CSS! Valid XHTML 1.0! Last modified: Tue Dec 12 23:49:45 BRDT 2000
Francisco Reverbel
reverbel at ime.usp.br