Universidade Federal de Pernambuco Graduação em Ciência da Computação



Baixar 197.47 Kb.
Página6/7
Encontro29.07.2016
Tamanho197.47 Kb.
1   2   3   4   5   6   7

3.3 – JXME

O projeto JXTA para J2ME, é uma implementação de JXTA voltada aos dispositivos móveis como celulares, PDA’s, pagers. Maiores informações sobre a constituição da tecnologia J2ME para o entendimento deste capítulo podem ser vistas no apêndice A.



3.3.1 - Objetivos





  • Ser interoperável com as outras implementações de JXTA.

  • Prover uma estrutura P2P para dispositivos móveis e limitados.

  • Ser simples e fácil de usar pelos desenvolvedores

  • Ser pequeno o suficiente para ser usado em celulares e PDAs

  • Permitir a criação de aplicações que sejam fáceis de usar

  • Ser compatível com o profile MIDP.


3.3.2 – Restrições

Por causa das limitações dos dispositivos e do profile MIDP, esse tipo de peer só pode atuar como minimal peer, ou seja eles não podem assumir papeis mais sofisticados (não podem por exemplo rotear informações para outros peers, ou oferecer serviços a outros membros de um peer group). Então todo o processamento mais pesado como a busca de recursos na rede deve ser feita por outros membros da rede, essas tarefas são assumidas pelo já apresentado anteriormente Relay Peer:



Fig7 – Relays em JXME


Os Relays Peers atuam como Proxy para os dispositivos móveis, tomando pra si a maioria das tarefas necessárias para manter a lógica P2P entre os dispositivos móveis e o resto da rede P2P. Para isso os Relays realizam as seguintes tarefas:

  • Prover interoperabilidade com os protocolos de JXTA

  • Atuar como um Proxy que cria grupos, pipes, descobrem outros peers, e entram em grupos.

  • Filtrar o tráfico JXTA

  • Otimizar os advertisements

Os Relays não comprometem a visão P2P da rede, porque os minimal peers não necessitam estabelecer e manter uma relação estática com os Relays, como ocorre no modelo cliente servidor, um minimal peer pode dinamicamente trocar ou usar múltiplos Relays. Em um futuro próximo, com o aumento do poder computacional dos dispositivos móveis, os Relays serão cada vez menos usados, até serem completamente desnecessários.


A plataforma MIDP não fornece suporte ao processamento de arquivos XML no caso da versão para celulares, e além disso, enquanto é processado, um arquivo XML precisa ser mantido na memória. Em dispositivos com limitação de memória, como celulares por exemplo, ainda não há como processar arquivos XML diretamente, por isso o Relay precisa filtrar as mensagens XML, descartando todas as informações desnecessárias, e as redireciona ao dispositivo móvel num formato binário através do protocolo http, com isso o volume de tráfico na rede é reduzido.

3.3.2 - A API de JXME

JXME fornece uma API simples fornecendo o mínimo de serviços para que um dispositivo móvel limitado possa interagir com o Relay e através desse acessar os serviços da rede P2P. É composta de apenas três classes:



  • Message: Provê métodos para criar e manipular mensagens JXTA

  • Element: Provê métodos para construir e manipular componentes básicos das mensagens de JXTA

  • PeerNetwork: Provê mecanismos para interagir com uma rede JXTA.

Apesar de ser uma API bastante reduzida, ela suporta as seguintes operações:



  • Descoberta de Pipes: Uma aplicação JXME é capaz de procurar e manter uma lista limitada de pipes de aplicações.

  • Descoberta de Grupos: Uma aplicação JXME é capaz de procurar peer groups e de se associar a eles.

  • Descoberta de Peers: Uma aplicação JXME é capaz de descobrir outros peers.

  • Criação de Pipes: É capaz de criar pipes ponto-a-ponto e propagate pipes.

  • Criação de Grupos: É capaz de criar peer groups.

  • Comunicação: É capaz de trocar mensagens com outros peers.



3.3.3 - JXME Proxyless

Em junho de 2005, foi lançada a versão proxyless de JXME, essa versão é focada em dispositivos wireless com um poder de processamento maior, como palms por exemplo. Essa versão provê manipulação das mensagens XML e é capaz de usar serviços de JXTA de mais alto nível, como serviços de roteamento, e usa o protocolo TCP para o transporte da informação. Como o foco desse trabalho é aplicações para celulares 3G essa versão não foi utilizada, mas ela é importante pois mostra os rumos que podem ser tomados futuramente quando os celulares se tornarem mais robustos em relação a hardware.



4 - A Aplicação

O tipo de aplicação escolhida para ser implementada foi um Chat. Essa escolha foi feita buscando-se uma praticidade maior para permitir uma interação de vários usuários ao mesmo tempo. O foco da aplicação é controlar a comunicação P2P, ser capaz de pegar a localização do usuário, e colocar essa informação na rede P2P de forma que ela tenha uma importância significativa, e possa ser aproveitada pelos outros usuários.


A implementação pode ser dividida em 3 fases:

  • Na primeira foi desenvolvido o módulo de obtenção da Localização.

  • Na segunda foi desenvolvido um chat e uma infra-estrutura básica de trocas de informação usando os conceitos de rede P2P.

  • No final foi feita a convergência, adicionando-se o recurso de poder se visualizar a localização de um peer remoto em relação a um usuário num mapa 2D. Abaixo a estrutura geral da aplicação pode ser visualizada na figura:

Fig8 – Encapsulamento da Aplicação


Para a implementação do módulo de Localização foi usada a Java Location API já apresentada no capítulo 3. Como já foi explicado, essa API provê uma interface básica para o acesso as informações de localização do usuário abstraindo o método de posicionamento, mas é necessário para que esta funcione que seja implementado um provedor de localização para pelo menos um dos métodos existentes, para esse trabalho foi decido implementar o método GPS pois este apresenta a seguintes vantagens:

  • É um método bastante conhecido e usado.

  • Por ser do tipo handset, emular ou simular suas características é mais simples do que os métodos baseados em redes.

  • Possui um conjunto de mensagens padronizadas (formato NMEA).

  • Possui uma ótima exatidão.

As funcionalidades básicas para o módulo de Localização foram então divididas em duas classes, uma é um parser que lê as mensagens GPS no formato NMEA (uma descrição do formato e principais sentenças NMEA são descritas no apêndice B), e converte num formato binário que é repassado então para o provedor de localização GPS, que encapsula essas informações num objeto Location. Para o funcionamento desse módulo é pressuposto que o dispositivo já obteve sua localização GPS, o parser apenas para efeito de simulação obtém as informações de um arquivo de texto, mas nada impede que a captura de informações seja implementada realmente de acordo com a forma como o dispositivo real obtem essa informação. A figura abaixo resume como o módulo de localização funciona.



Fig9 – Módulo de localização


O chat foi desenvolvido usando a infra-estrutura de JXME, que também foi explicada no capítulo 3, este foi baseado num dos exemplos de aplicativos de demonstração que vem no binário da plataforma.
O funcionamento padrão do chat se baseia na conexão com um grupo universal, todos os peers ao se conectarem a rede P2P se conectam a esse grupo, e a partir daí recebem toda e qualquer mensagem direcionada ao mesmo. A estrutura a primeiro momento pode lembrar uma estrutura cliente servidor, mas o grupo não é um dispositivo físico na rede como um servidor, ele é uma unidade lógica de JXTA (peer group) que é descrita através de um advertisement. O que acontece é que cada peer está com um pipe aberto com um ID igual pra todos, esse ID, é o ID padrão para receber e enviar mensagens ao grupo, então o que ocorre é realmente uma transmissão P2P onde vários peers recebem a mensagem, isso é feito usando-se um pipe do tipo propagating.
A mensagem de envio de dados do chat é estruturada de forma que a mensagens contenha a informação sobre o peer responsável pelo envio da mesma, e qual a informação contida na mensagem enviada. Isso é feito da seguinte forma: Quando uma mensagem é criada, mesmo em JXME, ela segue um padrão de criação de elementos estruturados, seguindo um padrão de organização semelhante ao de XML. Então temos objetos elementos que possuem uma descrição (o equivalente as tags de XML) e os dados (equivalente aos dados contidos nas tags de XML).
Foi implementada também uma classe que pudesse mostrar ao usuário, num mapa, a localização dos peers, para efeitos de demonstração foi usado o mapa da guidecity que é de uma aplicação de demonstração da Java Location API que vem com o emulador da Sun, o Wireless Toolkit 2.3 Beta. Para efeitos de demonstração a localização real foi indexada para coordenadas da tela de acordo com o mapa da cidade fictícia, ficando assim as coordenadas da aplicação para a demonstração, restritas a um intervalo fixo.
Para realizar a parte final, a integração das tecnologias, duas decisões precisaram ser tomadas:
A primeira foi decidir qual momento em que seria necessário que a informação sobre a localização do usuário fosse coletada, essa decisão aparentemente simples, é de fundamental importância se sairmos do âmbito de simulação e entrarmos no âmbito real. Como explicado no capítulo 2 alguns métodos de posicionamento como o GPS tem a desvantagem de terem uma certa demora na coleta da localização, isso é uma coisa muito importante quando levamos em consideração o fator humano, um usuário não gostaria de ficar esperando demais para poder utilizar um serviço. Para a simulação então foi decidido que a coleta seria feita no momento de realizar a conexão com a rede P2P como um processo a parte.
Levando-se em consideração que o usuário precisa esperar um tempo para que a conexão seja estabelecida, é feita então a coleta da informação da localização, isso tem a vantagem de diminuir o tempo total (conexão + coleta), porém ao mesmo tempo acrescenta mais tempo para o usuário receber a confirmação que a conexão está estabelecida. É um fator a ser analisado ainda mais cuidadosamente no futuro.
Outro detalhe importante é a questão da atualização da Localização do usuário, num ambiente real e utilizando um dispositivo móvel é natural que um usuário possa estar se deslocando, então dependendo do foco da aplicação é importante que a localização do usuário seja atualizada no decorrer do tempo, mas para esta aplicação como seria inviável a atualizar as coordenadas no arquivo txt contendo a localização GPS do usuário, foi decidido que a coleta será feita apenas uma vez, mas o cuidado em estruturar a implementação de forma a permitir que essa atualização seja fornecida em aplicações futuras foi tomado .
A segunda decisão foi como estruturar a informação de localização na mensagem a ser enviada. Para simplificar ficou decidido que a localização seria adicionada como mais um elemento na mensagem. Como já foi explicado a mensagem contém elementos que seguem uma estruturação igual a de arquivos XML, então foi acrescentado um elemento “JxtaLocation”, que possui como dados uma string de caracteres no seguinte formato: “latitude:longitude:altitude:exatidãoHorizontal:exatidãoVertical”.

1   2   3   4   5   6   7


©principo.org 2016
enviar mensagem

    Página principal