O mapeamento da arquitectura da plataforma Imagine sobre JXTA foi concretizado em duas fases. A primeira fase reflecte a utilização directa dos métodos oferecidos pelo sistema JXTA e que permitem a disponibilização das primitivas referentes à gestão de participantes, grupos e comunicação inerente a estes. A segunda fase foi composta pela implementação da gestão de eventos e gestão do espaço partilhado à custa das primitivas já implementadas na primeira fase.
A figura 5.1 resume o mapeamento dos conceitos presentes na plataforma Imagine sobre JXTA. Um participante é representado com a classe User na plataforma Imagine e é representado com a classe PeerGroup em JXTA. Os grupos são representados com a classe Group na plataforma e são representados com a classe PeerGroup em JXTA, sendo que os eventos são modelados na plataforma Imagine à custa de subgrupos. Os restantes conceitos presentes na plataforma (eventos e espaço partilhado) são implementados à custa das primitivas disponibilizadas pela plataforma Imagine.
Group Event User User Espaço partilhado User sharedspace PeerGroup Peer PeerGroup Peer Imagine JXTA
Figura 5.1: Mapeamento da arquitectura da plataforma Imagine sobre JXTA
De seguida, analisa-se cada componente da plataforma e resume-se o mapeamento efectuado para cada componente.
5.2.1 Participantes
Um participante é identificado por um nome único na plataforma e esse participante é membro de um grupo global, que abrange todos os participantes registados.
A plataforma suporta esta entidade através da classe Users. As operações disponibi- lizadas por esta classe que permitem o registo (Users.register) e o cancelamento do registo de um participante (Users.unregister), manipulam a classe base de JXTA, a classe NetworkManager.
A gestão de participantes é concretizada directamente utilizando a política que JXTA definiu para a gestão destes. Cada participante tem um identificador de sistema, sendo este gerado a partir do nome fornecido no registo do participante. Esse identificador de sistema é uma característica fundamental de JXTA, que permite que um participante possa alterar o endereço do dispositivo físico onde está a ser executado e mantenha o identificador de sistema, mantendo assim a transparência na localização.
A classe Peer presente em JXTA serve para referenciar outros participantes, sendo esta bastante útil para o envio de mensagens, por exemplo.
Um participante tem sempre um anúncio que o identifica. Isto simplifica a tarefa de reconhecimento de novos participantes, sendo apenas necessário distribuir o anúncio que o identifica. O conceito de anúncio é definido em JXTA e foi introduzido na secção
3.2.2.3.
JXTApermite o registo de participantes com o mesmo nome dado que JXTA identifica os participantes com identificadores únicos gerados a partir do nome submetido. Na pla- taforma Imagine o nome de cada participante é único e proibe-se o registo de participantes com o mesmo nome.
5.2.2 Grupos
Um grupo é identificado por um nome e esse nome é único na plataforma. Cada grupo consiste numa organização lógica entre membros, na qual podem existir zero ou mais membros e onde as entradas e saídas desse grupo ocorrem através da utilização de pri- mitivas para esse efeito. Todos os participantes do sistema pertencem a um grupo global e todos os grupos criados na plataforma derivam deste grupo global, definindo assim uma hierarquia de grupos na qual a raiz é o grupo global.
A classe que representa um grupo na plataforma Imagine é a classe Group. Esta classe contém um Hash Map com todos os eventos que um participante subscreveu no contexto desse grupo e contém a classe JXTAGroup que representa o próprio grupo. Essa classe JXTAGroup contém a implementação, sobre JXTA, das operações possíveis de efectuar num grupo.
A classe Group oferece uma organização ao conceito de grupo e subgrupos (eventos) que existem no contexto deste grupo. Todas as primitivas disponibilizadas por esta classe têm ligação directa com as primitivas presentes na classe que representa o grupo (JXTA- Group) ou no subgrupo (evento) que se pretende manipular (que por sua vez também é
representado como um objecto JXTAGroup).
A classe JXTAGroup contém a implementação, sobre JXTA, das operações de gestão de grupos. Estas operações manipulam alguns dos serviços disponibilizados por JXTA, como por exemplo, o serviço de filiação (MembershipService), o serviço de comunicação (EndpointService) e o serviço de descoberta (DiscoveryService). Esses serviços são disponi- bilizados pela classe PeerGroup, que representa em JXTA um grupo.
Um grupo tem sempre um anúncio que o identifica e que à semelhança dos partici- pantes, conta com as mesmas propriedades apresentadas na secção3.2.2.3.
5.2.3 Comunicação
Um dos modelos de comunicação suportados pela plataforma é baseado em mensa- gens, sendo este ligado directamente com o mecanismo existente em JXTA. O envio de mensagens é alcançado através da utilização de uma primitiva da API para esse efeito (Groups.send ou Users.send). Quanto à recepção de mensagens, essa é efectuada através de objectos de escuta (listeners).
No envio de uma mensagem para um participante ou grupo, é necessário indicar qual é o grupo, o nome e parâmetro desse objecto de escuta. Relativamente à recepção dessa mensagem, é necessário ter um objecto de escuta registado no mesmo grupo, com o nome e o parâmetro para o qual se enviou a mensagem.
Para cada mensagem recebida por um participante, é efectuada uma pesquisa de um objecto de escuta que esteja registado para a recepção da mensagem. Se existir esse ob- jecto de escuta, então é lançada uma instância desse objecto para tratar essa mensagem (idêntico ao conceito de handler). Esses objectos de escuta derivam da classe EndpointLis- tenerdisponibilizada por JXTA.
5.2.4 Eventos
A gestão de eventos é alcançada através do modelo publicação/subscrição, apresentado na secção3.1.3. Este modelo é adaptado no sistema JXTA através da criação de subgru- pos associados ao grupo ao qual se pretende criar um evento, ou seja, quando se pretende criar um evento, este está sempre associado a um grupo e portanto será criado um sub- grupo que representa esse tipo de evento. Todos os participantes que pretendem subs- crever esse evento necessitam de entrar nesse subgrupo e registar um objecto de escuta para que possa receber todas as mensagens associadas a esse evento.
5.2.5 Espaço partilhado
Face ao espaço partilhado, este é implementado em dois contextos, o de cliente e o do servidor.
Do lado do cliente, para comunicar com o espaço partilhado existe a primitiva Group. sharedSpace que oferece as quatro operações descritas na secção3.3. Essa primitiva encarrega-se de enviar o pedido para o gestor do espaço partilhado com os respectivos
argumentos passados aquando da invocação. Para a recepção das respostas dos pedidos efectuados ao espaço partilhado, é necessário registar um objecto de escuta com o nome sharedspacee parâmetro à escolha do programador, explicado em detalhe na secção5.3.4. Do lado do servidor e como já foi referido, a implementação do espaço partilhado visou comprovar a utilidade deste conceito, no âmbito da proposta desta dissertação, pelo que se adaptou uma concretização simplificada do conceito de espaço partilhado através da utilização de um único servidor que gere os espaços partilhados associados a todos os grupos. Este servidor é representado na plataforma como um participante com o nome sharedspace. Este servidor cria um novo espaço partilhado sempre que um grupo é criado, sendo para esse efeito gerada uma mensagem, por forma a avisar o servidor de que existe um novo grupo. Todas as operações que são invocadas sobre o espaço partilhado são convertidas em mensagens directas para o participante sharedspace.
Ao implementar-se o espaço partilhado desta forma, possibilitou-se um mais rápido desenvolvimento do mesmo de forma a testar e validar todos os seus aspectos. Em alter- nativa, seria possível implementar o espaço partilhado distribuindo os seus tuplos pelos participantes que estão envolvidos nesse grupo e utilizando um mecanismo de gestão da coerência de informação entre todos os participantes.