Resource discovery em uma arquitetura P2P aplicado à

distribuição e compartilhamento de componentes de software

Marcílio Oliveira1-2 Islene Garcia1 Aminadab Nunes2
1
Instituto de Computação – Universidade Estadual de Campinas (UNICAMP)
Caixa Postal 6176 – 13.084-971 – Campinas – SP – Brasil
2
Laboratório de Inovação em Software – Ci&T / UNICAMP
Centro de Computação da Unicamp (CCUEC)
marcilio@ccuec.unicamp.br islene@ic.unicamp.br aminadab@cit.com.br

Abstract. The Software Component Sharing Network is one of the results of a

project which is under development in the Software Inovation Laboratory
Ci&T-Unicamp. The purporse of this article is to present the architecture that
solves the problem of resourse discovery and the search for components in the
presented network. A search heuristic in a peer-to-peer network has been
implemented considering independence of a central server and total
knowlegde of the peers in the network. This solution overcomes one of the
main problems that can be found in a tradional peer-to-peer network
architecture, such as independence of a central server and necessity of
knowing about the peers the network has. Besides that, such a solution is
simple to implement and is based on open patterns, which is one of premisses
of the RCCS. We will also present the how the graphical interface to search
for components works.

Resumo. A RCCS, Rede de Compartilhamento de Componentes de Software, é

fruto de um projeto em desenvolvimento no Laboratório de Inovação em
Software Ci&t-Unicamp. O objetivo deste artigo é apresentar a arquitetura
que soluciona o problema de resource discovery e a busca por componentes
na RCCS. Foi implementada uma heurística de busca em uma rede peer-to-
peer (P2P). Esta solução ataca os principais problemas encontrados em
arquiteturas tradicionais de redes P2P, como independência de um servidor
central, e necessidade de conhecimento dos pontos da rede. Além de ser
facilmente implementável e baseada em padrões abertos, que é uma das
premissas da RCCS. Também mostraremos como funciona a interface criada
para a busca.

1. Introdução
Conceitualmente, Peer-to-Peer (P2P) é uma alternativa aos modelos computacionais do
tipo cliente-servidor. O termo P2P se refere a uma classe de sistemas e aplicações que
utilizam recursos distribuídos para realizar funções críticas de maneira descentralizada
[Milojicic et al, 2002]. Através desta tecnologia, um sistema pode acessar diretamente
recursos disponibilizados por outro, independente de terceiros atuando como servidores
centrais.
Várias aplicações P2P podem ser vislumbradas, como processamento de dados
distribuído, sistema de compartilhamento de arquivos distribuído, ou algum outro tipo
de aplicação distribuída. O primeiro passo para qualquer uma destas aplicações é
permitir às maquinas saberem a respeito da existência de outras na rede. Em outras
palavras, os participantes da rede precisam saber: "quem, em toda a rede, gostaria de
cooperar comigo?" Este primeiro passo, segundo [Harchol-Balter et al., 1999], é
conhecido como resource discovery.
O problema de resource discovery vem crescendo no contexto de redes P2P.
Neste contexto, em algum momento o ponto deve ser conhecido e conhecer outro ponto
da rede, uma vez que, um ponto pode comunicar-se diretamente com outro ponto da
rede se, e somente se, ele o conhece.
Este artigo apresenta uma arquitetura P2P para a RCCS, que será detalhada no
tópico 2. Nosso objetivo é resolver o problema de resource discovery na rede de
compartilhamento e montar uma heurística de busca por componentes, levando em
consideração os aspectos arquiteturais, a praticidade e as funcionalidades da rede.
O texto está organizado da seguinte maneira: a seção 2 apresenta a RCCS, com
uma descrição mais detalhada da rede assim como suas principais premissas e soluções
envolvendo P2P e Web Services. A seção 3 apresenta a arquitetura da rede, assim como
a modelagem dos objetos que são transmitidos na rede, com dados de envio e de
resultado das pesquisas por componentes. A seção 4 apresenta as principais
funcionalidades da RCCS, com nossa solução para o problema de resource discovery e
a arquitetura de busca por componentes na rede. Por fim, as conclusões e a descrição
dos trabalhos futuros são apresentadas na seção 5.

2. A Rede de Compartilhamento de Componentes de Software

A RCCS é uma rede aberta, baseada em padrões abertos para comunicação, arquitetura
e modelagem dos componentes. A idéia é que qualquer entidade pode participar como
fornecedora de componentes de software ou apenas consumidora dos componentes
distribuídos na rede. A rede deve funcionar como um repositório ou biblioteca de
componentes, porém de forma totalmente distribuída e independente de entidades
centrais.
Com o grande crescimento das redes de interconexão de computadores para a
troca de informações e serviços, várias aplicações têm exigido mecanismos mais
otimizados para difusão de mensagens. As soluções atuais têm sido encontradas em
algoritmos distribuídos que resolvem problemas clássicos como o de resource
discovery. Porém, várias são as soluções que dificilmente possam ser aplicadas na
prática, devido à complexidade de implementação, como a proposta em [Angluin et al.,
2004] que apresenta uma boa solução, porém com alta complexidade de implementação.
Desta forma, um dos principais focos no desenvolvimento da solução de resource
discovery e da busca é a simplicidade e eficiência com as quais essa solução possa ser
implementada.

2.1. Principais Premissas da RCCS

Para atingir seu propósito, a rede foi idealizada considerando-se algumas premissas
fundamentais. E é em torno destas premissas que as pesquisas e o desenvolvimento se
realizam. A seguir, são listados esses aspectos pré-definidos para a RCCS:
 Utilização de padrões. A rede deve ser modelada seguindo padrões abertos
[OMG, 2004] [Kozaczynski et al, 2003] [IBM, 2004] para facilitar o surgimento
de novas implementações e participações na rede.
Implementação de referência. No processo de construção da arquitetura da rede
deve ser desenvolvida também uma implementação de referência, atuando como
base para o desenvolvimento de novas implementações.
Interoperabilidade. É importante que a rede não esteja restrita a uma plataforma
de desenvolvimento. Como a comunicação deve ser possível entre pontos com
diferentes implementações, é muito importante que a proposta proporcione
interoperabilidade.
Independência de entidade central. A RCCS não deve ser dependente de
nenhuma entidade específica, de modo que nenhum ponto da rede seja
indispensável, e a queda de um ponto (ou simplesmente sua ausência na rede)
não torne a rede indisponível momentaneamente.
Repositórios distribuídos. Não existe um conjunto de repositórios centrais onde
os componentes são armazenados. Estes repositórios devem estar de forma
distribuída, descentralizando os recursos da rede.
Escalabilidade. Tendo em vista que a rede é aberta, é imprescindível que sua
arquitetura suporte escalabilidade em relação ao número de participantes.
Com base nas premissas apresentadas como “independência de entidade central,
repositórios distribuídos, escalabilidade e cada usuário poder disponibilizar
componentes”, a RCCS foi concebida com arquitetura P2P. Neste cenário, tornou-se
chave resolver o problema de resource discovery e desenvolver uma heurística de busca
por componentes na RCCS. Para isso, foi necessário um estudo sobre as principais
arquiteturas P2P, com o objetivo de obter em cada uma delas aspectos positivos que
pudessem ser utilizados na RCCS. No tópico a seguir (tópico 2.2) apresentamos as
principais arquiteturas P2P pesquisadas, assim como uma análise da viabilidade prática
de suas soluções, dados os objetivos da RCCS.

2.2. Arquiteturas Peer-to-Peer

A tecnologia P2P foi fortemente impulsionada por aplicações de compartilhamento e
troca de mensagens bastante populares, como Napster [Ku, 2002], Gnutella [Ripeanu,
2001] e ICQ [ICQ Inc, 2004]. Tais aplicações deixam claro a potencialidade e as
possibilidades de desenvolvimento. Neste contexto, o ambiente acadêmico se mostra
ideal para realizar experimentos e se beneficiar dessa tecnologia, pois pode utilizar
novas ferramentas que auxiliam a troca de informações sem despender recursos
adicionais. [Rocha, 2004].
Após o surgimento de diversas aplicações de compartilhamento de conteúdo na
internet e da popularização dos sistemas de mensagens instantâneas, o assunto P2P
ganhou força e tem chamado a atenção. Porém, em grande parte das características
estudadas dentro do P2P, poucas são novidades. O próprio conceito das aplicações
não é novo. Podemos listar alguns exemplos como telefone, redes internas de jogos,
servidores FTP interligados, que sempre utilizaram o conceito de comunicação ponto a
ponto. Podemos também listar outras características já conhecidas como
descentralização, escalabilidade, realização de operações desconectadas, algoritmos
distribuídos (muitos dos utilizados já são aplicados em outras arquiteturas),
processamento distribuído, etc. Por outro lado, P2P traz consigo novas necessidades,
das quais vale ressaltar as novas necessidades tecnológicas como de segurança e suporte
a escalabilidade.
Junto à idéia de utilização de recursos compartilhados, o P2P traz consigo uma
série de vantagens, como baixo custo de obtenção, pois não é necessário nenhum gasto
adicional com hardware. Além disso, possibilita a escalabilidade, não estando
vulnerável a um crescimento descontrolado da rede. Outra vantagem é a utilização de
recursos ociosos de outros computadores participantes da rede. Por fim, a natureza
descentralizada dos sistemas P2P os protege de alguns tipos de falhas bastante comuns
em sistemas centralizados, onde a falha do servidor central pode ser fatal para o
funcionamento do sistema.
Um sistema P2P pode ter sua arquitetura construída de duas formas: ser um
sistema P2P híbrido ou um sistema P2P puro. Várias outras arquiteturas podem ser
encontradas na literatura, porém, conceitualmente são resultado de uma modificação ou
melhoria destas duas arquiteturas principais [Walkerdine, Melville and Sommerville,
2002], que são apresentadas nos tópicos a seguir.

2.2.1. Arquitetura P2P híbrida – CIA (Centralized Indexing Architecture)

A característica principal de um sistema P2P híbrido é a existência de um ponto central,
que é utilizado para busca de outros elementos (nós) da rede. A existência deste
servidor central para busca não descaracteriza o sistema como peer-to-peer, pois, uma
vez encontrado um recurso, a comunicação é feita diretamente entre os pontos, sem a
necessidade do servidor. A utilização de alguns métodos como armazenamento de
históricos e endereços em cache, torna a rede mais independente da existência de um
servidor central para a busca.
A figura 1 ilustra a busca e a comunicação peer-to-peer em uma rede com
arquitetura híbrida.

Figura 1. Busca e contato em uma rede P2P híbrida.

Pela figura, percebe-se que a busca é realizada em um servidor central e, a

partir do resultado obtido, um ponto conecta diretamente ao outro ponto, caracterizando
a conexão peer-to-peer.
Um exemplo de utilização desta arquitetura é o Napster [Ku, 2002], que é um
sistema de compartilhamento de música na internet que foi bastante utilizado e hoje
serve como uma forte referência para este tipo de rede.
Podemos observar que, uma vez que o processo de busca é centralizado, existe
um ponto de vulnerabilidade, do qual depende toda a rede. Quando o servidor de busca
estiver fora de funcionamento por algum motivo, os usuários não conseguirão encontrar
os outros participantes da rede. Este tipo de dependência é indesejável na RCCS,
tornando a arquitetura híbrida original imprópria para a rede. A RCCS deve ser
totalmente independente de qualquer entidade e o não funcionamento de alguma parte
da rede não deve, em momento algum, comprometer o seu funcionamento.

2.2.2. Arquitetura P2P Pura – DIFA (Distributed Indexing with Flooding Architecture)
Em uma arquitetura P2P pura não existem servidores centrais ou supernós que sejam
responsáveis por encontrar ou armazenar o endereço dos participantes da rede. A busca
é realizada de forma totalmente descentralizada, segundo algum algoritmo distribuído
utilizado.
A figura 2 ilustra a busca em uma rede peer-to-peer com arquitetura pura.

Figura 2. Busca em uma rede P2P pura.

Um exemplo de sistema P2P puro é o Gnutella [Ripeanu, 2001], que não

possui servidor central e utiliza buscas baseadas em flooding. Neste mecanismo de
busca, um ponto da rede dispara a busca para os seus vizinhos, que é novamente
repassada para os vizinhos dos vizinhos e assim em diante. Geralmente é estabelecido
um tempo de vida ou um número de “saltos” para a busca, e isso pode fazer com que
algum ponto da rede não seja visitado, como acontece na figura 2.
Porém, o grande problema de arquiteturas que utilizam algoritmos de flooding
para realizar o resource discovery é a sobrecarga causada na rede. Além disso, é difícil
controlar onde a busca está sendo realizada, uma vez que ela é disparada diversas vezes
por outros pontos da rede que recebem a busca original.
O fato de ser totalmente independente de um servidor central para a busca é
bastante atrativo para uma possível arquitetura da RCCS, porém estas duas
características citadas acima, de sobrecarga na rede e falta de controle sobre a busca,
torna esta arquitetura também incompleta para ser implantada na rede de
compartilhamento.
Desta forma, tendo em vista características positivas nas duas arquiteturas
citadas, uma boa solução seria fazer um sistema que reunisse o melhor de ambas as
arquiteturas (CIA e DIFA), montando um método simples e bastante funcional de
realizar o resource discovery. O método de realizar o resource discovery e a heurística
de busca são apresentados com detalhes na seção 4, na funcionalidade de busca por
componentes.

2.3. Web Services

A comunicação entre um repositório e um consumidor será feita através de Web
Services. Levando em consideração a premissa de utilizarmos padrões abertos, temos
nos Web Services fortes características, promovendo também a interoperabilidade. Eles
oferecem uma nova camada de abstração, permitindo integrar aplicações, mudar a
interface com o usuário e evoluí-las. Sabendo que a necessidade de comunicação entre
os usuários é real, devemos considerar que é mais do que desejável que se criem
mecanismos para que isso aconteça da melhor forma possível, com velocidade e
segurança.
No centro desta visão está o conceito de operabilidade conjunta, ou seja, a
capacidade de sistemas diferentes se comunicarem e compartilharem dados sem estarem
ligados entre si. Este é um dos objetivos dos Web Services.
O grupo de trabalho da W3C (World Wide Web Corsortium) de Arquitetura
dos Web Services chegou a um acordo com relação à definição de um Web Service
[IBM, 2004]. Sua definição é: “um Web Service é uma aplicação de software
identificada por um URI (Uniform Resource Identifier), cujas interfaces e bindings são
capazes de serem definidos, descritos e descobertos como artefatos XML. Um Web
Service permite que haja interações diretas com outros agentes de software utilizando
mensagens baseadas em XML, enviadas e recebidas através de protocolos baseados na
Internet”.
Isso significa dizer que é possível acessar qualquer Web Service disponível na
Internet e utilizar todas as suas funcionalidades. O acesso será na maioria das vezes via
HTTP, mas internamente existe uma cadeia de caracteres XML que está empacotada em
um protocolo SOAP (Simple Object Access Protocol). O SOAP é um padrão aberto
criado por grandes empresas da indústria de tecnologia para padronizar a transferência
de dados em diversas aplicações. Para isso, usou-se o XML (Extensible Markup
Language), que é um padrão amplamente aceito pela indústria de software e,
principalmente, utilizado na definição dos demais protocolos [McIlraith, Son and Zeng,
2001].
Toda a comunicação entre os pontos da rede é feita através de Web Services.

3. Modelagem e arquitetura da rede

Um dos aspectos mais importantes é a modelagem da rede. Como dito anteriormente,
trata-se de uma rede P2P, sem um servidor central. Mas isto não é suficiente. É
necessário identificarmos a arquitetura, determinarmos como os pontos da rede se
comunicarão, qual a tecnologia utilizada pra fazer a troca de informações e como estas
informações serão transmitidas na RCCS.

3.1. Modelagem da rede

A RCCS pretende atingir diversas categorias de entidades relacionadas a
desenvolvimento e utilização de componentes de software. A figura 3 ilustra a forma
com que a rede foi idealizada, com a participação de universidades e centros de
pesquisa, órgãos governamentais, hubs de distribuição de software livre, fábricas de
componentes, dentre outras entidades interessadas em compartilhar ou simplesmente
buscar componentes na RCCS:
 Figura 3. Arquitetura da rede de compartilhamento de componentes de
software.

Em cada repositório de componentes deve haver um servidor onde os serviços

fiquem disponíveis através de Web Services, e a comunicação entre os pontos da rede é
feita através do cliente e o serviço disponibilizado. Desta forma, a arquitetura permite
que os pontos da rede comuniquem-se diretamente, sem a interferência ou dependência
de um servidor central. A inexistência deste servidor central proporciona à rede uma
característica interessante de independência de qualquer entidade. Uma vez
desenvolvido o protocolo de comunicação e uma implementação de referência, qualquer
grupo de usuários pode montar a rede e mantê-la em funcionamento.
No centro do desenvolvimento está o laboratório de inovação em software
Ci&T/Unicamp. Neste laboratório são realizadas pesquisas a respeito de
componentização, arquiteturas P2P, plataformas de desenvolvimento e novas
tecnologias. É do laboratório que deve resultar uma implementação final de referência
para a RCCS, assim como seus modelos, padrões e protocolos.
Hoje muito se vê a respeito da utilização de componentes, mas pouco se faz
para que esta prática de reuso seja realmente difundida, sobretudo dentro de instituições
públicas, que não possuem um catálogo próprio de componentes nem um repositório
onde os componentes necessários possam ser encontrados. E é desta forma, como uma
ferramenta que impulsione práticas de utilização de componentes, que a RCCS deve
funcionar, sobretudo facilitando o compartilhamento e a busca de componentes de
software. Além de validar práticas de compartilhamento em redes Peer-to-Peer.

3.2. Papéis dos participantes da rede de compartilhamento

Levando em consideração que um ponto da rede pode simplesmente procurar por
componentes, não sendo, obrigatoriamente, um repositório, existe uma diferença de
papéis entre os participantes da rede.
Um ponto pode ser simplesmente um consumidor de componentes, disparando
pesquisas na rede para o acesso aos componentes compartilhados. É o que chamamos de
RAB (Reusable Asset Browser), um agente da rede que faz a busca.
 Para o funcionamento da rede, teremos os repositórios de componentes. Um
repositório de componente é denominado RAR (Reusable Asset Repository), que
disponibilizam seus componentes na rede para serem acessados por outros participantes.
Como uma das premissas da RCCS é que qualquer usuário também poderá
disponibilizar seus componentes, é possível que um ponto da rede funcione como RAR
e como RAB ao mesmo tempo, ou seja, compartilhando seus componentes e buscando
por novos componentes na rede.
A RCCS possui servidores de referência, ou yellow pages, que são registros de
repositórios distribuídos. As yellow pages funcionam como catálogos de repositórios de
componentes, que podem ser consultados para que se tenha maior conhecimento dos
participantes da rede. A seção 4.1 detalha o funcionamento da busca por repositórios
nas yellow pages.

3.3. Protocolo de comunicação e troca de objetos na RCCS

O protocolo de comunicação determina quais são e como serão representadas as
informações transmitidas na rede. Como a comunicação é feita através de Web Services,
as informações serão trocadas através de objetos, ou seja, o protocolo trata de quais
objetos são transportados na rede. Para descrever tais objetos, primeiro precisamos
saber como os componentes são representados, uma vez que serão sobre os
componentes as informações transmitidas na rede.
A modelagem do componente foi feita baseada no RAS (Reusable Asset
Specification) [Kozaczynski et al, 2003], que é uma especificação proposta pela
Rational [Rational, 2004] e aceita pela OMG [OMG, 2004] como padrão para
especificação de componentes. É uma representação totalmente baseada em meta
modelos.
O principal objetivo do RAS é especificar a quantidade mínima de meta
informações que um “Reusable Asset”, ou seja, um componente, deve ter. Além disso,
ele determina quais artefatos um componente possui, desde diagramas e casos de uso,
até os arquivos de teste, código fonte e binário.
Algumas alterações foram feitas no padrão proposto pelo RAS, visando
atender as necessidades da rede. As principais alterações foram simplificações feitas no
extenso modelo proposto, porém mantendo a fidelidade ao padrão da OMG.

4. Funcionalidades principais da rede

Devemos pensar em uma rede que possa trazer, de fato, funcionalidades que
impulsionem e incentivem a utilização de componentes. Para isso, algumas
funcionalidades são básicas e, sobretudo, essenciais. Pensando na forma mais natural
de utilizarmos um sistema de compartilhamento, vimos que a busca de material é o
primeiro passo. Levando em consideração alguns sistemas de busca [Google, 2004] e
sistemas populares de compartilhamento de material, observamos que uma busca por
conteúdo na Internet geralmente é feita através de um texto informado.
Além de encontrar um componente, o usuário deve ter a opção por fazer o
download. Para isso, a funcionalidade de download também se faz necessária. Visando
agilizar a busca diminuir o tráfego de dados, uma etapa é inserida entre a busca e o
download: o Asset Info. Ou seja, uma funcionalidade para captura de informações sobre
o asset. A busca retornará informações básicas sobre os assets encontrados, e, a partir
disso, o usuário poderá requisitar maiores informações sobre o componente. E então, o
Asset Info retornará todas as informações do componente, baseadas na modelagem,
descrita no tópico 3.3. A partir das informações fornecidas, o usuário poderá decidir por
fazer ou não o download do componente.
Toda a aplicação foi desenvolvida utilizando a plataforma J2EE, com a
utilização de ferramentas gratuitas. Os tópicos a seguir explicam sobre as principais
funcionalidades da RCCS.

4.1. Resource discovery e busca por componentes na RCCS

A busca é o primeiro passo para o funcionamento da rede. Podemos considerá-
la como a parte mais importante do sistema, uma vez que ela determinará, muitas vezes,
a qualidade do serviço. Uma busca deve ser simples e rápida, porém eficiente.
Tendo em vista que temos uma arquitetura peer-to-peer para a rede de
compartilhamento e baseados nas duas principais arquiteturas existentes (CIA e DIFA),
a arquitetura de busca deveria utilizar o que consideramos como pontos fortes de cada
arquitetura existente.
Se por um lado a arquitetura pura sobrecarrega a rede em suas buscas por
recursos, ela forma uma rede totalmente independente de um servidor central e isso
deve ser levado em consideração na nossa solução. Da mesma forma, a arquitetura CIA
utiliza um único servidor central para busca, tornando a rede mais vulnerável, porém ela
não possui problemas clássicos como sobrecarga da rede, falta de controle sobre a busca
(pois o usuário sabe onde está buscando) e conhecimento global da rede (todos os
pontos da rede estão registrados no servidor), e assim, também devemos levar em
consideração vários aspectos da CIA em nossa arquitetra.
Tendo em vista todos os aspectos destas principais arquiteturas originais, foi
montada uma arquitetura de busca onde existe uma base inicial de conhecimento em
cada ponto da rede (seus vizinhos, segundo a DIFA) e a busca pode ser disparada
diretamente para estes vizinhos, sem necessidade de uma consulta prévia em um
servidor central. Mas esta busca não é propagada pelos vizinhos, evitando a sobrecarga
da rede. Porém, a arquitetura da rede deve torná-la apta a conviver com fatores como o
crescimento do número de participantes, uma vez que a busca é feita apenas em pontos
conhecidos. Neste contexto, surge a necessidade da existência de servidores de
referência (as yellow pages), onde um ponto pode escolher por consultar sobre novos
pontos da rede e disparar as chamadas de busca para estes outros pontos também, até
então desconhecidos. Observe que isso não torna o servidor imprescindível, porém,
acrescenta maior poder à busca. Desta forma, um usuário (ponto da rede) pode escolher
onde realizar a busca: se esta busca é realizada em seus vizinhos conhecidos
(selecionando, inclusive, quais estes vizinhos serão consultados) e, além disso, pode
optar por realizar a busca também nos pontos da rede ainda desconhecidos e capturados
através de uma consulta nas yellow pages da rede. Uma vez feita esta busca nas yellow
pages, os repositórios encontrados (RARs) podem ser acrescentados ao banco de
conhecimento daquele ponto, aumentando sua base de conhecimento sobre os
integrantes da rede.
A figura 4 ilustra a arquitetura da rede, onde um Reusable Asset Browser
conhece os repositórios (RARs) A e B e desconhece os repositórios C e D, porém,
através de uma consulta nas yellow pages, ele toma conhecimento de todos os
repositórios da rede, podendo fazer com que sua busca atinja a rede inteira (fig 4b).
 Figura 4. Arquitetura de busca na RCCS.

Então, uma heurística básica de busca foi montada. No momento da busca, o

usuário seleciona, entre um conjunto de pontos conhecidos, onde deseja realizar a busca
e, além disso, pode optar por buscar por novos participantes da rede em servidores
yellow page, que armazenam serviços disponibilizados, utilizando o protocolo de
publicação de serviço dos Web Services, o UDDI (Fig 4a). Conhecendo os demais
participantes da rede, retornados pelas yellow pages, dispara a busca para todos os
participantes da rede que ainda não conhecia (Fig 4b).
A existência de um servidor de referência torna muito mais prática e rápida a
solução do resource discovery, e como os pontos da rede possuem sua própria base de
conhecimento, a consulta neste servidor central é opcional e sua inexistência ou
indisponibilidade não faz com que a rede deixe de funcionar, ou seja, a busca por
componentes na rede continua independente de uma entidade central, seguindo nosso
objetivo inicial.
A interface implementada para a busca dá ao usuário a possibilidade de
escolher em quais repositórios a busca deve ser realizada. Além disso, pode optar
também por buscar por novos repositórios nas yellow pages.. A figura 5a mostra a
interface de busca avançada, que oferece a possibilidade do usuário refinar a busca,
determinando a categoria, distribuição, tecnologia principal e idioma suportado. A
figura 5b ilustra o resultado de uma busca na RCCS.

Figura 5. Interfaces de busca avançada e resultado da RCCS.

 O resultado da busca é apresentado de forma bastante detalhada. Os
componentes retornados na busca são listados, apresentando algumas informações,
como repositório de origem, categoria, distribuição e descrição.

4.2. Asset Info e download

O Asset Info é uma nova funcionalidade que foi adicionada entre a busca e o download
do asset, visando tornar a busca mais rápida e minimizar a quantidade de dados
transportados na rede. É um serviço onde o usuário do RAB solicita maiores
informações sobre um componente e recebe todas as informações deste componente em
um objeto transmitido de volta.
Um componente pode possuir vários artefatos, como diagramas, documentos
de especificação e teste, código fonte ou binário. Desta forma, cada um destes artefatos
pode ser obtido separadamente, ou pode ser feito o download do asset completo, com
todos os seus artefatos incluídos, que são armazenados em um único arquivo, que
poderá ser baixado por um participante da rede.
O download também é realizado via Web Services, os arquivos são
transmitidos no pacote SOAP [IBM, 2004]. Algumas APIs já provêem soluções
semelhantes, porém a carência de documentação impossibilitou a utilização de soluções
prontas.
Neste artigo não pretendemos apresentar maiores detalhes sobre estas
funcionalidades, mas achamos importante lembrar sobre outras funcionalidades da
RCCS além da busca por componentes, principalmente porque estas funcionalidades
estão diretamente ligadas aos nossos trabalhos futuros.

5. Conclusão e trabalhos futuros

Após as pesquisas realizadas, pudemos concluir que nenhumas das arquiteturas
propostas originalmente para redes P2P eram satisfatórias para a RCCS. Da mesma
forma, soluções para problemas de resource discovery oferecidas por outros trabalhos já
realizados também não se aplicavam a nossa proposta, uma vez que sua implementação
era relativamente complexa e a implementação da RCCS deve ser simples, facilitando a
adesão de mais entidades na rede para compartilhamento de componentes.
A exemplo de vários outros sistemas P2P, montamos uma arquitetura mista,
baseada em características das duas principais arquiteturas originais, DIFA e CIA,
fazendo com que a rede seguisse sua premissa de independência de um servidor central,
porém utilizando um servidor de referência (yellow pages), tornando mais prática a
solução do problema de resource discovery na rede.
Além disso, como os pontos da rede já possuem uma base própria de
conhecimento de outros pontos, a busca por componentes é feita em uma única etapa,
sendo disparada diretamente para os pontos selecionados. Isto atribui à RCCS a
importante característica de controle da busca e do tráfego de dados na rede, o que seria
impossível seguindo a DIFA, que seria, a princípio, a arquitetura mais indicada.
E, por fim, como trabalhos futuros, visamos pesquisar a respeito das outras
funcionalidades, como Asset Info e download dos componentes da rede. Além disso,
pretendemos realizar testes de desempenho da busca distribuída, simulando a existência
de um maior número de repositórios participando da RCCS.
Referências Bibliográficas
Angluin, D., Aspnes, J., Chen, J. and Yin, Y. (2004) “Fast construction of Overlay
Networks”. (Julho, 2004). Disponível em: citeseer.ist.psu.edu/angluin04fast.html. (Último
acesso em 05/12/2004).
Google. “Sobre o Google”, http://www.google.com.br/intl/pt-BR/about.html (Último acesso em
12/12/2004)
Harchol-Balter, M., Leighton, T. and Lewin, D. (1999) “Resource Discovery in
Distributed Networks”. In Proc. 15th ACM Symp. on Principles of Distributed
Computing, May 1999, pp. 229-237.
ICQ Inc. About the Icq - Webpage. http://company.icq.com/info/community.html (Último
acesso, 05/12/2004)
IBM Red books. “Technology options for Application Integration and Extended
Enterprise patterns”. (2004) Disponível em: http://www.redbooks.ibm.com/redpapers/pdfs/
redp3840.pdf. (Último acesso em 03/12/2004).

Kozaczynski, W. et al. (2003) “RAS - Reusable Asset Specification” Rational Software

Corporation and Catapulse, Inc., draft Recommendation Aug. 03 2003.
Ku, Raymond S. R. , (2004) "The Creative Destruction of Copyright: Napster and the
New Economics of Digital Technology" . University of Chicago Law Review, 2002 –
Disponível em: http://ssrn.com/abstract=266964 – (Último acesso em 10/12/2004)
McIlraith, S., Son, T. C., and Zeng, H., (2001) "Semantic web service". IEEE
Intelligent Systems, 16(2):46–53,2001.
Milojicic, D., Kalogeraki, V., Lukose,R., Nagaraja, K., Pruyne, J., Richard, B.,Rollins,
S. and Xu, Z. (2002) “Peer-to-Peer Computing”. Technical Report HPL-2002-57,
HP, 2002.
OMG. “Object Management Group”, http://www.omg.org/ (Último acesso em 13/03/2004)
Rational. “IBM Rational Software”, http://www-306.ibm.com/software/rational/ (Último acesso
em 13/03/2004)
Ripeanu, M. (2001) "Peer-to-peer architecture case study: Gnutella network". In
Proceedings of International Conference on Peer-to-peer Computing, August
2001.
Rocha, J. et al. (2004) “Peer-to-Peer: Computação Colaborativa na Internet”. Mini-
curso, SBRC 2004.
Walkerdine, J., Melville, L., Sommerville, I., (2002) “Dependability Properties of P2P
Architectures” , In the Second International Conference on Peer-to-Peer
Computing (P2P’02)