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



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

3 - Plataformas




3.1 - Location API

A chamada Location API de J2ME [JSR 179], foi aceita pelo comitê da Java Community Process em junho de 2003. Essa API foi desenvolvida pela Nokia e seu objetivo é prover uma interface padrão para acessar informações baseadas na localização, como as coordenadas de um dispositivo móvel, de forma independente do tipo de método de posicionamento que esteja sendo usado.



3.1.1 - Definindo Critérios

A aplicação usando a Location API pode definir critérios para a seleção do tipo de método de posicionamento, esses critérios podem divididos em rígidos e leves :


Critérios Rígidos:

  • Ter informação de Altura

  • Ter informação de velocidade e curso

  • Questão financeira (método de menor custo por exemplo)


Critérios Leves:

  • Exatidão

  • Tempo de resposta desejado

  • Grau de consumo de energia tolerado

A plataforma seleciona o método que melhor case com o critério escolhido pelo usuário, levando em consideração a disponibilidade e implementações de provedores de localização para os métodos de posicionamento.



3.1.2 - Principais Elementos da API





  • LocationProvider: Objeto provedor de localização, ou seja, obtém a localização de acordo com o critério escolhido.

  • Location: Objeto que contém as coordenadas, a velocidade, o curso (se disponíveis), o endereço, e o timestamp que indica quando a localização foi obtida.

  • QualifiedCoodinates: Representa um ponto como latitude, longitude, e opcionalmente altitude, além de ter também informações sobre a exatidão. Provê métodos para calcular a distância e o ângulo entre duas coordenadas.

  • Landmark: É uma localização associada a um nome e uma descrição, essas informações são usadas para armazenar a localização de pontos específicos, que podem ser agrupados por categorias como museus, restaurantes, praças por exemplo.



3.2 - JXTA

JXTA É uma arquitetura open source que define um conjunto de protocolos para as funcionalidades requeridas para uma rede P2P. É independente de sistema operacional, de linguagem de programação e do tipo de transporte empregado na rede. A especificação dos protocolos [JXTA Especification] definem estados que os pontos da rede deve assumir para qualquer tipo de dispositivo. O projeto JXTA foi iniciado pela Sun Microsystems em abril de 2001, e de lá pra cá mais de 6 milhões de usuários tem feito o download dessa tecnologia.


O objetivo principal de JXTA é prover uma plataforma integrada com as funcionalidades necessárias para criar redes P2P independentes de sistemas operacionais e linguagens. Para atingir esse objetivo, JXTA ataca três pontos fundamentais:

  • Interoperabilidade

  • Independência de Plataforma

  • Ubiqüidade

É importante ressaltar que JXTA não é uma aplicação, e não define também os tipos de aplicações que podem ser desenvolvidas. Os protocolos definidos no padrão, também não são definidos de uma forma rígida, suas funcionalidades podem ser estendidas de acordo com a necessidade. Essa é uma característica muito importante, e um dos principais motivos da escolha de JXTA para a utilização neste trabalho.


Em relação aos conceitos de P2P apresentados anteriormente, JXTA tenta encontrar um meio termo entre centralização e descentralização, tomando por conceito que alguns serviços numa rede P2P são mais efetivos se feitos por um limitado número de peers.
Com JXTA é possível criar uma rede virtual P2P em cima da rede física da Internet. Os peers podem trocar mensagens independentemente da infra-estrutura da rede e do protocolo de transporte, a figura abaixo mostra o mapeamento da rede virtual de JXTA para a rede que compõe a Internet:

Fig3 – Rede virtual de JXTA


Atualmente existem três implementações da plataforma de JXTA: JXTA-Java SE, JXTA-JAVA ME (JXME) e JXTA-C/C++. As três implementações são interoperáveis, e existem trabalhos já em andamento para a implementação em outras linguagens.

3.2.1 - As Camadas Lógicas de JXTA

A plataforma JXTA pode ser dividida em três camadas mostradas abaixo:



Fig4 – Camadas lógicas de JXTA


A Camada Core:
Essa camada provê os elementos essenciais para uma solução P2P. É nessa camada que são implementados os protocolos de JXTA.
A camada de serviços:
Essa camada consiste de serviços de rede que são desejáveis, mas não são uma parte obrigatória de uma solução P2P. Os serviços providos por essa camada implementam funcionalidades que podem ser incorporados em diferentes aplicações P2P, como busca de recursos, e de arquivos em um peer, ou realização de autenticação.
A camada de Aplicação:
Nessa camada são usados os recursos da camada de serviço para criar as aplicações P2P como conhecemos. Por exemplo um aplicativo de mensagem instantânea ou de troca de arquivos. Como uma aplicação pode englobar apenas um serviço ou agregar vários serviços, muitas vezes fica difícil fazer essa separação entre serviço e aplicação.

3.2.2 - Elementos de JXTA



Peer:
É qualquer entidade capaz de fazer algum trabalho útil e comunicar os resultados disso a outra entidade através da rede. Ou seja, são os nós numa rede P2P, que formam a unidade fundamental desse tipo de arquitetura. Em JXTA cada nó opera independentemente e de forma assíncrona e é identificado de forma única através do seu PeerID. Em JXTA os peers dependendo de suas funcionalidades e complexidade podem ser classificados em:

  • Minimal Peers: Podem enviar e receber mensagens, mas não podem armazenar advertisements ou rotear mensagens para outros peers. Dispositivos como celulares estão inclusos nessa categoria.

  • Simple Peers: Servem a um usuário final. Podem prover serviços e/ou usar serviços de outros pares.

  • Rendezvous Peers: Apresentam um conceito muito semelhante ao já citados super peers da arquitetura P2P híbrida. Eles provêm informação sobre a localização na rede de outros pares e recursos, são usados para propagar mensagens dentro de um grupo de nós para um nó externo, permitem aos simple peers em uma rede privada a capacidade de fazer broadcast a outros membros do grupo fora desta.

  • Relay Peers: Provêm mecanismos de comunicação com peers separados por um firewall ou por máscaras de rede. Ou seja são capazes de rotear mensagens a outros peers da rede. Também são usados como Proxy pelos minimal peers.


Pipe e Endpoint:
O conceito original de Pipe vêm do sistema operacional Unix, onde um pipe representa um mecanismo de comunicação entre o sistema operacional e o seu Shell, a informação é colocada numa das pontas do pipe e sai na outra ponta. A especificação de JXTA usa a mesma nomeclatura e funcionalidade, só que para enviar mensagens entre peers, abstraindo assim qualquer tipo de infra-estrutura de comunicação.

Uma vez usando um pipe para transmitir e receber suas mensagens os peers não precisam conhecer a topologia da rede ou onde um peer qualquer está localizado na mesma. Os pipes usam o conceito de endpoin para indicar os pontos de entrada e saída de comunicação, e é chamando de canal a conexão entre esses dois pontos.

É interessante perceber aqui como JXTA é diferente das redes tradicionais. A maioria dos protocolos usados na Internet tem um endereço fixo como uma URL ou endereço IP que são usados para interligar os clientes. Já JXTA abstrai a idéia de um endereço para o cliente através dos endpoints.

Um peer pode ter mais de um endpoint, os peers como já visto podem se comunicar através de vários protocolos como TCP e HTTP, e fazendo isso através de múltiplos endpoints. Abaixo a figura mostra como ocorre a transmissão através de pipes:


Fig5 – Funcionamento dos Pipes

Atualmente existem implementações de três tipos de pipes:


  • Unicast: Unidirecional, sem segurança e não confiável.

  • Unicast Secure: Unidirecional, seguro e não confiável

  • Propagating: Pipe de propagação, sem segurança e não confiável

O unicast pipe conecta um peer a outro através de uma comunicação de via única. O propagating pipe conecta um output pipe a múltiplos imput pipes. A especificação de JXTA define os pipes como unidirecionais, ou seja a informação é transmitida em uma única direção, e de forma assíncrona, mas permite também que outros tipos de pipes sejam implementados de acordo com as necessidades das aplicações.


Advertisements
É um documento XML que descreve em JXTA mensagens, peers, peer groups, ou serviços. Os advertisements são usados para trocar informações sobre os recursos disponíveis numa rede JXTA. É função dos Rendezvous Peers descobrir e repassar a informação dos advertisements da rede, esses peers são capazes de armazenar advertisements e suportar buscas.
Mensagens
Mensagens em JXTA podem transmitidas de duas formas:

  • As mensagens são pacotes que contém um payload de dados formatados de acordo com o padrão XML.

  • As mensagens são transmitidas de forma econômica, como mensagens binárias, isso ajuda a tornar alguns protocolos mais eficientes do que se suas mensagens fossem transmitidas no formato XML, e também para permitir encriptação.



3.2.3 - Os Protocolos de JXTA

Foram definidos um conjunto de 6 protocolos, baseados em mensagens XML. Cada protocolo cobre um aspecto fundamental de uma rede P2P, e é dividido em uma parte responsável pelo par local, e outra pelo par remoto.

A escolha de XML como base para mensagens dos protocolos de JXTA tem vários motivos, primeiro porque XML é um padrão largamente usando atualmente, existindo assim um amplo suporte a processamento de arquivos XML na maioria das linguagens de programação, segundo porque os arquivos XML podem ser validados.
Mas XML tem também suas desvantagens já que é uma forma não-compacta de transmitir dados. As mensagens em XML acabam ficando muito maiores do que um equivalente em mensagem binária.
Nos protocolos a parte do par local gera mensagens e as envia ao par remoto.Já no par remoto a mensagem é processada para uma determinada tarefa. Cada protocolo é semi-independente um do outro.
Pilha de Protocolos de JXTA:

Fig6 – pilha de protocolos de JXTA



Peer Resolver Protocol (PRP)

O PRP é um protocolo que permite o envio de uma mensagem genérica para outro nó , e processa uma resposta genérica para uma requisição.

Possui dois tipos de mensagens:


  • Resolver Query Message: Para enviar requisições

  • Resolver Response Message: Para enviar respostas


Peer Discovery Protocol (PDP)

Os peers descobrem os recursos disponíveis na rede enviando requisições a outros peers (geralmente um Rendezvous Peer).O PDP vai definir como os peers requisitam notificações e respondem requisições de outros peers.

Possui 2 tipos de mensagens:


  • Discovery Query Message: Uma mensagem de requisição, para descobrir recursos.

  • Discovery Response Message: Uma mensagem de notificação dos recusos disponíveis.


Rendezvous Protocol (RP)

O RP descreve como as mensagens serão propagadas para outros peers através de um Rendezvous Peer. Para isso ocorrer cada peer deve conectar-se a um Rendezvous Peer e obter um “aluguel“ que especifica o tempo que um peer poderá usar o Rendezvous para propagar suas mensagens, antes de precisar renová-lo.

Dispõe de três tipos de mensagens :


  • Lease Request Message: É enviada quando um peer requisita um aluguel ao Rendezvous Peer

  • Lease Granted Message: É enviada pelo Rendezvous para aprovar o aluguel, e determinar o tempo do mesmo.

  • Lease Cancel Message: É enviada por um peer para se desconectar do Rendezvous Peer.

Esse é um dos protocolos de JXTA onde as mensagens não são especificadas em XML, por isso por questão de eficiência é usada uma representação compacta binária para a transmissão.


Peer Information Protocol (PIP)

O PIP permite que um peer possa obter informações sobre o status de outros peers da rede previamente descobertos. Essas informações podem ser o tempo que um peer está no ar, a quantidade de tráfego processada por um peer, entre outras informações. Esse não é um dos protocolos obrigatórios de JXTA, ou seja ele só precisa ser implementado quando um peer precisa monitorar o status de um nó remoto para tomar decisões de uso do mesmo. Convém lembrar que em redes P2P o monitoramento de recursos leva a um uso mais eficiente dos mesmos. O PIP possui dois tipos de mensagens:



  • Peer Info Query Message: É enviada para requisitar o status de um nó remoto.

  • Peer Info Response Message: É enviada para prover o status de um nó, a outros nós.


Pipe Binding Protocol

Descreve como criar conexões entre peers e como serão mandadas as informações. Esse protocolo define o processo de ligação de um pipe a um endpoint.

Possui dois tipos de mensagens:


  • Pipe Binding Query Message: É enviada para perguntar a um peer se ele está ligado a um pipe com o mesmo ID.

  • Pipe Binding Answer Message: A resposta da requisição.


Endpointing Routing Protocol (PEP)

Provê um mecanismo para determinar a rota para um endpoint. A forma como os dados serão enviados na rede, são de responsabilidade de uma implementação particular deste protocolo.

Atualmente existem implementações para os seguintes tipos de transportes:


  • TCP: Usa um socket para conectar-se diretamente a um outro peer.

  • HTTP: Usado para transpor barreiras como firewalls, ou permitir transferência de informações a dispositivos móveis como celulares, tem como desvantagem o fato de não permitir broadcast

  • Servlet HTTP: Usado em aplicações que suportem Servlets.

  • TLS: Para prover comunicação segura, com o uso de autenticação.

Os protocolos de JXTA não atuam de forma independente, todos são necessários para se obter o máximo de funcionalidades da rede P2P. Por exemplo o Peer Resolver Protocol usa o Rendezvous Protocol para enviar mensagens ao Rendezvous Peer.




3.2.4 - Performance em JXTA

Para uma performance mais eficiente, buscando eliminar os possíveis problemas já apresentados na questão da performance dos sistemas P2P do capítulo 2, JXTA usa as seguintes técnicas:



  • Alguns tipos de mensagens são encaminhados com um número definido de saltos. Isso previne que as mensagens alcancem todos os peers da rede.

  • A informação da descoberta de peers na rede é armazenada em cash, eliminando assim a necessidade de sempre enviar mensagens de descoberta de peers toda vez que a informação é requerida.

  • Os dados na rede, dependendo de seu tipo, possuem a propriedade do TTL ativa, prevenindo assim o acúmulo de informação, quando o TTL de uma mensagem expira, a mensagem é descartada.

  • Peers de alta capacidade são usados para reduzir a carga sobre peers que tenha uma baixa capacidade de processamento ou de banda.

  • O roteamento de mensagens é feito de forma inteligente por cada nó, para assegurar que a melhor rota está sendo tomada em direção ao destino das mensagens.

  • O protocolo de transporte é selecionado baseado na eficiência da parte da rede usada no momento. Por exemplo, IP broadcast é usado em redes locais, enquanto TCP ou HTTP são usados entre redes LAN para prover a comunicação direta entre os peers.



3.2.5 - Vantagens e Desvantagens de JXTA

As grandes vantagens de JXTA são principalmente prover uma abstração para a comunicação entre peers muito melhor do que os protocolos P2P existentes, permitindo uma grande variedade de serviços, dispositivos, e formas de transporte na rede. O emprego de XML também ajuda, pois provê um formato padrão para a estruturação dos dados e uma fácil adaptação a variedade das formas de transporte.


Mas também existem problemas na definição de JXTA, principalmente na questão de como da invocação de serviços. Atualmente existem padrões que definem como um serviço é invocado, entre eles o Web Services Description Language (WSDL) amplamente utilizado na invocação de serviços de web services, mas nenhum desses padrões é usado por JXTA. Ou seja JXTA provê troca de informação entre peers, mas não tem nenhum mecanismo para trocar informações necessárias para a invocação de serviços.
A questão do uso de XML também é polêmica, apesar de ter as vantagens já listadas, XML também apresenta desvantagens pois o overhead causado pela troca de mensagens XML dependendo do tipo de aplicação pode ser um grande problema, principalmente se uma aplicação não tem o objetivo de aproveitar as capacidades de JXTA de incorporar outros serviços P2P.

1   2   3   4   5   6   7


©principo.org 2016
enviar mensagem

    Página principal