Arquitectura para Fornecimento de Serviços Push Multimédia baseados em Localização

Transcrição

1 Arquitectura para Fornecimento de Serviços Push Multimédia baseados em Localização João Pedro Rebola de Lima Gonçalves Dissertação para obtenção do Grau de Mestre em Engenharia Informática e de Computadores Presidente: Orientador: Orientador: Vogal: Acompanhante: Júri Professor António Ferreira Rito da Silva Professor António Artur Ferreira da Silva Professor Paulo Jorge Pires Ferreira Professor Nuno Filipe Valentim Roma Eng. Francisco van Uden Chaves Novembro 2010

2 Agradecimentos Este trabalho é submetido ao Instituto Superior Técnico da Universidade Técnica de Lisboa, completando o ciclo de Mestrado em Engenharia Informática e de Computadores. O trabalho foi desenvolvido no âmbito de uma parceria entre o Instituto de Engenharia de Sistemas e Computadores Investigação e Desenvolvimento (INESC-ID) de Lisboa com a empresa Movensis Serviços de Apoio a Comunicações, S.A. Quero expressar os meus sinceros agradecimentos aos professores António Artur Ferreira da Silva, Paulo Jorge Pires Ferreira e Vitor Manuel da Silva Rodrigues, que foram muito importantes no desenvolvimento e orientação deste trabalho. Não posso deixar de agradecer a todas as pessoas, família e amigos, que me deram o apoio necessário para que este trabalho pudesse ser concluído. Da minha família, agradeço especialmente aos meus pais Maria Rebola e Pedro Gonçalves pelos sábios conselhos que me deram e por acreditarem sempre em mim. Aos meus amigos, um abraço especial a Filipe Carvalho, José Figueiredo, Mafalda Santana, Sara Ferreira e Gonçalo Rocha, pelo apoio incondicional e incentivo. Um agradecimento muito especial também a Michelle Laranjeira Granja, pela sua paciência e apoio quando tudo parecia impossível. Quero igualmente agradecer a Diogo Simões e Francisco Chaves, por todo o conhecimento transmitido e incentivo no desenvolvimento deste trabalho, sem os quais este nunca teria sido possível. Finalmente, dedico este trabalho em memória de Edite Gonçalves, minha avó, cujo empenho e interesse por ver o neto graduado nunca serão esquecidos, assim como todo o seu apoio e incentivo durante o decorrer do meu percurso académico. Lisboa, 20 de Novembro de 2010 João Gonçalves I

3 Resumo A utilização do telemóvel tornou-se prática corrente na sociedade moderna. Com o crescente número de acessos móveis à Internet, muitos novos tipos de serviços surgiram tirando partido da mobilidade dos utilizadores, tais como mobile banking, instant messaging, entre outros. Uma classe de serviços que utiliza a localização do utilizador como critério serviços baseados em localização (LBS) surge com interesse particular, permitindo o fornecimento de serviços com informação acerca da vizinhança espacial do utilizador. Estes serviços podem ser estendidos com conteúdo multimédia rico, entregue de forma push, constituindo uma solução dinâmica para mobile marketing. Este trabalho apresenta uma plataforma de criação de serviços baseados em localização com push de conteúdo multimédia com lógica programável, focando-se na escalabilidade, acessibilidade e flexibilidade de componentes, permitindo a sua utilização com vários sistemas de localização e interfaces de comunicação. Utiliza a tecnologia inovadora Parlay X, uma camada de web-services sobre a arquitectura IMS da rede de operador móvel, para providenciar um sistema de localização e forma de envio de conteúdo multimédia de forma push. Palavras-chave: LBS (Serviços Baseados em Localização), Multimédia, Serviços Push, Parlay X. Abstract Mobile phone usage has become a standard practice in today s society. With the growing usage of mobile Internet access, many new types of services have appeared that make use of the user s mobility, such as mobile banking, instant messaging and so on. A class of services that use the user s location as criteria location-based services (LBS) is of particular interest, since it allows the provision of services with information on the users vicinity. These services can be extended with rich multimedia content delivered in a push way, providing a dynamic solution for mobile marketing purposes. This work introduces a platform for housing mobile multimedia push location services with programmable logic, focusing on scalability, accessibility and flexibility of components, allowing its usage with various location systems and communication interfaces. It uses the innovative Parlay X technology, a web-services layer over a mobile network operator s IMS architecture, to solve both the location and content push issues. Keywords: LBS (Location Based Services), Multimedia, Mobile, Push Services, Parlay X. II

4 Índice ÍNDICE... III ÍNDICE DE FIGURAS... VI ÍNDICE DE TABELAS... VII LISTA DE ACRÓNIMOS... VIII 1 INTRODUÇÃO ENQUADRAMENTO E MOTIVAÇÃO OBJECTIVO TRABALHO RELACIONADO SOLUÇÃO ROADMAP CONCEITOS E TRABALHO RELACIONADO TÉCNICAS DE LOCALIZAÇÃO Técnicas de Localização de Âmbito Local Técnicas de Localização por Satélite Técnicas de Localização por Rede de Operador Comparação de Soluções SOLUÇÕES PARA ENVIO DE CONTEÚDO MULTIMÉDIA DE FORMA PUSH Aplicação e Protocolo Proprietários MMS (Multimedia Messaging System) WAP-Push MBMS (Multimedia Broadcast-Multicast Service) Comparação de Soluções SOLUÇÕES ABRANGENTES Bluetooth Parlay X OneAPI Comparação de Soluções IMS (IP MULTIMEDIA SUBSYSTEM) E PARLAY X SOLUÇÕES COMERCIAIS E ACADÉMICAS CONCLUSÕES ARQUITECTURA REQUISITOS DO SISTEMA CASOS DE USO DIAGRAMA DE COMPONENTES III

5 3.3.1 Operador Móvel Componente de Billing Interface Apresentação Lógica Persistência DIAGRAMAS DE INTERACÇÃO CONCLUSÕES IMPLEMENTAÇÃO COMPONENTE DE PERSISTÊNCIA Tecnologia de Persistência Servidor de Utilizadores Servidor de Serviços Servidor de Conteúdos GATEWAY PARLAY X Emulador Parlay X Componentes Java CONECTORES COMPONENTE DE LÓGICA Gestor de Interfaces Núcleo Lógico COMPONENTE DE APRESENTAÇÃO Tecnologia Utilizada Portal de Utilizador Portal de Administração e Provedores CONCLUSÃO AVALIAÇÃO DA SOLUÇÃO AMBIENTE DE TESTES Servidor de Páginas de Utilizadores Servidor de Utilizadores, Serviços e Conteúdos Base de Dados Emulador de Gateway Parlay X TESTES DE FUNCIONALIDADE Testes de Integração Testes de Sistema TESTES DE NÃO-FUNCIONALIDADE Testes de Desempenho Testes de Usabilidade ANÁLISE DOS RESULTADOS IV

6 5.5 INSTALAÇÃO ESCALÁVEL CONCLUSÕES TRABALHO FUTURO COMPONENTE DE BILLING E REPORTING SEGURANÇA INTEGRAÇÃO COM A ONEAPI DIFUSÃO ESCALÁVEL DE CONTEÚDO MULTIMÉDIA SERVIÇOS INTERACTIVOS BIBLIOGRAFIA V

7 Índice de Figuras FIGURA FACTORES CRÍTICOS DE SUCESSO PARA SERVIÇOS PUSH LBS MULTIMÉDIA... 3 FIGURA 1-2 EXEMPLOS DE TIPOS DE LBS... 4 FIGURA DIAGRAMA DE FUNCIONAMENTO DE ALTO NÍVEL DA SOLUÇÃO... 7 FIGURA 2-1- QUATRO COMPONENTES ESSENCIAIS PARA O FORNECIMENTO DE UM LBS... 8 FIGURA ENVIO DE MENSAGEM WAP-PUSH PARA UM TERMINAL MÓVEL [29] FIGURA INFRA-ESTRUTURA TÍPICA PARA UM LBS UTILIZANDO PONTOS DE ACESSO BLUETOOTH. 19 FIGURA DIAGRAMA DE CAMADAS DA ARQUITECTURA IMS (IP MULTIMEDIA SUBSYSTEM) [39] FIGURA CASOS DE USO PARA O UTILIZADOR USER FIGURA CASOS DE USO PARA OS UTILIZADORES ADMINISTRATIVOS FIGURA CASOS DE USO PARA O ACTOR PARLAY X GATEWAY FIGURA CASOS DE USO PARA O ACTOR NÚCLEO LÓGICO FIGURA DIAGRAMA DE COMPONENTES DA ARQUITECTURA PARA A SOLUÇÃO PROPOSTA FIGURA DIAGRAMA DE CAMADAS DE UM MÓDULO DE ACESSO A DADOS FIGURA ENTRADA DE UTILIZADOR EM ÁREA GEOGRÁFICA E NOTIFICAÇÃO FIGURA TRATAMENTO DA NOTIFICAÇÃO DE ENTRADA EM ÁREA E SELECÇÃO DE SERVIÇO FIGURA ENTREGA DO SERVIÇO AO UTILIZADOR FIGURA SINCRONIZAÇÃO DE NOTIFICAÇÕES DE ENTRADA FIGURA AUTENTICAÇÃO DE UTILIZADORES FIGURA PLANEAMENTO DA IMPLEMENTAÇÃO FIGURA RELAÇÃO ENTE CATEGORIAS E SUBCATEGORIAS TEMÁTICAS FIGURA DIAGRAMA DE ESTADOS DE SERVIÇOS FIGURA APLICAÇÃO WEB DO EMULADOR PARLAY X DA ERICSSON FIGURA ESTRUTURA DE CLASSES DE UM CONECTOR FIGURA ESTRUTURA DE CLASSES DE UMA INTERFACE FIGURA PROCESSO DE REGISTO E AUTENTICAÇÃO DE UTILIZADORES FIGURA MENU DE TOPO DE PÁGINA NO PORTAL DE UTILIZADOR FIGURA PÁGINA DE PESQUISA DE SERVIÇOS NO PORTAL DE UTILIZADOR FIGURA AMBIENTE DE TRABALHO DO PORTAL DE ADMINISTRAÇÃO FIGURA 4-11 JANELA PRINCIPAL DA APLICAÇÃO VIRTUAL USER MANAGER FIGURA JANELA DE EDIÇÃO DE UTILIZADOR, APLICAÇÃO USER MANAGER FIGURA JANELA DE GESTÃO DE ÁREAS GEOGRÁFICAS FIGURA PASSOS DO WIZARD DE CRIAÇÃO DE SERVIÇOS FIGURA DIAGRAMA DE INSTALAÇÃO DO AMBIENTE DE TESTES FIGURA VISUALIZAÇÃO DE TRÁFEGO DE CHAMADAS A WEB-SERVICES NO EMULADOR PARLAY X. 62 FIGURA MAPA NO EMULADOR PARLAY X PARA ENVIO DE NOTIFICAÇÕES FIGURA DISTRIBUIÇÃO ESCALÁVEL DOS COMPONENTES DO SISTEMA FIGURA SISTEMA DE NOTIFICAÇÕES NA INTEGRAÇÃO COM A ONEAPI VI

8 Índice de Tabelas TABELA VANTAGENS E DESVANTAGENS DA LOCALIZAÇÃO POR INFRAVERMELHOS TABELA VANTAGENS E DESVANTAGENS DA LOCALIZAÇÃO POR ULTRA-SONS TABELA VANTAGENS E DESVANTAGENS DA LOCALIZAÇÃO POR W-LAN TABELA COMPARAÇÃO DE SOLUÇÕES PARA LOCALIZAÇÃO TABELA COMPARAÇÃO DE SOLUÇÕES PARA ENVIO DE CONTEÚDO MULTIMÉDIA DE FORMA PUSH. 18 TABELA APIS PARLAYX TABELA COMPARAÇÃO DE SOLUÇÕES ABRANGENTES (LOCALIZAÇÃO E ENVIO DE DADOS) TABELA REQUISITO-BASE DO SISTEMA TABELA REQUISITOS NÃO-FUNCIONAIS DO SISTEMA TABELA REQUISITOS FUNCIONAIS DO SISTEMA TABELA INTERFACES EXPORTADAS PELOS MÓDULOS DE GESTÃO DE DADOS DO COMPONENTE LÓGICA TABELA PÁGINAS DE DADOS DE PERFIL DO UTILIZADOR NO PORTAL DE UTILIZADOR TABELA PERMISSÕES DOS UTILIZADORES NO PORTAL DE ADMINISTRAÇÃO TABELA ESPECIFICAÇÕES TÉCNICAS DO AMBIENTE VIRTUAL TABELA ESPECIFICAÇÕES TÉCNICAS DO SERVIDOR DE PÁGINAS DE UTILIZADORES TABELA ESPECIFICAÇÕES TÉCNICAS DO EMULADOR DE GATEWAY PARLAY X TABELA INTERACÇÕES PARA TESTES DE INTEGRAÇÃO TABELA ÁREAS DEFINIDAS PARA TESTAR O ENVIO DE NOTIFICAÇÕES TABELA ASSOCIAÇÃO DE SERVIÇOS A ÁREAS GEOGRÁFICAS PARA EFEITOS DE TESTE TABELA CATEGORIAS DE PREFERÊNCIAS DEFINIDAS PARA EFEITOS DE TESTE TABELA ASSOCIAÇÃO DE SERVIÇOS DE TESTE A PREFERÊNCIAS TABELA LÓGICA DOS SERVIÇOS UTILIZADOS NOS TESTES TABELA RESULTADO DOS TESTES DE DESEMPENHO NA DETECÇÃO DE UTILIZADORES TABELA RESULTADO DO TESTE DE DESEMPENHO NO FORNECIMENTO DE SERVIÇOS TABELA RESULTADO DOS TESTES COM UTILIZADORES TABELA RESULTADOS DOS QUESTIONÁRIOS A UTILIZADORES VII

9 Lista de Acrónimos A-GPS AOA API BM-SC DAO DB DBMS E-OTD GPRS GPS GSM HTTP ID IMS IP IR ISP J2ME LAN LBS MBMS MMS MSISDN PDA PPG RFID RMI RPC RTSP RTT SDK SMIL SMPP SMTP SMS SOAP Assisted Global Positioning System Angle of Arrival Application Programming Interface Broadcast-Multicast Service Centre Data Access Object DataBase DataBase Management System Enhanced Observed Time Difference General Packet Radio Service Global Positioning System Global System for Mobile Communications Hyper-Text Transfer Protocol Identificador IP Multimedia Subsystem Internet Protocol Infra-Red Internet Service Provider Java 2 Micro Edition Local Area Network Location Based Services Multimedia Broadcast-Multicast Service Multimedia Messaging Service Mobile Subscriber Integrated Services Digital Number Personal Data Assistant Push Proxy Gateway Radio-Frequency IDentification Remote Method Invocation Remote Procedure Calls Real-Time Streaming Protocol Round Trip Time Software Development Kit Synchronized Multimedia Integration Language Short Message Peer-to-Peer (Protocol) Simple Mail Transfer Protocol Short Message Service Simple Object Access Protocol VIII

10 TDOA TOA UMTS URL W-LAN WAP WSDL XML Time Difference of Arrival Time of Arrival Universal Mobile Telecommunications System Uniform Resource Locator Wireless Local Area Network Wireless Application Protocol Web Services Definition Language extensible Markup Language IX

11 1 Introdução 1.1 Enquadramento e Motivação No início da década de 1960, a Internet surgiu como um meio de partilha de informação e dados entre vários computadores dispostos em localizações geográficas diferentes. Hoje em dia, estima-se que seja usado por mais de um quarto da população mundial [1]. O crescimento da utilização da Internet na década de 1990 viu surgir novos tipos de conteúdos audiovisuais nas páginas web, sendo no entanto limitados pelas velocidades de transmissão de rede disponíveis na altura acesso maioritariamente feito por via telefónica - e pela capacidade de processamento dos computadores. A qualidade e quantidade destes conteúdos têm vindo a evoluir com o aumento significativo das velocidades de transmissão das redes informáticas e da capacidade de processamento dos terminais fixos que lhes acedem, proporcionando o fornecimento de serviços cada vez mais apelativos que não eram possíveis ou viáveis há duas décadas atrás [2]. Muitos dos serviços prestados actualmente através da Internet como o , mensagens instantâneas (IM Instant Messaging) e redes sociais são considerados essenciais pelos utilizadores. A ubiquidade no acesso a estes serviços [3] através da Internet faz com que, cada vez mais, estes se integrem activamente no estilo de vida dos seus utilizadores, tanto ao nível pessoal como profissional. Paralelamente, os terminais móveis, como o telemóvel, smartphone e computador portátil, têm evoluído também de modo a possibilitar o acesso à Internet em movimento. A mobilidade conferida por estes dispositivos associada às capacidades de comunicação e acesso à Internet dos mesmos tem conduzido à adopção dos telemóveis como dispositivos pessoais de eleição. O facto de, com a mobilidade e ubiquidade, podermos aceder a serviços em qualquer local, hora e em movimento tem vindo a motivar cada vez mais a implementação de novos e melhores serviços, seguindo um novo paradigma serviços móveis. Estes fazem uso da capacidade de comunicação global conferida pelo acesso à Internet e pela informação de contexto que conseguem extrair do meio envolvente do utilizador, como a posição geográfica, som envolvente, entre outros. O acesso móvel à Internet, apesar de limitado pelas características dos terminais móveis, tem vindo a evoluir com o avanço na sua capacidade de processamento e com o aumento da largura de banda e velocidade das redes móveis que lhes servem de suporte de comunicação. É hoje possível proporcionar serviços mais ricos e apelativos ao utilizador final através das redes móveis de terceira geração 3G e 3.5G permitindo estas velocidades de utilização da Internet no telemóvel comparáveis às fornecidas por ISPs (Internet Service Providers) ao domicílio. Num futuro próximo, as redes móveis de quarta-geração (4G - LTE (Long Term Evolution) e WiMax) irão contribuir para o esbatimento da linha divisória entre os acessos à 1

12 Internet móveis e fixos em termos de funcionalidade e velocidade, sendo uma área de crescente desenvolvimento [4]. O aumento da capacidade dos terminais móveis e das redes móveis que suportam a comunicação entre eles possibilita o aparecimento de serviços contendo elementos multimédia ricos. Estes são particularmente importantes em cenários de publicidade, turismo e eventos promocionais, nos quais a transmissão de imagens e sensações ao utilizador final são determinantes na aceitação do serviço como um serviço de qualidade. A transmissão de conteúdo adaptado a cada tipo de utilizador é igualmente importante no domínio do marketing O2O (one-to-one) [5], no qual o conteúdo é adaptado individualmente para o público-alvo, tendo em consideração as suas preferências. Os terminais móveis, pelas características inerentes de mobilidade, possibilitam o fornecimento de serviços baseados na localização do seu utilizador (LBS Location Based Services). Este tipo de serviços beneficia de interesse acrescido quando combinado com a possibilidade de comportar conteúdo multimédia rico. Entre várias possibilidades, esta combinação permite a obtenção informação acerca de eventos na proximidade da localização do utilizador, informação sobre o seu percurso e difusão de imagens e vídeos de acontecimentos na sua proximidade. A forma de aceder a estes serviços é frequentemente baseada em pedidos feitos pelo utilizador à entidade fornecedora do serviço, denominando-se uma política de fornecimento de serviços do tipo Pull. Neste caso, é o utilizador que explicitamente fornece a sua localização e informação relevante para que o serviço seja fornecido. Uma outra possibilidade, consiste em fornecer serviços sem a necessidade de um pedido explícito por parte do utilizador. Neste tipo, denominado de Push, são obtidas automaticamente, por parte de uma entidade externa ou periodicamente por uma aplicação controlada pelo utilizador, informações de localização e contexto relevantes para o fornecimento do serviço, o qual é enviado sem a intervenção do utilizador. Os serviços do tipo push são particularmente úteis na difusão de informação por vários terminais móveis [6]. Existe actualmente um número reduzido de soluções que permitam o fornecimento de serviços móveis do tipo Push baseados em localização. Grande parte destas não permite o fornecimento de conteúdos multimédia de forma abrangente, sendo necessário recorrer a aplicações instaladas nos terminais móveis ou a protocolos de transmissão de dados que limitam a os potenciais clientes do serviço. A utilização destas soluções implica também frequentemente a instalação de infra-estruturas de redes móveis de suporte ou o recurso a tecnologias de localização não disponíveis na maioria dos terminais móveis. As soluções existentes são também muitas vezes concebidas para fornecimento de serviços especializados, focando-se na área de serviços móveis informativos relacionada com a localização do utilizador e pontos de interesse na sua proximidade ou publicitários. As tecnologias empregues por cada solução na resolução dos seus problemas específicos são por vezes desadequadas à adaptação a outros potenciais tipos serviços, limitando a sua flexibilidade. 2

13 Considerando então os pontos apresentados, identificam-se os seguintes factores críticos de sucesso para uma solução de fornecimento de serviços do tipo push com conteúdos multimédia e baseados em localização (Figura 1-1): Escalabilidade: Os serviços baseados em localização com conteúdo multimédia lidam com transacção de dados volumosos, tendo também elevada probabilidade de um número elevado de utilizadores. Como tal, existe uma necessidade de escalabilidade por parte da solução, em relação ao número de utilizadores. A noção estende-se também aos próprios serviços fornecidos, devendo o sistema também suportar um elevado número de serviços diferentes. Acessibilidade: Tratando-se de serviços baseados em localização, existe a necessidade de estarem disponíveis através de tecnologias acessíveis isto é disponíveis para grande parte dos utilizadores do serviço, ao nível do hardware e software utilizado nos terminais móveis. Deve também utilizar técnicas de localização que permitam cobrir uma maior área possível. Flexibilidade: As soluções existentes para serviços desta natureza são muitas vezes indicadas para um só tipo de serviço, seja ele publicitário (advertising), de interacção social, informativo ou lúdico. Uma solução flexível implica a possibilidade de construção de todos estes tipos de serviços sobre a mesma plataforma, com a vantagem de ser possível adicionar novos serviços com requisitos e características funcionais diferentes a posteriori. Escalabilidade Multimedia Push LBS Acessibilidade Flexibilidade Figura Factores críticos de sucesso para serviços Push LBS Multimédia Torna-se então necessário responder a questões como: Como fornecer serviços LBS de uma forma global? Como transmitir conteúdos multimédia de forma Push para o utilizador? Como obter e manipular a informação necessária para fornecer o serviço ao utilizador? 3

14 Como permitir a existência simultânea de vários fornecedores de serviço mantendo a escalabilidade do sistema? Como permitir a definição de serviços de forma genérica, tendo em vista a flexibilidade do sistema? 1.2 Objectivo Os serviços baseados em localização têm diversas áreas de aplicação possíveis (Figura 1-2), tendo sido sobretudo popularizados com a introdução do GPS (Global Positioning System) em aplicações de auxílio de navegação com recurso a mapas utilizado sobretudo em assistentes de navegação para automóveis. Transmissão de relatos desportivos Entretenimento Mensagens Instantêneas Localização de Amigos Publicidade LBS Informação Noticias Emergência Navegação Potos de Interesse Traçar Rotas Figura 1-2 Exemplos de tipos de LBS A aplicação de navegação por GPS necessita apenas de obter a localização do terminal móvel no Mundo, de modo a apresentá-la num mapa ao utilizador e executar algum processamento sobre as rotas possíveis que este pode tomar. Tipicamente, um serviço LBS fará algum processamento da informação de contexto associada á localização do utilizador, enviando informação personalizada de volta para o mesmo o que pode ser tão simples quanto o envio de uma notificação ao utilizador quando este entra ou sai de uma determinada área geográfica. Soluções deste género existem hoje em dia sob a forma de serviços de informação e publicidade móvel, fornecendo conteúdo quando o utilizador se encontra na proximidade de locais de interesse ou zonas comerciais [7]. O objectivo deste trabalho é o desenho e implementação de uma plataforma de fornecimento de serviços móveis LBS do tipo Push com conteúdo multimédia, possibilitando a construção de serviços tão simples quanto os serviços de publicidade móvel mencionados, mas suficientemente modular e flexível para permitir a inclusão de novos tipos de serviços no futuro. Assim, esta plataforma deverá permitir: 4

15 Registo de utilizadores e preferências dos mesmos. Definição de serviços configuráveis (configuração de áreas geográficas de acção, calendarização, forma de transmissão de conteúdos e tipo de conteúdos possíveis de transmitir), servindo-se da informação de contexto (localização, tempo e preferências) dos utilizadores. Mapeamento entre utilizadores e serviços, feita quer por adesão directa a serviços quer por heurísticas com base nas preferências do utilizador ou no seu estado actual. Envio de conteúdo multimédia rico (streams de áudio, vídeo e imagens) para os utilizadores sem a sua intervenção directa - de forma Push. Considerando os factores críticos apresentados (Figura 1-1) e a enumeração de funcionalidades apresentada acima, pretende-se que a solução seja capaz de fornecer os serviços LBS recorrendo a tecnologia padrão (standard) presente nos telemóveis usados actualmente e com a possibilidade de utilização de técnicas de localização que abranjam uma maior área possível (Acessibilidade). Pretende-se igualmente que a solução mantenha uma qualidade de serviço (QoS Quality of Service) e desempenho aceitáveis face a um número elevado de subscritores e serviços [8], evitando ao máximo componentes centralizados e colocando ênfase numa arquitectura modular e cujos componentes possam ser distribuídos e replicados por vários nós na rede de servidores (Escalabilidade). Finalmente, a solução deverá suportar serviços de diferentes tipos, isto é, com lógicas de funcionamento, pré-requisitos e tratamento de informação de localização diferentes entre eles, permitindo assim a construção de novos tipos de serviços sobre a mesma arquitectura (Flexibilidade). Com os pontos apresentados, formulou-se a hipótese que se pretende provar: Servindo-se das tecnologias actualmente disponíveis nos terminais móveis e nas redes de comunicação móvel, é possível criar uma plataforma flexível de definição e fornecimento de serviços do tipo push baseados na localização e outras informações de contexto do utilizador e dotados de conteúdo multimédia rico. De modo a provar a hipótese formulada, serão estudadas tecnologias e técnicas disponíveis que permitam a determinar a localização de um terminal móvel, bem como a possibilidade de transferir conteúdos multimédia de forma Push para os terminais móveis, mantendo a compatibilidade com o máximo de dispositivos possível. Será ainda necessário definir uma arquitectura que permita alcançar os requisitos de Escalabilidade e Flexibilidade enumerados, sendo estes não só derivados das tecnologias escolhidas mas também do desenho e separação de módulos arquitecturais que terá de ser tido em conta desde o início. A solução deverá ter assim o potencial de crescer com o número 5

16 de serviços prestados através dela não só aqueles estudados, mas outros que poderão surgir e com o número de subscritores. 1.3 Trabalho Relacionado Para o desenvolvimento de uma solução de fornecimento de serviços LBS do tipo push com conteúdo multimédia, são analisadas soluções em quatro vertentes Soluções completas de fornecimento de serviços LBS do tipo push académicas e comerciais, técnicas de localização, soluções para envio de conteúdo multimédia de forma push e soluções abrangentes. As soluções comerciais e académicas são soluções completas que permitem alcançar alguns dos objectivos propostos, não abrangendo necessariamente todos os factores críticos enumerados. São analisadas ofertas comerciais de Bluetooth Marketing [7] e duas soluções académicas, uma focando Bluetooth [9] e outra utilizando a tecnologia Parlay X [10]. Na perspectiva de análise às tecnologias usadas no desenho de uma solução LBS do tipo push, identificam-se técnicas de localização disponíveis para o efeito, assim como soluções disponíveis para efectuar a transferência de conteúdos multimédia de forma push. No âmbito das técnicas de localização, são estudadas técnicas de três tipos: Âmbito local, permitindo a localização a curto alcance e espaços interiores. Satélite, possibilitando a localização à escala global, com pouca tolerância a obstáculos ao sinal, menos indicadas para espaços interiores. Rede Móvel, abrangendo ambas as áreas interior e exterior mas em desvantagem na precisão. Para as técnicas de transferências de conteúdos multimédia de forma push, analisam-se soluções utilizando protocolos personalizados, o sistema de mensagens disponível por rede móvel SMS (Short Messaging System), MMS (Multimedia Messaging System) e WAP-Push assim como o MBMS (Multimedia Broadcast-Multicast Service), desenhado para streaming de conteúdo multimédia de forma escalável entre múltiplos receptores. Finalmente, são analisadas soluções abrangentes, isto é, permitindo a combinação entre soluções de localização e envio de conteúdos multimédia. Destacam-se neste campo o Bluetooth, utilizado nas soluções comerciais estudadas, e o Parlay X, uma framework emergente para criação de aplicações que utilizem as funcionalidades disponibilizadas pelas redes de operador móvel. As soluções analisadas são comparadas, verificando a sua adequação ao cumprimento dos objectivos propostos e factores críticos. 1.4 Solução A solução proposta utiliza a tecnologia Parlay X para efectuar a localização de terminais, envio de conteúdo multimédia para os mesmos e obtenção de informação de contexto, recorrendo a um conjunto de funcionalidades disponibilizadas por esta mesma tecnologia. A Figura 1-3 representa o funcionamento de alto nível da solução. 6

17 1 Localização Terminal Móvel 6 Contexto 5 Provedor de Serviços Envio de Dados Figura Diagrama de funcionamento de alto nível da solução 1. O terminal móvel envia a informação de localização do utilizador para a interface de localização do provedor de serviços. 2. O utilizador e a zona em que este se encontra são obtidos e enviados para o provedor de serviços, onde são processados para obter um serviço para fornecer ao utilizador com base nas suas preferências e serviços aderidos. 3. No processamento do serviço, o provedor pode requisitar informação de contexto sobre o utilizador, fazendo-o através da interface de contexto. 4. A interface de contexto obtém a informação necessária acerca do utilizador e retorna-a ao provedor, para processamento. 5. O provedor prepara o conteúdo do serviço a enviar ao utilizador, colocando-o na interface de envio de dados. 6. A interface de envio de dados envia o conteúdo para o terminal móvel do utilizador, com o formato apropriado. Para além deste comportamento, a solução possibilitará a criação e definição de serviços por parte de entidades provedoras, fornecendo as devidas interfaces para o efeito, assim como a criação de zonas onde os serviços terão efeito, através de uma interface administrativa. É também contemplado o registo de utilizadores de serviços e manipulação das suas preferências. 1.5 Roadmap No capítulo 2, apresentam-se um estudo de soluções disponíveis para a construção de uma solução que cumpra os objectivos propostos. Estas soluções são comparadas e, em conclusão, é escolhida qual a mais adequada. Esta será utilizada no capítulo 3 para a definição da arquitectura do sistema, onde serão explicados todos os componentes estáticos da arquitectura e a relação entre eles. Finalmente, serão definidas métricas de teste à solução proposta no capítulo 4, concluindo sobre o trabalho realizado no capítulo 5. 7

18 2 Conceitos e Trabalho Relacionado A construção de uma arquitectura de suporte a LBS (Location Based Services) pressupõe que se conheçam quais os seus requisitos de funcionamento [11] (Figura 2-1). Terminal Móvel Rede de Comunicação Móvel LBS Provedor de Conteúdos e Serviços Sistema de Localização Figura 2-1- Quatro componentes essenciais para o fornecimento de um LBS Terminal Móvel: O dispositivo para o qual vai ser fornecido o serviço. A solução tem de ser abrangente em relação aos terminais actualmente no mercado. Rede de Comunicação Móvel: Os dados transferidos durante o fornecimento do serviço terão de ser transmitidos por uma rede de comunicação. Esta será a rede móvel de operador, havendo interesse em usufruir das velocidades das redes de geração actual e de próxima geração 3G e 3.9G/4G, respectivamente. Sistema de Localização: A possibilidade de determinar a posição do utilizador é essencial ao fornecimento de um serviço baseado em localização. É necessária a investigação de quais as formas possíveis de localizar um terminal móvel e a sua viabilidade para integração na arquitectura que se propõe desenvolver. Provedor de Conteúdos e Serviços: A arquitectura desenvolvida terá como objectivo a definição de um distribuidor de LBS, sendo portanto o provedor de serviços. Por sua vez, o provedor de conteúdos detém o conteúdo para um serviço em particular. O provedor de serviços deverá portanto de comunicar com o provedor de conteúdos de forma a poder enviar conteúdo para o utilizador. Será objectivo deste capítulo o estudo das possíveis formas de fornecer os conteúdos aos utilizadores, enviando-os sem que estes os requisitem explicitamente isto é, de forma push. De forma a permitir a definição de serviços LBS, é necessária a obtenção do contexto de utilização do serviço, destacando-se em primeiro lugar a posição do utilizador como informação de contexto indispensável. De um modo geral, o contexto define-se como o conjunto dados que é possível obter acerca do utilizador e que pode ser utilizado para fornecer um serviço mais personalizado [12]. Difere das preferências do utilizador na medida em que este é calculado no acto do fornecimento do serviço, sendo portanto dinâmico. Em contrapartida, as preferências 8

19 do utilizador constituem informação estática podendo no entanto ser alteradas por este a qualquer momento. São exemplos de informação de contexto de utilização: Posição Actual Histórico de Posições Orientação Ambiente envolvente (social, cultural, condições atmosféricas, ) Estado do dispositivo usado A obtenção de informação de contexto é importante no fornecimento de serviços personalizados para o utilizador. Apesar de não ser o objectivo principal do trabalho a exploração de uma forma de obter toda a informação de contexto possível, serão privilegiadas tecnologias e soluções que permitam obtê-la como complemento da sua utilização. Ao longo deste capítulo, serão exploradas tecnologias e soluções existentes que permitam o fornecimento de serviços LBS do tipo push (i.e. sem um pedido explícito por parte do utilizador), analisando o modo como estas cumprem ou não os factores críticos enumerados para este projecto. Estas incidirão sobre soluções de localização e de push de conteúdo multimédia, assim como soluções abrangentes. 2.1 Técnicas de Localização O requisito principal no fornecimento de serviços baseados em localização é o conhecimento da localização do utilizador do serviço. Uma técnica bastante utilizada hoje em dia para este efeito é o GPS (Global Positioning System), capaz de fornecer coordenadas precisas para a posição do utilizador em qualquer ponto do Globo [13]. Nesta secção, serão apresentadas as técnicas de localização para o fornecimento de um serviço LBS, separadas logicamente em três categorias: Local: Técnicas utilizadas para localização a curto alcance ou em espaços interiores. Satélite: Técnicas de posicionamento global, via satélite. Rede de Operador: Técnicas utilizando a infra-estrutura de rede de um operador móvel Técnicas de Localização de Âmbito Local As técnicas de localização de âmbito local obtêm este nome por providenciarem apenas cobertura de áreas geográficas de pequena dimensão. São sobretudo empregues na localização de terminais que se encontrem em espaços interiores. Destacam-se: Localização por Infravermelhos Localização por Ultra-sons Localização por WiFi W-LAN 9

20 Localização por Infravermelhos A radiação infravermelha (IR Infrared) é um tipo de radiação electromagnética com um comprimento de onda entre os 700 e os 3000 nm (nanómetros). É invisível ao olho humano, estando abaixo da frequência da luz vermelha, obtendo igualmente assim o seu nome. O sistema Active Badge [14],desenvolvido pela Olivetti Research, é um sistema de localização por Infravermelhos, cujo objectivo principal é facilitar a logística de recursos humanos no meio empresarial, tirando partido do conhecimento da localização de cada elemento pessoal dentro da empresa. A ideia principal por trás do Active Badge é a distribuição de receptores de Infravermelhos por pontos-chave do edifício, estando cada membro do pessoal dotado de um emissor IR a Active Badge. Os receptores IR representam posições fixas no espaço, sendo a sua localização bem conhecida. As active badges emitem um sinal IR contendo um código de identificação único que, ao ser captado pelos receptores, é processado pelo sistema de localização, permitindo a determinação da posição do utilizador. A posição é calculada pela proximidade ao receptor que captou o sinal. É necessário um mapeamento entre os receptores de IR e as posições em que estes se encontram. Um sistema semelhante ao Active Badge é descrito em [15]. Este utiliza a localização por infravermelhos para guiar visitantes num museu. O sistema de localização por IR é portanto indicado a espaços interiores, com poucos obstáculos, e cujos pontos de referência sejam preferencialmente imóveis ou cuja localização seja bem conhecida. Tabela Vantagens e desvantagens da localização por Infravermelhos Vantagens Desvantagens Funciona no interior de edifícios. Limitado à utilização em espaços interiores. Tecnologia barata de produzir. Necessita de instalação de uma infraestrutura de receptores. Transmissor e receptor têm de estar a apontar directamente um para o outro (i.e. não tolera obstáculos ao raio IR). Grande parte dos telemóveis actuais não possui ligação IR Localização por Ultra-Sons Funcionando de forma semelhante à localização por Infravermelhos, é possível substituir o feixe IR por ultra-sons, mantendo a mesma arquitectura do sistema. Os ultra-sons são ondas sonoras com frequências superiores às possíveis de captar com o ouvido humano, situando-se acima dos 20KHz ( Hz (Hertz)). 10

21 O sistema de localização por ultra-sons desenvolvido pela AT&T Labs o sistema Active Bat [16] tem uma topologia semelhante ao sistema Active Badges, sendo usados emissores de ultra-sons os Active Bats no lugar das badges. Uma diferença notável para o sistema de localização por IR é o modo como a posição do emissor é calculada. Em vez de ser determinada pela proximidade ao sensor que captou o sinal, é calculada por triangulação utilizando a informação do sinal captado em múltiplos receptores aumentando a precisão. Outra diferença reside nas características dos ultra-sons face aos feixes IR. Ao propagarem-se em todas as direcções, e podendo ser reflectidos por obstáculos, não sofrem do problema de bloqueio de feixe presente no outro sistema. Tabela Vantagens e desvantagens da localização por ultra-sons Vantagens Desvantagens Funciona no interior de edifícios. Limitado à utilização em espaços interiores. Face ao IR, o sinal emitido não é facilmente bloqueado. Necessita de instalação de uma infraestrutura de receptores. Mais preciso que a localização por IR. Tecnologia basicamente impossível de utilizar em telemóveis WiFi W-LAN (Wireless Local Area Network) A W-LAN serve como propósito principal o fornecimento de acesso sem fios (wireless) a uma rede Ethernet, através da emissão de sinais rádio respeitando a norma IEEE [17]. As redes W-LAN, em modo de infra-estrutura, são compostas por uma série de routers e/ou access points wireless, aos quais os dispositivos móveis se conectam. Através do conhecimento da localização fixa das antenas presentes nos routers e access points, é possível determinar a localização dos dispositivos móveis a eles conectados [18] [19]. Este método tem uma precisão tanto maior quanto maior a densidade de antenas no sistema. Outros modos de localização passam pela triangulação da força do sinal captado numa dada posição, oriundo de múltiplos emissores ou pelo mapeamento das forças dos sinais recebidos por parte do receptor, que pode ser usado para calcular a sua posição [20]. A utilização de W-LAN como um método de localização é rentável, dado ser tecnologia de baixo custo e relativamente comum [13]. 11

22 Tabela Vantagens e Desvantagens da localização por W-LAN Vantagens Tecnologia de baixo custo e acessível. Possível utilização em espaços exteriores, com diferentes antenas. Desvantagens Necessita de instalação de uma infraestrutura densa de antenas para obter uma precisão aceitável. Grande parte dos telemóveis actuais não possui WiFi. Routers e Access Points mudam frequentemente de localização, introduzindo erros nos cálculos de posição Técnicas de Localização por Satélite As técnicas de localização por satélite permitem determinar a posição do utilizador em qualquer parte do Mundo. Existem várias implementações de localização por satélite, destacando-se o GPS (norte-americano, criado com finalidade militar), Galileo (projecto europeu, criado com finalidade civil) [21] e Glonass (de origem russa, criado para fins militares). Nesta secção, focar-se-á a tecnologia mais disseminada e utilizada o GPS. No GPS [22], existem diversos satélites na órbita terrestre, estando o sistema desenhado de modo a que estejam pelo menos cinco visíveis a cada instante em qualquer ponto do Mundo, permitindo a sua utilização à escala global. O sistema funciona utilizando um receptor de GPS, cuja captando de sinais de pelo menos três satélites, de modo a calcular a sua posição. Para que tal seja possível, os satélites enviam um sinal contendo um código numérico pseudo-aleatório (pseudorandom number code PNC [13]), este código é posteriormente comparado com o PNC do receptor, permitindo calcular o tempo de propagação do sinal. Multiplicando este valor pela velocidade da luz a velocidade à qual o sinal se propaga, obtém-se a distância do satélite ao receptor. Para que o sistema funcione de forma precisa, é necessária sincronização absoluta do relógio do satélite, utilizando-se portanto relógios atómicos de elevada precisão. O GPS, apesar de obter uma precisão muito boa no exterior, não é indicado para utilização em espaços interiores. O sinal de GPS sofre de erros na propagação, causados pelas condições atmosféricas, reflexão e bloqueio por parte de obstáculos no terreno. Para colmatar estes problemas, desenvolveu-se o A-GPS (GPS Assistido) [22], que combina a localização por satélite com técnicas de localização por rede móvel. O cruzamento da informação de localização fornecida por ambas as técnicas permite um aumento de precisão e confere ao A-GPS a possibilidade de funcionar em espaços interiores [23]. Contudo, a desvantagens relativamente a estas tecnologias reside no facto de não se encontrarem disponíveis em grande parte dos terminais móveis, não sendo portanto abrangentes. 12

23 2.1.3 Técnicas de Localização por Rede de Operador As técnicas apresentadas anteriormente são utilizadas maioritariamente para um tipo de ambiente interior ou exterior. Hoje em dia, os operadores de rede móvel têm uma grande extensão de território continental coberto, sendo possível a rede para localizar um terminal móvel. Ao contrario das restantes técnicas, a localização por rede de operador tem a vantagem de funcionar tanto em espaços fechados interiores como em espaços abertos exteriores. As redes móveis ou redes celulares - são compostas por células, que podem ser vistas como delimitando áreas geográficas. O seu tamanho depende da área geográfica coberta e das necessidades de serviço para essa área [13], e a sua forma depende das condições de propagação do sinal (e.g. obstáculos sólidos, atmosfera, entre outros). A cada célula está associada uma estação base (base station), responsável por servir os terminais móveis que estiverem dentro do seu alcance, com a capacidade de os detectar quando entram na sua área Identificação por Célula (Cell Identification) A forma mais simples de identificar a posição de um terminal móvel é determinando a que célula este se encontra ligado. Esta técnica é também conhecida como Cell ID. Dado que a posição das células é fixa, a posição de um terminal a pode ser aproximada da posição da célula à qual se encontra ligado. Apesar da implementação simples, sofre no entanto de baixa precisão. Na prática, uma célula pode ter um alcance de 20 Km [24], sobretudo em zonas rurais, um valor de erro inaceitável na maioria das situações em que se pretende fornecer um LBS. Em zonas onde existe uma maior densidade de células, a precisão pode rondar os 200m, constituindo uma opção razoável Identificação por Célula Melhorada (Enhanced Cell Identification) É possível aperfeiçoar a localização por célula adicionando mecanismos que permitam aumentar a precisão de localização. Uma forma de o alcançar em redes GSM (Global System for Mobile Communications) é a utilização da variável de ajuste de envio de pacotes pela rede o Timing Advance (TA). A rede GSM utiliza divisão de frequência em intervalos de tempo (time slots) para permitir que vários utilizadores partilhem a mesma frequência. Como tal, é necessário que o utilizador envie um pacote de dados para a rede com algum avanço para garantir que este chegue a tempo de preencher o time slot respectivo - a variável Timing Advance. O seu valor é calculado a múltiplos de 500 a 550 metros de distância da estação base da célula onde o terminal se encontra [13], podendo ser usado para determinar uma posição mais precisa para o terminal desde que este esteja a mais de 550 metros de distância da estação base e o tamanho da célula seja suficientemente grande. Outra forma de determinar a distância de um terminal a uma estação é a utilização da medida de força do sinal, o que é possível em teoria sabendo à partida as características do sinal. Contudo, essa medida depende de outras variáveis que a influenciam, como a forma do terreno, obstáculos e a própria atmosfera. 13

24 Um aperfeiçoamento possível à técnica de Cell ID+TA é a utilização da medida de tempo de propagação do sinal entre o terminal e a estação base, reflectido de volta para o terminal Round Trip Time (RTT) [25]. Esta medição permite determinar uma circunferência contendo todos os pontos possíveis no espaço onde o terminal pode estar localizado. Cruzando com medições de outras duas estações base, é possível obter a intersecção de três circunferências resultando numa área de probabilidade. São necessárias pelo menos três estações base para determinar a posição de um terminal com alguma precisão. Este último método é tanto mais útil quanto mais precisas forem as medições de RTT, isto é, quanto menor for a latência entre a chegada do sinal à estação e a sua reflexão de volta para o terminal. É também viável sobretudo em zonas de grande densidade de células, onde é possível que o terminal esteja em contacto com diversas estações base em simultâneo. Em conjunto, estas técnicas proporcionam uma melhoria significativa à precisão possível de alcançar com o Cell ID, desde que sejam reunidas as condições necessárias para a sua aplicação TOA (Time of Arrival) e U-TDOA (Uplink-Time Difference of Arrival) A determinação do tempo de chegada de um sinal vindo de um terminal para uma estação base pode ser usada para calcular a posição relativa do mesmo [26] - a técnica Time of Arrival (TOA). Esta funciona medindo o tempo de propagação do sinal entre o terminal e uma estação base, permitindo a determinação da sua posição partindo da velocidade de propagação do sinal. Os tempos absolutos de partida e chegada do sinal são medidos em ambas as extremidades, pelo que é necessária sincronização absoluta entre o terminal e a estação receptora. A técnica Time Difference of Arrival (TDOA) [25], funciona segundo os mesmos princípios. Dispondo de duas estações base, e partindo da diferença entre o tempo de chegada do sinal de um terminal a cada uma delas, é possível traçar uma curva hiperbólica entre as estações base com a potencial posição do terminal. Com outra medição entre duas estações base, podem intersectar-se as duas linhas hiperbólicas, obtendo-se uma posição possível para o terminal. Estas técnicas são bastante precisas, mas dependem da sincronização entre os terminais e as estações base. Dado requererem mais do que uma estação base para o cálculo da localização do terminal, funcionam melhor em locais de elevada densidade de células AOA (Angle of Arrival) Esta técnica consiste na determinação do ângulo de chegada (Angle of Arrival AOA) do sinal proveniente de um terminal móvel ao chegar à estação base [13]. Com a informação do ângulo, é possível traçar uma recta na direcção de onde o sinal provém. Uma segunda medição por parte de outra estação base vai permitir o cálculo de intersecção entre as duas rectas geradas, resultando num ponto provável para a localização do terminal. Comparativamente às restantes técnicas, esta requer que as antenas sejam capazes de detectar o ângulo de recepção do sinal, necessitando de hardware especial. 14

25 E-OTD (Enhanced Observed Time Difference) De forma semelhante à técnica TOA (Time of Arrival), esta funciona por observação do tempo de propagação do sinal entre uma estação base e o terminal móvel. A diferença relevante reside no facto de ser o terminal móvel a calcular a sua posição, necessitando portanto de software para o efeito [13]. Esta particularidade torna-a pouco usada, face ao TOA Comparação de Soluções Com base nas soluções apresentadas nesta secção, elaborou-se uma tabela comparativa das mesmas. Tabela Comparação de soluções para localização IR Ultra-sons WiFi GPS A-GPS Rede Móvel Espaços Interiores X X X X X Espaços Exteriores X X X X Disponibilidade em terminais móveis X Sem necessidade de instalação de novas infraestruturas X X X Precisão X X X X Das soluções apresentadas a rede móvel de operador é aquela que cumpre um maior número de factores críticos de sucesso, pela sua acessibilidade através de uma infra-estrutura já existente e pela compatibilidade com todos os telemóveis no mercado. 2.2 Soluções para envio de Conteúdo Multimédia de forma Push Um componente essencial de um serviço LBS é a forma como o conteúdo é providenciado ao utilizador. O âmbito deste trabalho é o fornecimento de serviços do tipo push, sendo portanto necessário analisar as soluções disponíveis para o efeito Aplicação e Protocolo Proprietários Uma forma de transferir conteúdos multimédia de forma push é a existência de uma aplicação proprietária instalada no terminal móvel que consiga manter uma ligação de dados permanente com a plataforma provedora de serviços. Esta solução garante uniformidade entre o conteúdo que é fornecido e a forma como este é apresentado ao consumidor no dispositivo móvel. 15

26 Contudo, esta forma de push, por si só, não constitui uma solução óptima para o problema em questão. A utilização de uma aplicação pressupõe a sua instalação no dispositivo móvel, traduzindo-se num esforço adicional no desenvolvimento para múltiplos modelos de diferentes plataformas. Esta desvantagem é reduzida pela utilização de frameworks como o J2ME Polish ou o PhoneGap, que facilitam a portabilidade para telemóveis com características diferentes ao nível de hardware e software. A ligação com o servidor de conteúdos neste tipo de solução terá de ser mantida pela própria aplicação, não constituindo uma verdadeira solução push. É necessário o envio de pacotes de rede com o intuito de manter activa a ligação entre cliente e servidor, contribuindo negativamente para o consumo energético do telemóvel e de tempo de CPU (Central Processing Unit) do mesmo [27] MMS (Multimedia Messaging System) O MMS estende a especificação SMS em termos de serviços de envio e recepção de mensagens móveis, removendo a limitação de 160 caracteres deste último e adicionando a capacidade de envio de conteúdo multimédia nas mensagens [28]. De forma semelhante ao SMS, é adequado ao envio de conteúdo de forma push, cumprindo o critério de acessibilidade, por ser implementado ao nível do operador móvel e estar disponível em praticamente todos os telemóveis actuais. Existem algumas desvantagens inerentes a esta tecnologia quando utilizada para distribuição conteúdos. Em primeiro lugar, requer que o telemóvel receptor esteja correctamente configurado para a recepção de MMS, o que nem sempre se verifica. Em segundo lugar, o operador pode fazer o envio de MMS usando o método Unicast para múltiplos receptores, sendo portanto pouco adequado para envio de conteúdo de grandes dimensões para um elevado número de subscritores WAP-Push O protocolo WAP (Wireless Applictation Protocol) foi criado em 1997 com o objectivo de unificar as tecnologias de transmissão de dados via wireless. Hoje em dia, é conhecido pela tentativa de trazer a web aos terminais móveis. Uma tecnologia adicionada a este protocolo, na sua versão 1.2, foi a capacidade de fazer push de URLs (Uniform Resource Locator) para terminais móveis o WAP-Push [29]. Na Figura 2-2 está representado o modo como é feito o envio de WAP-Push para o terminal móvel. O servidor de conteúdos envia o URL para o operador móvel, através do protocolo Push Access Protocol (PAP). Este, por sua vez, redirecciona-lo para o telemóvel de destino a partir do Push Proxy Gateway (PPG), normalmente via SMS. À recepção, o conteúdo é obtido através do URL e mostrado no browser WAP do terminal. 16

27 Figura Envio de Mensagem WAP-Push para um terminal móvel [29] Esta solução constitui uma forma para envio de conteúdos push-to-pull, dada a necessidade de descarregar posteriormente o conteúdo a partir do URL fornecido. Uma solução baseada em WAP-Push garante a compatibilidade com a maioria dos telemóveis existentes no mercado. Destaca-se o caso particular dos smartphones, possuindo um leitor multimédia capaz de reproduzir streams de vídeo via RTSP (Real-Time Streaming Protocol) [30] [31], cujo URL poderá facilmente ser fornecido através de WAP-Push. Constitui, desta forma, uma solução viável e simples para o streaming de vídeo e áudio MBMS (Multimedia Broadcast-Multicast Service) O MBMS (Multimedia Broadcast-Multicast Service) [27] [32] é um protocolo que permite a transmissão de conteúdo multimédia em difusão para vários terminais móveis utilizando a infraestrutura de rede de terceira geração, Apresentando-se como tecnologia nativa de difusão em redes UMTS. Este protocolo suporta dois modos de operação download e streaming. Estes dois modos são suportados sobre a mesma infra-estrutura, sendo o modo streaming usado para transmissão contínua de vídeo e imagem (e.g. Mobile TV) e o modo download para transferência de ficheiros de tamanho e tipo arbitrários [33]. Uma vantagem do MBMS é o facto de ser desenhado para a utilização em serviços do tipo push, permitindo activar remotamente o terminal móvel quando existe uma transmissão de dados disponível [27]. Permite assim a poupança de energia no dispositivo móvel, evitando a manutenção de uma ligação de dados permanente com polling. Por outro lado, o MBMS não se encontrando implementado nos terminais móveis comerciados actualmente implica a implementação do lado de uma aplicação cliente que permita utilizá-lo. Para o modo download, tem de ser suportado o protocolo FLUTE [34], o qual não é implementado na maioria dos terminais. Para streaming, o terminal móvel tem de possuir um leitor multimédia capaz de reproduzir streams utilizando descodificadores de vídeo H.264 e áudio MPEG-4/AAC, via RTSP, qual é possível em smartphones Comparação de Soluções Com base na análise de cada uma das tecnologias apresentadas para distribuição push de conteúdo multimédia, resumem-se as suas características na Tabela

28 Tabela Comparação de soluções para envio de conteúdo multimédia de forma push Protocolo SMS MMS WAP-Push MBMS Proprietário Independência de software específico X 1 X X Suporte a conteúdos multimédia ricos X X 2 X X Solução push nativa X X X X Compatibilidade com vários modelos X X X de terminais Suporte a conteúdos ricos no futuro X X X Baixo consumo energético do terminal X X X X Escalabilidade X X Existem duas tecnologias oferecendo o mesmo número de vantagens máximo WAP- Push e MBMS. A vantagem do WAP-Push é a ausência de necessidade de uma aplicação para entregar o conteúdo no terminal móvel. Esta vantagem é contrabalançada por se tratar de uma tecnologia push-to-pull, sem garantia de escalabilidade na difusão. Por outro o MBMS foi desenhado especificamente para a escalabilidade em difusão, necessitando contudo de uma aplicação de controlo. Comparando as suas tecnologias, o ideal seria uma solução híbrida utilizando as duas tecnologias. O MMS, possuindo o mesmo número de vantagens em tabela, não permite a transmissão de conteúdo de grandes dimensões. Esta desvantagem faz com que seja desfavorável face às duas concorrentes, não impedindo contudo a sua utilização, dado que grande parte do conteúdo usado em publicidade móvel pode ser adaptada a este meio de comunicação. 2.3 Soluções Abrangentes Para além das tecnologias apresentadas anteriormente, existem soluções que consideram ambas as partes localização e push de conteúdos. Nesta secção serão apresentadas as técnicas denominadas de abrangentes, pelo seu carácter dual Bluetooth O Bluetooth apresenta-se como uma tecnologia de transmissão de dados sem fios, via radiofrequência, de curto alcance cerca de 10 (dez) metros [11]. As principais vantagens desta tecnologia são a sua inclusão na maior parte dos telemóveis recentes e a capacidade de transmissão de qualquer tipo de ficheiro sem necessidade de uma aplicação específica. 1 Na utilização de SMS como uma tecnologia push-to-pull, é necessária uma aplicação para ler o conteúdo da mensagem e descarregar o conteúdo a ela associado. 2 Os conteúdos multimédia enviados por MMS são normalmente reduzidos para que a transferência seja mais rápida ou para que sejam compatíveis com um elevado número de dispositivos móveis. Isto limita a gama de conteúdos ricos que podem ser transmitidos por MMS. 18

29 Pode ser igualmente usado para localizar um dispositivo móvel, de forma idêntica à técnica de localização via W-LAN. Adequa-se sobretudo a espaços interiores, podendo ser usada em exteriores mediante a utilização de access points com antenas de alcance superior. A transmissão de dados via Bluetooth é iniciada por emparelhamento entre os dispositivos receptor e emissor. Esta operação que frequentemente de intervenção manual, podendo ser no entanto feita automaticamente. Os problemas com a utilização da tecnologia Bluetooth surgem sobretudo com o modo como esta é vista pelos utilizadores. A recepção de conteúdo pressupõe que o dispositivo móvel mantenha o Bluetooth activo e visível, o que é frequentemente tido como uma ameaça de segurança e privacidade para os utilizadores. É igualmente comum associar esta funcionalidade a um consumo acrescido de energia, pelo que os utilizadores têm preferência por não a activarem. Outro problema com a utilização do Bluetooth é a necessidade de uma infra-estrutura no local. Será necessária a instalação dos pontos de acesso (AP Access Points) Bluetooth nos locais onde o serviço é consumido. Para efectuar a comunicação entre os pontos de acesso e o servidor de conteúdos, um modem terá de ser associado a cada AP para comunicar com o provedor de serviços, para que este os possa enviar. Na Figura 2-3 encontra-se representada a arquitectura típica de um sistema LBS usando Bluetooth. Figura Infra-estrutura típica para um LBS utilizando pontos de acesso Bluetooth Parlay X O Parlay X [35] é uma norma criada pelo Parlay Group e que consiste num conjunto de APIs (Application Programming Interfaces) baseada em web-services para aceder a funcionalidades de alto nível de uma rede de operador móvel, tornando rápido o desenvolvimento de aplicações que utilizem estas funcionalidades. O Parlay X encontra-se neste momento na versão 3.0. Uma listagem dos serviços providenciados por esta versão encontra-se na Tabela 2-6. Com estas APIs, a utilização do Parlay X permite a implementação dos requisitos de um serviço LBS, destacando-se portanto como uma solução abrangente. Para além de resolver os problemas relacionados com a localização e com o push de conteúdo multimédia, o Parlay X permite também acesso a outros serviços que possibilitam a 19

30 determinação de contexto de um utilizador, útil para o fornecimento do serviço LBS como é o caso do estado do terminal. Tabela APIs ParlayX 3.0 API Descrição Common Definições comuns às várias APIs do Parlay X. Third Party Call Estabelecimento e gestão de uma chamada entre vários dispositivos móveis feita através de uma aplicação intermediária. Call Notification Gestão e Recepção de notificações de chamadas estabelecidas por um subscritor da rede móvel. Short Messaging Recepção e envio de SMS, com ou sem notificações de entrega. Multimedia Messaging Recepção e envio de MMS. Payment Reservas de pagamento e pagamentos pré e pós-pagos Account Management Definições de conta e carregamento de saldo de contas. Terminal Status Obtenção de estado de um terminal móvel (e.g. acessibilidade). Terminal Location Informação de localização de um terminal móvel na rede. Call Handling Especificação de como as chamadas serão processadas para um número específico. Audio Call Gestão de conteúdos multimédia a serem reproduzidos durante uma chamada entre os vários participantes. Multimedia Conference Criação de uma conferência multimédia e gestão de participantes e conteúdos envolvidos na mesma. Address List Gestão de grupos de subscritores. Management Presence Registo e obtenção de informação de presença para utilizadores registados. Message Broadcast Envio de mensagens para terminais fixos ou móveis numa determinada zona geográfica. Geocoding Obtenção de informação de residência/localização de um subscritor. Application driven QoS Alteração dinâmica da qualidade de serviço para uma conexão estabelecida para um utilizador da rede. Device Capabilities and Configuration Obtenção de informação acerca da capacidade e configurações de um terminal móvel e envio de configurações para o mesmo. Multimedia Streaming Controlo de streams multimédia para um subscritor. Control Multimedia Multicast Session Management Controlo de uma sessão de multicast de conteúdo multimédia para um conjunto de subscritores Terminal Status Esta API permite a obtenção do estado de um terminal móvel, ou seja, de está disponível ou indisponível. Esta informação é útil para utilização como contexto de fornecimento de um serviço, permitindo o envio de conteúdo para um terminal indisponível Terminal Location Este web-service permite a obtenção da localização de um terminal móvel dentro da rede. Sempre que possível, é usada a melhor técnica de localização de rede móvel de operador, sendo empregue a localização por identificador de célula caso não exista outra alternativa. 20

31 Presence O web-service Presence permite obter informação detalhada do estado de um utilizador de entre um conjunto de estados possíveis definidos na especificação. Esta informação pode ser processada de modo a fornecer um serviço altamente personalizado ao utilizador. Contudo, a informação de presença tem de ser publicada pelo utilizador, limitando a utilização desta API Message Broadcast Este serviço é útil na especificação de LBSs, na medida em que permite o envio de mensagens para números fixos e móveis numa determinada zona geográfica. A utilização desta API directamente apenas permite o envio de mensagens SMS em difusão de forma incondicional, isto é, para todos os MSISDNs que se encontrem na área seleccionada, sem qualquer critério de preferência. No entanto, é uma solução útil no envio de mensagens cujo alvo seja uma população, como um aviso de emergência Application Driven QoS No fornecimento de serviços com conteúdos multimédia é necessário ter em consideração não só a capacidade que o dispositivo móvel tem de os processar como também a capacidade da rede para que o envio possa ser feito em tempo útil com uma qualidade desejável. Nesse sentido, definem-se métricas de qualidade de serviço (QoS Quality of Service) para garantir que o utilizador recebe o tipo de conteúdo adaptado à largura de banda disponível, realizandoo a partir desta API do Parlay X Device Capabilities and Configuration Esta API permite a obtenção de informação relativa às características e capacidades de um terminal móvel, sendo útil no fornecimento de serviços que exijam algum tipo de equipamento dedicado. Caso o terminal móvel não cumpra as necessidades do serviço, este pode responder de forma apropriada, ou adaptar o seu conteúdo Multimedia Streaming Control e Multimedia Multicast Session Management Estas duas APIs funcionam em conjunto. A primeira permite o controlo de streams de conteúdo multimédia. A segunda, facilita a criação de sessões de Broadcast e Multicast (difusão) de conteúdo multimédia, utilizando MBMS OneAPI De modo semelhante ao Parlay X, a OneAPI [36], criada pelo grupo GSMA [37], apresenta um conjunto de APIs para acesso às funcionalidades providenciadas pelos operadores móveis, através de uma interface web-services. A OneAPI destaca-se pelo aproveitamento das interfaces web definidas pelo grupo moderador do Parlay X e pela sua implementação em operadores reais, como a Vodafone-Spain e a Orange. 21

32 Contudo, esta API é ainda um trabalho em desenvolvimento, não implementando todo o espectro de operações especificadas pelo Parlay X. Define apenas APIs de envio de SMS, envio de MMS, Localização e Pagamentos, as quais estão a ser expandidas pelo grupo moderador. Deste modo, esperam-se novos desenvolvimentos no futuro Comparação de Soluções Na Tabela 2-7 comparam-se as diversas soluções abrangentes para localização e transferência de conteúdo multimédia estudadas nesta secção. Tabela Comparação de soluções abrangentes (localização e envio de dados) Bluetooth Parlay X OneAPI Independência de software específico X X X Suporte a conteúdos multimédia ricos X X X Controlo do utilizador na recepção de conteúdo X Ausência de intervenção do utilizador para configuração X X Baixo consumo energético do terminal X X Maturidade da especificação X X Maturidade comercial X Infra-estrutura de rede móvel já existente X X A OneAPI, apesar de não implementar todas as operações especificadas no Parlay X, apresenta-se como uma tecnologia alternativa e viável na implementação da solução proposta. Contudo, opta-se pela utilização da especificação do Parlay X em detrimento da OneAPI, devido à maturidade da primeira. Deve também acrescentar-se que uma solução implementada utilizando Parlay X é facilmente portável para OneAPI, dadas as semelhanças entre elas. O Bluetooth, apesar de ser uma solução com implementações reais e comercialmente mais madura, não é uma alternativa viável face às duas anteriores. Esta exige que a funcionalidade de comunicação via Bluetooth esteja activa no terminal móvel do utilizador antes do fornecimento do serviço, o que conduz a um aumento do consumo energético do terminal e a um esforço adicional por parte do utilizador na sua activação. Também não beneficia da existência à partida de uma infra-estrutura como meio de comunicação e localização, necessitando de uma instalação de access-points e modems no local, limitando a sua cobertura e versatilidade. 2.4 IMS (IP Multimedia Subsystem) e Parlay X O IMS IP Multimedia Subsystem apresenta-se como uma arquitectura funcional [38] de suporte à transmissão de conteúdos multimédia sobre o protocolo IP (Internet Protocol). O seu objectivo principal é a integração vários tipos de rede wired e wireless, introduzindo 22

33 mecanismos unificados de controlo de sessão e QoS de forma a possibilitar uma plataforma para criação e lançamento de serviços utilizando conteúdo multimédia. O IMS não é uma solução em si para o fornecimento de serviços multimédia, mas sim um conjunto orquestrado de protocolos e entidades que, em conjunto, permitem o acesso de terminais móveis a serviços multimédia variados, o controlo por parte dos operadores da qualidade de serviço (QoS Quality of Service) e taxação apropriada dos serviços e conteúdos neles integrados. Figura Diagrama de camadas da arquitectura IMS (IP Multimedia Subsystem) [39] No canto superior direito da Figura 2-4, na camada de serviços do IMS, encontra-se um possível posicionamento do Parlay X. O Parlay X integra-se com o IMS como um ponto de entrada para os mecanismos de comunicação e controlo disponibilizados por esta arquitectura. Apresenta-se portanto como um facilitador no acesso aos serviços da arquitectura IMS, não competindo directamente com esta. 2.5 Soluções Comerciais e Académicas Existem algumas soluções desenvolvidas para a disponibilização de serviços LBS do tipo push. No âmbito do desenvolvimento de uma solução, é importante ter conhecimento de quais as tecnologias utilizadas por estas outras soluções e qual o público-alvo a que se destinam. Ao nível académico, Lauri Aalto et al apresenta um sistema de publicidade móvel baseado em localização B-MAD [9] utilizando a tecnologia Bluetooth como sistema de localização e WAP-Push para a entrega de conteúdos ao utilizador. Esta solução não cumpre todos os factores críticos apontados, tanto na escalabilidade (a utilização exclusiva de WAP-Push 23

34 Unicast 3 como forma de entrega de conteúdo não constitui uma solução totalmente escalável) como na acessibilidade, pela limitação imposta aos terminais móveis suportados. Afonso Vaz apresenta igualmente um sistema de prestação de serviços LBS do tipo push, via SMS [10], utilizando a tecnologia Parlay X. Apesar de abrangente, pela compatibilidade com virtualmente todos os terminais móveis no mercado, e da elevada acessibilidade pela utilização da rede de operador como forma de localização, está limitada ao fornecimento de serviços sem conteúdo multimédia, pela utilização de SMS como meio de transmissão de dados. Não considera também o critério de escalabilidade, tanto no desenho da solução como pela utilização exclusiva de SMS Unicast como forma de efectuar difusão de conteúdo. Ao nível comercial, são facilmente encontradas soluções baseadas em Bluetooth, como as disponibilizadas pela companhia BluAir [7]. Estas apresentam as mesmas desvantagens associadas à solução de Lauri Aalto, sendo pouco flexíveis no tipo de serviços prestados. 2.6 Conclusões As tecnologias apresentadas neste capítulo constituem soluções possíveis para os problemas da determinação da localização de um terminal móvel e envio de conteúdo multimédia de forma push. Pela análise das tecnologias apresentadas, conclui-se que a utilização dos serviços disponibilizados pelo Parlay X 3.0 é a opção mais viável na construção do sistema em causa. Não só se trata de uma solução abrangente, resolvendo os problemas da localização e da transferência de conteúdos de forma push, como também providencia outras formas de determinação do contexto de utilização de um serviço. Assim, a implementação será baseada no trabalho desenvolvido em [10], adaptando a arquitectura às necessidades da solução que se pretende desenvolver de modo a cumprir os factores críticos enunciados. Não deve ser, contudo, ignorada a utilização da OneAPI como substituto a curto prazo da implementação providenciada pelo Parlay X. Existe especial interesse em produzir uma solução suficientemente flexível que permita a sua integração no futuro com esta tecnologia, entre outras que possam surgir no futuro. 3 Unicast consiste num tipo de comunicação ponto-multiponto feito através de múltiplas conexões ponto-a-ponto [63]. 24

35 3 Arquitectura Com base nas tecnologias estudadas no capítulo anterior, é apresentada a arquitectura para o sistema que se propôs desenvolver, fazendo-se primariamente uma listagem dos requisitos de sistema, funcionais e não-funcionais, seguindo-se os casos de uso do mesmo e, finalmente, uma descrição de quais os componentes que constituem a arquitectura. 3.1 Requisitos do Sistema Os requisitos de sistema permitem definir os aspectos funcionais e não-funcionais de uma solução que cumpra os objectivos enunciados. Dada a sua natureza hierárquica, o requisitobase que descreve, de forma abstracta, todo o sistema é: Tabela Requisito-base do sistema ID Descrição R.0 O sistema deve permitir, de forma eficiente e eficaz, o fornecimento de serviços do tipo push baseados em localização com conteúdo multimédia a utilizadores nele registados e cujas preferências sejam adequadas. Partindo deste requisito, o qual não é funcional ou não-funcional, é possível especializar e definir os requisitos não-funcionais e funcionais (Tabela 3-2 e Tabela 3-3, respectivamente). Tabela Requisitos não-funcionais do sistema ID RNF.1 RNF.2 RNF.3 RNF.3.1 RNF.3.2 RNF.4 RNF.5 Descrição A detecção periódica de utilizadores em áreas geográficas deve ser efectuada em períodos menores que 10 segundos desde a entrada do utilizador na mesma. A entrega do conteúdo ao meio de comunicação deve ser feita num espaço de tempo menor que 10 segundos desde a recepção da notificação geográfica. O conteúdo deverá ser entregue utilizando SMS, para conteúdo somente textual, MMS, para apresentações multimédia com sons e imagens simples, ou WAP-Push para streams de vídeo e áudio, com integração futura com MBMS. Deverá ser possível adicionar novos meios de comunicação à arquitectura desenhada de forma modular. Para cada meio de comunicação, deverá ser possível a utilização de outras APIs, mantendo as actuais em funcionamento. A solução deverá ser preferencialmente independente do sistema de gestão de bases de dados utilizado, ou possibilitar a mudança do mesmo de forma fácil. A solução deverá manter a qualidade de serviço em RNF.1 e RNF.2 para um mínimo de utilizadores e 100 serviços numa primeira fase. 25

36 Tabela Requisitos funcionais do sistema ID Descrição RF.1 Detectar a entrada de utilizadores em áreas geográficas. RF.2 Persistir os dados relevantes para o seu funcionamento. RF.2.1 Persistir a informação dos utilizadores. RF.2.2 Persistir a informação dos serviços. RF.2.3 Persistir a informação dos conteúdos. RF.3 Permitir a criação de utilizadores e alteração dos seus dados. RF.3.1 Permitir a associação de um nome, nome de utilizador único, palavra-passe e e- mail único a um utilizador. RF.3.2 Permitir a definição de um conjunto de preferências para cada utilizador. RF.3.3 Permitir a utilizadores a adesão a serviços. RF.3.4 Permitir o bloqueio de serviços a utilizadores. RF.3.5 Permitir a associação de terminais móveis a utilizadores. RF.3.6 Permitir a um utilizador receber apenas serviços aos quais aderiu. RF.4 Permitir a definição de áreas geográficas, com um nome, descrição e identificação espacial que as permita identificar univocamente. RF.5 Permitir a criação de serviços. RF.5.1 Permitir a associação de um nome, descrição e informação acerca da entidade responsável a um serviço. RF.5.2 Permitir a associação de um serviço a um horário de funcionamento. RF.5.3 Possibilitar a associação de um serviço a múltiplas áreas geográficas. RF.5.4 Possibilitar a definição da lógica de funcionamento do serviço. RF.5.5 Possibilitar que um serviço seja fornecido apenas a utilizadores que a ele aderirem. RF.6 Permitir a indexação de conteúdos multimédia. RF.7 Enviar conteúdo multimédia para os utilizadores através de meios de comunicação apropriados a terminais móveis. RF.7.1 Enviar conteúdo textual. RF.7.2 Enviar conteúdo com imagem e texto estáticos. RF.7.3 Enviar streams de vídeo e som. 3.2 Casos de Uso Com base no levantamento de requisitos efectuado, apresentam-se os casos de uso relevantes, os quais representam interacções entre actores entidades humanas ou sistemas externos e o sistema que se propõe desenvolver. 26

37 Figura Casos de uso para o utilizador User Na Figura 3-1 estão representadas as interacções de utilizadores do sistema User com o mesmo. Os serviços baseados em localização residentes no sistema são fornecidos a este tipo de utilizador, ao qual é permitida a gestão do seu perfil e preferências e a pesquisa de quais os serviços disponíveis no sistema. 27

38 Figura Casos de uso para os utilizadores administrativos Destacam-se ainda três tipos de utilizadores Administrator, Service Provider e Content Provider. O primeiro é o administrador do sistema, permitindo controlar todos os dados que nele residem. Os Service Providers são entidades às quais é permitida a criação de serviços e sua publicação no sistema, com conteúdos fornecidos por eles próprios ou por utilizadores do tipo Content Provider. As possíveis interacções de cada um com o sistema estão representadas na Figura

39 Figura Casos de uso para o actor Parlay X Gateway Para além das interacções de actores humanos com o sistema, existe também uma interacção notável de um sistema externo com ele. A gateway Parlay X invoca o sistema com o propósito de notificar a entrada de utilizadores em áreas geográficas (Figura 3-3). Figura Casos de uso para o actor Núcleo Lógico Finalmente, o sistema também comunica com outras entidades externas. Na Figura 3-4 estão representados os casos de uso d o sistema Núcleo Lógico e dois outros sistemas externos a gateway Parlay X e um servidor de (SMTP Simple Mail Transfer Protocol). 29

40 A comunicação com a gateway Parlay X é essencial, permitindo o registo de utilizadores e áreas geográficas, para notificações de entrada, e a obtenção de informação contextual sobre os utilizadores do sistema localização e estado do terminal móvel. É também através da gateway que é enviado o conteúdo associados aos serviços, via SMS, MMS ou WAP-Push. O servidor de é utilizado para a comunicação com os utilizadores de forma formal. Exemplos práticos são o envio de s de confirmação de registo no sistema, recuperação de palavra-passe e outras comunicações importantes de carácter informativo. 3.3 Diagrama de Componentes A Figura 3-5 representa um diagrama de componentes da arquitectura proposta para o desenvolvimento da solução. Os componentes a sombreado não são implementados na solução apresentada. Figura Diagrama de componentes da arquitectura para a solução proposta Nesta secção serão apresentados cada um dos componentes do sistema, mencionando a sua importância para o cumprimento dos objectivos referidos no primeiro capítulo. 30

41 3.3.1 Operador Móvel A rede de operador móvel é transparente para o sistema a desenvolver. A solução escolhida, para realizar as operações de localização e envio de conteúdos para o terminal móvel, utiliza funções encapsuladas pelo componente Parlay X 3.0 Gateway, o qual terá de ser instalado no operador móvel. É apenas necessário assegurar a existência deste componente Componente de Billing De forma a possibilitar a existência de serviços com subscrição paga, torna-se importante a definição de um componente que permita gerir as transacções monetárias entre o sistema e os utilizadores o componente de Billing. Como principal função, este sistema deve manter um registo de transacções efectuadas entre as várias entidades e permitir a facturação dos serviços prestados. Como a facturação de serviços não está incluída no âmbito da solução a desenvolver, este sistema poderá ser integrado como trabalho futuro, de modo a expandir o modelo de negócio da solução para além da prestação de serviços gratuitos Interface Este componente intermedeia a comunicação entre o sistema que se propõe desenvolver e os meios necessários para efectuar a localização, transferência de dados e determinação do contexto de utilização para os serviços baseados em localização. Note-se, porém, que o objectivo da divisão deste módulo em subcomponentes independentes resulta da necessidade de construir uma solução flexível, tornando possível a substituição de um subcomponente por outra implementação sem modificar o comportamento da solução Localização Este subcomponente permite a localização de terminais móveis e gera eventos quando um terminal entra numa dada zona previamente registada. Para tal, utiliza as funcionalidades de Terminal Location do Parlay X, comunicando com o gateway através de web-services.um dos requisitos para a implementação de um LBS (Location Based Service) o Sistema de Localização fica assim coberto Transferência de Dados Este subcomponente permite o envio de conteúdos multimédia para um terminal móvel. Utiliza os serviços de envio de mensagens disponibilizados pelo Parlay X, encontrando-se planeada a utilização do serviço de streaming de conteúdo multimédia baseado em MBMS Multimedia Streaming Control e Multimedia Multicast Session Management. 31

42 Disponibiliza portanto funcionalidades de envio de SMS, MMS e WAP-Push, ou poderá estabelecer uma ligação de streaming de conteúdo multimédia, utilizando a implementação de controlo de sessões facultada pela versão 3.0 do Parlay X Contexto Este subcomponente permite a obtenção de informação relativa ao contexto de utilização de um serviço para um utilizador. Pode ser utilizado para verificar pré-requisitos para o fornecimento do serviço ou como critério de selecção dentro da própria lógica de serviço. Disponibiliza funcionalidades para verificar o estado de um terminal móvel através do serviço Terminal Status do Parlay X e informação de presença do utilizador. Ao surgirem novas necessidades de contexto para o fornecimento de novos serviços, são adicionadas a este subcomponente Apresentação Neste componente encontram-se os módulos que permitem a interacção de utilizadores com o sistema. Estes correspondem a portais web, estando disponíveis para qualquer utilizador do sistema através de um browser web. O Portal de Utilizador permite o registo de utilizadores no sistema, e a definição das suas preferências, assim como a subscrição ou adesão e bloqueio de serviços. É o portal onde se espera obter um maior fluxo de dados. Entidades que pretendam criar e registar serviços no sistema utilizam o Portal de Provedor de Serviços. Os serviços poderão ser definidos com zonas activas, horários nos qual devem ser fornecidos, preferências de utilizador a que se destinam podendo requerer ou não a subscrição explícita de utilizadores, conteúdo a distribuir e de que forma é distribuído. A definição de zonas activas para um dado serviço não pode ser definida neste portal, por razões de segurança, podendo contudo ser requisitado a um administrador. No Portal de Administração, o administrador de sistema pode registar e remover provedores de serviço, assim como criar zonas activas para utilização pelos serviços Lógica Esta subcomponente contém o cerne da lógica da solução, intermediando as funcionalidades da camada de apresentação com as da camada de persistência e utilizando o componente de Interface para o fornecimento dos serviços. Intervém em todo o funcionamento do sistema, desde que é notificada a entrada de um utilizador numa área registada até ao envio do conteúdo de um dos serviços que se lhe aplica. 32

43 Gestor de Interfaces Este subcomponente intermedeia a comunicação entre o componente de Interface e os restantes componentes e módulos do sistema. Para além de expor interfaces para o efeito, possui também um módulo que permite a gestão de eventos, o Gestor de Eventos Gestor de Eventos Este módulo tem como função aguardar o sinal de entrada de utilizadores em áreas geográficas previamente criadas no gateway Parlay X. Assim que recebe uma notificação, a informação do MSISDN (Mobile Subscriber Integrated Services Digital Network Number) o número de telemóvel do utilizador - e identificador (ID) de zona são enviados para o Gestor de Serviços, que tratará do processamento do evento. De modo a permitir a notificação de entrada de utilizadores em áreas geográficas, estas têm de ser registadas na gateway Parlay X, cada uma com uma lista de todos os utilizadores do sistema para os quais se pretende receber notificações. A gateway não permite acrescentar utilizadores a áreas geográficas já registadas, sendo necessário remove-las em primeiro lugar e voltar a registá-las novamente, num processo designado de sincronização entre utilizadores e áreas geográficas, sendo este da responsabilidade deste módulo. Este processo é feito periodicamente, dada a sua complexidade computacional para um número elevado de áreas geográficas e utilizadores Núcleo Lógico O tratamento do evento de entrada numa zona é feito neste módulo. O identificador de zona é usado para obter quais os serviços que lhe estão associados. Juntamente com o MSISDN do utilizador, é feito um cruzamento entre as suas preferências e os serviços que se lhe aplicam. A lógica do serviço é executada recolhendo os dados de contexto necessários do módulo Informação de Contexto do componente Interface. Finalmente, o serviço é fornecido ao utilizador obtendo-se o conteúdo e enviando-o através do módulo Envio de Conteúdos também do componente Interface. No acto de envio, o serviço é registado como fornecido a esse utilizador, para evitar ser enviado várias vezes, dando também hipótese a outros serviços de igual prioridade para serem fornecidos posteriormente. Serve portanto como forma de evitar spam para o utilizador Gestor de Perfis O módulo de gestão de perfis do núcleo lógico efectua o cruzamento entre as preferências dos utilizadores e as preferências-alvo de um serviço, executando o algoritmo responsável pela escolha de qual o serviço a ser fornecido a um utilizador para a área geográfica em questão Processador de Lógica de Serviço Com a possibilidade de programar a lógica de um serviço, isto é, a forma como será entregue o conteúdo e tratamento de informação de contexto associada ao utilizador-alvo, este módulo tem como função a execução do fluxo de lógica workflow do serviço. Recebe o 33

44 serviço a ser processado e, como resultado da execução do fluxo lógico, deverá entregar o conteúdo a ele associado aos utilizadores finais. Deverá possibilitar também a execução de processamento intermédio aos dados do utilizador e comunicação com sistemas externos Reporting Todas as operações relevantes efectuadas dentro do sistema registos de utilizadores, fornecimento de serviços, entre outras devem ser registadas no componente de Reporting. O seu objectivo é permitir a consulta de informação sobre a utilização do sistema, de modo a obter estatísticas e métricas do seu funcionamento. Dada a complexidade na construção de ferramentas de reporting, o seu desenho e concepção não faz parte do âmbito da solução proposta. Contudo, dado ter utilidade na perspectiva de negócio, inclui-se como um componente na arquitectura actual Gestor de Billing O subcomponente Gestor de Billing comunica directamente com o componente de Billing, o sistema externo responsável por facturar o fornecimento de serviços com subscrição paga. O tipo de cobrança de serviços deverá poder ser efectuado de duas formas: Débito directo aos utilizadores que recebem o serviço. Cobrança à entidade fornecedora de serviço com base em estatísticas de utilização ou valores tabelados. De modo a permitir a segunda opção, este subcomponente deverá interligar-se com o subcomponente de Reporting para obter os dados necessários para inferir custos com base em estatísticas de utilização. Tal como o componente de Billing, este não faz parte do âmbito da solução a desenvolver, servindo apenas para a expansão do modelo de negócio da solução Interface de Dados O subcomponente de gestão de dados é composto por três módulos que intermedeiam o acesso aos dados persistentes do sistema serviços e áreas, utilizadores e conteúdos. Encapsulam o acesso às bases de dados, ocultando o seu esquema e permitindo a sua modificação sem alteração ao funcionamento da solução. É esta a interface com a qual o componente de apresentação comunica directamente. Estes módulos permitem também a comunicação com múltiplas instâncias de componentes de persistência, ocultando pormenores de replicação e distribuição, o que auxilia na escalabilidade do sistema. Os conteúdos podem também residir do lado dos provedores de conteúdo, minimizando o espaço ocupado no sistema, sendo apenas necessário alterar esta interface para os obter remotamente. As interfaces exportadas pelos vários módulos encontram-se na Tabela

45 Tabela Interfaces exportadas pelos módulos de gestão de dados do componente Lógica Módulo Gestor de Serviços Gestor de Utilizadores Gestor de Conteúdos Interfaces exportadas Obter informação sobre serviços e áreas geográficas, dado o seu ID. Criar e remover serviços e áreas geográficas. Associar áreas geográficas a serviços, e pesquisar com base nessa associação. Criar, remover e alterar utilizadores e os seus dados. Obter dados de utilizadores (dados de conta, preferências, subscrições de serviços e bloqueio de serviços). Obter o histórico de serviços fornecidos ao utilizador. Inserir, remover e alterar localizações de conteúdos. Alterar dados de um conteúdo. Transferir um conteúdo Persistência Este componente permite o acesso aos dados necessários para o fornecimento dos serviços LBS. A persistência conta com a existência de três bases de dados (DB), as quais podem ser distribuídas de modo a aumentar a escalabilidade do sistema: Serviços e Áreas Geográficas: Definições de serviços e zonas geográficas, bem como a associação entre eles (muitos-para-muitos). Utilizadores e Preferências: Informação de registo de utilizadores, as suas preferências, serviços aderidos ou subscritos e bloqueados. É também mantido o histórico de serviços fornecidos, para que não o sejam novamente num determinado espaço de tempo. Conteúdos: Conteúdos para distribuição, identificados por um ID único, nome do conteúdo e nome do content provider que lhe está associado, para que possam ser facilmente referenciados pelo provedor Estrutura A estrutura do componente de persistência pode ser visto como um modelo de camadas (Figura 3-6). Cada um dos módulos deste componente implementa-o de forma independente. Web-Services Services Database Manager DAO Framework Figura Diagrama de Camadas de um módulo de acesso a dados 35

46 DAO (Data Access Object) O acesso aos dados persistentes na base de dados é feito através de DAOs (Data Access Objects). Estes objectos permitem efectuar as operações de obtenção, inserção, alteração, remoção e selecção de dados persistentes, através de mecanismos OO (Object Oriented) Framework A Framework consiste num conjunto de interfaces e classes facilitam a construção dos vários componentes do sistema. Este módulo contém a interface genérica a que todos os DAOs devem obedecer, ferramentas para manipulação de ficheiros remotos (Download e Upload), um módulo de gestão de ficheiros de configuração (ConfigurationManager) e tipos de dados úteis para o sistema (MSISDN, entre outros) Database Manager Este módulo agrega todos os DAOs existentes no servidor, permitindo o acesso centralizado a instancias dos mesmos. Faz igualmente a gestão centralizada das ligações à base de dados, sendo uma instância única, o núcleo de cada servidor de dados Services A camada de serviços contém a lógica do servidor. Para cada caso de uso possível, é desenvolvido um serviço, que obedece à interface definida no módulo Framework. Um serviço é responsável pela recepção dos parâmetros de entrada (inputs) para a operação a efectuar, executá-la através de um fluxo lógico de operações e transformar os outputs para vistas (views) convenientes para serem fornecidas a outros componentes do sistema ou exteriores. Apesar de manipularem directamente entidades internas ao sistema, são sempre devolvidas vistas dessas mesmas entidades, incorrendo numa penalização de desempenho pela transformação de objectos em representações semelhantes. Contudo, estas representações são muitas vezes de um tamanho reduzido e o desempenho perdido na sua criação é recuperado no tempo de transmissão pela rede Web-Services A camada de web-services exporta as operações da camada Services, para que possam ser invocadas remotamente. Deste modo, os web-services constituem apenas pontos de entrada para os serviços lógicos. Foram concebidos para utilizar SOAP (Simple Object Access Protocol) sobre HTTP (Hyper-Text Transfer Protocol) como meio de comunicação. Contudo, podem ser implementados novos utilizando REST (Representational State Transfer) ou qualquer outro meio de comunicação (e.g. RMI (Remote Method Invocation) ou RPC (Remote Procedure Call)) sem modificar a arquitectura existente, assegurando a flexibilidade à adopção de novos meios de comunicação mais eficientes e integração com outros sistemas. 36

47 3.4 Diagramas de Interacção O comportamento da solução ao nível funcional pode ser descrito através de vários diagramas de interacção, com o objectivo de demonstrar a comunicação entre os vários componentes. 1 Utilizador Entra em área geográfica Área Geográfica Detecta localização 2 3 Envia notificação Gateway Parlay X Gestor de Eventos Figura Entrada de utilizador em área geográfica e notificação A Figura 3-7 representa o processo de notificação de entrada de utilizadores em áreas geográficas. Ao entrar numa das áreas geográficas (1) registadas na gateway Parlay X, a posição do utilizador é detectada (2) e o seu MSISDN e identificador de área são enviados para o componente Gestor de Eventos da solução (3). Base de dados de Serviços 5 Retorna lista de serviços Pede serviços na área 4 Envia ID de área e MSISDN do utilizador 2 Pede preferências do utilizador 1 Retorna preferências Gestor de Eventos Gestor de Perfis 3 Base de dados de Utilizadores 6 Envia serviço escolhido Processador de Serviço Figura Tratamento da notificação de entrada em área e selecção de serviço A solução terá agora de processar a notificação de entrada do utilizador na área geográfica (Figura 3-8), de modo a fornecer um serviço ao utilizador. Após recepção da notificação, o Gestor de Eventos reencaminha o MSISDN do utilizador e o identificador (ID) de área geográfica ao Gestor de Perfis (1). Este, por sua vez, recolhe informação de perfil do utilizador (2 e 3) e a lista de serviços candidatos para serem fornecidos dentro da área 37

48 geográfica do utilizador (4 e 5). Após seleccionar o melhor serviço com base nas preferências do utilizador, esse é passado ao Processador de Serviço (6), que se encarregará de fazer o processamento da lógica de serviço e envio de conteúdo. Utilizador Envia conteúdos 4 1 Obtém conteúdos Envia conteúdos 3 Retorna conteúdos 2 Gateway Parlay X Processador de Serviço Base de Dados de Conteúdos Figura Entrega do serviço ao utilizador Na Figura 3-9 encontra-se a fase de fornecimento de serviço ao utilizador. O Processador de Serviço encarrega-se de processar a lógica do serviço e de obter os conteúdos (1 e 2) para entrega. Dependendo do meio de entrega escolhido, será invocada uma função (3) diferente na gateway Parlay X, que fará por sua vez a entrega do conteúdo (4). Base de dados de Serviços 2 Retorna lista de áreas Pede todas as áreas 1 5 Cria notificações de entrada 3 Pede todos os MSISDNs de utilizadores Retorna lista de MSISDNs Gateway Parlay X Gestor de Eventos 4 Base de dados de Utilizadores Figura Sincronização de notificações de entrada A gateway Parlay X notifica a entrada de utilizadores em áreas geográficas previamente registadas na mesma. O processo de registo de áreas geográficas sincronização é feito periodicamente pelo Gestor de Eventos (Figura 3-10). Em primeiro lugar, é feita uma consulta à base de dados de serviços de modo a retornar a lista de todas as áreas geográficas presentes no sistema (1 e 2). É igualmente feita uma consulta à base de dados de utilizadores com o intuito de obter uma lista de todos os MSISDNs (3 e 4). Com esta informação, são então registadas as áreas geográficas na gateway Parlay X, cada uma contendo a lista de MSISDNs de utilizadores para os quais devem ser enviadas notificações aquando da entrada nas mesmas. 38

49 1 Acede à página de utilizador Pede autenticação 2 4 Valida autenticação Retorna resultado da validação 5 Utilizador 3 Envia dados de autenticação Mostra página do utilizador 9 Servidor Aplicacional 7 Pede dados do utilizador Retorna dados do utilizador 8 Componente Lógica Figura Autenticação de utilizadores As interacções de qualquer um dos tipos de utilizadores com o sistema requerem sempre um primeiro passo de autenticação (Figura 3-11). Ao aceder aos portais através de um browser web (1), o servidor aplicacional pede os dados de autenticação ao utilizador (2) username e password os quais, após recepção (3), são enviados para a componente lógica da solução para validação (4). Se estes estiverem correctos (5), o servidor aplicacional pede então os dados relevantes do utilizador (6 e 7), os quais irá utilizar para compor a página de utilizador. Finalmente, a página é então mostrada no browser do utilizador (8). 3.5 Conclusões Neste capítulo foram apresentados os requisitos funcionais e não-funcionais para o desenvolvimento da solução, assim como os casos de uso, demonstrando as interacções entre os actores e o sistema. Com base nos requisitos definidos e nos casos de uso, propôs-se uma arquitectura para a solução. Esta foi desenhada para ser modular, flexível e de ser facilmente distribuição de modo a atingir um nível de escalabilidade elevado. Dividiu-se portanto em 4 (quatro) macro componentes distintos Interfaces, Apresentação, Lógica e Persistência. O componente de Interfaces tem como objectivo fazer a ligação com os sistemas externos, possuindo 3 (três) tipos de interfaces distintas Localização, Transferência de Dados e Contexto. Estas são desenhadas para invocar serviços na gateway Parlay X do lado do operador móvel, sendo no entanto passíveis de serem utilizadas outras implementações. Os portais onde os utilizadores podem interagir com o sistema estão presentes no componente Apresentação, servindo como ponto de entrada para a camada lógica do sistema e permitindo as interacções definidas nos casos de uso para cada um dos actores. A camada lógica do sistema existe sob a forma do componente Lógica. É este que é responsável pelo tratamento de eventos de entrada de utilizadores em áreas geográficas e o fornecimento de serviços, intermediando também o acesso dos portais aos dados. Os dados do sistema estão acessíveis através do componente Persistência. Este componente exporta interfaces para acesso aos repositórios de dados de utilizadores, serviços e áreas e conteúdos, existindo como um componente independente na arquitectura. Finalmente, são apresentadas também as interacções entre os vários componentes do sistema sob a forma de diagramas de interacção. Estes servem para demonstrar o modo como os vários componentes comunicam entre si, fornecendo também uma visão geral do funcionamento da solução. 39

50 4 Implementação Neste capítulo é descrita a implementação da solução, com vista ao cumprimento dos requisitos definidos no capítulo anterior e de acordo com os casos de uso estudados. Será dado ênfase aos pormenores de implementação dos vários componentes do sistema, detalhando as tecnologias utilizadas e decisões tomadas no desenvolvimento dos mesmos. Como em qualquer trabalho de engenharia, foi efectuado um planeamento do curso das actividades, o qual se encontra abreviado na Figura 4-1. Figura Planeamento da implementação 4.1 Componente de Persistência Os servidores de dados são implementações dos subcomponentes de persistência assinalados na arquitectura do sistema, responsáveis pela abstracção do acesso aos dados. Assim, são especificados três tipos de servidores: Servidor de Utilizadores Servidor de Conteúdos Servidor de Serviços Nesta secção será apresentada em detalhe a implementação de cada um destes servidores e a tecnologia utilizada para o efeito. 40

51 4.1.1 Tecnologia de Persistência Cada servidor de dados possui acesso, via Hibernate versão 3.0 [40], a uma base de dados para guardar os seus conteúdos. Apesar estar fora do âmbito do projecto a escolha de uma base de dados particular para o efeito, optou-se pela utilização de MySQL Community Server versão 5.1 [41] para o ambiente de desenvolvimento, pela facilidade de configuração. Dado existirem três esquemas de dados diferentes para cada um dos servidores utilizadores, serviços e conteúdo e pelo facto de entre eles haver algumas dependências de chaves, é necessário um mecanismo para manter a consistência dos dados quando são feitas modificações num esquema com dados partilhados por outro, de modo a evitar referências soltas. Como solução ao problema da consistência dos dados, é delegado a um processo automático as inserções e remoções que permitem manter a coerência de chaves entre os vários esquemas Servidor de Utilizadores A materialização da camada persistente para os dados de utilizadores é feita através de uma instância de um servidor de dados o Servidor de Utilizadores. Esta entidade é responsável pelas seguintes operações, ao nível de dados: Criação e remoção de utilizadores Autenticação de utilizadores Pesquisa e alteração de dados de utilizadores (preferências) Gestão de subscrições e bloqueio de serviços de utilizadores Gestão de categorias de preferências e roles Gestão de histórico de serviços Para além de exportar interfaces correspondentes a estas operações, o servidor de utilizadores possui ainda mecanismos automáticos daemons para fazer a limpeza de sessões de autenticação expiradas e do histórico de serviços. A periodicidade destas operações de manutenção pode ser especificada nas configurações do servidor de utilizadores Relação de Dados Os utilizadores são entidades persistentes possuindo um identificador único, informação de autenticação (username e password), contacto via correio electrónico ( ) e um ou mais roles. Adicionalmente, um utilizador pode ter preferências, caso em que é registada a sua data de nascimento, sexo e um conjunto de subcategorias de preferências temáticas. As categorias de preferências são ordenadas em árvore, com categorias (Category) a agrupar conjuntos de subcategorias (SubCategory) (Figura 4-2). São apenas permitidos dois 41

52 níveis na árvore. Caso se aplicasse um padrão Composite 4 [42] no desenho desta hierarquia, seria possível profundidade arbitrária na árvore, mas isso tornaria o modelo de dados significativamente mais complexo. Para cada utilizador é ainda mantido um histórico de serviços já fornecidos como forma de monitorizar a actividade do mesmo e de forma a impedir a entrega de dois serviços iguais em intervalos de tempo próximos. Cada entrada do histórico contém o identificador único de serviço, o identificador da área onde foi accionado e a data em que foi fornecido. São ainda mantidas duas listas serviços subscritos e serviços bloqueados. Os serviços subscritos (adesões) são aqueles que, independentemente das preferências do utilizador serão sempre preferidos para entrega, ao passo que os serviços bloqueados não são fornecidos sob nenhuma circunstância. O utilizador possui também uma flag que indica se apenas quer que sejam fornecidos serviços aos quais aderiu ou subscreveu. Para cada utilizador é também mantido um conjunto de MSISDNs, que correspondem aos números de telemóvel que o utilizador regista no sistema para fornecimento de serviços. -id -name Category 1 * SubCategory -id -name Figura Relação ente categorias e subcategorias temáticas Servidor de Serviços Este servidor é responsável pela persistência dos dados necessários para descrever os serviços. É também aqui que se encontram as definições das áreas geográficas onde estes se encontram activos. São implementadas as seguintes operações: Criação e remoção de serviços Calendarização de serviços Criação de Áreas Geográficas Associação de áreas geográficas a serviços Associação de preferências a serviços Áreas Geográficas Uma área geográfica é definida por um identificador único, nome, descrição e quatro valores de vírgula flutuante que definem uma posição geográfica latitude, longitude, altitude e raio. Foi escolhida a precisão de vírgula flutuante simples (float) ao invés de dupla (double), por ser a utilizada pelo Parlay X. Por razões de segurança, o raio máximo de uma área geográfica 4 O padrão de desenho Composite, em linguagens orientadas por objectos, permite a criação de uma hierarquia de objectos, de profundidade arbitrária, partindo apenas de uma única superclasse com duas implementações um nó (node) que agrega objectos do tipo folha (leaf) ou do seu próprio tipo. 42

53 é de 10km e apenas é permitido a utilizadores com perfil de administração criar e alterar áreas geográficas através da sua interface gráfica Serviços Os componentes centrais do sistema são os serviços. Tal como as áreas geográficas, são definidos por um identificador único, possuindo um nome e descrição para fácil identificação e pesquisa. Os atributos notáveis de um serviço são o seu estado, tipo preferencial para entrega de conteúdos, horário, preferências-alvo e workflow. Os estados possíveis de um serviço (Figura 4-3) determinam se este pode ou não ser considerado para fornecimento. Todos os serviços inicialmente criados iniciam no estado Pending (pendente). Após confirmação da legitimidade do serviço por parte de um administrador, novamente por questões de segurança, o serviço passa para o estado Active (activo), ficando disponível para ser fornecimento a utilizadores ou desactivado (Inactive). deactivate Pending confirm Active Inactive activate Figura Diagrama de estados de serviços O tipo preferencial de entrega define qual o meio de entrega que deve ser considerado em primeiro lugar em caso de ambiguidade no cenário de criação automática da lógica de serviço. Considerando-se um exemplo em que é necessário enviar uma imagem e o serviço tem como meio preferencial o correio electrónico ( ), será sempre enviado um ao utilizador ao invés de um MMS ou qualquer outro meio de entrega igualmente adequado. O horário de um serviço define quais os períodos em que um serviço deve ser fornecido, sob a forma de um intervalo fechado entre duas datas. Adicionalmente, é possível definir para cada intervalo de datas períodos durante o dia nos quais o serviço pode ser fornecido. Estes períodos diários são também intervalos fechados. Um serviço possui também um conjunto de preferências alvo, de um conjunto de indentificadores de subcategorias definidos no servidor de utilizadores. A adequação de um serviço a um utilizador é feita por comparação com as preferências do utilizador-alvo. Finalmente, o workflow de um serviço define qual a lógica a executar quando este serviço for seleccionado para fornecimento a um utilizador. Este atributo é especificado através de uma linguagem formal para o efeito LobsterScript Servidor de Conteúdos O servidor de conteúdos funciona como um directório para referenciar e procurar conteúdos multimédia de utilizadores do tipo Content Provider. Existe apenas uma entidade no modelo de dados deste servidor Conteúdo (Content). 43

54 São definidas as seguintes operações para este servidor: Criação e remoção de conteúdos. Procura de conteúdos por critérios (nome, Content Provider, descrição, entre outros). Os conteúdos são entidades com um identificador único, nome e descrição. Para além destes atributos, possuem um URL que indica a localização do conteúdo (local ou remotamente), o identificador do utilizador Content Provider ao qual o conteúdo pertence e o tipo de dados a que o mesmo se refere (MIME-type). 4.2 Gateway Parlay X O componente Gateway Parlay X reside do lado da rede do operador móvel, exportando interfaces de comunicação via web-services SOAP (Simple Object Access Protocol). De modo a contornar a indisponibilidade desta gateway, a Ericsson disponibiliza um SDK denominado Telecom WebServices SDK [43] para desenvolver e testar serviços que utilizem o Parlay X. Este SDK possui dois componentes distintos: Emulador simulando uma gateway Parlay X 2.1 e Componentes Java beans encapsulando chamadas a web-services Parlay X em classes Java de utilização simplificada. A versão utilizada do SDK é a Emulador Parlay X O SDK contém um componente que permite a simulação de uma gateway Parlay X Terminal WebServices Network Emulator. Este existe sob a forma de uma aplicação web, executada num servidor aplicacional Apache Tomcat versão 5 [44] ou Sun Glassfish versão 2.0 [45] ou superior (Figura 4-4). O emulador permite: Criar e remover terminais móveis virtuais. Enviar, receber e visualizar conteúdo de mensagens SMS, MMS e WAP-Push. Enviar notificações de localização através de um mapa interactivo. Visualizar o estado de pedidos feitos à gateway via web-services. Suporta também dois protocolos de operação: SIG4 proprietário da Ericsson - e Parlay X 2.1, tendo sido escolhido o último para manter a compatibilidade da solução com outras implementações de gateways Parlay X que possam ser utilizadas no futuro. 44

55 Figura Aplicação web do emulador Parlay X da Ericsson Componentes Java Os componentes Java encapsulam as chamadas aos web-services Parlay X em classes Java de fácil utilização. Permitem também abstrair os mecanismos de callback requeridos pelos serviços de notificação do Parlay X, que de outra forma seriam mais complexos de tratar. Todas as operações permitidas pelo emulador são encapsuladas em classes distintas. A solução utiliza os mecanismos de comunicação via SMS, MMS e WAP-Push, suportados através das classes SendSMS, SendMMS e SendWapPush, respectivamente. 4.3 Conectores De forma permitir a comunicação entre os componentes do sistema (Lógica, Persistência, Apresentação e Interfaces) e entre estes e entidades externas ao mesmo, foi desenvolvido um conjunto de bibliotecas de comunicação em Java os conectores (Connectors). Estas classes seguem a convenção de codificação ilustrada na Figura 4-5. ConnectorFactory +createinstance() : ConnectorClient «uses» «interface» ConnectorClient +operation_1() +operation_2() +operation_2() ConnectorImplOne ConnectorImplTwo +operation_1() +operation_2() +operation_3() +operation_1() +operation_2() +operation_3() Figura Estrutura de classes de um conector Os conectores para os servidores de dados e núcleo lógico transformam as interfaces de web-services SOAP destes componentes em classes Java, permitindo a sua utilização 45

56 directamente no código. São utilizados na componente lógica para comunicar com os servidores de dados e no componente de apresentação para comunicar com a lógica. Existem também conectores para comunicação com sistemas externos, implementando parte do componente Interface definido na arquitectura. Em particular, o conector de Parlay X, que encapsula as classes fornecidas no SDK da Ericsson [43], obedecendo à mesma estrutura definida (Figura 4-5). São definidos também conectores para envio de via SMTP (Simple Mail Transfer Protocol), comunicação com o sistema de envio de SMS da Movensis [46] SMS-SE -, e envio de SMS utilizando o protocolo SMPP (Short Message Peer-to-Peer). A utilização destes conectores promove a flexibilidade e modularidade do sistema, permitindo estendê-lo com novas interfaces de comunicação sempre que necessário. 4.4 Componente de Lógica No desenho da arquitectura, o componente de lógica é o ponto central do sistema, responsável por garantir a entrega dos serviços aos utilizadores, detectando a entrada dos mesmos em áreas geográficas e utilizando um conjunto de interfaces para obter informação contextual relevante e fazer o envio do conteúdo relativo aos serviços Gestor de Interfaces O Gestor de Interfaces é responsável por manter as ligações do núcleo lógico com o exterior. Este gestor contém um conjunto de classes singleton [42] em Java que gerem as entradas e saídas (I/O) do núcleo lógico, as quais são implementadas pela biblioteca de conectores. Existem três tipos de interfaces: Interface de Localização Interface de Comunicação Interface de Contexto Cada uma destas interfaces segue uma adaptação do padrão de desenho Strategy [42], possuindo uma classe para cada operação por elas suportada (Figura 4-6). Deste modo, é possível, utilizando a mesma interface, executar as operações de modo diferente ou recorrendo a outros sistemas externos, promovendo a modularidade e flexibilidade do sistema. «interface» OperationOne ConcreteOperationOne Interface operationone() +operationone() -operationoneinstance : OperationOne -operationtwoinstance : OperationTwo 1 +operationone() +operationtwo() «interface» OperationTwo +operationtwo() ConcreteOperationTwo +operationtwo() Figura Estrutura de classes de uma Interface 46

57 Gestor de Eventos O gestor de eventos é o componente responsável pela detecção da entrada de utilizadores em áreas geográficas e invocação do núcleo lógico para processamento do evento de entrada. Esta funcionalidade é implementada por uma thread cujo propósito é a recepção de notificações de entradas em áreas, provenientes da gateway Parlay X ou de qualquer outro meio que faça um pedido via web-service para o mesmo. É também esta que executa a sincronização periódica de áreas e utilizadores para criação de notificações do lado da gateway Parlay X. O mecanismo de sincronização encontra-se detalhado na secção Núcleo Lógico A funcionalidade do núcleo lógico é implementada por uma classe LogicManager -, existindo sob a forma de um bean EJB (Enterprise Java Beans) [47] que inicia com o arranque do servidor aplicacional. Na sua rotina de arranque, cria o gestor de interfaces, instanciando os vários conectores. É responsável pela manutenção de uma thread-pool contendo as threads utilizadas para tratar os eventos de entrada de utilizadores em áreas geográficas AreaEntryHandler. Destacam-se cinco cenários para o funcionamento deste componente: Sincronização de áreas e utilizadores Notificação de entrada em área geográfica Selecção do serviço a fornecer Execução da lógica do serviço Envio de conteúdo Sincronização de Utilizadores e Áreas Geográficas O processo de sincronização entre áreas geográficas e utilizadores serve para registar os utilizadores em cada uma das áreas geográficas no sistema, para que sejam recebidas notificações de entrada no Gestor de Eventos. O Parlay X suporta o registo de pedidos de notificações de entrada de terminais móveis em áreas geográficas mediante o web-service StartGeographicalNotification, cuja descrição e parâmetros se encontram no Anexo I. Este serviço permite criar uma notificação com um identificador único (correlation id), para uma dada área definida através de latitude, longitude, precisão (raio), e uma lista de identificadores de terminais móveis (MSISDNs). Essa lista identifica quais os terminais para os quais deve ser detectada a entrada nessa mesma área. Para facilitar a identificação das notificações, o correlation id escolhido é o identificador único da área geográfica no servidor de dados, permitindo identificar automaticamente a área geográfica na qual o utilizador entrou sem efectuar cálculos com a sua posição geográfica. A desvantagem deste mecanismo de notificações do Parlay X é o facto de não permitir a actualização de uma notificação com novos utilizadores, tendo esta de ser removida e novamente criada com todos os utilizadores. Isto implica a sincronização periódica entre áreas 47

58 e utilizadores na gateway Parlay X, removendo as notificações anteriores através do serviço StopGeographicalNotification e criando novas notificações para todas as áreas do sistema e todos os utilizadores. Este procedimento tem complexidade algorítmica ( ), seja o número de áreas geográficas definidas no servidor de serviços. Como o processo pode demorar algum tempo a concluir, a sua periodicidade deve ser ajustada de modo a que não coincida com o início de outro processo de sincronização. Isto é, deve ajustar-se a frequência de sincronização para um valor superior ao tempo que o processo demora a concluir. A utilização de uma frequência de execução muito baixa é indesejável, pois deteriora a noção de disponibilidade do sistema para utilizadores recém-registados. Assim, define-se uma métrica usada para calcular o valor do período de sincronização: Para valores de tais que: ( ) Seja o período de sincronização e o tempo que demora o processo de sincronização a concluir, o valor de na iteração actual ( ) é calculado multiplicando uma constante configurável pelo tempo que o processo demorou a executar na iteração anterior. Quanto maior o valor de, maior é o tempo entre sincronizações, mas existe também uma menor probabilidade de dois processos se sobreporem Notificação de Entrada em Área Geográfica A notificação de entrada de um utilizador numa área geográfica registada pode ocorrer de duas formas: Através de uma chamada ao web-service NotifyAreaEntry da componente lógica. Através de uma callback do Parlay X. Para os dois casos, é obtida nessa notificação a informação de qual a área geográfica (ID de área) e qual o terminal móvel do utilizador que nela entrou (MSISDN), no componente Gestor de Eventos. No Anexo I está a estrutura que contém a informação recebida numa notificação proveniente do Parlay X - LocationNotification. O identificador único do utilizador é obtido utilizando o seu MSISDN como critério de pesquisa no servidor de utilizadores. Após recepção da notificação e obtenção do utilizador, o Gestor de Eventos vai passar o ID de área e o utilizador a uma thread - AreaEntryHandler - que efectuará o tratamento da notificação, seleccionando o serviço a fornecer ao utilizador. Esta thread implementa o subcomponente Gestor de Perfis. 48

59 Selecção de Serviço O cerne do componente de lógica é o algoritmo de selecção de serviço, executado pela thread AreaEntryHandler. O seu objectivo é a selecção do melhor serviço a fornecer ao utilizador, dentro dos disponíveis numa determinada área geográfica. É feita uma consulta ao servidor de serviços, utilizando o ID da área onde o utilizador acabou de entrar, de modo a obter todos os serviços associados a essa área. Cada serviço retornado é um potencial candidato, com igual probabilidade de ser escolhido para ser fornecido ao utilizador. Da lista de candidatos, são removidos todos os serviços bloqueados pelo utilizador, assim como aqueles que já foram anteriormente fornecidos e os que, possuindo um horário de funcionamento, não se encontram dentro do estabelecido. Os restantes serviços são separados em duas listas, consoante tenham sido subscritos ou não pelo utilizador. Para cada serviço de cada uma das listas, é calculada a sua utilidade para o utilizador, dada pelo algoritmo: Seja uma função binária que relaciona a presença de um elemento num conjunto. ( ) { Seja o conjunto de preferências de um utilizador e o conjunto de preferências de um serviço, define-se a função como a função de utilidade de um serviço para o utilizador. ( ) ( ( ) ) É dada preferência ao que tenha o valor de utilidade mais elevado dentro da lista dos serviços subscritos, inclusive os que tenham valor de utilidade zero (0). Caso não exista nenhum serviço candidato na lista dos subscritos, e o utilizador não possua activada a flag que indica que só pretende que lhe sejam fornecidos serviços aos quais aderiu explicitamente, é escolhido aquele que tem o valor de utilidade mais elevado dentro lista dos não subscritos. Neste último caso, descartam-se os serviços cujo valor de utilidade é zero, evitando deste modo o fornecimento de serviços não subscritos que não têm preferências em comum com o utilizador. Também os serviços que tenham activado a flag que indica que só são fornecidos a utilizadores que lhes aderiram ou subscreveram explicitamente são ignorados neste caso Execução da Lógica de Serviço Após selecção com sucesso de um serviço, a thread AreaEntryHandler cria uma instância de uma nova thread ServiceDeliveryHandler a qual é responsável pela execução do fluxo lógico (workflow) do serviço. Como argumentos de criação, esta thread recebe o serviço a fornecer, o utilizador ao qual este será fornecido e a área geográfica para a qual a notificação de entrada foi disparada. 49

60 O atributo workflow do serviço contém um script, na linguagem LobsterScript, definindo a lógica de execução do serviço. Após extrair este parâmetro, a thread compila o script e cria, no ambiente de execução (environment) do mesmo as variáveis correspondentes ao utilizador, área geográfica e serviço sob a forma de records, com os nomes user, area e service, respectivamente. Este script é então avaliado e, caso a avaliação termine sem erros, o serviço é colocado no histórico de serviços do utilizador LobsterScript No âmbito da definição da lógica de execução de um serviço, é necessário que esta seja algo mais do que uma única rotina que faz a entrega de conteúdo quando um utilizador entra numa área geográfica. Por vezes, é útil fazer algum processamento dos dados do utilizador, comunicar com sistemas externos e escolher, com base noutros critérios, qual é efectivamente o conteúdo que deve ser entregue. Tornou-se numa prioridade a criação de um mecanismo que permitisse à entidade responsável pelo serviço a definição do seu fluxo lógico. Pretendia-se inicialmente a definição de um conjunto de classes em Java que, interligadas como uma cadeira de pipes-and-filters [48] permitissem construir um fluxo de lógica. Contudo, esta solução exige que de desenvolva um número elevado de classes (filters) e conectores (pipes), para manter um nível de expressividade aceitável. Caso isso não se verificasse, estarse-ia a comprometer a criação de serviços com lógica mais complexa. Uma alternativa passaria pela utilização de JBPM [49], um motor de interpretação de diagramas de processos de negócio descritos em XML, numa linguagem própria - JPDL. Teria, no entanto, a mesma desvantagem que a abordagem anterior, sendo necessário definir quais os blocos de operações válidas num workflow e as suas combinações possíveis. Avaliou-se também a utilização de Javassist [50], um software que tem como objectivo complementar a linguagem Java com mecanismos de reflexão (intercessão) que não estão disponíveis na linguagem-base. Torna-se possível desta forma armazenar código-fonte numa base de dados para posterior execução no acto do fornecimento do serviço. Esta alternativa, apesar de ser a mais flexível, pode ser potencialmente perigosa, pela possibilidade de utilizar muitas das características da linguagem Java e permitindo o acesso a classes e métodos não desejáveis no contexto da lógica de serviço, sendo uma ameaça à segurança do sistema. Após avaliação das hipóteses anteriores, optou-se então pela criação de uma linguagem interpretada, com um âmbito limitado mas suficientemente flexível e expressivo para definir a lógica dos serviços no sistema LobsterScript (Location Based Services TERminal Script). Uma descrição da linguagem LobsterScript pode ser consultada no Anexo II Envio de Conteúdo O envio de conteúdo para os utilizadores é suportado através de várias funções acessíveis a partir do workflow do serviço, em LobsterScript, as quais se apresentam no Anexo II juntamente com a descrição da linguagem. Cada função vai invocar, no componente de Interfaces, a rotina específica para envio da mensagem com os parâmetros respectivos. 50

61 Os anexos de uma mensagem são URLs apontando para ficheiros remotos ou locais. Para serem anexados à mensagem, os conteúdos são inicialmente descarregados para uma directoria temporária local com o nome <msisdn_do_utilizador>_<timestamp> (e.g. /usr/tmp/ _ /). Após envio da mensagem, a directoria é eliminada para conservar espaço no servidor. Caso os anexos não sejam URLs mas sim identificadores únicos de conteúdos, os URLs serão obtidos do servidor de conteúdos em primeiro lugar Envio de SMS A rotina de envio de SMS na interface é implementada recorrendo aos web-services Parlay X 3.0. Este web-service possui vários parâmetros de entrada, representados no Anexo I. O envio de SMS não faz uso dos parâmetros de charging, visto a solução não considerar a cobrança do envio de conteúdos ao utilizador. No entanto, seria uma opção interessante para serviços subscritos com pagamento (e.g. SMS Premium), os quais já existem no mercado Envio de MMS e WAP-Push O envio de MMS e WAP-Push é feito através do mesmo web-service Parlay X. Os parâmetros encontram-se no Anexo I. O conteúdo multimédia associado a este tipo de mensagens é transmitido utilizando a capacidade de anexar ficheiros a uma mensagem SOAP (SOAP with Attachments [51]), tal como seria possível com um . Este passo é feito automaticamente pelo SDK utilizado, bastando passar uma lista de ficheiros locais como argumento à rotina de envio. O formato de ficheiro utilizado para compor os elementos das mensagens multimédia MMS é o SMIL (Synchronized Multimedia Integration Language) [52]. Os ficheiros SMIL descrevem um fluxo de elementos multimédia que devem ser apresentados na mensagem MMS sob a forma de uma apresentação, permitindo a sua composição no ecrã do terminal móvel. Muitos terminais suportam a escrita e recepção de MMS no formato SMIL, sendo este o formato utilizado nos terminais virtuais do emulador da gateway Parlay X Envio de O envio de é feito através do Connector para servidores SMTP, que por sua vez utiliza a API Java Mail [53]. Esta API torna possível o envio de s para todos os servidores que suportem o protocolo SMTP, sem estar condicionado à utilização de APIs proprietárias com limitações de serviço impostas pelos seus distribuidores. 4.5 Componente de Apresentação No desenvolvimento da solução, foram desenhados dois tipos de interfaces gráficas, fazendo parte do componente de apresentação. São elas: Portal de Utilizador Portal de Administração 51

62 As funcionalidades requeridas dos portais de provedores de serviços e conteúdos, os quais existiam separadamente no diagrama de componentes da arquitectura do sistema, são providenciadas unicamente através do portal de administração Tecnologia Utilizada Ambos os portais foram implementados na linguagem Java, recorrendo ao SDK de construção de interfaces web SmartGWT [54]. Este software, com base no SDK GWT (Google Web Toolkit) [55], permite a criação de aplicações web na linguagem Java, que é compilada a posteriori para a linguagem Javascript. Esta extensão ao GWT, introduz componentes mais complexos e um estilo de codificação mais compacto. Para o caso particular da interface de utilizador, esta foi desenvolvida para ser integrada na rede social Facebook [56]. Utiliza uma biblioteca de acesso às APIs de desenvolvimento de aplicações para esta rede social tendo como base a linguagem Java RestFB [57] Portal de Utilizador A interface gráfica de utilizador ou portal de utilizador - foi desenhada para ser integrada como uma aplicação na rede social Facebook. Esta integração conduz a benefícios imediatos no que diz respeito à visibilidade do sistema por parte dos utilizadores e à utilização do mecanismo de autenticação da própria rede social. É também possível obter, deste modo, informação de contexto relevante para o fornecimento de serviços directamente através do perfil do utilizador na rede social, informação essa cuja replicação num website externo seria difícil de atingir, dado o nível de confiança por parte dos utilizadores para com a rede social em questão. Ao nível funcional, o portal de utilizador permite: Registar e autenticar um utilizador no sistema. Alterar informação de perfil de utilizador. Alterar as preferências de um utilizador. Consultar serviços aos quais o utilizador aderiu, bloqueou ou que já lhe foram fornecidos. Pesquisar serviços existentes na plataforma. Estas funcionalidades encontram-se descritas nas secções seguintes em detalhe Registo e Autenticação de Utilizadores Ao aceder pela primeira vez à aplicação no Facebook, é apresentado ao utilizador o pedido de autorização da rede social para cedência dos dados à aplicação desenvolvida. Ao aceitar, o utilizador é redireccionado para uma página web onde terá de aceitar os termos de utilização da aplicação antes de ser efectuado o registo. A existência deste último passo é 52

63 indispensável para informar o utilizador do seu papel no sistema e qual o tipo de serviços que lhe vai ser fornecido caso aceite. O registo do utilizador é então feito de forma automática, sendo recolhidos os dados de perfil do utilizador na rede social: Primeiro e último nome. Endereço de correio electrónico ( ). Idade, se disponível. Sexo, se disponível. O username do utilizador, no modelo de dados do sistema, é o seu nome de utilizador interno do Facebook. A autenticação integrada com a rede social faz com que seja dispensável a utilização do atributo password no modelo de dados para utilizadores registados desta forma. O processo de autenticação encontra-se ilustrado na Figura 4-7. Processo de Registo e Autenticação Aplicação web Facebook Pede autorização ao utilizador para a aplicação Autorizado? Sim Apresenta termos de licença Não Sim Fim Não Termos aceites? Sim Utilizador existente? Não Recolhe dados de perfil do utilizador Sim Apresenta página do utilizador Fim Núcleo lógico Obtém informação do utilizador Cria perfil de utilizador no sistema Figura Processo de registo e autenticação de utilizadores Dados de Perfil e Preferências de Utilizador O acesso à página de perfil de utilizador é feito através do botão Preferences, no menu do topo da página (Figura 4-8). Nesta página, é possível aceder funções de manipulação e consulta de dados de perfil do utilizador, encontrando-se estas no menu vertical do lado esquerdo. Cada uma das entradas do menu conduz a uma secção diferente, as quais se encontram descritas na Tabela 4-1. Figura Menu de topo de página no Portal de Utilizador 53

64 Tabela Páginas de dados de perfil do utilizador no Portal de Utilizador Secção Página Descrição Profile Permite consultar e alterar o nome e endereço de correio electrónico do utilizador. Contém também estatísticas de quantos serviços já foram fornecidos, o número de serviços com adesão e o número de serviços bloqueados. Preferences Permite a escolha das categorias de preferências do utilizador e alteração da data de nascimento e sexo do mesmo. Mobile Phones Permite a consulta, criação e remoção de terminais móveis utilizados para fornecer serviços ao utilizador Histórico de Serviços, Subscrições e Serviços Bloqueados Ainda na página Preferences, é possível a consulta do histórico de serviços fornecidos ao utilizador e os serviços que este subscreveu ou bloqueou. Estas funcionalidades estão acessíveis igualmente através do menu lateral da página, nos botões Provided Services (serviços providenciados), Subscriptions (serviços aderidos ou subscritos) e Blacklist (serviços bloqueados). Os serviços que foram fornecidos recentemente são igualmente mostrados na página principal (Home) do portal, quando o utilizador se autentica. Os dados relativos a estas funcionalidades são mostrados sob a forma de tabelas ao utilizador Consulta e Pesquisa de Serviços O utilizador pode consultar quais os serviços disponíveis no sistema através do botão Services no menu de topo de página. Nesta página (Figura 4-9), é possível a consulta de serviços utilizando a barra de pesquisa. Esta possui um campo para o texto a pesquisar (Search), uma caixa de selecção para o critério (Criteria) de pesquisa (nome ou descrição). 54

65 Os resultados de pesquisa são apresentados numa tabela abaixo, automaticamente à medida que o utilizador digita na caixa de texto. É possível a subscrição e bloqueio de serviços directamente, através dos botões Subscribe e Block, respectivamente. Figura Página de pesquisa de serviços no portal de utilizador Portal de Administração e Provedores Os portais de administração e provedores de conteúdo e serviços fazem parte da mesma aplicação web o Portal de Administração. Este providencia ao utilizador um ambiente semelhante ao ambiente de trabalho (desktop) de um computador pessoal (Figura 4-10). Figura Ambiente de trabalho do portal de administração As funcionalidades do portal de administração são implementadas sob a forma de aplicações virtuais, cujos ícones se encontram no ambiente de trabalho. Os diferentes tipos de utilizador administrativo no sistema têm acesso a funcionalidades diferentes dentro do portal, existindo aplicações virtuais diferentes nos seus ambientes de trabalho (Tabela 4-2). 55

66 Tabela Permissões dos utilizadores no portal de administração Permissão de Utilização Aplicação Virtual Funcionalidades Administrator Service Provider Content Provider User Manager Criar e remover utilizadores. X X 5 Service Manager Criar e remover serviços. Alterar dados X X de serviços, associar serviços a áreas geográficas e programar a lógica dos mesmos. Content Manager Criar e remover conteúdos multimédia. X X X Area Manager Criar áreas geográficas e alterar os X seus dados e posição User Manager Esta aplicação virtual permite a gestão dos utilizadores no sistema. A utilizadores cujo role é administrator é permitida a pesquisa e visualização de informação sobre qualquer utilizador, ao passo que aos do service providers apenas é permitida a criação de utilizadores do tipo content provider e visualização da informação de utilizadores por estes criados. Figura 4-11 Janela principal da aplicação virtual User Manager A criação de novos utilizadores é feita utilizando o botão no canto superior esquerdo da janela ( Add user ). Esta operação abre uma nova janela onde os dados do utilizador nome, nome de utilizador, palavra-passe, e role são inseridos. O botão Edit, em cada linha da tabela na janela principal, permite a consulta e alteração dos dados do utilizador respectivo, abrindo a janela da Figura Aos utilizadores do tipo service provider é apenas permitido visualizar informação acerca de utilizadores content provider por si criados. 5 Os Service Providers possuem acesso limitado à aplicação virtual User Manager, sendo apenas permitida a criação de utilizadores do tipo Content Provider. 56

67 Figura Janela de edição de utilizador, aplicação User Manager Na janela de edição de utilizador possui a informação dividida por vários separadores, de forma semelhante ao portal de utilizador. Apenas é permitida a visualização de informação de utilizadores do tipo user após criação, sendo as alterações efectuadas no portal de utilizador Area Manager A aplicação virtual Area Manager permite a utilizadores do tipo administrator criar e alterar áreas geográficas nas quais podem estar associados serviços. Este componente utiliza a API Google Maps para GWT [58]. Figura Janela de gestão de áreas geográficas As áreas geográficas são representadas no mapa da janela principal como círculos semitransparentes com um marcador no centro. Ao pressionar com o botão esquerdo do rato sobre estes marcadores, é possível alterar as propriedades da área (Figura 4-13), como o nome, descrição e raio de acção. A alteração da posição de uma área é feita arrastando o marcador para outra localização no mapa. A criação de áreas geográficas é possível pressionando com o botão esquerdo do rato em qualquer zona vazia do mapa. Esta operação irá abrir um popup com um formulário 57

68 semelhante ao de visualização de dados de área, mas vazio, permitindo o preenchimento dos dados de área Service Manager Esta aplicação virtual permite, de forma semelhante à User Manager a visualização de informação sobre serviços existentes no sistema e criação dos mesmos. Para facilitar a criação de serviços, o utilizador é guiado através de um wizard. O fluxo lógico deste wizard está representado na Figura O utilizador pode voltar atrás a qualquer momento durante a sua execução, sendo o serviço criado apenas quando este pressiona o botão Finish no ecrã final. Selecção do conteúdo a enviar Inicio Identificação do serviço Selecção de áreas geográficas Selecção do tipo de serviço Escolha do horário Fim Programação da lógica de serviço Figura Passos do wizard de criação de serviços O passo inicial é a configuração do serviço com identificação básica, isto é, um nome e descrição. De seguida, são escolhidas num mapa quais as áreas geográficas nas quais o serviço vai estar activo. Segue-se a selecção da forma preferencial de envio do serviço e- mail, SMS, MMS, entre outros no passo de selecção do tipo de serviço. Após a selecção do tipo de serviço, e de forma a possibilitar a criação de serviços de uma forma mais simples, o utilizador pode optar por não programar o script de lógica do serviço, especificando apenas quais os conteúdos a enviar. Neste caso, será criado um script automático com as operações necessárias para o envio desses conteúdos. Finalmente, é escolhido opcionalmente o horário de fornecimento do serviço, seleccionando a data de inicio e fim e quais os períodos do dia em que o serviço estará activo. A omissão desta configuração fará com que o serviço fique sempre activo. É possível consultar a informação de cada serviço, de forma semelhante à aplicação User Manager, pressionando o botão Edit na tabela de serviços da janela principal. Aí é permitida a consulta de todos os aspectos configurados no wizard e sua modificação Content Manager O suporte ao registo de conteúdos multimédia no sistema é conseguido através da aplicação virtual Content Manager. De forma semelhante às aplicações User Manager e Service Manager, os conteúdos de um dado provedor Content Provider são apresentados ao utilizador numa tabela, com um botão no canto superior esquerdo para a criação dos mesmos. 58

69 Ao criar um conteúdo, o provedor terá de preencher o seu nome, descrição, owner (caso queira ceder a pertença do conteúdo a outro utilizador), caminho absoluto (path) e tipo de conteúdo. O path de qualquer tipo de conteúdo tem de ser um URL válido, global. Se for possível determinar o tipo de conteúdo directamente através do path, este será automaticamente seleccionado. Caso contrário, o utilizador terá de escolher o tipo de uma lista de MIME-types. 4.6 Conclusão O desenvolvimento da solução foi feito respeitando o diagrama apresentado no capítulo 3 para a arquitectura do sistema. Foram apresentados, neste capítulo, quais os mapeamentos entre os componentes desenhados e a sua implementação, com destaque às tecnologias e algoritmos utilizados para o efeito. A implementação do componente de persistência tem em consideração a necessidade de flexibilidade da solução, pela escolha de utilização da tecnologia Hibernate. Esta possibilita a independência do sistema de gestão de base de dados utilizado, cumprindo o requisito nãofuncional RNF.4. A sua implementação foi feita também pela divisão em 3 (três) subcomponentes independentes Servidores de Dados os quais são independentes da restante solução, possibilitando a sua distribuição. O componente de lógica, por sua vez, foi implementado como uma aplicação residente num servidor aplicacional, utilizando um conjunto de interfaces modulares e intercambiáveis para comunicar com os restantes componentes e com a gateway Parlay X. Deste modo, tornase possível a adaptação futura deste componente a outros meios de comunicação. Destaca-se também a utilização de uma linguagem de scripting para programar o fluxo lógico de um serviço LobsterScript. É deste modo possível tornar a solução mais flexível, permitindo serviços com lógica arbitrária e comunicação com entidades externas. Finalmente, foram apresentadas as implementações do componente de apresentação os portais de Utilizador e Administração. Destaca-se a integração do portal de utilizador com a rede social Facebook, criando visibilidade para o sistema e permitindo obter informação sobre o utilizador no domínio da rede social, estando também o sistema de autenticação integrado com esta. 59

70 5 Avaliação da Solução O objectivo deste capítulo é a descrição do processo de avaliação do sistema desenvolvido, e os resultados obtidos através do mesmo. De modo a obter conclusões acerca da adequabilidade da solução aos requisitos levantados nos capítulos anteriores, foram efectuados dois tipos de testes Testes de Funcionalidade e Testes de Não-Funcionalidade. Dentro dos testes de funcionalidade, destacam-se os Testes de Integração e de Sistema, que visam testar o cumprimento dos requisitos funcionais do sistema. Para os testes de nãofuncionalidade, destacam-se os Testes de Desempenho e Testes de Usabilidade, que avaliam de modo objectivo os requisitos não-funcionais do sistema. De modo a validar os testes efectuados, apresenta-se também o ambiente utilizado para o efeito, destacando quais os componentes de hardware e software utilizados e a sua relação. 5.1 Ambiente de Testes O ambiente de testes utilizado encontra-se representado na Figura 5-1. Ambiente Virtual Emulador de Gateway Parlay X 4Mbit Internet 1Mbit Terminal de Utilização Servidor de Páginas de Utilizadores Servidor de Utilizadores, Serviços e Conteúdos Base de Dados Figura Diagrama de instalação do ambiente de testes O terminal de utilização, onde são realizados os testes funcionais, encontra-se ligado através da Internet a um servidor aplicacional contendo os portais de utilizadores. Este é uma máquina dentro de um ambiente virtual que incorpora o emulador da gateway Parlay X, o servidor de Utilizadores, Serviços e Conteúdos e uma máquina com a base de dados. As características do servidor de suporte ao ambiente virtual encontram-se na Tabela 5-1. Tabela Especificações técnicas do ambiente virtual Ambiente Virtual Sistema de Virtualização VMware 7.1 Workstation Sistema Operativo host Microsoft Windows 7 Professional x86-64 CPU Intel Core i GHz (4 cores) RAM 6 GB HDD 1 TB 5400RPM (Rotações por minuto) 60

71 5.1.1 Servidor de Páginas de Utilizadores O servidor de páginas de utilizadores contém os portais de utilizador e administração descritos no capítulo anterior. Estas residem num servidor aplicacional jboss versão 5.1.0GA, numa máquina virtual cujas características estão representadas na Tabela 5-2. Tabela Especificações técnicas do Servidor de Páginas de Utilizadores Servidor de Páginas de Utilizadores Sistema Operativo guest Ubuntu Server x86-64 CPU cores 2 RAM 1 GB HDD 20 GB pré-alocados Servidor de Utilizadores, Serviços e Conteúdos Este servidor contém uma instância de cada um dos três servidores de dados desenvolvidos Servidor de Utilizadores, Servidor de Serviços e Servidor de Conteúdos e uma instância da componente lógica central do sistema. Os quatro componentes enumerados residem numa única instância do servidor aplicacional jboss versão 5.1.0GA, na máquina em questão. As especificações da máquina são semelhantes às apresentadas na Tabela 5-2, utilizando a máquina apenas 1 core de CPU. Apesar de ser possível a distribuição de cada um dos servidores de dados por máquinas diferentes, optou-se por esta configuração pelo facto de se estar a utilizar tecnologia de virtualização. Um maior número de máquinas diminuiria o desempenho geral do sistema, contrabalançando as vantagens da distribuição dos componentes Base de Dados A base de dados que serve de repositório de dados a todos os componentes do sistema reside numa única máquina virtual, cujas características são semelhantes às apresentadas para o Servidor de Utilizadores, Serviços e Conteúdos. Dada a possibilidade de escolher qualquer sistema de gestão de base de dados (SGBD), optou-se o MySQL Server versão 5.1. Esta escolha assenta sobretudo no baixo consumo de recursos deste SGBD e na sua facilidade de configuração num ambiente Linux Emulador de Gateway Parlay X O componente Telecom WebServices Network Emulator, do SDK da Ericsson para desenvolvimento de aplicações baseadas em Parlay X apresentado no capítulo anterior, encontra-se instalado numa máquina virtual própria. A diferença desta para as restantes 61

72 máquinas virtuais reside no sistema operativo escolhido Microsoft Windows Server 2003 e no servidor aplicacional onde o emulador se encontra instalado Sun Glassfish versão 2.0. As configurações da máquina estão representadas na Tabela 5-3. Tabela Especificações técnicas do Emulador de Gateway Parlay X Emulador de Gateway Parlay X Sistema Operativo guest Microsoft Windows Server 2003 R2 CPU cores 1 RAM 1 GB HDD 10 GB pré-alocados Para além de comunicar directamente com o Servidor de Utilizadores, Serviços e Conteúdos, esta máquina providencia também acesso à consola web de administração do emulador Terminal WebServices Network Emulator. Esta tem particular relevância para os testes a efectuar, na medida em que permite: Visualizar os pedidos feitos via web-service ao emulador. Emular terminais móveis de utilizadores e visualizar mensagens SMS, MMS e WAP-Push nos mesmos. Enviar eventos de entrada de utilizadores em áreas geográficas Visualização de Pedidos aos web-services Uma das funcionalidades mais úteis do emulador é o painel de visualização de chamadas a web-services (Figura 5-2). Este possibilita a consulta de quais os web-services invocados pelas várias máquinas que comunicam directamente com o emulador e os parâmetros que lhes foram passados como argumentos na invocação. Figura Visualização de tráfego de chamadas a web-services no emulador Parlay X 62