Middleware para Serviços
Baseados em Localização
Ricardo Couto Antunes da Rocha
[email protected]
© 2004 – Ricardo Couto Antunes da Rocha
1
Roteiro
 Motivação
 Aplicações de Serviços baseados em Localização
 Arquitetura de Software para LBS
 Requisitos para Middleware para LBS
 Modelos de Middleware para LBS
 Conclusões
© 2004 – Ricardo Couto Antunes da Rocha
2
Motivação
 Cenário atual: popularização de dispositivos móveis e de
tecnologia de posicionamento (como GPS)
 Cenário habilita o desenvolvimento de aplicações de LBS
 Algumas operadores de telefonia oferecem aplicações
simples de LBS. Exemplo: DoCoMo i-area.
© 2004 – Ricardo Couto Antunes da Rocha
3
Motivação
 Ambiente de computação móvel são
tradicionalmente heterogêneos:
Rede: GPRS, TCP, 802.11
Identidade: usuário/senha, device id, telefone celular
Posicionamento: GPS, cell id, ...
 Middleware habilita o desenvolvimento de
aplicações apesar do ambiente heterogêneo.
 Fio motivador:
Características necessárias e modelos interessantes
para um middleware para permitir a implementação de
aplicações de LBS.
© 2004 – Ricardo Couto Antunes da Rocha
4
Aplicações de LBS
 Recuperar a localização de um usuário móvel é
um desafio menor.
 Desafios mais evidentes:
Tratamento homogêneo da localização
Casamento de interesse entre consumidores de
informação e disseminadores de informação
Disseminação seletiva de informações, dependendo da
localização
Volume grande de dados:
 Localização não está associada apenas aos usuários móveis
mas também às informações distribuídas
© 2004 – Ricardo Couto Antunes da Rocha
5
Aplicações de LBS
 Exemplo:
Um estudante de pós-graduação deseja estudar PAA na
biblioteca. Ele acessa uma aplicação de LBS em seu
PDA e registra o seu interesse (estudar PAA) e
requisita à aplicação encontrar outro estudante com o
mesmo interesse e próximo da biblioteca. A aplicação
mostra três estudantes que atendem a esses requisitos
e o estudante envia uma mensagem para um deles,
sugerindo o estudo em grupo.
© 2004 – Ricardo Couto Antunes da Rocha
6
Arquitetura de Software para
LBS
© 2004 – Ricardo Couto Antunes da Rocha
7
Requisitos para Middleware
para LBS
 Capacidade de tratar diferentes aspectos da localização:
 Aspecto espacial
 Temporalidade
 Inaccuracy, imprecisão e incerteza
 Grandes volumes de dados
 Queries contínuas
 Capacidade de funcionar com tecnologias heterogêneas
 Canais de notificação (GPRS, SMS, 802.11)
 Posicionamento (GPS, cell id, indoor)
 Conceitos de posicionamento (lat/long, célula, rua, ...)
 Permitir o casamento complexo de interesses entre
diversos usuários
© 2004 – Ricardo Couto Antunes da Rocha
8
Modelos de middleware para
LBS
 Publish/Subscribe
Baseado em conteúdo
Baseado em subject spaces
 Espaço de tuplas
 Baseado em DBMS
© 2004 – Ricardo Couto Antunes da Rocha
9
Modelo Publish/Subscribe
 Comunicação é intermediada por um serviço de
eventos ou event broker
 Modelo de eventos push/pull
Publicador de eventos é o publisher: envia os eventos
ativamente para o broker
Consumidor de eventos é o subscriber: registra no
broker o interesse por eventos e é notificado quando o
evento desejado ocorre
 Modelo de comunicação assíncrono e
desacoplado
 Tipos de publish/subscribe: tópico, tipo, conteúdo
e subject spaces
© 2004 – Ricardo Couto Antunes da Rocha
10
Publish/Subscribe baseado
em Conteúdo
 Eventos são formados por um conjunto de
atributos.
Exemplo: E = {(MAC ID=05:AA:01:02:11),
(CPU=70%),(location=(13,234))}
 O subscriber registra o interesse por eventos com
uma série de predicados que descrevem
restrições aos valores dos atributos de eventos.
Exemplo: (location, (x < 10) and (y
<=200))
 Características do evento localização:
Pode mudar em uma taxa relativamente alta
O publicador de eventos pode ser um agente externo
© 2004 – Ricardo Couto Antunes da Rocha
11
Publish/Subscribe baseado
em Conteúdo
 Abordagem alternativa para pub/sub para LBS
L-ToPSS: localização é tratada separadamente das
demais informações de contexto
Arquitetura:
© 2004 – Ricardo Couto Antunes da Rocha
12
Publish/Subscribe
Subject Spaces
 Cenário
Uma loja de café envia propagandas para usuários
móveis na vizinhança de 1 Km
Um consumidor quer receber tais notificações, mas ele
não bebe mais do que 2 copos no intervalo de 5 horas
 Modelos publish/subscribe tradicionais não tratam
muito bem este cenário:
Desafio é evitar o recebimento de notificações
redundantes ou que não sejam do interesse
Notificação depende do tempo em que foi feito a
última notificação (só após 5 h, sistema pode enviar
outra notificação)
Publisher estabelece uma restrição (área de 1 Km)
© 2004 – Ricardo Couto Antunes da Rocha
13
Publish/Subscribe
Subject Spaces
 Características básicas:
Stateful
Publishing e subscription são igualmente tratados
 Subject space é um espaço multidimensional
em que cada dimensão representa um atributo
de um assunto (subject)
 Formalmente, é uma tupla {Do,Vo}, onde
Do={d1,d2,..dn} e Vo é o conjunto de valores
permitidos neste espaço
 Exemplo: dl = {(x,double),(y,double),(z,double)}
© 2004 – Ricardo Couto Antunes da Rocha
14
Publish/Subscribe
Subject Spaces
 Relacionamento entre Subject Spaces
S2
S4
S3
S1
© 2004 – Ricardo Couto Antunes da Rocha
S5
15
Publish/Subscribe
Subject Spaces
 Objeto de interesse: entidade monitorada pelo
publisher e que pode ser do interesse de um ou
mais subscribers
 Cada objeto de interesse possui um conjunto de
predicados: triplas com dimensão, operador,
valor.
 Exemplo: L1 = {(x < 10), (y <= 20)}
 Portanto, um objeto pode ocupar uma região em
um subject space
© 2004 – Ricardo Couto Antunes da Rocha
16
Publish/Subscribe
Subject Spaces
 Mudança de estado de um objeto em um
sistema de publish/subscribe ocorre em três
situações:
1. Adicionando um objeto no subject space
2. Atualizando um objeto no subject space
3. Removendo um objeto no subject space
 Subscriptions são conjuntos de requisitos que
especificam o interesse de um subscriber
© 2004 – Ricardo Couto Antunes da Rocha
17
Publish/Subscribe
Subject Spaces
 Outros operadores e formalismos:
Filtro: mapeia um conjunto de regiões em verdadeiro
ou falso. É utilizado em subscriptions
Tempo: tratado como um domínio discreto. Duas
funções são definidas:
 Função-π: mais recente instante em que duas regiões
combinaram
 Função-σ: mais recente instante em que duas regiões
deixaram de combinar
 Now: instante atual
© 2004 – Ricardo Couto Antunes da Rocha
18
Publish/Subscribe
Subject Spaces
 Espaço é multidimensional portanto a verificação
do casamento entre publications e subscriptions é
mais complexa  implementação pode ser
menos eficiente.
 Algumas técnicas para passar espaço
multidimensional para unidimensional podem ser
aplicadas.
 Vantagens do modelo
Evita notificações redundantes
Modelo publish/subscribe é simétrico
Usa operações de atualização, ao invés de remoção e
inclusão
© 2004 – Ricardo Couto Antunes da Rocha
19
Modelo baseado em tuplas
 Modelo proposto para coordenação de atividades
entre processos concorrentes. Originado em
Linda.
 Implementações para computação móvel: Lime e
L2imbo
 Permite comunicação desacoplada e anônima
 Dois elementos se comunicam lendo e
escrevendo em um espaço de tuplas:
Coleção global e persistente de tuplas
Uma tupla pode ser um dado tipado, contendo um
conjunto de valores, ou especificar um tipo de dado
© 2004 – Ricardo Couto Antunes da Rocha
20
Modelo baseado em tuplas
 Um elemento pode realizar três operações básicas:
 Out(t): insere a tupla t no espaço de tuplas
 In(p): extrai uma tupla do espaço de tuplas que combina com o
padrão de tupla p.
 Rd(p): similar a In(p), exceto que não remove a tupla do espaço
de tuplas
 Outras operações são providas por diferentes
implementações de middlewares de tuplas.
 Em LBS:
 Publicador registra a informação na forma de uma tupla
 Consumidor recupera a informação lendo no espaço de tuplas
 Modelo utiliza uma interação do tipo pull e não permite
disseminação de informação adequadamente.
© 2004 – Ricardo Couto Antunes da Rocha
21
Modelo baseado em DBMS
 Compreende o uso do modelo de interação de
banco de dados para implementar comunicação e
coordenação entre elementos.
 Permite o modelo de interação pull
 Permite operações relacionais flexíveis para
recuperação de informação
 Modelo disseminado na indústria e implementado
por boa parte dos GIS
© 2004 – Ricardo Couto Antunes da Rocha
22
Conclusões
 Middleware é uma abordagem adequada para superar
problemas de interoperabilidade e heterogeneidade
típicos do ambiente móvel.
 Por outro lado, o número crescente de propostas de
middlewares pode criar novos problemas de
interoperabilidade e inibir sua adoção.
 Esta apresentação discutiu requisitos que middlewares
(implementações e modelos) devem ser capazes de
atender para permitir a implementação de cenários de
LBS.
 Entretanto, isso não pressupõe o desenvolvimento de
novos middlewares mas a adequação dos modelos atuais
aos requisitos de LBS.
© 2004 – Ricardo Couto Antunes da Rocha
23