Sistemas de Objetos Distribuídos - Projeto

Segundo Semestre de 1997

	Descrição Geral
	Metas
	Etapas
	Prazos
	Registro das Equipes

Descrição Geral

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 automàticamente 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.

Os sub-componentes de um objeto Part agregado são também objetos Part. Esses objetos não são necessàriamente 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

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 execucã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. (Uma implementação portável deste comando teria de usar o serviço de nomes. Mas neste projeto é aceitável que voce opte pela simplicidade e chame a função _bind do Orbix.) 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. (É so' 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 voce tiver gás para escrever um cliente com uma interface com o usuário mais elaborada e amigável (GUI), vá em frente!

Etapas

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: Término da implementação do servidor. Agora as informações sobre peças são armazenadas persistentemente. A queda e a reativacão de servidores não devem ter nenhum efeito sobre os relacionamentos entre as peças mantidas por esses servidores. Trabalhe considerando que o número de objetos Part implementados por um servidor pode ser grande o suficiente para inviabilizar a ativação simultânea de todos eles. Ou seja, voce precisará de um loader que ative dinâmicamente esses objetos.

Ao final da segunda etapa as equipes de projeto farão uma demonstração do funcionamento de seus sistemas.

Prazos

	Primeira etapa: 29 de outubro
	Segunda etapa: 21 de novembro

Registro das Equipes