Middleware para Serviços Baseados em Localização Ricardo Couto Antunes da Rocha rcarocha@inf.puc-rio.br

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

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.

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.

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

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.

Arquitetura de Software para LBS

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

Modelos de middleware para LBS Publish/Subscribe Baseado em conteúdo Baseado em subject spaces Espaço de tuplas Baseado em DBMS

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

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

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:

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)

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)}

Publish/Subscribe Subject Spaces Relacionamento entre Subject Spaces S2 S1 S3 S4 S5

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

Publish/Subscribe Subject Spaces Mudança de estado de um objeto em um sistema de publish/subscribe ocorre em três situações: Adicionando um objeto no subject space Atualizando um objeto no subject space Removendo um objeto no subject space Subscriptions são conjuntos de requisitos que especificam o interesse de um subscriber

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

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

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

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.

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

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.