Anderson Luiz Brunozi, Eliana De Martino *, Nádia Corradi, Robert Bafini, Grace Kelly de Castro Silva, Patricia Maria Pereira, Armando Zampar Junior e Vinicius José Latorre Este artigo apresenta os resultados do Projeto Serviços e Aplicações Móveis (SAM) que utiliza a especificação OpenLS (Open Location Services) do OpenGIS Consortium, combinada com tecnologias emergentes como Web Services, para o desenvolvimento de aplicações LBS. Serviços baseados em localização (LBS) são serviços que utilizam informação geográfica combinada ou não com a posição do terminal móvel, com o fim de obter e gerar informação útil aos usuários dos dispositivos móveis. Existem várias iniciativas na definição de padrões que focam no aumento da interoperabilidade entre serviços baseados em localização. Entre as principais iniciativas pode-se mencionar a especificação OpenLS (Open Location Services) do OpenGIS Consortium. Palavras-chave: LBS. GPS. Kerberos. Web services. OpenLS. 1. Introdução A evolução tecnológica das redes de comunicação de dados sem fio, a possibilidade de integração destas ao mundo IP e à Internet, associada à adequada especificação de sistemas e às necessidades de mercado, permitiram o crescimento exponencial do mercado das comunicações móveis. A mobilidade possibilita a extensão do ambiente de trabalho da empresa às áreas externas, levando o acesso remoto às informações corporativas para os seus colaboradores, permitindo-lhes a aplicação de ações imediatas e integrando-os melhor em ações de trabalho colaborativo. A mobilidade, associada a informações de localização, permite selecionar a informação a ser disponibilizada ao usuário de forma que somente o conteúdo relevante naquele momento seja considerado. O mercado de serviços de localização demanda tecnologias que têm como princípio a simplicidade, dado que esses serviços são largamente utilizados por terminais móveis. Além disso, soluções LBS devem ter alto grau de interoperabilidade, visto que podem ser disponibilizadas em diferentes plataformas e sistemas operacionais e muitas vezes possuem interface com sistemas legados. O uso da tecnologia Web Services em soluções LBS objetiva atender estes requisitos, uma vez que ela permite que sistemas executados em diferentes ambientes se comuniquem via XML ou outros padrões Web [1]. A informação em formato XML é legível tanto para humanos como é processável por máquinas. Por esta razão há a necessidade de proteger informações sensíveis que devam ser transmitidas através da rede em mensagens SOAP (Simple Object Access Protocol). Este artigo inclui resultados parciais do Projeto Serviços e Aplicações Móveis (SAM), da Fundação CPqD, que propõe a adoção da tecnologia Web Services e a utilização de padrões abertos na construção de soluções LBS, bem como na implementação da infra-estrutura de segurança do sistema. 2. A tecnologia Web Services Nos últimos anos o modelo de arquitetura orientada a serviços vem despertando a atenção dos desenvolvedores de software com a promessa de trazer grandes ganhos para a comunicação entre os sistemas de computação existentes. Essa arquitetura pode ser definida como uma arquitetura de software que relaciona os componentes de um sistema em um ambiente distribuído, onde são disponibilizados serviços que podem ser acessados dinamicamente através de uma rede [2]. * Autor a quem a correspondência deve ser dirigida: martino@cpqd.com.br.
Figura 1 Comunicação via Web Services A tecnologia Web Services implementa a maioria das características dessa arquitetura. Ela propõe a exposição das transações e das regras de negócios por meio de protocolos que podem ser acessados e entendidos por qualquer linguagem de programação, em qualquer sistema operacional, rodando em qualquer dispositivo [3]. Dessa forma, os Web services são um caminho para a redução de custos por intermédio da redução da redundância dos dados e serviços. Conforme ilustrado na Figura 1, na tecnologia Web Services, a disponibilização e o acesso aos serviços envolvem três elementos: consumidores de serviços, provedores de serviços e serviços de diretório. A troca de mensagens entre provedores e consumidores de serviços utiliza o protocolo Simple Object Access Protocol (SOAP). O SOAP [4] é um protocolo baseado em XML, para troca de informações em um ambiente distribuído, contendo os seguintes elementos: Envelope: identifica o documento XML como uma mensagem SOAP e é responsável por definir o conteúdo da mensagem. Header (opcional): contém os dados do cabeçalho. Body: contém as informações de chamada e de resposta ao servidor. Fault: contém as informações dos erros ocorridos no envio da mensagem. Esse elemento só aparece nas mensagens de resposta do servidor. O Axis [5] da Apache é uma implementação do SOAP e foi adotado no Projeto SAM, pois, entre outras funcionalidades, possui extenso suporte à Web Service Description Language (WSDL), pode ser utilizado em servidores de aplicação tais como Tomcat e possui ferramenta para geração de classes Java a partir do WSDL e vice-versa. Para a implementação de clientes Web Services em dispositivos móveis, a utilização do Ksoap [6] é a única opção prática, já que a especificação da API definida pela JSR172 - J2ME TM Web Services Specification [7], que especifica um conjunto mínimo de classes para suporte a clientes Web Services em terminais móveis, ainda é recente e não foi incorporada na máquina virtual dos terminais móveis. 3. O Projeto SAM O Projeto Serviços e Aplicações Móveis (SAM) visa ao desenvolvimento de uma plataforma de software para comunicação de dados entre agentes em campo e os centros de dados de suas corporações, utilizando terminais móveis. Aproveitando as facilidades das redes celulares quanto à comuni- 86
cação de dados, a plataforma foi planejada para explorar as funcionalidades de mobilidade que estão contempladas nos seguintes módulos principais: Sistema de Mobilidade: fornece a infra-estrutura para a comunicação entre serviços, sincronização de dados, acesso seguro a serviços, autenticação e autorização. Sistema de Localização de Terminais Móveis: fornece a localização dos terminais móveis, base de dados de localização e funções de gerenciamento de localização. Sistema de Geoposicionamento: fornece mapas georreferenciados, análises temáticas, definição de rotas otimizadas e visualização da localização dos agentes em campo. No Projeto SAM, optou-se por uma arquitetura orientada a serviços utilizando Web Services porque, dessa forma, os sistemas acima descritos mantêm baixo acoplamento entre si, permitindo que sejam desenvolvidos em paralelo e integrados posteriormente como componentes da arquitetura SAM. 4. LBS Padrões abertos utilizados A interoperabilidade é um dos pontos-chave a ser considerados no desenvolvimento de aplicações LBS, visto que estas devem ser disponibilizadas em diferentes plataformas e sistemas operacionais, e muitas vezes devem ter interface com sistemas e bancos de dados legados. O OpenGIS Consortium (OGC) [8] define uma série de padrões computacionais que objetivam promover interoperabilidade entre Sistemas de Informação Geográfica (SIG). Alguns dos padrões OGC utilizados nesta pesquisa estão descritos a seguir. 4.1. OpenGIS Location Services (OpenLS) A especificação OpenLS [9] foi aprovada pelo OpenGIS Consortium em janeiro de 2004. Ela define um conjunto de interfaces para o desenvolvimento de serviços baseados em localização, todos utilizando protocolos no padrão Web. Os serviços especificados encontram-se descritos a seguir: Serviço de Diretório: provê acesso a um diretório on-line para localização de um determinado lugar, produto ou serviço. Serviço de Gateway: identifica a posição geográfica de um determinado terminal móvel. Serviço de Geocodificação/ Geocodificação Reversa: identifica uma posição geográfica dado o nome de um lugar ou endereço. Também funciona de forma reversa identificando um endereço completo dada uma posição geográfica. Serviço de Apresentação de Mapas: apresenta informações geográficas no terminal móvel. É utilizado para apresentar mapas destacando rotas entre dois pontos, pontos de interesse, áreas de interesse, localizações e/ou endereços. Serviço de Determinação de Rotas: determina a rota entre dois pontos informados pelo usuário. O usuário também pode, opcionalmente, informar pontos pelos quais a rota deve passar, rotas preferenciais (mais rápida, mais curta, menos tráfego, mais atrativa, etc.) e o modo de transporte. 4.2. Web Map Server (WMS) A especificação WMS 1.1.1 [10] padroniza interfaces que devem ser utilizadas por clientes para requisitar mapas aos servidores e também padroniza o modo como esses servidores devem descrever e retornar esses mapas. Um servidor Basic WMS é capaz de: Gerar mapas georreferenciados (como uma imagem ou um conjunto de objetos gráficos). Responder às perguntas sobre o conteúdo de um mapa, retornando informações sobre um determinado objeto (feature) do mapa. Descrever quais mapas ele pode produzir e quais podem ou não ser consultados, para que um cliente desse servidor saiba quais mapas podem ser requisitados. Esses serviços podem ser requisitados pelo cliente utilizando as três interfaces definidas pela especificação WMS: 1. GetMap (obrigatória), para requisitar um mapa. Na requisição devem ser especificados parâmetros como o layer, a área que deve ser mapeada (extent), o sistema de coordenadas e o nome do estilo. 2. GetFeatureInfo (opcional), para consultar o mapa. Na requisição deve ser especificada a coordenada em que deve ser feita a consulta. 3. GetCapabilities (obrigatória), para descrever os mapas. 87
5. Segurança Protocolo Kerberos Desenvolvido pelo Massachusetts Institute of Technology (MIT) [11], o Kerberos é um protocolo de autenticação projetado para prover autenticação segura a aplicações Cliente/Servidor por meio do uso de criptografia de chave secreta. É um padrão bem estabelecido, altamente testado e de código aberto e tem sido largamente utilizado por empresas para identificar clientes de serviços de rede, que se comunicam através de redes de comunicação abertas, intrinsecamente inseguras, e para proteger a privacidade da comunicação com esses serviços. Tendo em vista a necessidade de prover ao sistema SAM uma infra-estrutura de autenticação que garanta que o acesso às funcionalidades do sistema seja realizado apenas por usuários autorizados, a necessidade de proteger informações sensíveis que devam ser transmitidas através da rede em mensagens SOAP, bem como a utilização do mesmo mecanismo de segurança para o cliente Web e o cliente móvel, decidiu-se por utilizar o protocolo Kerberos V5 na implementação da infra-estrutura de segurança do sistema. Uma segunda opção para prover segurança à comunicação através de Web Services seria a utilização do protocolo HTTPS, em vez do HTTP, como protocolo de transporte para as mensagens SOAP. Porém, com esta solução, a segurança da comunicação estaria sendo confiada ao transporte, e não seria mais uma responsabilidade da aplicação, que permite um controle de seleção da informação a ser criptografada. O principal impedimento para a utilização do protocolo HTTPS como transporte, entretanto, é o fato de que esta solução não é suportada pela maioria dos terminais móveis de baixo custo atualmente disponíveis, uma vez que esses terminais, em sua maioria, possuem uma máquina virtual Java que não define como obrigatório o suporte a HTTPS para os dispositivos móveis. 6. Descrição do protótipo 6.1. Arquitetura A arquitetura proposta para desenvolvimento do protótipo prevê a adoção da tecnologia Web Services a fim de garantir a interoperabilidade e a ubiqüidade dos serviços envolvidos, conforme Figura 2. O Servidor Web recebe, dos diversos clientes, as requisições XML encapsuladas em mensagens SOAP e encaminha-as para o serviço responsável pela sua execução. O serviço responsável processa a Requisição, acessando informações na base de dados caso seja necessário, e envia a Resposta de volta para o Servidor Web, que a codifica como uma Resposta XML e a envia para a Aplicação Cliente. Esta, por sua vez, decodifica a Resposta XML e aplica as funções de apresentação apropriadas para mostrar a resposta no dispositivo. Em uma arquitetura baseada em serviços, vale ressaltar que um serviço pode acessar outro a fim de executar suas funções. Dessa forma é gerado um encadeamento de serviços, podendo um mesmo serviço assumir o papel de provedor ou consumidor. O protótipo implementado está restrito aos seguintes casos de uso: Autenticação de usuário no cliente Web e no cliente móvel. Visualização da localização de um determinado terminal móvel. Visualização do histórico da localização de um determinado terminal móvel. Nos casos de uso em questão, após a autenticação de um usuário utilizando o protocolo Kerberos, o Serviço de Apresentação permite a visualização de um mapa com a localização do terminal móvel que se encontra em uma dada posição (X, Y). Essa posição é obtida por meio do Serviço de Localização, implementado para um Figura 2 Arquitetura do protótipo 88
Cliente Web Internet Serviço de Autenticação Cliente Web Servidores Kerberos Figura 3 Serviço de Autenticação GPS Satélite GPS Web Services OpenLS GPS Bluetooth http BTS Rede Celular/Fixa Serviço de Localização Cliente móvel http Servidor de localização Figura 4 Serviço de Localização Base de localização terminal móvel GSM/GPRS acoplado a um GPS (Global Positioning System) externo via Bluetooth. O conjunto dessas posições em um determinado espaço de tempo permite gerar uma lista de posições (X, Y), formando o histórico da localização de um determinado terminal móvel. 6.2. Serviço de Autenticação Seguindo a padronização de comunicação via Web Services em todo o sistema, para a autenticação de usuários foi implementado um serviço que serve como interface para que os clientes se comuniquem com o servidor Kerberos, utilizando um protocolo XML, conforme Figura 3. Quando o cliente solicita autenticação no sistema, este irá receber do servidor Kerberos [11], por intermédio do Serviço de Autenticação, um TGT (Ticket-Granting Ticket). De posse desse TGT, o cliente poderá usá-lo para comprovar sua identidade ao servidor de autenticação e obter um ticket de serviço para poder se comunicar de forma segura com os outros serviços que compõem o sistema. 6.3. Serviço de Localização A especificação OpenLS define interfaces de serviços que facilitam o desenvolvimento de aplicações baseadas em localização. Entre os serviços padronizados está o Serviço de Localização utilizado no protótipo. A Figura 4 ilustra o esquema implementado no protótipo do Serviço de Localização: A posição (latitude, longitude) é capturada do GPS (Global Positioning System) pelo terminal móvel via interface Bluetooth e enviada via HTTP a um servidor de localização que armazena e gerencia os dados de localização. O Serviço de Localização é disponibilizado via Web Services e acessado por meio de uma interface encapsulada na estrutura definida pelo padrão OpenLS. De acordo com a especificação, a requisição ao Serviço de Localização ocorre por 89
xls:slirtype xls:inputgatewayparameterstype xls:inputmsidstype SLIR xls:inputgatewayparameters xls:inputmsids xls:inputmsinformation Standard Location Immediate Request. Presponse type is Synchronous Figura 5 Requisição do Serviço de Localização xls:sliatype xls:inputgatewayparameterstype xls:inputmsidstype xls:outputmsinformationtype SLIA Standard Location Immediate Response xls:inputgatewayparameters xls:inputmsids xls:inputmsinformation Xls:Position Figura 6 Resposta do Serviço de Localização intermédio de um SLIR (Standard Location Immediate Request), ilustrado na Figura 5, que contém as seguintes informações: InputGatewayParameters: detalhes para a requisição, como prioridade, tipo de localização, tipo do sistema de referência espacial. InputMSInformation: identificação do terminal móvel (tipo e valor), encapsulada pela estrutura InputMSID. O identificador pode ser, por exemplo, o IMEI (International Mobile Equipment Identity). No processamento de uma requisição, o Serviço de Localização acessa uma base de dados de localização onde estão armazenados, classificados por terminal móvel, os dados de posição coletados por um certo período de tempo. O resultado obtido é disponibilizado por meio de um par de coordenadas (X, Y) na forma de latitude e longitude, sendo esta enviada ao usuário por intermédio de um SLIA (Standard Location Immediate Answer), ilustrado na Figura 6, também definido na especificação OpenLS, que contém as seguintes informações: OutputGatewayParameters: envelope que carrega a resposta do Serviço de Localização. OutputMSInformation: contém a identificação do terminal e a posição requisitada encapsulada pela estrutura OutputMSID. 6.4. Serviço de Apresentação O Serviço de Apresentação é outro serviço cuja interface, definida pela especificação OpenLS, é implementada neste protótipo. A Figura 7 ilustra o esquema implementado no protótipo do Serviço de Apresentação: O Serviço de Apresentação é disponibilizado via Web Services e é acessado por meio da interface definida na especificação OpenLS. De acordo com a especificação, a requisição ao Serviço de Apresentação ocorre por intermédio de um PortrayMapRequest, ilustrado na Figura 8, o qual contém as seguintes informações: Output: especifica formato, altura e largura do mapa a ser gerado. BaseMap (opcional): especifica a lista de layers que devem compor o mapa. Overlay (opcional): especifica a lista de tipos de dados que devem ser retornados sobre o mapa. Entre os tipos de dados possíveis, pode ser especificada uma determinada posição (X, Y) que se deseja visualizar. No processamento de uma requisição, o Serviço de Apresentação acessa uma base de dados georreferenciada, recupera um mapa centrado na posição (X, Y) informada e disponibiliza o mapa em uma URL acessível pelo usuário. O acesso à base de dados georreferenciada é feito utilizando-se a interface WMS, conforme apresentado anteriormente na Figura 7. O mapa obtido é disponibilizado por meio de uma URL, sendo esta enviada ao usuário por intermédio do PortrayMapResponse, ilustrado na Figura 9, também definido na especificação OpenLS. 6.5. Execução do protótipo Um esquema simplificado do Projeto SAM é apresentado na Figura 10. No atual protótipo [12], foram implementados três Web services 90
Web Serviços OpenLS Serviço de Apresentação Base de dados georrefenciada WMS Figura 7 Serviço de Apresentação xls:portraymaprequesttype Output + 1.. Specifies the output of the map(s) taht should generated PortrayMapRequest + Content of a presentation request Basemap + The layers that should make up the basemap, (getcapabilities Provides the impl Provides) Overlay + 0.. Overlays the set of ADT s onto the basemap Figura 8 Requisição do Serviço de Apresentação xls:portraymapresponsetype PortrayMapResponse + xls:map - Content of a presentation response 1.. Figura 9 Resposta do Serviço de Apresentação desenvolvidos nos sistemas anteriormente descritos: Serviço de Autenticação, Serviço de Apresentação e Serviço de Localização (Gateway). Uma aplicação agregadora foi desenvolvida para fazer o papel de controller na chamada de Web services. A própria aplicação agregadora é também um Web service, que é chamada tanto pelo cliente móvel como pelo cliente Web. O protótipo é executado por meio de um cliente Web ou de um cliente móvel, por intermédio do qual o usuário, após sua autenticação, informa a identificação do terminal móvel que deseja localizar. 91
Figura 10 Esquema simplificado SAM Figura 11 Protótipo SAM Localização de um agente interface Web Figura 12 Protótipo SAM Localização de um agente interface móvel (P900 SonyEricsson) 92
Figura 13 Protótipo SAM Histórico da localização de um agente interface Web Figura 14 Protótipo SAM Histórico da localização de um agente interface móvel (P900 SonyEricsson) O Serviço de Localização é acionado a fim de determinar a posição (X, Y) do terminal em questão. Conhecendo a posição (X, Y), o Serviço de Apresentação é invocado e o mapa é apresentado na tela. As figuras 11 a 14 mostram o resultado obtido para a localização de um terminal móvel, e o resultado obtido para o histórico da localização de um terminal móvel. Na aplicação, cada terminal móvel é associado a um agente em campo. 7. Considerações finais A fim de garantir a ubiqüidade dos serviços, aplicações LBS devem estar disponíveis em vários tipos de dispositivos, ter interface com sistemas e bancos de dados legados, além de suportar uma variedade de tecnologias de infraestrutura de rede. O uso de padrões abertos na definição das interfaces é uma forma de garantir a interoperabilidade entre os sistemas. A tecnologia Web Services também vem sendo amplamente difundida como uma solução revolucionária para os problemas de integração entre os sistemas de computação. A combinação da tecnologia Web Services com a utilização de padrões abertos foi um grande desafio nesta pesquisa, uma vez que a especificação OpenLS 1.0 ainda não está preparada para essa tecnologia. No entanto, uma iniciativa está em andamento no OpenGIS com o objetivo de desenvolver e estender os padrões OGC Web Services (OWS) para facilitar a descoberta, o acesso e o uso de dados geográficos e de serviços de geoprocessamento, por meio do suporte a WSDL/SOAP. Os trabalhos de padronização do OpenGIS estão sendo acompanhados no âmbito de Comitê Técnico, via afiliação da Fundação CPqD, que permite acesso e influência no desenvolvimento das especificações. 93
8. Referências [1] ARSANJANI, A.; HAILPERN, B.; MARTIN, J.; TARR, P. Web Services: promises and compromises. ACM Queue, mar. 2003. [2] AMORIM, S. A tecnologia Web Services e sua aplicação num sistema de gerência de telecomunicações. Tese de mestrado, Universidade Estadual de Campinas, Campinas, SP, 2004. [3] COSTA, G. O modelo de Web Services Como desenvolver aplicações em uma nova arquitetura de software. Promon Tecnologia Business & Technology Review Series, 2002. [4] SOAP. Simple Object Access Protocol [on-line]. 2003. Disponível em: <http://www.w3.org/tr/ soap12>. Acesso em: 7 nov. 2005. [5] Axis. Apache Axis [on-line]. 2003. Disponível em: <http://ws.apache.org/axis>. Acesso em: 7 nov. 2005. [6] Ksoap 2.0. Disponível em: <http:// ksoap.objectweb.org/>. Acesso em: 7 nov. 2005. [7] JSR 172. Disponível em: <http://www.jcp.org/ en/jsr/detail?id=172>. Acesso em: 7 nov. 2005. [8] OGC. OpenGIS Consortium [on-line]. 1994. Disponível em: <http://www.opengis.org>. Acesso em: 7 nov. 2005. [9] OGC. OpenGIS Location Services: Core Services [Parts 1-5]. Versão 1.0. MA: Open GIS Consortium, Inc., 2004. [10] OGC. Web Map Service Implementation Specification. Versão 1.1.1. MA: Open GIS Consortium, Inc., 2002. [11] Kerberos V5. Disponível em: <http:// Web.mit.edu/kerberos/>. Acesso em: 7 nov. 2005. [12] G. K. C. SILVA, P. M. P., G. C. MAGALHÃES. Disponibilização de serviços baseados em localização via Web Services. Geoinfo 2004. Abstract This article reports the results of the project Mobile Services and Applications that uses the OpenLS (Open Location Services) specification from the OpenGIS Consortium, combined to emerging technologies such as WebServices, for developing LBS applications. Location-Based Services (LBS) are services which use geographical information, combined or not with the position of the mobile terminal in order to obtain and generate useful information to the users of mobile devices. There are several initiatives in the definition of standards which aim at increasing the interoperability among location-based services. Among the main initiatives we can mention the OpenLS (Open Location Services) specification from the OpenGIS Consortium. Key words: LBS. GPS. Kerberos. Web services. OpenLS. 94