JXTA – Parte I

 

O projeto JXTA é uma plataforma de código fonte aberto criada pela Sun Microsystems em 2001 sob orientação de Bill Joy e Mike Clary. O projeto, atualmente, envolve muitas empresas, universidades e desenvolvedores que estão contribuindo para o seu crescimento.

Essa plataforma fornece as funcionalidades necessárias para a construção de uma rede Peer-to-Peer (P2P), tais como, endereçamento, descoberta de recursos e peers, transferência de dados, etc.

 

Nesse artigo iremos abordar a arquitetura JXTA, discutindo as vantagens e desvantagens do poderoso ambiente P2P.

 

P2P

A maioria das aplicações de sistemas distribuídos se comunicavam através da rede utilizando o conceito de cliente-servidor. Neste paradigma existe uma ou mais máquinas servidoras que disponibilizam serviços (dados, computação) para clientes. Sendo assim, o repositório de informações se mantém estático e centralizado e sujeito a atualizações apenas do administrador, e o usuário assume uma condição passiva, na qual ele apenas recebe, mas não compartilha informação. O compartilhamento pode ser obtido através do intermédio do servidor.

Os sistemas Peer-to-Peer (P2P) podem ser basicamente definidos como sistemas distribuídos onde cada peer é ao mesmo tempo cliente e servidor, isto é, provedor e consumidor de serviços de rede. Todos os peers são considerados iguais em sua capacidade de compartilhar informação com outros membros da rede, sendo que podem conectar-se diretamente, sem a necessidade de um servidor central. É uma nova maneira de se implementar a descentralização dos sistemas, das aplicações, ou simplesmente dos algoritmos. Uma maneira de aumentar o poder computacional, de armazenamento, e de conectividade entre computadores pessoais distribuídos pelo mundo.

 

Quando as pessoas falam sobre P2P é como se estivessem falando sobre compartilhar mídia ou usar um instant messaging. Essas aplicações representam o sucesso da tecnologia, porém não são apenas esses os potencias e benefícios que a tecnologia peer-to-peer oferece:

·         Melhora da escalabilidade: com a ausência de servidores centrais cresce a quantidade de recursos disponíveis;

·         Redução do custo de infra-estrutura: grande parte dos custos é reduzida pela utilização de recursos que antes eram considerados inutilizados, mas que agora disponibilizam suas informações a todos os outros peers da rede;

·         Balanceamento de carga: monitora o tráfego e o perfil da rede para facilitar a troca de informações entre os peers. Por exemplo, um usuário não precisa se conectar a um site do outro lado do mundo quando a informação que ele deseja está em uma máquina no mesmo prédio;

·         Repositórios dinâmicos de informações: em uma rede p2p um peer procura por outros peers ativos para fazer o download da informação desejada. Usuários que tiverem posse dessa informação podem torná-la disponível para compartilhamento com todos peers da rede. Sendo assim qualquer informação de alta demanda pode se espalhar rapidamente pela rede;

·         Redundância e tolerância à falhas: a replicação da informação em vários peers proporciona um alto grau de redundância o que implica em um alto grau de disponibilidade de informações para os usuários;

·         Dinamicidade: sistemas p2p assumem que o ambiente é dinâmico, ou seja, peers podem estar entrando e saindo da rede continuamente. Assim como aplicações distribuídas os sistemas peer-to-peer tem que se adaptar a essa troca de participantes e conseqüentemente realocar as tarefas para outros participantes para garantir a integridade de um serviço mesmo quando algum peer sai da rede;

·         Ad-hoc communications: o suporte a redes ad-hoc é relacionado à dinamicidade. Os computadores não necessitam de uma rede física, o próprio grupo de peers é a infra-estrutura para a troca de recursos.

 

Arquitetura JXTA

A arquitetura JXTA é constituída de três camadas distintas, como mostra a Figura 1.

 

gnjxta1fig01.jpg 

Figura 1 - As três camadas do JXTA.

 

A camada principal JXTA Core provê as funções básicas através de protocolos que definem mecanismos de comunicação independente de plataforma (PCs, PDAs, Celulares,...), protocolo (NAT, DNS, Firewall, DHCP,...), linguagem, mecanismos de login/logout em peergroups e mecanismos de monitoração e segurança.

 

A camada Serviços JXTA provê funcionalidades, utilizando os protocolos da camada JXTA Core, que podem ser reutilizadas por várias aplicações. Ela define um conjunto de interfaces para que qualquer desenvolvedor crie seu serviço específico. A distribuição do JXTA já vem com o conjunto de serviços escritos da Sun, escritos em Java, o Sun JXTA Services.

 

A camada Aplicações JXTA é onde podem ser desenvolvidas as aplicações para o usuário final, como Instant Messaging, pó exemplo. Um ponto importante a lembrar é que um peer que fornece certa funcionalidade, ele pode ser visto como um serviço por alguns e como uma aplicação inteira por outros, isso depende do tipo de aplicação sendo construída.

 

Conceitos

 

Services

Conforme já dito anteriormente, os serviços são utilizados pela aplicação para permitir que os peers cooperem e se comuniquem para publicar, descobrir e chamar serviços. Dentro os principais serviços podem citar: Discovery Service, Membership Service, Access Service, Pipe Service, Resolver Service e Monitoring Service.

 

Os serviços podem já ser estar instalados em um peer, mas esse, também, caso queira executar um serviço que não forneça, pode instalar dinamicamente pela rede, como um plugin.

 

PeerGroups

Um dos conceitos mais subestimados em JXTA, mas importante para se utilizar a plataforma é o de PeerGroups. Um PeerGroup, como o próprio nome sugere, é um agrupamento de peers, mas que possuem funcionalidades como definir um escopo de propagação e roteamento de mensagens entre os peers; prover uma fronteira de segurança através de autorização para se fazer parte de um PeerGroup.

 

 As mensagens enviadas não devem atravessar PeerGroups, e todo PeerGroup deve ter pelo menos um Rendezvous.

 

Um PeerGroup implementa um conjunto de serviços como serviço de descoberta de Advertisements (Discovery Service), comunicação com pipes (Pipe Service), Rendezvous (Rendezvous Service), dentre outros.

 

Advertisement

Estruturas de meta-dados XML para descrever recursos de um peer. Eles são usados para descrever peers, peergroups, pipes, services e qualquer outro tipo de recurso.

 

Pipe

Pipe é uma comunicação virtual assíncrona e unidirecional entre dois peers, descrita por um Pipe Advertisement, responsável pela troca de mensagens entre peers, independente da sua localização, topologia e protocolo da rede. Às mensagens pode estar anexado qualquer tipo de objeto Java.

 

Existem dois tipos de pipe: Input Pipe para os peers receptores e o Output Pipe para os peers que enviam mensagens.

 

A plataforma JXTA já fornece as implementações para manipulação do Input e Output Pipes: JxtaSocket, JxtaServerSocket, JxtaBidiPipe, e JxtaServerPipe.

 

JXTA ID

Todos os recursos descritos pelos advertisements contêm um identificador único na rede JXTA. Esses IDs são representados através de URNs.

 

Protocols

A tecnologia JXTA é um conjunto de protocolos P2P que habilitam qualquer dispositivo conectado a uma rede, desde telefones celulares e PDA's a PC's e servidores, a comunicar e colaborar entre si como peers. Eles foram projetados para serem independentes de plataforma, linguagem de programação e protocolos de transporte. Os protocolos podem ser implementados em Java, C, Perl, entre outras linguagens, e também podem ser implementados sobre TCP/IP, HTTP, Bluetooth, entre outros protocolos de transporte.  O uso extensivo de documentos XML que descrevem serviços e informações e que são utilizados na comunicação e descoberta na rede JXTA, também contribui para independência de ambientes.

Os protocolos padronizam a forma como os peers: descobrem, comunicam e monitoram uns aos outros, organizam-se em grupos, publicam e descobrem serviços.

Atualmente são definidos 6 tipos de protocolos. Um peer não é obrigado a implementar todos os protocolos para fazer parte da rede, apenas  o Peer Resolver Protocol e o Endpoint Protocol, o que é chamado de JXTA Core. Os outros protocolos fazem parte do JXTA Standard Servides.

 

Peer Resolver Protocol (PRP)

O protocolo Peer Resolver é utilizado pelos serviços e aplicações para realizar operações de query/response dentro de um peergroup. As mensagens são enviadas a um handler, que contém mecanismos de como as mensagens de query serão distribuídas pelo peergroup e como as respostas serão tratadas. O processo de troca de mensagens é feito através do Peer Endpoint Protocol, realizando a troca de mensagens entre o peer o qual realizou a query e o handler.

 

No PRP não há garantias de que uma mensagem chegue ao seu destino nem que seja retornada uma mensagem de resposta, mesmo que seja para notificar que não houve resultados. Existem dois tipos de mensagens: Query Message, usada para realizar a busca; e Response Message, usada para retornar uma resposta.

 

Abaixo segue um exemplo de uma Query Message sendo enviada para um handler para realizar o descobrimento de um recurso de um peer na rede.

 

<?xml version="1.0"?>
<!DOCTYPE jxta:ResolverQuery>
<jxta:ResolverQuery xmlns:jxta="http://jxta.org">
    <HandlerName>
        urn:jxta:uuid-DEADBEEFDEAFBABAFEEDBABE0000000305
    </HandlerName>
    <jxta:Cred>
        JXTACRED
    </jxta:Cred>
    <QueryID>
        0
    </QueryID>
    <HC>
        0
    </HC>
    <SrcPeerID>
        urn:jxta:uuid-59616261646162614A7874615032503304BD268FA4764960AB93A53D7F15044503
    </SrcPeerID>
    <Query>
        <?xml version="1.0"?>
        <!DOCTYPE jxta:DiscoveryQuery>
        <jxta:DiscoveryQuery xmlns:jxta="http://jxta.org">
            <Type>
                0
            </Type>
            <Threshold>
                50
            </Threshold>
            <PeerAdv>
                <?xml version="1.0"?>
                <!DOCTYPE jxta:PA>
                </jxta:PA>
            </PeerAdv>
            <Attr>
            </Attr>
            <Value>
            </Value>
        </jxta:DiscoveryQuery>
    </Query>
</jxta:ResolverQuery>

 

O jxta:Cred contém as credenciais do peer que está enviando a query.
O HandlerName especifica o handler de destino da query.
O SrcPeerID é o ID do peer que está enviando a query.
O QueryID é o ID da query que também está na mensagem de reposta, para que o peer que a resposta é para aquela determinada query enviada.
O HC define a quantidade de peers pelo qual a mensagem já passou.
O Query, nesse exemplo, contém uma Discovery Query Message.

Leia também