Projeto Usando CORBA

Sistemas de Objetos Distribuídos - Primeiro Semestre de 2003

	Descriçao Geral
	Metas
	Etapas

	Requisitos
	Registro das equipes

Em construção...

Descrição Geral

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 devem 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 três 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 duas etapas, que corresponderão aos EPs 1 e 2 de SOD (MAC 440/5759). Ao final da segunda etapa as equipes farão uma demonstração do funcionamento de seus sistemas.

Primeira Etapa (EP1 de SOD)

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 (EP2 de SOD)

Implementação completa do servidor, que agora armazena num banco de dados as informações sobre peças. Nesta etapa os objetos Part (bem como as referências CORBA para esses objetos) são persistentes. 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 ou um ServantLocator (a seu critério) para resolver este problema.
- Solução com DefaultServant: a cada chamada remota de operação faça o servente default "vestir a camisa" do objeto CORBA alvo da chamada.
- Solução com ServantLocator: use o 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.
Parte opcional: faça duas implementações distintas de servidor, uma deles com um servente default e a outra com instanciação de serventes sob demanda, e compare os desempenhos de seus dois servidores.

Requisitos

Devem ser utilizados os seguintes ORBs:

MICO (ORB para C++)
JacORB (ORB para Java)

O projeto deve empregar mais de uma linguagem, isto é, não pode ser inteiramente escrito em C++ ou em Java. Em pelo menos uma das etapas, um dos programas (servidor ou cliente) produzidos deve ter sido escrito numa linguagem diferente do outro.

Registro das Equipes

Este projeto será desenvolvido em equipes de um ou dois alunos. As equipes devem se registrar com o professor, via email, até o dia 27 de março.

Equipes registradas:

Daniel André Vaquero (daniel at linux.ime.usp.br)
Daniel de Angelis Cordeiro (danielc at linux.ime.usp.br)
Paulo Silveira (paulo at paulo.com.br)
Renato Lucindo (lucindo at linux.ime.usp.br)
Thiago Moura Witt (witt at linux.ime.usp.br)
Danilo Toshiaki Sato (dtsato at linux.ime.usp.br)
Fernando Kasten Peinado (fernandopeinado at uol.com.br)
Eduardo Leal Guerra (eguerra at linux.ime.usp.br)
Vladimir Emiliano Moreira Rocha (vmoreira at linux.ime.usp.br)
Leonardo Miyagi (lmiyagi at abril.com.br)
David Paulo Pereira (email?)
Camila Correa Moraes (cacm at ime.usp.br)
Wagner César Bruna (wbruna at ipt.br)
Edgar Szilagyi (edgar at cecm.usp.br)
Yen Chin Schem (email?)
Fábio Pará D' Incecco (incecco at ime.usp.br)
Eric Soares Costa (elbarto at ig.com.br)
Igor Ribeiro Sucupira (igorrs at linux.ime.usp.br)
Andrew Gan King Yuan (andrew.yuan@attglobal.net)
Carlos Alberto Guimarães (carlos.guimaraes at compatibile.com.br)
Luiza Pagliari (lufp82 at yahoo.com.br)
Fernando Alberto de Sousa (email?)
Adriano Nagelschmidt Rodrigues (anr at ime.usp.br)
Fábio Henrique Nishihara (fhn at linux.ime.usp.br)
Marcos Roberto Yukio Koga (marcos at linux.ime.usp.br)
Bruno Pera (pera at linux.ime.usp.br)
Leo Watanabe (leowww at linux.ime.usp.br)
Carolina Siequeroli (c.siq at terra.com.br)
Fabio Braga de Oliveira (email?)
Denis Ferreira Lima (dflima at yahoo.com.br)
Thiago S. Barcelos (barcelos at ime.usp.br)
Rodrigo M. Barbosa (rodbar at ime.usp.br)
Antonio Wagner Martins Filho (awmf at ime.usp.br)
Peter Kreslins Junior (pkj at linux.ime.usp.br)
Marcos Eduardo Bolelli Broinizi (email?)
Alfredo Roberto Junior (alfredo at linux.ime.usp.br)
Thiago Faria Marzano (marzano at linux.ime.usp.br)
Fábio Levy Siqueira (levy.siqueira at poli.usp.br)
Ricardo Pinto Giorgi (ricardo.giorgi at poli.usp.br)
Flávia Rainone (flaviarnn at yahoo.com)
Stefan Neusatz Guilhen (sngim at linux.ime.usp.br)
Gustavo Rodrigues Silva (gustavor at linux.ime.usp.br)
Pedro Vasconcellos (vascon at linux.ime.usp.br)
Leandro Esteves Barion (lebarion at uol.com.br)
Rodrigo Dombrowski (rodrigod at linux.ime.usp.br)
André Casado Castaño (casades at uol.com.br)
Maíra de Assis Ramos (mairaramos at hotmail.com)
Marcus Machado Sampaio Moyses (mmoyses at linux.ime.usp.br)

Last modified: Thu Apr 24 18:29:57 EST 2003
Francisco Reverbel
reverbel at ime.usp.br