Sumário
IntroduçãoArquiteturas Konark iMobile ME JXTA for J2ME
Conclusão
Introdução
Aumento na adoção de dispositivos móveis: notebooks, celulares, PDAs, etc.Maturidade e difusão das redes sem fio.Surgimento de um novo cenário para as aplicações.Características das aplicações P2P, como dinamismo e autonomia, casaram bem com computação móvel.
Konark
Konark
Proposto na Universidade da Flórida.Oferece suporte para redes parcialmente e complemente ad-hoc.Utiliza um micro servidor HTTP e mensagens em XML (SOAP).Não faz restrição ao protocolo de rede, mas exige o uso de TCP/IP como protocolo de transporte.O Konark é divido em dois componentes principais: Serviço de Descoberta Serviço de Entrega
Serviço de Descoberta
TC P/IP
Messaging Layer
Konark S DP M anager
A pp lica tion
TC P/IP
Messaging Layer
Konark S DP M anager
A pp lica tion
W ire les s L ink La ye r
Serviço de Descoberta
Realiza a descoberta de serviços na rede.A descoberta pode ser iniciada pelo cliente ou pelo servidor.Processo controlado pelo Konark SDP Manager.Utiliza uma estrutura em árvore para armazenar os serviços – tanto os anunciados como os locais.
Estrutura em árvore do Konark
Dois tipos de nós: Nó de classificação Nó de serviço
Por definição, os nós mais próximos da raiz recebem classificações genéricas, e os mais distantes recebem classificações mais específicas.Os nós também são classificados como: todos, genéricos e específicos.
Estrutura em árvore do KonarkRoot
Service
Devices Services
Information Shopping Entertainment
Personal Food Games Music
Internet Fax Restaurant Chess MP3
Estrutura em árvore do Konark
Um serviço é identificado utilizando o caminho dele até a raiz.
RootService:Services:Entretainment:Games:ChessPara diferenciar dois serviços providos por nós diferentes, o Konark utiliza a URL de localização do serviço.
Serviço de Descoberta
Quando o serviço não é se encontra na estrutura interna, a busca é realizada.Um cliente que deseja descobrir um serviço, envia uma mensagem contendo dois campos: Palavra-chave ou Caminho Porta de retorno
Devido aos recursos limitados, o cliente pode empregar filtros nos anúncios.
Serviço de Descoberta
Um servidor pode anunciar seus serviços espontaneamente ou em reposta a uma busca.Pode-se utilizar a classificação todos, genéricos e específicos na pesquisa/anúncio.Um anúncio contém cinco campos: Nome, Caminho, Tipo, URL e TTL
Serviço de Entrega
É responsável por receber as requisições, invocar o método e retornar o resultado.Todos os serviços são compostos de um arquivo de descrição (em XML) e uma parte computacional – por exemplo, uma DLL ou uma classe Java.
Serviço de Entrega<Service> <ServiceName> </ServiceName> <ServiceType> </ServiceType> <Keywords> <Word> </Word> </Keywords> <Properties> <Property> <Name> </Name> <Values> </Values> </Property> </Properties> <Functions> <Function>
<Name> </Name> <Parameter> <Name> </Name> <Type> </Type> </Parameter> <ReturnParameter> <Name> </Name> <Type> </Type> </ReturnParameter> </Function> </Functions></Service>
Serviço de Entrega
Para um nó requisitar um serviço, primeiro ele deve obter o arquivo XML de descrição contendo os parâmetros necessários para a realização da requisição.
Serviço de Entrega
URL
Servidor
Arquivo XML
Cliente
Árvore de Serviços
Requisição
iMobile ME
iMobile
Foi inicialmente desenvolvido para servir como proxy para os dispositivos sem fio – iMobile SE (Standard Edition).Executava em servidor na rede infra-estruturada.O iMobile SE é baseado em três componentes principais: devlets applets infolets
Arquitetura do iMobile SE
apple ts
in foletsdevlets eng ine
ce lu la rP D Abanco de dados
LD A P
iMobile Micro Edition
Para dar suporte a aplicações P2P, o iMobile SE foi portado para os dispositivos móveis.Foram feitas modificações na arquitetura e a principal mudança foi a retirada dos applets.Também foi acrescentado caixas de mensagens.Sem os applets o iMobile ME possibilita apenas o compartilhamento de dados.
iMobile ME
engineconsole echo
rpc
addr
rcm d
de v le ts in fo le ts
outbox o utb oxinbo x inbo x
iMobile ME
Não há padronização para os x-lets, deixando o desenvolvedor livre para implementar qualquer tipo de modelo ou protocolo – se suportado.Três x-lets desempenham papeis importantes na arquitetura: console (devlet): permite que o usuário interaja com o
sistema. rcmd (devlet): responsável por receber e tratar as
requisições vindas de outros dispositivos. rpc (infolet): responsável por interagir com os rcmds para
obter informações de outros dispositivos.
Caixas de Mensagem
O iMobile ME utiliza caixas de mensagens para garantir uma sessão de comunicação mais confiável, evitando problemas de desconexão ou variação de largura de banda.O usuário é responsável por iniciar o processo de sincronização.Caso o iMobile SE não localize o destinatário da mensagem na hora do roteamento, a mensagem é armazenada e será entregue quando o usuário se conectar.
Descoberta de Recursos
iMobile ME não suporta redes ad-hoc.Todo o processo de descoberta de recursos disponíveis e roteamento das mensagens é realizado pelo iMobile SE.Os nós móveis devem manter seus dados atualizados no iMobile SE.
JXTA for J2ME
JXTA
Arquitetura aberta para desenvolvimento de aplicações P2P.Criada pela Sun Microsystems, e, hoje, mantida por colaboradores de todo o mundo.Tem como ideais: Interoperabilidade. Independência de plataforma. Ubiquidade.
Arquitetura JXTA
Arquitetura JXTA
A arquitetura do JXTA pode ser dividida em três camada: Core: encapsula as primitivas essenciais
(descoberta de grupos e nós, transporte, etc.) Service: acomoda serviços adicionais
comumente utilizado ou desejáveis pelas aplicações (busca e indexação, diretórios, etc.)
Application: aplicações específicas que utilizam os serviços da rede.
Elementos do JXTA
PeerPeer GroupPipeMensagemAdvertisementsSegurançaProtocolos
Peer
Qualquer dispositivo que faça parte da rede JXTA.Cada nó opera independente e assincronamente dos outros.Os nós publicas os seus peer endpoints, por onde eles recebem conexões.Classificados como: Minimal edge peer Full-feature edge peer Rendezvous peer Relay peer
Peer
Peer Group
Os nós podem se auto-organizar em grupos, estabelecendo políticas internas.Os motivos que levam a criação de grupo varia.
Ex.: Definição de escopo computacional, comunicação segura e monitoramento.Grupos podem ser usados para prover serviços com tolerância a falha – se um membro ficar indisponível, outro pode tratar a requisição.
Pipes
São canais de comunicação assíncronos e unidirecionais.Não há nenhuma restrição sobre o tipo de dado que trafega por um pipe.Os pipes são dividos em pipe de entrada e de saída, provendo dois modos de comunicação: Ponto-a-Ponto: conecta um pipe de saída a um pipe de
entrada Propagação: conecta um pipe de saída a vários pipes de
entrada.
Modos de Comunicação
Mensagem
Uma mensagem pode ser representada em formato binário ou em formato XML.Elas são formadas de uma seqüência de elementos.Os elemento possuem um nome, um tipo e conteúdo.
Formato XML<?xml version="1.0"?><!DOCTYPE Message><Message version="0"> <Element name="jxta:SourceAddress“ mime_type="text/plain"> tcp://123.456.205.212 </Element> <Element name="stuff“ encoding="base64“ mime_type="application/octet-stream"> ............ </Element></Message>
Formato Binário
jxmg 0 01 05 proxy 05jxel 2 0 07 request 06 searchjxel 2 0 04 type 04 Peerjxel 2 0 04 attr 04 Namejxel 2 0 05 value 06 Waxsysjxel 2 0 09 requestId 01 1
Obs.: A mensagem em formato binário não possui espaços em branco ou quebras de linhas.
Advertisements
São os anúncios utilizados para descoberta de serviços, nós, grupos e pipes.São representados por documentos XMLs e também utilizam TTL para manutenção da arquitetura.Na implementação para J2SE, é provido pelos rendezvous peers um serviço de indexação para otimizar a busca.
Advertisements
Segurança
Os desenvolvedores do JXTA querem que os protocolos de comunicação sejam compatíveis com os protocolos de transporte seguro já difundidos (SSL, TLS, etc.).O uso de XML dá suporte a essa compatibilidade (certificado, digests, etc.).
Protocolos
A arquitetura JXTA já fornece um conjunto de protocolos padrões, que são divididos em duas categorias: Core Specification: protocolos obrigatórios que
devem ser implementados. Standard Service: protocolos opcionais, mas
que facilitam os desenvolvimento.
Java Micro Edition
J2ME é uma tecnologia Java destinada à pequenos dispositivos, como pagers, celulares, PDAs, set-top boxes, etc.Fornece dois tipos de configurações: CDC e CDLC.Fornece diversos profiles: MIDP, FP, PP, etc.
JXTA for J2ME
O projeto visa: Manter compatibilidade com o JXTA rodando
em desktops Prover infra-estrutura para desenvolvimento de
facilitado de aplicações P2P Ser compatível com CLDC e MIDP Ser pequeno o suficiente para rodar em
aparelhos celulares
Adaptações na Arquitetura
Devido à limitações, tanto dos equipamentos quanto da tecnologia Java, os desenvolvedores optaram por utilizar os relay peers como proxies para os dispositivos móveis.Eles provêem a interoperabilidade com a rede infra-estruturada, filtram os dados e fazem a conversão entre XML e binário.As APIs e serviços também foram reduzidos para se acomodar às limitações.Não fornece suporte à segurança.
Exemplo
Conclusões
Konark
Redes parcialmente ou totalmente ad-hoc.Utiliza padrões bem disseminados – HTTP e SOAP. Mas pode necessitar de mais recursos computacionais.Estrutura de armazenamento em árvore com classificação auxilia na busca.Utilização de propriedades nos serviços.Não há suporte a segurança.
iMobile ME
Utiliza a rede infra-estruturada (iMobile SE).Arquitetura centralizada.Suporte ao compartilhamento de recursos.Não há padronização, o que torna a arquitetura flexível, mas não interoperável.Suporte a desconexão através das caixas de mensagens.
JXTA for J2ME
Utiliza os relay peers para a execução de tarefas, como busca e criação de pipes.Não permite a criação de redes ad-hoc.Ubiquidade.Interoperabilidade com a rede infra-estruturada.Independência de plataforma.
Konark iMobile JXTAInfra-estrutura Não Sim Sim
Protocolo Transporte
HTTP sobre TCP/IP
Independente Independente
Protocolo de Rede Independente - Independente
Tipo de Mensagem XML - XML ou Binária
Suporte Desconexão
Não Sim Não
Protocolos Padronizados
Sim Não Sim
Descoberta de Recursos
Anúncio/Pesquisa
Via iMobile SE Anúncio/Pesquisa
Centralizado Não Sim Não*
Demanda de Recursos
Alto Variável Baixo
Perguntas?!?
Obrigado!