Sistemas de Objetos Distribuídos - Projeto

Segundo Semestre de 1999

Descriçao Geral

Metas

Etapas

Prazos

Registro das equipes

Em construção...

Vamos construir uma "versão enxuta" de um sistema de informações sobre "peças" ou "componentes" (parts). O sistema será distribuído por múltiplos servidores CORBA, cada qual implementando um repositório de informações sobre peças. Cada peça será representada por um objeto cuja interface é Part. Cada servidor implementará um objeto PartRepository, que é essencialmente uma coleção de Parts.

As definições (em IDL) das interfaces Part e PartRepository encontram-se neste arquivo. 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.

Cada objeto Part encapsula as seguintes informações:

o código da peça, um identificador automaticamente gerado pelo sistema na ocasião da inserção das informações sobre a peça;
o nome da peça;
a descrição da peça;
a lista de sub-componentes da peça.

Uma peça pode ser uma agregação de sub-componentes ou pode ser uma peça primitiva (não composta por sub-peças). Sua lista de sub-componentes contém pares (subPart, quant), onde subPart referencia um sub-componente da peça, e quant indica quantas unidades do sub-componente aparecem na peça. Uma peça primitiva tem lista de componentes vazia.

Os sub-componentes de um objeto Part agregado são também objetos Part. Esses objetos não são necessariamente implementados pelo servidor CORBA que implementa a peça agregada. Eles podem estar distribuídos por múltiplos servidores. Tais servidores podem inclusive ter sido escritos por diferentes equipes de projeto.

Metas

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

O Servidor

O programa servidor implementará as interfaces PartRepository e Part. Escreva-o tendo em mente que poderão ocorrer várias execuções simultâneas do programa servidor: cada "processo servidor" (uma execução do programa servidor) implementará um objeto PartRepository, mais a correspondente coleção de objetos Part. Isto significa que o programa servidor deve receber como argumentos, na linha de comando, certos parametros que tem de variar de um processo servidor para outro (o nome do servidor, por exemplo).

O Cliente

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

estabeleça uma conexão com um (processo) servidor;
interaja com o repositório implementado pelo servidor,
- examinando o nome do repositório e o numero de peças nele contidas,
- listando as peças no repositório,
- buscando uma peça (por código de peça) no repositório,
- adicionando ao repositório novas peças (primitivas ou agregadas);
tendo uma referência a uma peça, referência essa previamente obtida como resultado de uma busca num repositório, interaja com a peça,
- examinando o nome e a descrição da peça,
- obtendo o (nome do) repositório que a contém,
- verificando se a peça é primitiva ou agregada,
- obtendo o número de sub-componentes diretos e primitivos da peça,
- listando suas sub-peças.

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) peças agregadas cujas sub-peças estejam distribuídas por vários repositórios. Provavelmente o mais fácil é escrever um cliente com uma interface tipo linha de comando. Uma possibilidade é um cliente "linha de comando" que mantenha tres variáveis:

o "repositório corrente", uma referência ao repositório com o qual toda interação ocorre;
a "peça corrente", uma referência à peça com a qual toda interaçao ocorre;
a "lista de sub-peças corrente", usada exclusivamente quando uma nova peça é adicionada ao repositório corrente.

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

bind Faz o cliente se conectar a outro servidor e muda o repositório corrente. Este comando recebe o nome de um repositório e obtém do serviço de nomes uma referência para esse repositório, que passa a ser o repositório corrente.

listp Lista as peças do repositório corrente.

getp Busca uma peça por código. A busca é efetuada no repositório corrente. Se encontrada, a peça passa a ser a nova peça corrente.

showp Mostra atributos da peça corrente.

clearlist Esvazia a lista de sub-peças corrente.

addsubpart Adiciona à lista de sub-peças corrente n unidades da peça corrente.

addp Adiciona uma peça ao repositório corrente. A lista de sub-peças corrente é usada como como lista de sub-componentes diretos da nova peça. (É só para isto que existe a lista de sub-peças corrente.)

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 (incompleta, por sinal), 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!

Etapas

O projeto será dividido em 3 etapas. Ao final da terceira etapa as equipes farão uma demonstração do funcionamento de seus sistemas.

Primeira Etapa

Implementação parcial do servidor.
Todas as operações estão implementadas, mas as informações sobre peças não são armazenadas em disco. Quando um servidor encerrar sua execução, todos os dados que ele mantinha se perderão.
Implementação completa do cliente.
Use o cliente para exercitar e testar o sistema como um todo. Enquanto todos os servidores envolvidos estiverem ativos, tudo deverá funcionar (inclusive os relacionamentos entre peças e sub-peças distribuídas por vários servidores).

Segunda Etapa

Implementação completa do servidor, usando um DefaultServant para os objetos Part.
Agora as informações sobre peças são armazenadas persistentemente. A queda e a reativação de servidores não devem ter nenhum efeito sobre os relacionamentos entre as peças mantidas por esses servidores.
Considere que o número de objetos Part implementados por um servidor pode ser grande a ponto de não ser possível manter em memória um servente para cada Part. Use um DefaultServant para resolver este problema.

Terceira Etapa

Reimplementação do servidor, agora com um ServantLocator para os objetos Part.
Os requisitos são os mesmos da etapa anterior: as informações sobre peças são armazenadas persistentemente e o número de objetos Part no servidor pode ser grande a ponto de não ser possível manter em memória um servente para cada um deles.
Em vez ter um servente default para todos as Parts no servidor, use um ServantLocator para fazer instanciação de serventes sob demanda. Aplique o evictor pattern para manter um cache dos serventes que foram utilizados mais recentemente e para se livrar dos demais.

Prazos

Etapa 1: 18 de outubro

Etapa 2: 16 de novembro

Etapa 3: 29 de novembro

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 4 de outubro.

Equipes registradas:

Paulo Teodoro Simardi (simardi@ime.usp.br)

Bruno Fernandes Degani (bfdegani@linux.ime.usp.br)
Fabio Luiz Ide (fli@linux.ime.usp.br)

Alexandre Ricardo Nardi(nardi@ime.usp.br)

Hamilton Nishimura (guido@linux.ime.usp.br)
Telmo Dias de Souza Carlos (telmo@linux.ime.usp.br)

Débora dos Santos Botta (debora@linux.ime.usp.br)
Wagner Dias (dias@ansp.br)

Leonardo Rochael Almeida (rochael@ime.usp.br)
Fernando Antônio Mac Cracken Cezar (cracken@ime.usp.br)

Jorge Bittencourt (jorgeb@ime.usp.br)
Marcelo Camacho de Souza (mcsouza@ime.usp.br)

Marcelo Brito dos Santos (brito@ime.usp.br)
Marcos Paulo Januário de Sousa (mpjs@ime.usp.br)

Alencar Yukio Shibayama (ays@linux.ime.usp.br)
Daniel Müller (muller@ime.usp.br)

Bruno Martins Moutinho (bruno@ime.usp.br)

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

João Luiz Cury Silvestre (jlcs@linux.ime.usp.br)

Roberto Toscano Costa (rtoscano@ime.usp.br)

Clóvis Seragiotto Júnior (junior@ime.usp.br)

João Dubeux Kawamura (joaodk@linux.ime.usp.br)
Alexandre Sussumu Hirohashi (lau@linux.ime.usp.br)

Ariane Machado Lima de Oliveira (ariane@ime.usp.br)
Regina Rocha de Morais Gonçalves (regi@ime.usp.br)

Rodrigo Vargas Crozato (vargas@linux.ime.usp.br)

Andrés Camacho
Marcelo Poeta Blasco (mblasco@linux.ime.usp.br)

Gabriel De Munno Francisco (gmunno@linux.ime.usp.br)
Raquel de Paula (rpaula@linux.ime.usp.br)

Cristina Ferreira Freitas Assunção (cristina@linux.ime.usp.br)

Alexandre Mello (alex_mello@yahoo.com)
Aldebaran Perseke (aldeba@ime.usp.br)

Francisco José da Silva e Silva (fssilva@ime.usp.br)
Huang Kuo Tching (huangkt@ime.usp.br)

Jeferson Roberto Marques (jmarques@linux.ime.usp.br)
Rogério César Iamamoto (iamamoto@linux.ime.usp.br)

Jishu Ashimine (jishu@ime.usp.br)

Last modified: Fri Nov 12 16:03:34 EDT 1999
Francisco Reverbel
reverbel at ime.usp.br

`bind`	Faz o cliente se conectar a outro servidor e muda o repositório corrente. Este comando recebe o nome de um repositório e obtém do serviço de nomes uma referência para esse repositório, que passa a ser o repositório corrente.
`listp`	Lista as peças do repositório corrente.
`getp`	Busca uma peça por código. A busca é efetuada no repositório corrente. Se encontrada, a peça passa a ser a nova peça corrente.
`showp`	Mostra atributos da peça corrente.
`clearlist`	Esvazia a lista de sub-peças corrente.
`addsubpart`	Adiciona à lista de sub-peças corrente `n` unidades da peça corrente.
`addp`	Adiciona uma peça ao repositório corrente. A lista de sub-peças corrente é usada como como lista de sub-componentes diretos da nova peça. (É só para isto que existe a lista de sub-peças corrente.)
`quit`	Encerra a execuçao do cliente.

	Etapa 1: 18 de outubro
	Etapa 2: 16 de novembro
	Etapa 3: 29 de novembro