Análise de Tecnologias para Computação Pervasiva UFF - Universidade Federal Fluminense PGC – Pós-graduação em Computação Análise de Tecnologias para Computação Pervasiva 22 de janeiro de 2003 MARCIO BELO R. DA SILVA Orientador: Prof. Orlando Loques

Conteúdo Introdução Requisitos para um ambiente pervasivo Tecnologias Atuais SLP JINI UPnP UPnP como escolha Projeto Prático UPnP Referências Objetivo: apresentar conteúdo abordados e propostas do artigo “Análise de Tecnologias para Computação Pervasiva” produzido para a monografia da disciplina.

Introdução Ambiente Pervasivo: é aquele onde os recursos computacionais não são notados Surge a necessidade de integração de diversos dispositivos: PCs e equipamentos de uso específico Interoperabilidade é a base para esse ambiente computacional Ambiente pervasivo: ideal: é aquele onde a presença de qualquer dispositivo trabalhando em benefício do usuário não é notada por ele. Surge (...): é crescente a demanda pela integração dos dispositivos. Citar motivos. Interoperabilidade: tanto em software quanto em hardware e traz à tona essa questão: qual ambiente tecnológico dará suporte a essa integração ?

Requisitos para um ambiente pervasivo Conectividade entre dispositivos Padrão unificado para descoberta, configuração e controle de dispositivos Formatos padronizados de mídia e protocolos de “streaming” Segurança: mecanismos padronizados de autenticação e autorização para usuários e dispositivos Requisitos (...): desafios e dificuldades para a computação pervasiva. Conectividade: capacidade dos dispositivos trocarem informações através de uma rede. Redes Ethernet, 802.11, Bluetooth, e outras. Padrão (...): tornar o ambiente auto-configurável, sem necessidade (ou quase sem) de intervenção humana. Formatos padronizados (...): apenas a capacidade de trocar informações não é suficiente. É preciso conciliar os formatos em que os dados são trocados. Esse tópico o padrão XML terá um papel importante, mas não definitivo. Por exemplo: qual o formato de mídia de vídeo será adotado ? E para música ? Etc. Segurança: dualidade a ser conciliada: permissividade x segurança (inversamente proporcionais)

Tecnologias Atuais WSDL UDDI Location-aware applications SLP JINI UPnP WSDL: Permite a descrição completa da interface de um serviço usando a linguagem XML. Implementação + Meta-dados (WSDL). UDDI: Páginas amarelas de serviços. Location-aware applications: A seguir propostas completas para integração de serviços analisas no artigo: SLP (Service Location Protocol) JINI UPnP Existem outras tecnologias não abordadas: Bluetooth e Salutation

SLP (Service Location Protocol) Concentra-se no problema do descobrimento de serviços Padrão independente (IETF) Baseado TCP/IP Componentes principais: UAs, SAs, DAs. DA não é obrigatório: SAs e DAs fazem multicast Descrição do serviço é feita por par atributo-valor Anúncios com expiração Possui uma arquitetura aberta; Não obriga a presença de um diretório (DA) central na sua arquitetura, o que confere maior flexibilidade a esse ambiente. Possui como limitação o fato de se concentrar na descoberta de serviços, porém não apresenta um bom mecanismo de descrição dos serviços;

JINI 1: serviço descobre Lookup Server (LUS) 2: serviço envia proxy para o LUS 3: cliente descobre LUS 4: cliente envia requisição para o LUS por serviços disponíveis 5: LUS envia proxy do serviço para o cliente 6: cliente interage com o serviço diretamente Depende da existência do LUS Dependente de plataforma: JAVA Mobilidade de código Roda sobre a camada Java, o que possibilita independência de sistema operacional e de mecanismo de transporte em rede. Apresenta como desvantagens a necessidade do LOOKUP SERVER - um repositório central de proxies – e o fato de ser um padrão proprietário;

UPnP Padrão aberto independente de plataforma, linguagem de desenvolvimento e de rede física Padrões Internet: TCP/IP, UDP, HTTP, HTML, XML, SOAP, etc. Não depende de um componente centralizado para localização Rede de configuração zero Questões de segurança ainda não resolvidas Padrão aberto (…): Independente de plataforma e linguagem de desenvolvimento: ao contrário do Jini Não depende de um componente centralizado para localização: componentes como DHCP e DNS são opcionais, ao contrário do Jini, que exige a existência do LOOKUP SERVER. Rede de configuração zero: Questões de segurança (...): pendente.

UPnP (continuação) 0 Addressing 1 Discovery 2 Description 5 Presentation 4 Eventing 3 Control 0: Control Point´s e Device´s obtém endereços IP 1: Control Point descobre Device´s de seu interesse 2: Control Point aprende sobre as capacidades dos Device´s 3: Control Point invoca ações no Device 4: Control Point escutam mudança de estados nos Device´s 5: Control Point controla Device e/ou estados do Device usando interfaces HTML 0: Device ou Control Point enviam mensagem multicast a procura de um DHCP Server. Se exister um DHCP Server, recebe um IP (Maneged Network). Caso contrário, escolhe um IP por conta própria (Auto-IP) e realiza um ARP Probe verificando se já existe algum dispositivo na rede usando este IP. Caso exista tenta outro IP até encontrar um disponível. Uma vez usado o Auto-IP, periodicamente checa por um DHCP SERVER 1: Novo Device entra na rede: notifica por mensagem multicast (Notify) seus serviços aos Control Point’s. Os Control Point’s escutam uma porta multicast por essa notificação e tomam conhecimento deste novo Device. Esse novo device pode deixar a rede voluntariamente (Byebye) ou pela expiração do tempo da mensagem Notify. Novo Control Point: Envia mensagem multicast a procura de Device’s (Search) de seu interesse. Caso algum Device atende ao critério de busca do Control Point, este retorna uma mensagem unicast para o Control Point. 2:Após um Control Point descobrir um dispositivo, é preciso conhecer suas capacidades. Então, ele envia uma requisição unicast (HTTP GET) para o Device (com a URL fornecida na etapa Discovery) e recebe também via unicast uma mensagem de descrição do dispositivo (Service Description) baseada no padrão WSDL. 3: O Control Point invoca ações no Device enviando mensagem unicast (Invoke) usando o padrão SOAP e recebendo como resposta uma mensagem unicast (Response) com o resultado da invocação. Nesta fase o Control Point pode interrogar o Device sobre variáveis de estado que ele armazena. Para isso envia mensagem unicast (Query Invoke) e recebe como resposta mensagem unicast de resposta (Query Response). 4: O Control Point pode inscrever-se através de mensagem unicast (Subscription) para o Device para receber notificações sobre mudanças no valor das variáveis de estado do Device. Sempre que houver alguma mudança no valor de uma variável, o Device envia uma mensagem unicast (Notify) avisando o Control Point dessa mudança. Essa inscrição deve ser renovada num período de tempo determinado pela validade da mensagem (Subscription), caso contrário a inscrição é automaticamente cancelada. 5: O Control Point pode solicitar ao Device uma página de apresentação do dispositivo. Ele faz isso enviando uma requisição (HTTP GET) da página especificada na descrição do dispositivo pela tag presentationURL e recebendo como resposta a página de apresentação do Device.

UPnP (continuação) Rede Física de suporte UPnP Device Architecture UDP IP HTTPU/MU GENA SSDP SOAP HTTP TCP UPnP Forum UPnP vendor Rede Física de suporte Pilha do protocolo UPnP Começa com IP UDP usado para Discovery. TCP usado para Description, Control e Eventing. Camada HTTP: HTTPMU: variante multicast do protocolo HTTP para anúncios e procuras na rede UPnP. HTTPU: HTTP unicast para resposta às procuras. SSDP: Simple Service Discovery Protocol. Utiliza o UDP. Envia mensagens multicast e recebe respostas unicast. GENA (tanto unicast quanto multicast): General Event Notification Architecture. Protocolo usado nas inscrições e respostas SOAP: Simple Object Access Protocol. Camada UPnP Architecture: Camada UPnP Forum Camada UPnP Vendor Sistema operacional de suporte

UPnP como escolha Está sendo abraçado por diversas empresas, o que tende a consolidá-lo como padrão de mercado Característica aberta e extensível permite maiores possibilidades de uso atual e futuramente Estudo sobre segurança tem avançado de forma acelerada É o padrão que mais de aproxima do ambiente pervasivo ideal; Está sendo abraçado por grandes players do mercado, com utilizações práticas inclusive; Segurança ainda é uma lacuna a ser preenchida na tecnologia, mas já existem várias propostas, cada uma delas com características apropriadas para necessidades específicas.

Exemplo prático UPnP Network Light Media Streaming Network Light: Iniciar o Network Light; Iniciar o Device Spy; Ligar a lâmpada através do método SetTarget; Media Streaming: Iniciar o AV Media Server: adicionar um diretório que contenha músicas e vídeos; Iniciar o AV Renderer; Iniciar o AV Media Controller: clicar sobre uma das músicas ou vídeos oferecidos e enviar para o renderizador;

Referências [1] W3C Web Services Description Language (WSDL) Version 1.2. July, 9 2002. http://www.w3.org/TR/wsdl12/ [2] Microsoft, Web Services Description Language Explained. July, 2001. http://msdn.microsoft.com/library/en-us/dnwebsrv/html/wsdlexplained.asp [3] Microsoft Corporation. Universal Plug And Play Device Architecture. Version 1.0. 2000. www.upnp.org [4] Universal Plug And Play Forum. www.upnp.org [5] Mark Weiser, R.Gold, J.S.Brown. The origins of ubiquitous computing research at PARC in the late 1980s, IBM Systems Journal, vol.38, no. 4, 1999. [6] Jini Architectural Overview, Technical White Paper, Sun Microsystems, 1999. [7] Jini Network Technology Datasheet, Sun Microsystems, 1999. [8] A.C. Huang, B.C.Ling, J.Barton, A.Fox. Making Computers Disappear: Appliance Data Services, MobiCom 2001 Rome, Italy [9] uddi.org. UDDI Executive White Paper. November 14, 2001. www.uddi.org [10] uddi.org. UDDI Technical White Paper. September 6, 2000. www.uddi.org [11] Sandip H. Mandera. Web Services and UDDI: The New Wave of E-Business Renaissance www.devx.com [12] Sastry Duri, Alan Cole, Jonathan Munson, Jim Christensen. An Approach to Providing a Seamless End-User Experience for Location-Aware Applications, IBM, 2001. [13] Christian Bettstetter and Christoph Renner. A comparison of service discovery protocols and implementation of the Service Location Protocol, Technische Universität München. [14] Choonhwa Lee and Sumi Helal. Protocols for service discovery in dynamic and mobile networks, University of Florida, International Journal of Computer Research, Volume 11, Number 1, pp. 1-12. [15] Robert E. McGrath. Discovery and Its Discontents: Discovery Protocols for Ubiquitous Computing, National Center for Supercomputing Applications, Department of Computer Science, University of Illinois, Urbana-Champaign. [16] Golden G. Richard III. Service Advisement and Discovery: Enabling Universal Device Cooperation, University of New Orleans, Internet Computing, September, 2000.