Carregamento Dinâmico de Serviços de Mapas Contextuais via R-OSGi

Transcrição

1 Carregamento Dinâmico de Serviços de Mapas Contextuais via R-OSGi Lucas Balbino de Melo Ferreira, Ricardo Couto Antunes da Rocha 1 Instituto de Informática Universidade Federal de Goiás (UFG) Caixa Postal Goiânia GO Brasil {lucasferreira, ricardo}@inf.ufg.br Palavras-chave Serviços de Mapas Contextuais; Infraestrutura baseada em R-OSGi; Framework; R-OSGi no Android. 1. Introdução No projeto de pesquisa Provisão de Contexto Distribuída baseada em Escopo para Computação Sensível ao Contexto foi desenvolvido um framework para provisão de mapas [3] onde é possível o desenvolvimento de serviços de mapas que possam ser carregados e exibidos em dispositivos movéis baseados na plataforma Android 1. Para avaliar este framework foram implementados três instâncias de serviços de mapas: o serviço Google Maps 2, um protótipo de serviço de mapas próprio (bitmapeados) e um protótipo para um serviço com localizações simbólicas. Um dos principais problemas ainda não tratados nesta pesquisa é o carregamento dinâmico de instâncias do framework, que representam implementações de um serviço de mapas particular. Os serviços de mapas são mantidos remotamente, isto é, na rede, logo para acessar tais serviços um cliente deve ser capaz de interagir com o protocolo de comunicação específico do serviço, assim como com suas primitivas de visualização. O OSGi (ou Open Services Gateway Initiative) [1] é uma especificação desenvolvido pela OSGi Alliance de um padrão aberto de modularização dinâmica com componentes colaborativos e reutilizáveis. Ele provê um sistema de carregamento de componentes sob demanda, permitindo o melhor uso da memória, tempo de processamento e outros recursos. Alguns sistemas complexos como o ambiente integrado para desenvolvimento de software Eclipse 3 são construídos tendo com base o framework OSGi. O R-OSGi (Remote OSGi) [11] é uma extensão do OSGi que realiza o carregamento de componentes do OSGi de forma remota. Como Revisado pelo orientador. Aluno de PIBIC, Instituto de Informática, UFG. Orientador PIBIC maps.google.com/ 3

2 a interação entre o cliente e os serviços de mapas deve ser mantida de forma distribuída, o R-OSGi se torna um candidato à realização deste gerenciamento remoto. O objetivo deste trabalho é projetar e implementar uma infraestrutura de carregamento dinâmico de serviços de mapas na plataforma Android baseado no R-OSGi. Os serviços de mapas serão projetados segundo o framework proposto em [2] e implementados como um componente OSGi, para serem carregados dinâmica e remotamente por clientes dispostos na plataforma Android através do R-OSGi. A infraestrutura deve ser adequada à execução do framework R-OSGi em dispositivos móveis, ou seja, os bytecodes Java gerados para a comunicação deverão ser traduzidos para estruturas compatíveis à máquina virtual Dalvik (utilizada pela plataforma Android). Antes da iniciação do desenvolvimento dos artefatos esperados do projeto, é necessária a contextualização das teorias utilizadas neste processo. Na seção 3 todas as características e funções do framework a ser adaptado por esse projeto de pesquisa serão explicadas. Na seção 4 serão tratados assuntos relacionados à especificação base do sistema, o OSGi, que serão detalhados no ponto-de-vista do acesso remoto utilizando uma extensão de distribuição e na ideia da descoberta. Serão citados alguns projetos com perspectivas semelhantes a este trabalho na seção Trabalhos Relacionados Dentre os projetos correlacionados aos objetos deste trabalho há o ROCS (Remote OSGi Caching Service) [4] que utiliza os componentes do framework OSGi na administração do ciclo de vida da aplicação e nos mecanismos de carregamento de classes Java distribuídas para que serviços remotos possam ser descobertos em uma específica área. Ele provê o fornecimento dos serviços disponíveis para os dispositivos que se encontram em um ambiente, mesmo que estes dispositivos não queiram utilizar todos estes serviços. O ROCS proporciona melhorias em duas áreas: primeiro definindo um ambiente de inicialização mínima para a execução da pilha Java/OSGi padrão e em seguida fornecendo uma arquitetura para o carregamento na memória de classes necessárias para a distribuição dos servidores em tempo de execução. Este projeto possui a mesma preocupação do ROCS sobre carregamento remoto baseado em OSGi. Em [10], os autores propõem a utilização do OSGi em ambientes inteligentes. A abordagem remota do OSGi proposta inclui gerentes remotos e agentes de gerência. Um gerente remoto é um administrador centralizado que comunica com os agentes de gerência, que são conjuntos de módulos OSGi que provêm administração remota da plataforma de serviço alvo. O estudo de caso apresentado engloba dispositivos móveis para a integração com o ambiente inteligente. Já no artigo [6] é proposta um infraestrutura para aplicações sensíveis ao contexto ba-

3 seada em OSGi que utiliza uma arquitetura SOCAM (Service-Oriented Context-Aware Middleware) [7]. Através da arquitetura SOCAM um conjunto de serviços independentes é proposto para aquisição e interpretação de contextos. Ela converte vários espaços físicos onde os contextos são adquiridos em um espaço semântico onde aplicações sensíveis ao contexto podem compartilhar e acessar estes contextos facilmente. O OSGi é utilizado para oferecer independência de plataforma, vários níveis de sistema de segurança, vários serviços de diferentes fabricantes em uma única plataforma e suporte para múltiplas tecnologias de redes domésticas. A infraestrutura é organizada em um gateway residencial compatível com OSGi (cada componente SOCAM é construído como um componente OSGi independente) e um operador deste gateway. A arquitetura SOCAM utiliza comunicação entre os serviços e os clientes semelhante à proposta por este trabalho. Há ainda o sistema apresentado em [9] que estabelece uma estrutura sensível ao contexto com comunicação M2M (Machine-to-Machine) 4 para a recuperação de dados coletados de sensores por dispositivos móvies Android. Ele utiliza o OSGi para portabilidade e modularização do sistema, além de XMPP (extensible Messaging and Presence Protocol) 5 para a comunicação com o servidor remoto. Este sistema também apresenta uma relação entre a especificação OSGi e o sistema operacional Android com características comuns às da infraestrutura deste projeto. Esses projetos relacionados não são plenamente capazes de solucionar o problema que este trabalho propõe, pois nenhum desenvolve uma infraestrutura completa para a descoberta e comunicação remota entre cliente móvel e servidor estático com a especificidade de trabalhar com mapas. Em [4], os serviços em um ambiente são encontrados dinamicamente, no entanto ele necessita de um servidor ROCS genérico de cache (além dos serviços e do dispositivo cliente), o que dificulta a livre comunicação entre o dispositivo e o provedor dos serviços de mapas. O sistema de [10] é eficaz em áreas restritas e os dispositivos móveis não possuem papel de clientes propriamente dito, mas sim de controles do ambiente inteligente. O trabalho de [6] não contextualiza a ideia de clientes móveis e em [9], os serviços repassados ao dispositivo Android se traduzem em simples dados de sensores e não em possíveis serviços de provedores de mapas. 3. Framework para Carregamento Dinâmico e Transição Suave entre Mapas Contextuais O framework desenvolvido em [3] permite implementar o conceito de mapas contextuais. Estes mapas são providos, descobertos e carregados dinamicamente por diferentes bases de mapas que apresentam semânticas únicas. Este framework deve prover algumas funcionalidades: oferecer mecanismos de navegação nos mapas, disponibilizar os mapas recuperados de uma forma apresentável ao usuário, fornecer uma comunicação entre o cliente e os provedores dos ma- 4 m2m.com/ 5 xmpp.org/

4 pas e resgatar as notificações de descoberta de mapas e localização do usuário através de um middleware sensível ao contexto. Ele ainda deve oferecer integração transparente aos serviços de mapas de diversos servidores por uma única interface de navegação e visualização. Cada instância do framework define então um protocolo de comunicação com o provedor e especifica a renderização dos mapas na interface de usuário do cliente. Uma forma organizada e intuitiva de gerenciar as atribuições do framework foi projetá-lo conforme o padrão de projeto MVC (Model-View-Controller) [5]. O componente Model cuida da modelagem dos mapas em objetos manipuláveis pelo framework. Cada instância do framework implementará o Model de acordo com a estrutura de seus mapas. O componente View renderiza os mapas e responde aos comandos do usuário, como navegação e troca de mapas, através uma interface comum à todas as instâncias. Cada componente View é associado a um controlador descrito apenas como um atributo do tipo Controller responsável pela tradução dos comandos de navegação e detalhamento. O componente Controller estabelece a comunicação com os serviços de mapas e o middleware sensível ao contexto. Ele fica responsável por estabelecer um canal de diálogo entre o cliente e o servidor viabilizando a recuperação dos mapas contextuais do serviço de determinado provedor. Na sua interação com o middleware, ele publica o interesse em receber notificações de mudanças contextuais que possam interferir na lista de mapas exibida pela aplicação. O principal componente remoto a ser carregado nos clientes é o componente Controller, pois a forma de comunicação entre os servidores e o cliente será totalmente remodelada. 4. Carregamento Remoto de Componentes OSGi O OSGi é um middleware universal orientado a serviços que tem a responsabilidade de manter a consistência dos serviços instalados dependentes um do outro. Ele é uma plataforma voltada para uma distribuição de larga escala e para uma grande extensão de dispositivos. A definição do framework é dividida em camadas: Ambiente de Execução, Módulos, Ciclo de Vida e Serviços. O Ambiente de Execução cuida da especificação do ambiente Java onde o OSGi será provido (JavaSE, CDC, CLDC e outros ambientes de execução válidos para OSGi). A camada dos Módulos, a camada de implantação do OSGi, cria o conceito de bundles: unidades de modularização expressas por arquivos JAR. Nela são definidas as regras de carregamento e compartilhamento entre bundles e se um bundle pode se tornar invisível a outro. Estas regras são definidas a partir de um arquivo de configuração (manifest file) que expressa os serviços necessários para execução e os serviços fornecidos. A camada de Ciclo de Vida, a camada de gerenciamento do OSGi, determina uma API para o controle de operações relacionados tanto à segurança quanto ao ciclo de vida dos bun-

5 dles. Ela define quando os bundles poderão ser iniciados ou parados, e quando estes deverão ser instalados, atualizados e desinstalados. Uma classe especial chamada ativadora define os métodos que controla este ciclo, iniciando as operações do framework ou desalocando os recursos quando este for desativado. A camada de Serviços, a camada de comunicação do OSGi, especifica um modelo conciso e dinâmico de programação que torna o desenvolvimento de serviços simples, desacoplando as interfaces das implementações. Ela permite que desenvolvedores criem as relações entre serviços pelas especificações de suas interfaces. Serviços provedores publicam seus serviços em um registro de serviços, enquanto os serviços clientes pesquisam no registro para encontrar serviços disponíveis para o uso. Neste projeto, os serviços de mapas se registrarão e a partir de um serviço de descoberta, o framework rodando no cliente requisitará este serviço. A especificação original do OSGi não oferece acesso remoto aos seus componentes. Uma extensão fornecida pela última resolução do OSGi [1] chamada Distributed OSGi fornece a distribuição do OSGi centralizado. O Distributed OSGi cria o conceito de estabelecer um provedor de distribuição no framework OSGi: este pode criar um endpoint 6 para exportar um serviço ou criar um proxy que acessa um endpoint para registrar esse proxy como um serviço importado. Neste trabalho, escolhemos utilizar o serviço R-OSGi [11], que funciona como o provedor de distribuição, para o carregamento remoto de componentes. No R-OSGi, serviços locais e remotos são indistinguíveis e os erros relativos à distribuição são encapsulados. Ele possui quatro características principais: (i) utiliza a geração de um proxy dinâmico feita no tempo de bind pela invocação de serviços pela rede; (ii) possui um registro de serviços distribuído baseado no serviço de descoberta SLP; (iii) tem um tratador local de eventos que realiza o mapeamento de rede e falhas remotas; e (iv) é efetuada a injeção de tipos para solucionar as dependências de tipos. O carregamento dos serviços, além de distribuído, deve ser dinâmico, ou seja, descoberto em tempo de execução. Integrado ao R-OSGi, o serviço de descoberta SLP (Service Location Protocol) [8] disponibiliza o acesso a estes serviços remotos. O SLP é um protocolo desenvolvido pela IETF para redes TCP/IP escalável para amplas redes. A arquitetura do SLP possui três componentes: os User Agents (UA) que realiza a descoberta dos serviços em nome do cliente, os Service Agents (SA) que anunciam a localização e características dos serviços pelo servidor e os Directory Agents (DA) que coletam os endereços e informações recebidas pelos SAs em um banco de dados e responde às requisições dos UAs. Neste projeto o componente DA foi suprimido para simplicação, pois a requisição pode ser feita através de multicast do UA para os SAs e apenas os interessados res- 6 um mecanismo de acesso à comunicação de um serviço em outro framework ou outro processo, que requer algum protocolo para comunicação.

6 ponderem diretamente para UA específico. Porém se pela demanda este se tornar necessário, ele pode ser adicionado à infraestrutura sem problemas. A consulta SLP obedece o esquema service:abstracttype:concretetype, onde abstracttype = osgi indica que o serviço procurado é um serviço OSGi e concretetype é o nome da interface do serviço. 5. Infraestrutura de Carregamento Dinâmico de Serviços de Mapas A infraestrutura criada para a disponibilidade do carregamento remoto e dinâmico de mapas contextuais é composta por três elementos: (i) um dispositivo móvel cliente que realiza as requisições dos mapas, (ii) servidores de mapas que oferecem os mapas contextuais aos clientes e (iii) serviços de descoberta em rede que tornam possível a identificação dos serviços prestados pelos servidores ao cliente. O dispositivo móvel efetua uma consulta aos serviços de descoberta que lhe retornam os serviços de mapas dispostos em determinada rede. Em uma mesma rede, mais de um serviço de mapas pode estar disponível. Neste trabalho, consideraremos a rede local como o escopo de um serviço de mapas. A figura 1 ilustra o relacionamento entre os componentes da infraestrutura. Figura 1. Cenário de descoberta de serviços de mapas contextuais. Um dispositivo móvel pode se comunicar com mais de um serviço de descoberta, como apresentado na figura 1, pois cada serviço adere um escopo diferente às redes onde ele está instalado. Logo o dispositivo cliente pode ter acesso a mapas de provedores de redes diferentes e transitar entre esses mapas sem problema algum, pois cada serviço de descoberta atua de forma independente. Na seção 5.1 será especificado o funcionamento do framework principal da infraestrutura proposta pelo projeto. Na seção 5.2 serão discutidos alguns exemplos de implementações

7 possíveis para as instâncias dos servidores de mapas. A seção 5.3 demonstrará a importância do carregamento dinâmico neste trabalho, enquanto as seções 5.4 e 5.5 tratarão das particularidades necessárias para a execução do framework em um dispositivo móvel Android Framework para Carregamento Dinâmico de Mapas Contextuais O framework para carregamento dos mapas segue de uma estrutura fixa, chamada instância base, que possui primitivas e comandos aos mapas genéricos fornecidos pelo Google Maps para que a aplicação funcione mesmo sem localizar um servidor de mapas contextuais, além das instâncias deste framework para cada serviço de mapas, disponibilizadas pelos provedores. A instância base Framework de Mapas ainda necessita expor a interface com métodos implementáveis para que qualquer instância obtida de algum provedor de mapas consiga realizar o manuseio e o controle dos mapas contextuais deste. Cada servidor de mapas deve possuir uma instância do framework nos moldes do padrão de projeto MVC, pois é através dos procedimentos desenvolvidos na instância em cada componente que os mapas contextuais presentes no servidor poderão ser manipulados. Estas instâncias devem implementar todos os métodos da interface do framework para que todas as funcionalidades previstas sejam satisfeitas. Esta imposição é expressa pelos métodos A, B e C da interface base e da uma instância da interface presentes na figura 2. Para que o dispositivo móvel cliente possa obter a instância de um servidor de mapas específico e, a partir de suas funções, baixar mapas de forma dinâmica proporcionando à aplicação os controles sobre esses mapas, a instância base deve realizar uma consulta ao serviço de descoberta sobre este servidor. A infraestrutura proposta adotou o SLP [8] como serviço de descoberta e a consulta segue a partir do nome da interface do framework: a chamada service:osgi:interfacemaps na figura 2 expressa a assinatura da requisição. Logo, todo servidor deve exportar o nome da interface como identificação do serviço, para que o serviço de descoberta possa encontrá-lo e o framework possa utilizar o serviço que ele provê. Uma instância do framework é obtida pela geração de proxy dinâmico fornecida pela configuração do R-OSGi, porém apenas o componente Controller integra esse proxy, ou seja, ele é o único que realiza a comunicação remota entre o cliente e o serviço. Os demais módulos desenvolvidos pelo padrão MVC, Model e View, que são de suma importância para a administração dos mapas por meio da aplicação são obtidos através da injeção de tipos carregada a partir do cliente, também disponibilizado pelo R-OSGi. Este processo é ilustrado na comunicação entre o cliente e o servidor (1) da figura 2. Uma vez obtida com sucesso a instância de um servidor, o acesso ao serviço de mapas desta instância se torna direto. Logo, a aplicação executando sobre este framework pode utilizar os mapas de acordo com os procedimentos implementados pela instância. A captura de mapas contextuais por meio do componente Controller da instância pode ser visualizada em (2)

8 na figura 2. Figura 2. Etapas para a obtenção dinâmica de mapas contextuais pelo framework. O framework e toda a sua estrutura são organizados em forma de bundles OSGi. No cliente e no servidor, os bundles que exportam os serviços importantes para a distribuição remota do R-OSGi e para a descoberta pelo SLP rodam em cima de uma implementação da especificação OSGi (cada um sobre sua específica máquina virtual). No projeto foi utilizada a implementação Eclipse Equinox 7. Além de importar os serviços R-OSGi e SLP, o Framework de Mapas ainda importa os serviços de mapas, que são as implementações das instâncias do framework disponibilizado pelo servidor através do nome da interface. Um dispositivo cliente pode ter mais de uma instância executando e poderá transitar entre elas através de comandos da aplicação. A dinâmica de importações e exportações entre os bundles pode ser visualizada na figura 3. Ainda sobre a implementação do OSGi, outros bundles de apoio são executados sobre ela, porém eles não desempenham papel na explicação da infraestrutura do projeto e portanto foram suprimidos da figura

9 Figura 3. Especificação dos bundles na infraestrutura do projeto Implementação dos Serviços de Mapas Neste trabalho foram implementadas duas das três instâncias de serviços de mapas implementadas anteriormente em [3], porém com o carregamento dinâmico provido pelo OSGi. A instância sobre mapas bitmapeados utiliza um objeto específico da API Android para manipular as propriedades de um mapa e ele é representado através de uma imagem baixada em tempo de execução pelo cliente. A instância sobre mapas baseados em KML apresenta uma estrutura de arquivo interessante para a representação dos mapas Instância do Serviço de Mapas Bitmapeado Nesta instância, utilizamos o objeto MapObject para representar um mapa. Ele contém duas coordenadas geográficas GeoPoint do ponto mais a direita superior e mais a esquerda inferior, o nome deste mapa contextual, a URL onde a imagem pode ser baixada e o nível de zoom desta. A interface exportada pelo servidor (e passível de implementação no dispositivo cliente)

10 oferece dois métodos de busca: por nome ou por geolocalização. Em ambas consultas o retorno será uma lista de objetos referentes aos mapas encontrados (ou uma lista vazia, se nenhum for encontrado). O ativador OSGi do servidor registra o serviço pelo nome da interface através do R-OSGi e carrega todos os mapas que possui para que qualquer cliente tenha acesso a eles. Para o dispositivo móvel basta apenas descobrir esse serviço registrado com o SLP e requisitar os mapas através do método exposto. No código abaixo é mostrada a interface utilizada nesta instância. O nome da interface é genérico e utilizado para identificar como um serviço de mapas OSGi. p u b l i c i n t e r f a c e I n t e r f a c e M a p s { p u b l i c A r r a y L i s t<mapobject> getmaps ( S t r i n g name ) ; p u b l i c A r r a y L i s t<mapobject> getmaps ( GeoPoint g e o P o i n t ) ; } Se o serviço de mapas não está mais disponível ou se o dispositivo saiu do alcance da rede do servidor, o SLP notifica a indisponibilidade e o cliente fica impedido de tentar requisitar outras operações ao serviço. Os componentes carregados então são removidos da memória do dispositivo móvel para oferecer lugar a serviços acessíveis Instância do Serviço de Mapas baseado em KML Outra instância desenvolvida pelo projeto toma como base representações de mapas a partir de arquivos e não apenas objetos. Essa estrutura tem a vantagem de representar além de coordenadas, nome e local de obtenção de uma imagem, pode armazenar muitas outras informações como marcações, descrições dos mapas, caminhos e até informações para construir polinômios, além do conteúdo do arquivo ser escalável. Decidiu-se então escolher a representação através de arquivos KML. KML (Keyhole Markup Language) 8 é um arquivo sob a notação XML que expressa estruturas geográficas bidimensionais ou tridimensionais. Este arquivo permite a realização de pesquisas geográficas e simbólicas através de uma assinatura específica e mais universal. A assinatura é uma cadeia de caracteres e segue a disposição: loc:nomesimbólico, para consultas simbólicas ou geo:coordenadas, para consultas geográficas (seguido de coordenadas para o ajuste à tela do dispositivo). A interface oferece um serviço semelhante ao da instância anterior, entretanto uma lista de arquivos KML serão retornados referentes à assinatura da consulta (ou uma lista vazia, como na predecessora). 8 developers.google.com/kml/

11 A interface apresentada no código abaixo possui a mesma estrutura da exemplificada na instância da seção 5.2.1: o nome é importante na descoberta do serviço e o método será executado pelo proxy criado no cliente. p u b l i c i n t e r f a c e I n t e r f a c e M a p s { } p u b l i c A r r a y L i s t<kml> getmaps ( S t r i n g query ) ; As funções do ativador OSGi e as ações tanto do cliente quanto do servidor são análogas à instância com mapas bitmapeados Carregamento Dinâmico dos Serviços O framework necessita de um carregamento dinâmico dos serviços, pois a infraestrutura propõe uma ampla flexibilidade no desenvolvimento dos serviços, além de não obter os servidores de forma fixa. Assim novos provedores de mapas podem ser agregados e os existentes podem alterar a sua estrutura, respeitando os procedimentos da interface do serviço, sem afetar o cliente de forma direta. Este carregamento dinâmico é provido e mantido pelo R-OSGi, que trata da conexão com novos serviços disponíveis, atualização dos serviços existentes e exclusão dos serviços onde o acesso foi perdido. Em [3], o framework não dispunha da flexibilidade e escalabilidade que a modularização do OSGi propõe, logo o carregamento se tornava mais limitado, sendo feito via sockets. Também não havia sido totalmente desenvolvido o conceito de serviços de mapas, apenas a disponibilização e recuperação dos mapas contextuais, através de um endereço específico, sem descoberta dinâmica. Com o R-OSGi adjunto ao SLP, os serviços podem ser registrados remotamente e de forma assíncrona, tornando possível o carregamento no cliente quando este ingressa no escopo do provedor do serviço Serviço R-OSGi no Android O serviço R-OSGi não é naturalmente portável para executar sobre Android. As interfaces transmitidas entre servidor e cliente estão na forma de bytecode Java e portanto não executáveis pela máquina virtual do Android, Dalvik. Em [12], o autor descreve duas modificações necessárias tanto para rodar o R-OSGi sobre um dispositivo Android, quanto para acessar serviços remotos por um dispositivo Android. As alterações que permitem a execução do R-OSGi no Android são realizadas nas classes para torná-las acessíveis à máquina virtual Dalvik. Através de uma ferramenta disponibilizada pelo Android SDK chamada dx é possível converter um bundle OSGi em arquivos bytecode Dalvik. Entretanto a interface do serviço exportado deve ser adicionada em seu formato original (bytecode Java) a este novo pacote, permitindo a descoberta do serviço e o seu

12 envio para conexão remota. Por fim, o bundle executável por um dispositivo Android deve conter o manifesto, as classes em bytecode Dalvik e a interface do serviço em bytecode Java. No cliente, a interface em formato bytecode Java é recebida, analisada e é criado um objeto proxy desta em tempo de execução. Para que dispositivos Android possam realizar isto, as modificações devem ser feitas na análise e na criação do objeto proxy. É necessária a tradução da biblioteca ASM 9, responsável pela análise, para Android e a adição ao próprio contexto do R-OSGi de um método que converte o objeto proxy gerado de bytecode Java para bytecode Dalvik Componentes Android do Framework de Mapas Baseado na modificação proposta na seção 5.4, podemos portar um bundle R-OSGi para execução em um dispositivo Android. Contudo para que o framework da infraestrutura rode sem problemas no dispositivo cliente algumas particularidades devem ser ressaltadas. O ativador da instância base deve registrar o interesse em instâncias do framework e disponibilizar a execução de uma Activity 10 que implementa os controles básicos dos mapas do Google Maps. Os componentes Controller e View são implementados para administrar a renderização e navegação destes mapas. Quando um novo servidor de mapas for descoberto através do nome da interface, este é acrescentado à lista de provedores disponíveis e apresentado ao usuário que escolhe com qual servidor quer se comunicar. Uma vez selecionado o serviço de mapas, um objeto proxy é criado e este implementa todos métodos do framework, além de obter as classes necessárias para o funcionamento da instância. Os métodos do framework possuem as mesmas convenções que as da API do Google Maps, para facilitar a integração com este. Desta forma, o conceito de camadas de mapas possui a forma de um objeto Overlay Android, os comandos de controle sobre os serviços, como changecontexmap(), updatefwview() e clearfwview(), possuem semântica simples e as operações comuns de navegação em mapas também seguem da API, como set- Center(GeoPoint), setzoom(int), zoomin() e zoomout(). Portanto, o usuário pode navegar pelos mapas apresentados, realizar consultas ou mudar de provedor acessando a lista com os serviços acessíveis para obter novos mapas. Quando um servidor se torna indisponível, este é removido da lista e se estiver sendo utilizado, dá lugar ao próximo serviço (ou às primitivas do Google Maps, se não houver mais nenhum disponível). Vale ressaltar que as classes são executáveis à máquina virtual Dalvik através do processo de conversão proposto por [12]. 9 asm.ow2.org/ 10 Componente de interface gráfica da plataforma Android.

13 6. Conclusões Dentro do proposto, é possível afirmar que a implantação da infraestrutura desenvolvida não é trivial. Tanto a implementação de um serviço de descoberta eficaz quanto a portabilidade do R-OSGi no Android, por ser uma ideia relativamente nova, ainda possuem dificuldades intrínsecas e complicações desnecessárias. Todavia foi possível o desenvolvimento do conceito da infraestrutura, a adaptação dos elementos em componentes OSGi e a publicação e obtenção de serviços de mapas em redes locais. O trabalho começado em [3] construiu o framework de mapas com carregamento dinâmico e com possibilidade de transição suave entre os mapas contextuais obtidos. Este projeto estendeu este conceito apresentando uma infraestrutura que lida com este framework tendo base na especificação OSGi, uma das mais promissoras dos últimos anos. Ele ainda insere a elaboração de um sistema de descoberta dos mapas dispostos em serviços e a estrutura dos servidores de mapas. O estudo de caso das duas instâncias demonstra que os serviços de mapas podem ser diferentes e mesmo assim totalmente integráveis, revelando os benefícios desta estrutura. Nota-se que a infraestrutura especificada neste projeto ainda não apresenta todo potencial que possui, porém exibe um excelente ponto de partida para o que no futuro ubíquo será natural. Os mapas contextuais e as aplicações destes em escopos cada vez mais específicos são uma realidade necessária e por enquanto não estão recebendo a devida atenção. Este projeto contextualiza a inserção das informações pervasivas relacionadas aos mapas conjuntamente à mobilidade disponível em dispositivos de bolso. Ele expõe uma utilidade futura, mas que deve começar a ser desenvolvida hoje. Referências [1] ALLIANCE, O. OSGi Service Platform, Service Compendium: release 4, Version 4.2. Aqute Publishing, [2] DE OLIVEIRA PEREIRA, H. M., AND DA ROCHA, R. C. A. Localizacao, mapas e contexto: Um framework para desenvolvimento de aplicações baseadas em mapas contextuais. In Simposio Brasileiro de Computacao Ubiqua e Pervasiva (SBCUP) (2010). [3] DE SOUZA RESENDE, D. I., DA ROCHA, R. C. A., AND DE OLIVEIRA PEREIRA, H. M. Um framework para carregamento dinâmico e transição suave entre mapas contextuais. In Simposio Brasileiro de Computacao Ubiqua e Pervasiva (SBCUP) (2011). (submetido). [4] FRÉNOT, S., IBRAHIM, N., LE MOUËL, F., BEN HAMIDA, A., PONGE, J., CHANTREL, M., AND BERAS, D. ROCS: a remotely provisioned OSGi framework for ambient systems. In Proceedings of the 12th IEEE/IFIP Network Operations and Management Symposium (NOMS 2010) (Osaka, Japan, Apr. 2010), pp

14 [5] GAMMA, E., HELM, R., JOHNSON, R. E., AND VLISSIDES, J. Design Patterns: Elements of Reusable Object-Oriented Software. Addison-Wesley, Reading, MA, [6] GU, T., PUNG, H. K., AND ZHANG, D. Q. Toward an osgi-based infrastructure for contextaware applications. IEEE Pervasive Computing 3, 4 (Oct. 2004), [7] GU, T., PUNG, H. K., AND ZHANG, D. Q. A service-oriented middleware for building context-aware services. Journal of Network and Computer Applications 28, 1 (2005), [8] GUTTMAN, E., PERKINS, C., VEIZADES, J., AND DAY, M. Service Location Protocol, Version 2, June RFC [9] KUNA, M., KOLARIC, H., BOJIC, I., KUSEK, M., AND JEZIC, G. Android/osgi-based machine-to-machine context-aware system. Tech. rep., University of Zagreb, Faculty of Electrical Engineering and Computing, Department of Telecommunications, Unska 3, HR-10000, Zagreb, Croatia, [10] LEE, C., NORDSTEDT, D., AND HELAL, S. Enabling smart spaces with osgi. IEEE Pervasive Computing 2, 3 (July 2003), [11] RELLERMEYER, J. S., ALONSO, G., AND ROSCOE, T. R-osgi: distributed applications through software modularization. In Proceedings of the 8th ACM/IFIP/USENIX international conference on Middleware (Berlin, Heidelberg, 2007), MIDDLEWARE2007, Springer-Verlag, pp [12] SCHÜTTE, J. Remote osgi on android. remote-osgi-android/, [Online; acessado 20 de Junho de 2012].