SBRC MC

XXIX Simpsio Brasileiro de Redes de Computadores e Sistemas Distribudos 30 de maio a 3 de junho de 2011 Campo Grande, MS
Minicursos Livro Texto
Editora Sociedade Brasileira de Computao (SBC) Organizadores Fabola Gonalves Pereira Greve (UFBA) Ronaldo Alves Ferreira (UFMS) Realizao Faculdade de Computao Universidade Federal de Mato Grosso do Sul (UFMS) Promoo Sociedade Brasileira de Computao (SBC) Laboratrio Nacional de Redes de Computadores (LARC)
ii
Minicurso Livro Texto
Copyright 2011 da Sociedade Brasileira de Computao Todos os direitos reservados
Capa: Venise Melo Produo Editorial: Fabola Greve, Lucilene Vilela Gonalves, Ronaldo Alves Ferreira
Cpias Adicionais: Sociedade Brasileira de Computao (SBC) Av. Bento Gonalves, 9500 Setor 4 Prdio 43.412 Sala 219 Bairro Agronomia CEP 91.509-900 Porto Alegre RS Fone: (51) 3308-6835 E-mail: sbc@sbc.org.br
Dados Internacionais de Catalogao na Publicao (CIP) Simpsio Brasileiro de Redes de Computadores e Sistemas Distribudos (29.: 2011 : Campo Grande, MS). Minicursos / XXIX Simpsio Brasileiro de Redes de Computadores e Sistemas Distribudos ; organizadores Fabola Gonalves Pereira Greve, Ronaldo Alves Ferreira. Porto Alegre : SBC, c2011. 240 p. ISSN 2177-4978 1. Redes de computadores. 2. Sistemas distribudos. I. Greve, Fabola Gonalves Pereira. II. Ferreira, Ronaldo Alves. III. Ttulo.
XXIX Simpsio Brasileiro de Redes de Computadores e Sistemas Distribudos - SBRC 2011
iii
Promoo
Sociedade Brasileira de Computao (SBC) Diretoria
Presidente Jos Carlos Maldonado (USP) Vice-Presidente Marcelo Walter (UFRGS) Diretor Administrativo Luciano Paschoal Gaspary (UFRGS) Diretor de Finanas Paulo Cesar Masiero (USP) Diretor de Eventos e Comisses Especiais Lisandro Zambenedetti Granville (UFRGS) Diretora de Educao Mirella Moura Moro (UFMG) Diretora de Publicaes Karin Breitman (PUC-Rio) Diretora de Planejamento e Programas Especiais Ana Carolina Salgado (UFPE) Diretora de Secretarias Regionais Thais Vasconcelos Batista (UFRN) Diretor de Divulgao e Marketing Altigran Soares da Silva (UFAM) Diretor de Regulamentao da Profisso Ricardo de Oliveira Anido (UNICAMP) Diretor de Eventos Especiais Carlos Eduardo Ferreira (USP) Diretor de Cooperao com Sociedades Cientficas Marcelo Walter (UFRGS)
iv
Promoo
Conselho
Mandato 2009-2013 Virglio Almeida (UFMG) Flvio Rech Wagner (UFRGS) Silvio Romero de Lemos Meira (UFPE) Itana Maria de Souza Gimenes (UEM) Jacques Wainer (UNICAMP) Mandato 2007-2011 Cludia Maria Bauzer Medeiros (UNICAMP) Roberto da Silva Bigonha (UFMG) Cludio Leonardo Lucchesi (UFMS) Daltro Jos Nunes (UFRGS) Andr Ponce de Leon F. de Carvalho (USP) Suplentes Mandato 2009-2011 Geraldo B. Xexeo (UFRJ) Taisy Silva Weber (UFRGS) Marta Lima de Queiroz Mattoso (UFRJ) Raul Sidnei Wazlawick (PUCRS) Renata Vieira (PUCRS)
Laboratrio Nacional de Redes de Computadores (LARC)

Diretoria Diretor do Conselho Tcnico-Cientfico Artur Ziviani (LNCC) Diretor Executivo Clio Vinicius Neves de Albuquerque (UFF) Vice-Diretora do Conselho Tcnico-Cientfico Flvia Coimbra Delicato (UFRN) Vice-Diretor Executivo Luciano Paschoal Gaspary (UFRGS) Membros Institucionais CEFET-CE, CEFET-PR, IME, INPE/MCT, LNCC, PUCPR, PUC-RIO, SESU/MEC, UECEM UERJ, UFAM, UFBA, UFC, UFCG, UFES, UFF, UFMG, UFMS, UFPA, UFPB, UFPE, UFPR, UFRGS, UFRJ, UFRN, UFSC, UFSCAR, UNICAMP, UNIFACS, USP
Realizao
Comit de Organizao
Coordenao Geral Ronaldo Alves Ferreira (UFMS) Coordenao do Comit de Programa Artur Ziviani (LNCC) Bruno Schulze (LNCC) Coordenao de Palestras e Tutoriais Nelson Luis Saldanha da Fonseca (UNICAMP) Coordenao de Painis e Debates Jos Augusto Suruagy Monteiro (UNIFACS) Coordenao de Minicursos Fabola Gonalves Pereira Greve (UFBA) Coordenao de Workshops Fbio Moreira Costa (UFG) Coordenao do Salo de Ferramentas Luis Carlos Erpen De Bona (UFPR) Comit Consultivo Antnio Jorge Gomes Abelm (UFPA) Carlos Andr Guimares Ferraz (UFPE) Francisco Vilar Brasileiro (UFCG) Lisandro Zambenedetti Granville (UFRGS) Luci Pirmez (UFRJ) Luciano Paschoal Gaspary (UFRGS) Marinho Pilla Barcellos (UFRGS) Paulo Andr da Silva Gonalves (UFPE) Thais Vasconcelos Batista (UFRN)
vi
Realizao
Organizao Local Brivaldo Alves da Silva Jr. (UFMS) Edson Norberto Cceres (UFMS) Eduardo Carlos Souza Martins (UFMS/POP-MS) Hana Karina Sales Rubinstejn (UFMS) Irineu Sotoma (UFMS) Ktia Mara Frana (UFMS) Luciano Gonda (UFMS) Lucilene Vilela Gonalves (POP-MS) Mrcio Aparecido Incio da Silva (UFMS) Marcos Paulo Moro (UFGD) Massashi Emilson Oshiro (POP-MS) Nalvo Franco de Almeida Jr. (UFMS) Pricles Christian Moraes Lopes (UFMS) Renato Porfrio Ishii (UFMS)
vii
Mensagem do Coordenador Geral

Sejam bem-vindos ao XXIX Simpsio Brasileiro de Redes de Computadores e Sistemas Distribudos (SBRC 2011) em Campo Grande, MS. um prazer e uma distino organizar um simpsio de tamanha relevncia para a computao no Brasil, mais ainda por ser a primeira vez que a Regio Centro-Oeste tem o privilgio de sedi-lo. O SBRC um evento anual promovido pela Sociedade Brasileira de Computao (SBC) e pelo Laboratrio Nacional de Redes de Computadores (LARC). Ao longo dos seus quase trinta anos, o SBRC tornou-se o mais importante evento cientfico nacional em Redes de Computadores e Sistemas Distribudos e um dos maiores da rea de Informtica no pas. O SBRC 2011 est com uma programao bastante rica, de qualidade diferenciada e que consiste em: 18 sesses tcnicas de artigos completos que abordam o que h de mais novo nas reas de redes de computadores e sistemas distribudos; trs sesses tcnicas para apresentao de ferramentas selecionadas para o Salo de Ferramentas; cinco minicursos, com quatro horas de durao, sobre temas atuais; trs palestras e t rs tutoriais com pesquisadores de alto prestgio internacional; e trs painis sobre assuntos de interesse da comunidade. Alm dessas j tradicionais atividades do simpsio, ocorrero em paralelo oito workshops: XVI Workshop de Gerncia e Operao de Redes e Servios (WGRS), XII Workshop da Rede Nacional de Ensino e Pesquisa (WRNP), XII Workshop de Testes e Tolerncia a F alhas (WTF), IX Workshop em Clouds, Grids e Aplicaes (WCGA), VII Workshop de Redes Dinmicas e Sistemas P2P (WP2P), II Workshop de Pesquisa Experimental da Internet do Futuro (WPEIF), I Workshop on A utonomic Distributed Systems (WoSIDA) e I Workshop de Redes de Acesso em Banda Larga. O desafio de organizar um evento como o SBRC s pode ser cumprido com a ajuda de um grupo especial. Eu tive a f elicidade de contar com a co laborao de inmeras pessoas ao longo desta jornada. Meus sinceros agradecimentos aos membros dos Comits de Organizao Geral e Local por realizarem um trabalho de excelente qualidade e com muita eficincia, a qualidade da programao deste simpsio fruto do trabalho dedicado dessas pessoas. Sou grato a Faculdade de Computao da UFMS por ter sido uma facilitadora ao longo de todo o pr ocesso de organizao, desde a nossa proposta inicial at o f echamento da programao. Gostaria de agradecer, tambm, ao Comit Gestor da Internet no Brasil (CGI.br), s agncias governamentais de fomento e aos patrocinadores por reconhecerem a importncia do S BRC e investirem recursos financeiros fundamentais para a realizao do evento. Com o apoio financeiro recebido, foi possvel manter os custos de inscrio baixos e oferecer um programa social de alta qualidade. Em nome do Comit Organizador, agradeo a todos os participantes pela presena em mais esta edio do SBRC e d esejo uma semana produtiva, agradvel e com estabelecimento de novas parcerias e amizades. Ronaldo Alves Ferreira Coordenador Geral do SBRC 2011
viii
Mensagem da Coordenadora de Minicursos

um grande prazer introduzir os minicursos que sero apresentados nessa 29a. edio do Simpsio Brasileiro de Redes de Computadores e Sistemas Distribudos. Ao longo dos anos, os minicursos vm se configurando como uma excelente fonte de divulgao de resultados de pesquisa em temas atuais, de grande relevncia e n o cobertos pelas grades curriculares. Cada minicurso compe um captulo deste livro e est estruturado para ser apresentado durante o evento em cerca de quatro horas. Para esta edio, foram escolhidas 5 e xcelentes propostas, dentre 31 s ubmetidas, configurando uma taxa de aceitao de cerca de 16%. Cada proposta obteve entre 3 e 4 avaliaes feitas por um Comit de Avaliao criterioso composto por 26 pe squisadores especialistas nas diversas reas de redes e sistemas distribudos. Os minicursos selecionados para essa 29a. edio tm temtica bastante atual e em sua maioria abordam questes relativas prxima gerao de infraestrutura e servios para a Internet do futuro. Sabe-se que num futuro prximo, a Internet estar conectando os mais variados tipos de dispositivos e objetos e em quantidades inimaginveis. Ela ser omnipresente e universal. As redes devero se auto configurar de forma a at ender de maneira eficaz, permanente, segura e co nfivel as demandas de servios dos mais variados graus por comunidades que se auto organizam no tempo e no espao. Mais do nunca os aspectos de confiana no f uncionamento dos sistemas precisaro ser assegurados. Novos mecanismos de identicao de objetos, distribuio de contedo e buscas, inclusive semnticas, alm da oferta de recursos sob demanda, sero necessrios. Esses requisitos, dentre outros, formam o objeto de estudo dos captulos a seguir. O Captulo 1 a borda tcnicas de virtualizao de redes, considerando o padro de comunicao OpenFlow. Seu foco so as redes experimentais como laboratrio para as solues e desafios enfrentados na implementao dos novos protocolos, arquiteturas e servios da Internet do futuro. O captulo apresenta recentes experincias na rea tanto no Brasil como Exterior, uma descrio do arcabouo OpenFlow e aspectos de virtualizao, alm de requisitos, mecanismos de configurao e t estes para as redes experimentais. O Captulo 2 introduz as redes sociais on-line. As redes sociais so um extraordinrio testemunho e acelerador de movimentos sociais e sobretudo um formidvel vetor de democracia. Para tanto, permitem com que usurios criem e manipulem contedo de maneira ad-hoc e quase irrestrita. Tudo isso suscita o emprego de novas tcnicas para a manipulao de grande volume de dados e para o de senvolvimento de sistemas de distribuio de contedo confiveis e seguros, alm de novas formas de organizao, uso e busca de contedo, particularmente de minerao de dados. Elas introduzem novos padres de trfego na Internet e vrias alternativas de interao humanocomputador. O captulo faz uma breve apresentao das redes existentes, discute suas principais caractersticas, as diferentes abordagens de coleta e extrao de dados, alm de importantes mtricas e tipos de anlises utilizadas no estudo dos grafos que modelam essas redes.
ix
Web das coisas o t ema do C aptulo 3. A Internet das coisas abre a perspectiva de integrar objetos inteligentes que permeiam o nosso cotidiano (computadores ou dispositivos embarcados) Internet. A Web das coisas (WoT) prope a interligao dos diversos objetos via padres Web, de maneira a facilitar o seu uso e a sua integrao s inmeras aplicaes existentes na Web. O captulo introduz os conceitos e tecnologias da WoT, uma arquitetura de software com descrio do pr ojeto de implementao de seus componentes, bem como exemplos prticos de construo de aplicaes baseadas no paradigma da WoT. O Captulo 4 tem como preocupao a gerncia de identidades de usurios na Internet do futuro. A segurana uma preocupao maior no pr ojeto dos sistemas modernos. Fatores como o alto dinamismo, o e cletismo, a mobilidade, o anonimato, a extensibilidade e a es cassez de recursos tornam os ambientes atuais extremamente vulnerveis e sujeitos a variados ataques de agentes maliciosos. A gesto de identidades possibilita o c ontrole do pe rfil dos usurios e das suas relaes de confiana, define polticas de acesso e f az uso de mecanismos de autenticao para a o ferta segura de servios na rede. O captulo apresenta os principais desafios, descreve tcnicas adequadas, bem como os dispositivos especficos e arquiteturas existentes para a implementao da gerncia de identidades no novo modelo computacional introduzido pela Internet do futuro. O Captulo 5 discute a questo de alocao de recursos na Computao em Nuvem. Este novo paradigma permite com que um grande volume de recursos disponveis na Internet tenha utilizao imediata e s ob demanda, viabilizando assim a o ferta de servios, processos, dispositivos e infra-estrutura de maneira universal e ilimitada. O processo de alocao de recursos nesse contexto fundamental para o provimento dos mesmos. Ele deve ser dinmico e permitir com que os requisitos do conjunto de aplicaes possam ser atendidos. O captulo define e apresenta as tecnologias essenciais da computao em nuvem, com foco nos desafios e solues para a alocao de recursos. Gostaria de expressar os meus sinceros agradecimentos ao Ronaldo Alves Ferreira da UFMS, coordenador do SBRC 2011, pela confiana, presteza e apoio recebido ao longo das nossas interaes. Um grande agradecimento a todos os membros do Comit de Avaliao pelas timas intervenes, reatividade e boas discusses que contriburam para termos uma seleo criteriosa e construtiva. Meu agradecimento especial aos autores que, mais uma vez, prestigiaram a trilha de minicursos do SBRC, encaminhando propostas maduras e bem delineadas, que refletem a qualidade dos resultados das suas pesquisas. Fabola Gonalves Pereira Greve Coordenadora de Minicursos do SBRC 2011
Comit de Avaliao de Minicursos

Alfredo Goldman vel Lejbman (USP) Alysson Bessani (Universidade de Lisboa) Antnio Jorge Gomes Abelm (UFPA) Carlos Alberto Kamienski (UFABC) Carlos Montez (UFSC) Daniel Moss (University of Pittsburg) Eduardo Nakamura (UFAM) Elias Procpio Duarte Jr. (UFRP) Fabola Gonalves Pereira Greve (UFBA) Francisco Brasileiro (UFCG) Genaro Costa (UFBA) Hana Karina Salles Rubinsztejn (UFMS) Jos Marcos Nogueira (UFMG) Jussara Almeida (UFMG) Luci Pirmez (UFRJ) Lucia Drummond (UFF) Luciano Paschoal Gaspary (UFRGS) Luis Carlos De Bona (UFPR) Luiz Eduardo Buzato (UNICAMP) Marcelo Dias de Amorim (LIP6/CNRS) Marinho Barcellos (UFRGS) Nabor Mendona (UNIFOR) Noemi Rodriguez (PUC-Rio) Paulo Andr da Silva Gonalves (UFPE) Regina Arajo (UFSCar) Thais Vasconcelos Batista (UFRN)
xi
Sumrio
Captulo 1 Pesquisa Experimental para a Internet do Futuro: Uma Proposta Utilizando Virtualizao e o Framework OpenFlow ............... 1
1.1 Introduo .......................................................................................................... 3 1.2 Pesquisa Experimental em Internet do Futuro no Brasil e no Mundo ............... 6 1.2.1 Desafios Relacionados Internet do Futuro ........................................... 6 1.2.2 Iniciativas para Investigao em Internet do Futuro ............................. 11 1.2.2.1 GENI (Global Environment For Network Inovation) ............. 12 1.2.2.2 Future Internet Research and Experimentation (FIRE) ........... 16 1.2.2.3 Iniciativas Brasileiras .............................................................. 18 1.3 OpenFlow e Virtualizao ............................................................................... 19 1.3.1 O OpenFlow .......................................................................................... 19 1.3.1.1 Aplicaes ............................................................................... 20 1.3.1.2 Modos de Funcionamento dos Switch ..................................... 21 1.3.1.3 Controle Usando NOX ............................................................ 23 1.3.2 Virtualizao ......................................................................................... 25 1.3.2.1 Virtualizao de Sistemas........................................................ 26 1.3.2.2 Virtualizao de Redes ............................................................ 29 1.3.2.3 Redes de Sobreposio (Overlay)............................................ 31 1.3.2.4 Virtualizao de Rede com OpenFlow .................................... 32 1.4 Requisitos para Construo de um Ambiente para Experimento e Virtualizao de Redes ........................................................................................... 34 1.4.1 Tipos de Hardwares .............................................................................. 35 1.4.2 Arcabouos de Controle ........................................................................ 36 1.4.3 Monitorao e Medio ........................................................................ 37 1.4.4 Ferramentas para Gerncia de Virtualizao ........................................ 39 1.5 Estudo de Caso ................................................................................................ 42 1.5.1 Definio do Ambiente ......................................................................... 42 1.5.1.1 Dados de Implementao do Ambiente ................................... 42 1.5.1.2 Plano de Dados ........................................................................ 44 1.5.1.3 Plano de Controle .................................................................... 45 1.5.2 Aplicao Prtica .................................................................................. 46 1.5.3 Concluso .............................................................................................. 53 1.6 Consideraes Finais e o Futuro em Pesquisa Experimental em Internet do Futuro ..................................................................................................................... 53 1.6.1 Consideraes Finais............................................................................. 53 1.6.2 Tendncias Futuras ............................................................................... 54 Referncias ............................................................................................................. 55
xii
Captulo 2 Explorando Redes Sociais Online: Da Coleta e Anlise de Grandes Bases de Dados s Aplicaes .................................................... 63
2.1 Introduo ........................................................................................................ 64 2.2 Definies e Caractersticas de Redes Sociais Online..................................... 66 2.2.1 Definio ............................................................................................... 66 2.2.2 Elementos das Redes Sociais Online ..................................................... 67 2.3 Teoria de Redes Complexas ............................................................................ 69 2.3.1 Mtricas para o Estudo de Redes Complexas ....................................... 69 2.3.1.1 Grau dos Vrtices .................................................................... 69 2.3.1.2 Coeficiente de Agrupamento ................................................... 70 2.3.1.3 Componentes ........................................................................... 71 2.3.1.4 Distncia Mdia e Dimetro .................................................... 72 2.3.1.5 Assortatividade ........................................................................ 72 2.3.1.6 Betweenness ............................................................................. 72 2.3.1.7 Reciprocidade .......................................................................... 73 2.3.1.8 PageRank ................................................................................. 73 2.3.2 Redes Small-World ............................................................................... 74 2.3.3 Redes Power-Law e Livres de Escala ................................................... 74 2.4 Tcnicas de Coleta de Dados ........................................................................... 75 2.4.1 Dados dos Usurios ............................................................................... 75 2.4.2 Dados de Pontos Intermedirios ........................................................... 76 2.4.2.1 Servidores Proxy ..................................................................... 76 2.4.2.2 Agregadores de Redes Sociais ................................................. 77 2.4.3 Dados de Servidores de Redes Sociais Online...................................... 78 2.4.3.1 Coleta por Amostragem ........................................................... 79 2.4.3.2 Coleta em Larga Escala ........................................................... 81 2.4.3.3 Coleta por Inspeo de Identificadores ................................... 81 2.4.3.4 Coleta em Tempo Real ............................................................ 83 2.4.3.5 Utilizando APIs ....................................................................... 83 2.4.3.6 Ferramentas e Bibliotecas ........................................................ 84 2.4.3.7 tica dos Coletores .................................................................. 85 2.4.4 Dados de Aplicaes ............................................................................. 87 2.5 Extrao de Informao ................................................................................... 88 2.5.1 Viso Geral ........................................................................................... 88 2.5.2 Identificao de Entidades .................................................................... 91 2.5.3 Resoluo de Entidades ........................................................................ 91 2.6 Bases de Dados Disponveis na Web .............................................................. 93 2.7 Concluses ....................................................................................................... 93 Referncias ............................................................................................................. 94
xiii
Captulo 3 Web das Coisas: Conectando Dispositivos Fsicos ao Mundo Digital ........................................................................................... 103
3.1 Introduo ...................................................................................................... 104 3.2 Da Internet das Coisas a Web das Coisas ...................................................... 105 3.2.1 Internet das Coisas .............................................................................. 105 3.2.2 Web das Coisas ................................................................................... 107 3.3 Concretizando a Web das Coisas: REST & ROA ......................................... 110 3.3.1 REST ................................................................................................... 110 3.3.1.1 Princpios REST .................................................................... 110 3.3.2 ROA .................................................................................................... 113 3.3.2.1 URIs ....................................................................................... 113 3.3.2.2 Endereabilidade ................................................................... 114 3.3.2.3 Sem Estado ............................................................................ 114 3.3.2.4 Representao ........................................................................ 115 3.3.2.5 Links e Conectividade ........................................................... 115 3.3.2.6 Interface Uniforme ................................................................ 115 3.3.3 Desenvolvimento de Servios RESTful .............................................. 116 3.3.3.1 Requisitos do Servio Web de Exemplo ............................... 117 3.3.3.2 Identificao de Recursos ...................................................... 118 3.3.3.3 Representao de Recursos ................................................... 118 3.3.3.4 Definio de URI ................................................................... 121 3.3.4 Descritor WADL ................................................................................. 123 3.3.5 REST versus WS-* SOAP .................................................................. 124 3.4 Estendendo ROA para a Web das Coisas ...................................................... 126 3.4.1 Comunicao Orientada a Eventos ..................................................... 128 3.5 Web das Coisas: Desenvolvendo Aplicaes na Plataforma Sun SPOT....... 129 3.5.1 Introduo a Plataforma Sun SPOT .................................................... 129 3.5.2 Integrao de Dispositivos na Web ..................................................... 131 3.5.2.1 Tcnica de Implementao de Servidores Web em Dispositivos Embarcados ........................................................................................ 132 3.5.2.2 Implementao de Gateways ................................................. 138 3.5.2.3 Exposio de Dispositivos como Recursos REST ................ 142 3.5.2.4 Representao de Estado ....................................................... 142 3.5.3 Tcnicas de Implementao de Mashups Fsicos ............................... 143 3.6 Concluso ...................................................................................................... 145 Referncias ........................................................................................................... 146
xiv
Captulo 4 Gerncia de Identidade na Internet do Futuro ............... 151

4.1 Introduo ...................................................................................................... 152 4.2 Internet do Futuro .......................................................................................... 155 4.2.1 Exemplos de Servios da Internet do Futuro ...................................... 157 4.2.2 Redes da Prxima Gerao ................................................................. 159 4.3 Gerncia de Identidade .................................................................................. 161 4.3.1 Entidade, Identidade e Credencial ...................................................... 162 4.3.2 Ciclo de Vida ...................................................................................... 165 4.3.3 Sigle Sign-On ...................................................................................... 167 4.3.4 Usurios, Provedores de Identidade e Provedores de Servios .......... 167 4.4 Requisitos de um Sistema de Gesto de Identidade na Internet do Futuro ... 169 4.5 Iniciativas de Gerncia de Identidade para as Redes da Prxima Gerao ... 174 4.5.1 Projetos e Arquiteturas ........................................................................ 174 4.5.2 Alianas ............................................................................................... 181 4.5.3 Especificaes Consolidadas .............................................................. 182 4.6 Ferramentas e Tecnologias para Gerncia de Identidade .............................. 184 4.6.1 Cartes Inteligentes (Smart Cards) ..................................................... 185 4.6.2 Biometria ............................................................................................. 188 4.7 Concluses ..................................................................................................... 189 Referncias ........................................................................................................... 191
Captulo 5 Resource Allocation in Clouds: Concepts, Tools and Research Challenges ................................................................................ 197
5.1 Introduction ................................................................................................... 198 5.1.1 The Emergence of Cloud Computing ................................................. 198 5.1.2 The Value of Cloud for Business ........................................................ 199 5.1.3 The Value of Cloud Academy ............................................................ 200 5.1.4 Structure of the Short Course .............................................................. 201 5.2 What is Cloud Computing? ........................................................................... 201 5.2.1 Definitions ........................................................................................... 201 5.2.2 Agents Involved in Cloud Computing ................................................ 203 5.2.3 Classification of Cloud Operators ....................................................... 204 5.2.4 Mediation System ............................................................................... 207 5.2.5 Groundwork Technologies .................................................................. 208 5.3 Open Research Problems ............................................................................... 211 5.3.1 Challenges in the Negotiation Layer ................................................... 211 5.3.2 Challenges in the Resource Management and Resource Control Layers.... ........................................................................................................ 213 5.4 Resource Allocation ...................................................................................... 214 5.4.1 Definitions for Resource Allocation ................................................... 215
xv
5.4.2 Research Challenges in Resource Allocation ..................................... 216 5.4.3 Solutions.............................................................................................. 222 5.5 Open-Source Mediation Systems .................................................................. 226 5.5.1 Eucalyptus ........................................................................................... 226 5.5.2 OpenNebula ........................................................................................ 228 5.5.3 Nimbus ................................................................................................ 231 5.5.4 Comparisons........................................................................................ 233 5.6 Final Considerations ...................................................................................... 234 5.6.1 Review of the Matter........................................................................... 235 5.6.2 Future Trends ...................................................................................... 235 Referncias ........................................................................................................... 236
Captulo
1
Pesquisa Experimental para a Internet do Futuro: Uma Proposta Utilizando Virtualizao e o Framework Openow
Fernando N. N. Farias, Jos M. Dias Jnior, Joo J. Salvatti, Srgio Silva, Antnio J. G. Abelm, Marcos R. Salvador and Michael A. Stanton
Abstract The Internet has become a huge worldwide success and is changing the way we interact, work, and amuse ourselves. Much of its success is due to the great exibility of IP (Internet Protocol) technology. Despite all the success of the Internet, IP core technology is the cause of its own limitations, which become increasingly more evident. The main goals of activities labeled as Future Internet (FI) are the formulation and evaluation of alternative architectures to substitute IP. In this context, two approaches are being discussed and investigated, where the rst, called Clean Slate, aims at replacing the current architecture by a new fully rebuilt one, and the second, called Evolutionary, that intends to evolve the current architecture without losing compatibility with the current one. However, the biggest challenge now is where to enable and test the proposed approaches in order to validate efciently them without sacricing the current infrastructure, since there will be the need for routers and switches to be recongured, and resources to be allocated and monitored. Thus, the network must be as exible as possible so that this infrastructure allows the coexistence of multiple parallel models. In this sense, virtualization (of network devices, links, etc.) and the OpenFlow solution are being seen as the best alternatives to enable multiple experiments of new architectures in a production environment. An OpenFlow network allows the programming of network behavior, in addition to creating virtual network environments called slices (virtual networks with nodes, links and resources) to test new protocol models. This short course will be essentially theoretical and starts by presenting the motivation that is leading professionals and the academic community to
invest in research to investigate the challenges of the Future Internet. Next, recent experiments carried out for the Future Internet in Brazil and in research networks in Europe, North America, and Asia will be presented. After that, the OpenFlow framework will be detailed, including the main aspects of virtualization. We also describe the requirements for construction of an experimental testbed, including demonstration and details of the mechanisms needed to congure and evaluate such a test environment. A case study of creating multiple slices for testing networking protocols will be shown. Finally, future trends will be presented regarding the experimental research and the Future Internet.
Resumo
A Internet um enorme sucesso mundial e vem mudando a forma como interagimos, trabalhamos e nos divertimos. Boa parte deste sucesso se deve grande exibilidade da tecnologia IP. Apesar de todo o sucesso da Internet, a tecnologia bsica IP a causa das suas prprias limitaes que se tornam cada vez mais evidentes. Um dos principais objetivos da atividade conhecida como Internet do Futuro (IF) a formulao e avaliao de arquiteturas alternativas para substituir o protocolo IP. Nesse contexto, duas abordagens esto sendo discutidas e investigadas: a primeira denominada limpa (Clean Slate), que visa substituir a arquitetura atual por uma nova totalmente reconstruda, e a outra chamada evolucionria (Evolutionary) que pretende evoluir a arquitetura atual sem perder a compatibilidade com a anterior. No entanto, o maior desao agora onde habilitar e testar as propostas das respectivas abordagens de modo a valid-las ecientemente, sem prejudicar a infraestrutura atual, j que haver a necessidade de que roteadores e switches sejam recongurados, e recursos sejam alocados e monitorados. Em suma, a rede deve ser a mais exvel possvel, para que essa infraestrutura permita a coexistncia de mltiplos modelos paralelos. Nesse sentido, a virtualizao (de rede, dispositivos, enlace e etc.) e a soluo OpenFlow vem se tornando uma interessante alternativa para habilitar mltiplos experimentos com novas arquiteturas em um ambiente de produo. Uma rede OpenFlow admite a programao do comportamento da rede, alm da criao de ambientes de rede virtuais chamados fatias (redes virtuais com ns, enlaces e recursos) para testar novos modelos de protocolo. Este minicurso tem como principal objetivo apresentar os desaos e solues para se criar um ambiente de testes para a Internet do Futuro utilizando tcnicas de virtualizao de redes e o framework OpenFlow. O minicurso ser essencialmente terico e apresentar os fatores motivacionais que vm levando os prossionais da rea e a comunidade acadmica a investirem na realizao de pesquisa experimental para investigar os desaos da Internet do Futuro. Em seguida, sero expostas as recentes experincias realizadas para IF, tanto no Brasil como em backbones da Europa, da Amrica do Norte e da sia. Aps isso, ser detalhado o arcabouo OpenFlow, incluindo os principais aspectos sobre virtualizao. Logo depois, sero descritos os requisitos para construo de uma rede para experimentao, com a demonstrao e o detalhamento dos mecanismos necessrios para congurar e testar esse ambiente. Um estudo de caso de criao de vrias fatias de redes para testes de protocolos tambm ser demonstrado. Por m, sero apresentadas as tendncias futuras em relao pesquisa experimental em Internet do Futuro.
1.1. Introduo
A Internet hoje est sendo usada para uma grande variedade de propsitos comerciais e no comerciais. Para muitas pessoas uma ferramenta de trabalho crucial, para outras, seu local de trabalho. Porm, para a grande maioria, um eciente meio de comunicao, entretenimento ou plataforma educacional. Ou seja, a Internet um enorme sucesso mundial e vem mudando a forma como interagimos, trabalhamos e nos divertimos. Boa parte deste sucesso se deve grande exibilidade da tecnologia IP (Internet Protocol), que prov um mecanismo uniforme de transporte m a m, independente das tecnologias utilizadas nas camadas de mais baixo nvel. Apesar de todo o sucesso da Internet, a tecnologia bsica IP a causa das suas prprias limitaes, que se tornam cada vez mais evidentes. A noo central de tamanho nico, que requer tratamento idntico para todos os uxos de informao na Internet ao nvel do pacote IP, no desejvel e nem necessariamente econmica, especialmente quando certas classes de aplicao, tais como de mdia interativa ou de acesso remoto a instrumentos cientcos que, requerem garantias de qualidade de servio (Quality of Service - QoS) desnecessrias para a maioria de outras aplicaes. A atual arquitetura da Internet, inicialmente projetada h aproximadamente 30 anos, sofreu muitas extenses nos anos recentes para incluir novas funcionalidades, as quais no foram previstas no projeto inicial. Muitos especialistas de rede agora consideram que necessrio conduzir um estudo de arquiteturas alternativas para Internet do Futuro (IF), como uma maneira realmente eciente de resolver muitos dos problemas prementes que atualmente aigem a Internet. Algumas das desvantagens da continuada persistncia no uso da atual arquitetura incluem: Exausto j anunciada do espao atualmente disponvel de identicadores de rede IP verso 4 (IPv4), causando uma balcanizao da Internet, sem verdadeira conectividade global; Custos elevados dos roteadores IP, restringindo o crescimento da rede, motivado principalmente pela natureza no escalonvel das tabelas de roteamento, e dos requisitos de desempenho necessrios para poder processar essas gigantescas tabelas na mesma velocidade que seus enlaces; Investimentos imensos em medidas paliativas para conter problemas de segurana atualmente causados por spam, negao de servio (DoS - denial of service) e crimes de roubo de informao; Diculdades de combinar transparncia de acesso e desempenho de aplicao para usurios mveis. Devido a isso, nos ltimos anos, vm sendo aplicadas arquitetura da Internet uma srie de modicaes pontuais ou remendos, para atender s limitaes encontradas. Entre os remendos mais conhecidos, podem ser mencionados Classless Internet Domain Routing (CIDR), Network Address Translation (NAT), Servios Integrados (Intserv), Servios Diferenciados (Diffserv), IP Seguro, IP Mvel, rewalls e ltros de spam; estes so os mais conhecidos.
Por conta disso, h um entendimento crescente entre os pesquisadores em redes de computadores que solues para a maioria destes problemas, dependero de um redesenho fundamental da atual arquitetura da Internet, baseada em IP. E como aliada na busca dessas solues, surge a atividade conhecida como Internet do Futuro, que inclui entre seus principais objetivos a formulao e avaliao de arquiteturas alternativas para substituir o IP, o qual frequentemente ilustrado pelo conhecido modelo da ampulheta da Internet, apresentado na Figura 1.1.
Figura 1.1. A evoluo do conceito da Internet [Banniza et al. 2009]
Nesse contexto, duas abordagens esto sendo discutidas e investigadas. A primeira denominada limpa (Clean Slate), que visa substituir a arquitetura atual por uma nova totalmente reconstruda. A outra, chamada evolucionria (Evolutionary), que pretende evoluir a arquitetura atual sem perder a compatibilidade com a anterior. A proposta Clean Slate, que atualmente um dos esforos para o desenvolvimento da Internet do Futuro, tem como principal objetivo direcionar como ser efetuado o desenho da nova Internet [McKeown 2011]. Mas para que isso ocorra, a IF deve atender a um conjunto de requisitos importantes. Dentro desse contexto, David Clark [Clack 2011] cita os caminhos e os requisitos fundamentais para o sucesso desta nova arquitetura, proposta que Clean Slate ir tomar para projetar a IF. Dentre esses requisitos, possvel destacar como os principais desaos: robustez e disponibilidade, suporte a ns mveis economicamente vivel e rentvel, gerenciabilidade com segurana e ser evolutiva. As pesquisas baseadas em Clean Slate permitem explorar radicalmente uma nova arquitetura para Internet, mas isso no quer dizer que sero imediatamente aplicadas. Desse modo, algumas dessas solues podem ter ou no um caminho vivel de implantao na Internet atual [Feldmann 2007]. Por outro lado, tem-se a abordagem Evolutionary ou Incremental, que tem a misso, como pesquisadores da Internet, de primeiro medir e entender o estado corrente
que se encontra a infraestrutura atual da Internet, para poder prever qual caminho ela seguir e quais problemas enfrentar. Depois, com isso, criar o que pode ser referenciado como uma inteligente mutao [Rexford and Dovrolis 2010], ou seja, inovaes que podem, primeiro, afastar ou resolver estes desaos e, segundo, adaptar-se para a corrente infraestrutura da Internet, de uma forma que seja compatvel com as verses anteriores e possa ser incrementalmente expansvel. A adoo de qualquer uma das arquiteturas alternativas pode alterar a situao em que a Internet atual se encontra. Entretanto, um srio obstculo para adoo efetiva de tais inovaes tem sido a inabilidade de valid-las de maneira convincente. A reduo no impacto do mundo real de qualquer inovao se deve enorme base instalada de equipamentos e protocolos e relutncia em experimentar com trfego de produo, o que tem criado uma barreira extremamente alta para a entrada de novas ideias. O resultado que a maior parte das novas ideias da comunidade de pesquisa de rede no testada, levando crena comumente mantida de que a infraestrutura da Internet ossicou ou enrijeceu [Paul et al. 2011]. Tendo reconhecido o problema, a comunidade de pesquisa de rede est desenvolvendo solues alternativas para pesquisa experimental em IF. Suas atividades inicias, usando redes para experimentao (testbeds), comearam nos EUA com os programas Global Environment for Network Innovations (GENI) [GENI 2011] e Future Internet Design (FIND) [FIND 2011], onde suas principais propostas so testar e amadurecer um grande conjunto de pesquisas em comunicao de dados e sistemas distribudos. Alm disso, ainda h o programa Future Internet Research and Experimentation (FIRE) na UE (Unio Europeia) [FIRE 2011] que uma iniciativa de ambiente de pesquisa para experimentao e validao de ideias inovadoras e revolucionrias para novos paradigmas de redes e servios. Nesta mesma linha, temos o projeto AKARI no Japo [AKARI 2009], um programa de pesquisa que tem como objetivo implementar a nova gerao de redes para 2015, baseada na proposta Clean Slate. E por m, iniciativas semelhantes tambm foram lanadas mais recentemente na Coreia [Liu et al. 2009] e na China [Bi 2011]. Neste sentido, redes de experimentao programveis e virtualizadas vm sendo utilizadas por esses projetos para diminuir a barreira de custo entrada de novas ideias, aumentando a taxa de inovao da infraestrutura de rede. Com isso, so oferecidas infraestruturas capazes de habilitar, controlar e testar as respectivas abordagens, de modo a valid-las ecientemente, sem prejudicar a infraestrutura atual. No contexto de redes programveis, o arcabouo OpenFlow uma soluo que vem oferecendo aos pesquisadores a possibilidade de testar seus protocolos experimentais em redes de produo como: redes de um campus, redes metropolitanas ou em um backbone de rede de ensino e pesquisa [McKeown et al. 2008]. O OpenFlow, alm de oferecer o protocolo de controle, chamado de OpenFlow protocol para manipular a tabela de encaminhamento dos roteadores e switches, tambm oferece uma API (Application Programming Interface) simples e extensvel para programar o comportamento dos uxos de pacotes. Desta forma que, atravs desta API, pesquisadores podem rapidamente construir novos protocolos e aplic-los em um ambiente de produo sem prejudic-lo.
A virtualizao de computadores tem sido usada h muito tempo e hoje est amplamente disponvel em plataformas comuns. realizada por meio do compartilhamento de processadores e dispositivos de E/S, utilizando tcnicas de fatiamento de tempo e memria virtual. A virtualizao de redes, a mais recente, conseguida pelo uso de switches, roteadores virtuais e a multiplexao de enlaces [Chowdhury and Boutaba 2010]. Observando isso, o uso das tcnicas de virtualizao de redes (dispositivos, enlace, etc.) em conjunto com a soluo OpenFlow vem se tornando uma excelente alternativa para habilitar mltiplos experimentos com novas arquiteturas em um ambiente de produo. Uma rede OpenFlow permite que se possa programar o comportamento da rede, alm de criar ambientes virtuais de rede chamados de fatias (redes virtuais com ns, enlaces e recursos) para testar novas ideias e modelos de protocolos para IF. Este minicurso tem como principal objetivo apresentar as iniciativas para o desenvolvimento da IF, seus requisitos necessrios e o uso de virtualizao e OpenFlow para se criar um ambiente de testes para experimentao e desenvolvimento de protocolos na abordagem de IF. Alm desta seo introdutria, o artigo est dividido da seguinte maneira: Seo 2 - so apresentadas as recentes experincias realizadas para Internet do Futuro, tanto no Brasil como em backbones da Europa e da Amrica do Norte; Seo 3 - detalhado o framework OpenFlow, incluindo os principais aspectos sobre virtualizao; Seo 4 - so descritos os requisitos para construo de um testbed experimental; Seo 5 - tem-se um estudo de caso de criao de vrios slices de redes para testes de protocolos; Seo 6 - so apresentadas as consideraes nais e tendncias futuras em relao pesquisa experimental e Internet do Futuro.
1.2. Pesquisa Experimental em Internet do Futuro no Brasil e no Mundo

Atualmente, na comunidade acadmica, existe um amplo consenso de que a Internet atual sofre vrias limitaes relacionadas com escalabilidade, suporte a redes mveis de vrios tipos (ad-hoc, multi-hop e mesh), mobilidade, ao consumo de energia, transparncia, segurana e outras [Jain 2006]. A partir disso, nesta seo, so levantados e comentados os principais desaos que esto relacionados Internet do Futuro. Como tambm, so observados os projetos a respeito de investigao da IF como o caso do GENI (Global Environment for Network Innovation), nanciado pela NSF (National Science Foundation), FIRE (Future Internet Research and Experimentation), pela Unio Europeia e por iniciativas brasileiras. 1.2.1. Desaos Relacionados Internet do Futuro O conceito bsico da arquitetura da Internet foi desenvolvido h mais de trinta anos atrs. Neste tempo, tem-se aprendido bastante sobre redes de computadores e encaminhamento
de pacotes. Tambm, durante este mesmo perodo, a Internet vem sofrendo contnuas adaptaes, causadas pelo seu rpido crescimento e pela quantidade de usurios e aplicaes habilitadas sobre sua arquitetura. Essas adaptaes ou remendos demonstram que o projeto inicial j no se ajusta s necessidades atuais na rede. Alm disso, a arquitetura atual da Internet j apresenta inmeros problemas ainda no solucionados, impedindo o atendimento dos requisitos destas novas aplicaes e servios. Muitos especialistas em rede de computadores chegaram a um consenso de que agora consideram extremamente importante realizar estudos de arquiteturas alternativas para Internet do Futuro como uma maneira realmente eciente de resolver muitos dos problemas prementes que atualmente aigem a Internet. A seguir, so apresentados alguns dos principais desaos, que, segundo Paul [Paul et al. 2011], a nova arquitetura da Internet deve atender. a. Suporte a Novas Tecnologias de Rede A Internet atual projetada para tirar vantagem de uma grande gama de tecnologias de comunicao em rede. No entanto, hoje h vrios desaos no horizonte, entre elas as tecnologias sem o e as novas solues pticas As redes sem o abrangem uma srie de tecnologias que vo do Wi-Fi de hoje at as ultra-widebands e redes de sensores sem o de amanh. Considera-se que as redes sem o so talvez umas das maiores tecnologias de rede e com granularidade maior ou igual s redes locais (LAN). No entanto, uma consequncia das redes sem o a mobilidade. Atualmente, a mobilidade est na borda da rede, mas, os mecanismos para torn-la mais eciente no funcionam de maneira satisfatria. Principalmente, nas questes relacionadas ecincia energtica, mudana de ponto de acesso e aplicaes. Portanto, identicam-se os seguintes desaos para suporte s tecnologias sem o: a Internet do Futuro deve suportar a mobilidade como o objetivo primordial em sua construo. Os ns devem ser capazes de modicar seu ponto de acesso na Internet e, mesmo assim, continuarem sendo alcanveis a Internet do Futuro deve oferecer meios adequados para uma aplicao de descobrir as caractersticas dos mais variados tipos de enlace de rede sem o e se adaptar a eles, de maneira a prover as ecincias energticas destes ns. a Internet do Futuro deve facilitar o processo pelo qual os ns mveis, sicamente prximos, descubram-se uns aos outros. Outra tecnologia revolucionria a rede de transporte ptica. A comunidade de pesquisadores em redes pticas est desenvolvendo maneiras de como usar as novas tecnologias como comutadores pticos e elementos lgicos para encaminhar dados com taxas de transmisso muito maiores que as redes puramente eletrnicas. Isso envolve mudanas em vrios nveis: de redes em anis para redes em malha; de redes com comprimentos de ondas xamente alocados para transmissores (e receptores) dinamicamente sintonizados; de redes sem buffers pticos para redes com planos de controles inteligentes
e com buffers pticos sucientes; e de redes pticas que utilizam larguras de bandas xas para as que permitem que a largura de banda seja dinamicamente alocada, acessada e utilizada. Logo se identicam os desaos para Internet do Futuro poder explorar a emergente capacidade ptica: a Internet do Futuro deve ser projetada para permitir aos usurios utilizarem essas novas capacidades de transporte pticos, incluindo uma melhor conabilidade atravs de diagnsticos entre camadas; a Internet do Futuro deve permitir que os ns que so dinamicamente congurveis habilitem a camada eletrnica para o acesso dinmico de usurios; a Internet do Futuro deve incluir softwares de controle e gerenciamento que permitam rede formada por ns dinamicamente recongurveis ser congurada por aplicaes que necessitem de uma grande quantidade de recursos de rede, tal como largura de banda b. Segurana e Robustez Talvez a razo que mais estimulou a comunidade acadmica a pensar em um redesenho da Internet foi a possibilidade de ter uma rede com grandes avanos na segurana e na robustez. Na Internet atual, no h nenhuma abordagem, realmente abrangente para tratar questes de segurana. Ela possui muitos mecanismos, mas no uma arquitetura segura e muito menos um conjunto de regras determinando como esses mecanismos devem ser combinados para se obter uma boa segurana de maneira geral. A segurana em redes e principalmente a da Internet, atualmente se assemelha a um conjunto crescente de remendos, extremamente suscetvel a falhas. Para construo de uma rede mais robusta e segura, identicam-se os seguintes desaos: qualquer conjunto de hosts deve ser capaz de se comunicar entre si com alta conabilidade e previsibilidade e ns maliciosos ou defeituosos no podem ser capazes de interromper esta comunicao. Alm disso, os usurios devem esperar por um nvel de disponibilidade correspondente ou que exceda o sistema de telefonia de hoje; a segurana e robustez devem ser estendidas atravs de suas camadas, pois a segurana e conabilidade de um usurio nal dependem da robustez, tanto nas camadas de comunicao quanto nas aplicaes distribudas. c. Ecincia Energtica na Comunicao Atualmente, h uma preocupao mundial [Joseph and Lewis 2008] pelo desenvolvimento de tecnologias que diminuam o consumo de energia, principalmente em redes, como as de sensores sem o e as de dispositivos mveis Wi-Fi, onde recursos energticos so fatores
relevantes em sua comunicao. Com as atuais tecnologias, comunicando um bit sobre um meio sem o, em intervalos curtos, consomem mais energia do que o seu processamento, e no possui tendncia de mudanas em um futuro prximo [Chen, 2006]. No entanto, a Internet atual no possui mecanismos que levem em considerao a comunicao com requisitos de ecincia de energia, de modo a adaptar o seu consumo mediante a observao do meio. Ou ainda, que adapte o uso de energia para oferecer uma comunicao eciente, na transmisso de dados e no gerenciamento de rede, a baixos nveis energticos. Portanto, como desao para o projeto da Internet do Futuro: deve-se prover meios para uma ecincia energtica generalizada tanto para dispositivos sem o quanto os com o; desenvolver tecnologias com o foco no uso eciente da energia eltrica; incluir em sua arquitetura mecanismos que ofeream uma comunicao eciente tanto na transmisso de dados como no gerenciamento de rede; prover uma arquitetura para Internet do Futuro energeticamente otimizada. d. Separao de Identidade e Endereo Na Internet atual, um sistema identicado pelo seu endereo IP. Como resultado, quando o sistema mudar a localizao do ponto da sua interligao, seu endereamento tambm pode mudar. Ou seja, o endereo IP, neste caso, ao mesmo tempo, tem o papel de identicador e localizador. Devido a isso, os ns mveis se tornaram um desao na Internet atual. Por essas caractersticas, torna-se difcil iniciar a comunicao com um sistema mvel. Este um problema bem conhecido na Internet e h um nmero considervel de tentativas e propostas para resolver esse problema, incluindo: mobile IP, Internet indirection infraestructure [Stoica et al. 2004], host identify protocol [Moskowitz et al. 2005] e outros [Balakrishnan et al. 2004]. Assim, para a Internet do Futuro existem os seguintes desaos: aplicar solues que permitam a localizao global de um determinado host, atravs da utilizao de um sistema de endereamento global; denir novas formas de localizao e identicao, alm do desenvolvimento de endereamentos coesos s necessidades da rede. e. Qualidade de Servio e Qualidade de Experincia A natureza do IP, no orientado a conexo, diculta qualquer aplicao de garantia de QoS (Quality of Service - qualidade de servio). Alm disso, a caracterstica de encaminhamento de pacote baseado em melhor esforo faz com que qualquer abordagem
10
relacionada a questes de reservar de recursos ou prioridade interra no funcionamento estabelecido para Internet atual. Desta maneira, embora a qualidade de servio tenha sido extremamente pesquisada na comunidade acadmica ainda no h um modelo claro de como diferentes nveis de qualidade devem ser aplicados e de que forma ele se integrar arquitetura de rede atual. Desta fora, so desaos para arquitetura da Internet do Futuro:
permitir uma variedade de garantias levando em considerao tanto a qualidade da aplicao na rede como a qualidade de experincia do usurio; novos mtodos de encaminhamentos de pacote baseados nas caractersticas das aplicaes, principalmente as de tempo real.
f. Separao entre os Planos de Controle, Gerenciamento e Dados Na Internet atual, os planos de controle, gerenciamento e dados so unicados, ou seja, mensagens de controle, por exemplo, mensagens de conexo TCP (Transmission Control Protocol) ou mensagens de gerenciamento SNMP (Simple Network Management Protocol), seguem no mesmo canal em que trafegam os dados. Como consequncia, ocorre a possibilidade de um signicante risco de segurana dos dados de controle, alm do desperdcio de recursos da rede. Uma vantagem desta separao de planos a adoo de novas tecnologias de plano de dados pela arquitetura de rede como: um comprimento de onda; quadro SDH; ou uma linha de transmisso de energia (Power Line Comunication - PLC). Logo a separao entre os planos deve ser parte integrante desta prxima gerao da arquitetura da Internet.
g. Isolamento Para algumas aplicaes crticas, o usurio demanda isolamento em um ambiente compartilhado como na Internet atual. Isolamento signica garantir que o desempenho desta aplicao crtica no seja afetado por outras aplicaes que queiram compartilhar o mesmo recurso. Com o uso da virtualizao, o isolamento se tornou um fator ainda mais importante, principalmente para virtualizao de redes, onde um roteador ou uma infraestrutura de rede totalmente virtualizada, de forma que o encaminhamento de pacotes no pode, de maneira alguma, sofrer interferncias de, ou caus-las em outras infraestruturas. Assim, a prxima gerao da Internet deve prover em sua arquitetura um modo eciente de prover uma combinao programvel de isolamento e compartilhamento s suas aplicaes e servios.
11
h. Mobilidade Com a crescente e diversicada quantidade de servios na Internet, impulsionada principalmente pelo aumento do acesso de dispositivos sem o. Amplia-se a necessidade de mobilidade pelos usurios. Com isso, a forma de comunicao estabelecida originalmente pela arquitetura da Internet atual como conexo ponto-a-ponto e entrega imediata, faz com que esses tipos de usurios no sejam atendidos satisfatoriamente. Principalmente, por causa de uma questo comum relacionada mobilidade, que so os handovers, criados com o objetivo de evitar que os ns mveis tenham a perda das suas conexes ativas. Os protocolos da Internet atual no prevem o tratamento desse comportamento. E ainda, protocolos como TCP tambm so prejudicados por no prever esse tipo de usurio. Com isso, a Internet do Futuro enfrenta o grande desao de como permitir a movimentao do n entre diferentes pontos de acesso sem que as conexes ativas sejam perdidas.
i. Escalabilidade Com o aumento exponencial do nmero de estaes ou sistemas conectados Internet, alguns componentes da arquitetura atual tm sofrido com problemas de escalabilidade. Esse o caso do sistema de roteamento, que sofre com o aumento e as atualizaes frequentes de suas tabelas. Ainda h a questo dos endereamentos que no so capazes de suportar todos os elementos conectados rede, como o caso do IPv4. Portanto, a Internet do Futuro ter o desao de manter o sistema global de roteamento escalvel, alm de novos protocolos que mantenham essa escalabilidade, mesmo com o aumento do espao de endereamento. E tambm novas formas de endereamento para evitar a escassez do recurso. 1.2.2. Iniciativas para Investigao em Internet do Futuro Na comunidade de pesquisa em redes, h muito tempo atento ao crescimento de problemas da Internet, aumentou-se o interesse em estudar os desaos da Internet do Futuro e, com isso, modelar a arquitetura que conduzir a um nova gerao da Internet. No entanto, estas novas propostas e especulaes tericas na direo destas solues deveriam ser suportadas por uma infraestrutura real de rede experimental e testadas em ambientes de larga escala. Estas instalaes experimentais desempenhariam o papel de rede para experimentao ou ambiente de tese (testbed), possibilitando experimentos para a prova de conceitos de novas arquiteturas, protocolos, tecnologias e servios. Uma coexistncia com a rede de trfego de produo essencial para observao e captura de certos aspectos e fenmenos perceptveis apenas em instalaes operacionais e assim permitir que sejam avaliados os seus impactos sobre a sociedade e a economia. Observando essas necessidades, algumas iniciativas em pesquisa na Internet do Futuro comearam a surgir, em ferentes cantos do mundo, conforme a seguir.
12
1.2.2.1. GENI (Global Environment for Network Inovation) O Global Environment for Network Innovation (GENI) a principal iniciativa norteamericana em investigao e experimentao em Internet do Futuro. O GENI um conjunto de infraestruturas de redes para experimentao, dos mais variados modelos tais como: sem o, ptico e eltrico. Patrocinado pela National Science Fundation (NSF) desde 2005, atualmente est em fase de desenvolvimento e prototipagem. O objetivo do GENI montar um grande laboratrio em larga escala para experimentaes em redes de computadores, onde a maior importncia validar novas possibilidades para Internet do Futuro. Para o GENI, os conceitos principais relacionados experimentao em Internet do Futuro e que fazem parte do projeto de sua arquitetura so [GENI-Sys 2008]: Programabilidade: Os pesquisadores podero carregar software nos ns do GENI para modicar o seu comportamento; Virtualizao e outras formas de compartilhamento de recursos: Qualquer que seja a implementao de mquina virtual sobre um n GENI, ser permitido que mltiplos pesquisadores simultaneamente compartilhem a mesma infraestrutura. Cada experimento ter sua disposio uma fatia isolada, com recursos m-a-m alocados dentro do infraestrutura do GENI; Federao: O GENI ser composto por infraestruturas prprias e por outras de apoio, operadas por organizaes parceiras ao projeto, criando o conceito de uma federao de recursos e ns, que, na viso de um pesquisador, comportar-se- como se fosse uma nica infraestrutura; Experimentos baseados em fatias (Slices): Cada experimento no GENI ser realizada sobre uma plataforma composta de um conjunto de recursos reservados em diversas localizaes, chamada de uma fatia de recursos. Dentro dessa fatia o pesquisador poder remotamente descobrir, reservar, congurar, depurar, operar e gerenciar seus experimentos e recursos disponveis. Para se ter uma ideia de como o GENI ir funcionar aps a sua concepo, a Figura 1.2 ilustra o uxo que um pesquisador percorrer para habilitar seu experimento dentro da infraestrutura do GENI. Na Figura 1.2 ilustrado o processo que um pesquisador ir executar para solicitar e utilizar uma fatia para experimentao de seus modelos ou protocolos no ambiente GENI. Esse processo formado por trs estgios intermedirios: descoberta de recurso, criao da fatia e experimentao. Na descoberta de recursos (DR), Figura 1.2(a), o pesquisador ter uma viso global dos recursos disponveis para o seu experimento. A partir disso, poder denir, de maneira simples, quais os recursos do GENI sero utilizados em seus experimentos. Na criao da fatia, Figura 1.2(b), o pesquisado recebe uma fatia ou continer vazio onde sero instanciados os recursos e o software que foram denidos pela DR.
13
Figura 1.2. A criao de um fatia sobre a infraestrutura do GENI [GENI-Sys 2008]
Neste caso, uma fatia uma integrao de dois agregados: um cluster de computadores e uma rede ou um conjunto de redes. Por m, na experimentao, Figura 1.2(c), o pesquisador poder instalar os seus softwares, executar, parar e coletar resultados do experimento. O GENI pode ser visto como a conuncia de vrios grandes ambientes de teste, oferecendo alternativas para experimentao em redes. Dentre estes ambientes de teste podemos destacar: PlanetLab, ORBIT e EmuLab [Spiral2 2010] [Paul et al. 2011].
PlanetLab O PlanetLab [Peterson et al. 2006] um grande laboratrio para testes e desenvolvimento de aplicaes distribudas, criado a partir de 2002 por um consrcio de instituies acadmicas, governamentais e industriais, que montou uma grande malha de computadores espalhados pelo mundo em diversas redes. Hoje, possui mais de 1050 mquinas espalhadas em mais de 550 locais diferentes, em todos os continentes (v. http://www.planetlab.org/). O projeto dirigido a partir da Universidade de Princeton, EUA, mas h segmentos, por exemplo, na Europa, onde h outros centros de desenvolvimento e controle dos recursos comuns. O PlanetLab foi pioneiro no uso amplo dos conceitos de virtualizao dos ns e de criao de fatias de recursos virtuais e dedicados nos ns usados num experimento. No Brasil h participao do consrcio desde 2004.
14
No projeto GENI, o PlanetLab GENI [Spiral2 2010], ser uma alternativa de rede para experimentao para seus pesquisadores. O grupo de Princeton dirige esta atividade e tem como escopo integrar logicamente os componentes GENI aos servios PlanetLab como: PLC (PlanetLab Central Sofware), responsvel por criar a rede sobreposta denindo a topologia virtual que ser usada para experimento; e o SFA (Slice-Based Facility Architecture), responsvel por localizar e alocar os recursos para os experimentos [Peterson et al. 2009].
ORBIT O projeto ORBIT prov um rede sem o exvel aberto comunidade acadmica para experimentao. Ele foi desenvolvido para que pesquisadores entendessem as limitaes do mundo real das redes sem o, que muitas vezes no so percebidas em simulaes por causa das simplicaes aplicadas ao modelo ou por terem sido aplicadas em uma quantidade pequenas de ns. O ORBIT possui dois ambientes de teste no campus da Universidade Rutgers: o primeiro dentro de um laboratrio, constitudo por 400 ns dispostos em uma grade 20x20 (ilustrado na Figura 1.3), separados por um metro de distncia entre os ns adjacentes, onde cada n composto por uma plataforma PC com mltiplas interfaces sem o e com o. O segundo est localizado ao ar livre , numa rea de 1,5 hectares. Entre eles existem ns xos, e tambm ns mveis para prover mobilidade entre os roteadores (v. http://www.orbit-lab.org/wiki/WikiStart).
Figura 1.3. ORBIT Testbed Indoor
No GENI, sua integrao permitir que pesquisadores gerenciem esse ambiente de redes sem o dentro do GENI, alm estender a capilaridade de ns do ORBIT para outros ambientes sem o. No GENI, o ORBIT ser integrado dentro do ambiente OMF (cOntrol and Management Framework) [OMF 2011].
15
EmuLab EmuLab [Eide et al. 2006] um ambiente de teste em redes de computadores que oferece aos seus pesquisadores um leque de ambientes nos quais eles podem desenvolver, analisar e avaliar seus sistemas. O nome EmuLab refere-se tanto ao ambiente de teste quanto ao software de interao do usurio com ele. O projeto gerenciado pela Universidade de Utah, onde foram desenvolvidos os primeiros ns do EmuLab. Atualmente, h mais de doze pases utilizando o EmuLab, totalizando uma rede para experimentao com mais de cem ns. No Brasil, h um n desta rede instalado na USP (v. http://www.emulab.net/). Na Figura 1.4 temos os clusters de computadores utilizados pelo EmuLab. Os ambientes disponveis no EmuLab so: Emulao (Emulation), neste ambiente, o pesquisador dene uma topologia arbitrria com switches ou roteadores e ns PC; Live-Internet, onde o Emulab oferece um ambiente federado para experimentos sobre Internet; No 802.11 Wireless, prov um ambiente com ponto de acesso, roteadores e cliente para experimentos em rede sem o; e o ambiente Software-Dened Radio o qual permite experimentaes em camada 1 para anlise de processamento de sinal.
Figura 1.4. Cluster EmuLab
No GENI, a integrao do EmuLab ao projeto deu origem a um subprojeto conhecido como ProtoGENI [ProtoGENI 2011], e permitir ao EmuLab expandir ainda mais seu ambiente de teste, alm de controlar novos no oferecidos atualmente, por exemplo, infraestrutura de altssima velocidade da rede Internet2.
16
1.2.2.2. Future Internet Research and Experimentation (FIRE) A iniciativa FIRE (Future Internet Research and Experimentation) na Europa visa a pesquisa experimental e ao nanciamento de projetos que produzam infraestruturas para experimentao em Internet do Futuro. A meta que as pesquisas em tecnologias para Internet do Futuro sejam direcionadas rede ou a servio e tenham a possibilidade de comparar as solues correntes com as propostas futuras. Desta forma, arma-se que o FIRE possui duas dimenses relacionadas que direcionam suas pesquisas e seus investimentos [FIRE 2008]: Pesquisa Experimental: o objetivo integrar a pesquisa multidisciplinar e a experimentao em larga escala. A partir da, denir uma metodologia que direcionar pesquisa experimental na infraestrutura FIRE, baseada em um ciclo interativo que vai da pesquisa, passando pelo projeto e chegando experimentao; Facilidades para Testes: o objetivo oferecer mltiplos ambientes de teste, suportando vrias tecnologias e interligados e federados entre si para permitir a realizao de experimentos envolvendo dois ou mais dos ambientes distintos. Deste modo pretende-se que FIRE seja sustentvel, renovvel, dinmico e integrado em larga escala. Dever ainda facilitar a pesquisa experimental na comunidade acadmica, nos centros de pesquisa e na indstria. Para o FIRE, as experincias prticas so essenciais para dar credibilidade e levantar o nvel de conana na concluso da pesquisa. Alm disso, a experimentao deve ser executada em larga escala para que seja representativa, convincente e, para provar a escalabilidade da soluo, testada. Os projetos de ambiente de teste em destaque aqui, nanciados pela iniciativa FIRE incluem [FIRE 2010]: BonFIRE, CREW e OFELIA.
BonFIRE A iniciativa BonFIRE (Building Services Testbeds on FIRE) [BonFIRE 2011] um projeto baseado em nuvens em mltiplos locais para o suporte pesquisa de aplicaes, servios e sistemas, visando a Internet de Servios dentro da Internet do Futuro. O BonFIRE objetiva oferecer aos pesquisadores acesso a um ambiente experimental em larga escala para experimentao de seus sistemas e aplicaes, avaliaes do efeito crosscutting da convergncia dos servios, infraestrutura de rede e a anlise do impacto socioeconmico. O BonFIRE ir operar uma nuvem baseada em IaaS (Infrastructure as a Service) com polticas e melhores prticas de experimentaes. Ele ir se adaptar a uma abordagem multiplataforma federada provendo interconexo e interoperao entre os servios e a rede no ambiente de teste. A plataforma ir oferecer servios avanados e ferramentas para pesquisa de novos servios, incluindo nuvens de federaes, gerenciamento de mquinas virtuais, modelagem, gerenciamento do ciclo de vida a experimentao, monitoramento da qualidade de servio e anlise de desempenho.
17
CREW O principal objetivo do CREW (Cognitive Radio Experimentation World) [CREW 2011] estabelecer uma plataforma de teste aberta e federada que facilite o avano em pesquisa em sensoriamento de espectros, rdios cognitivos e estratgias de redes cognitivas em vises horizontais e verticais do espectro compartilhado em bandas licenciadas e no licenciadas. A Figura 1.5 ilustra a topologia e as tecnologias utilizadas no ambiente de teste.
Figura 1.5. Ambiente federado CREW [FIRE 2010]
O CREW incorpora quatro ambientes individuais de teste de rede sem o utilizando um leque de tecnologias sem o como: heterogneos ISM, Celular e Sensores sem o, com o estado da arte de plataforma de sensoriamento cognitivo. O CREW ir sicamente e virtualmente federar componentes interligando entidades de software e hardware de diferentes padres usando APIs padronizadas. Alm disso, o CREW estabelecer um benchmark framework (arcabouo de controle padro), habilitar experimentos controlados, metodologias para anlise automtica de performance e reproduzir condies para teste. OFELIA O projeto OFELIA [OFELIA 2011] visa criar um ambiente para experimentao que tambm permita a seus pesquisadores o controle a redes da sua maneira de forma precisa e dinmica. Para alcanar isso, o ambiente OFELIA baseado em OpenFlow, atualmente uma tecnologia de rede emergente que permite virtualizar e controlar ambientes de rede atravs de interfaces seguras e padronizadas (v. seo 4.3.1). O OFELIA prover equipamentos OpenFlow de alto desempenho para habilitar experimentos em alta escala. A infraestrutura federada pelo OFELIA inclui ilhas (ambientes de teste locais) OpenFlow na Blgica, Alemanha, Espanha, Sua e Reino Unido. Essas ilhas renem uma diversidade de infraestruturas baseadas em OpenFlow que permitir experimentaes em
18
redes multicamadas e multitecnologicas. Na Figura 1.6 apresentada como a estrutura dessas ilhas sero instaladas em cada um desses pases.
Figura 1.6. Estrutura de uma ilha, baseada em OpenFlow no projeto OFELIA [OFELIA 2011]
O OFELIA permitir o teste de novos algoritmos de roteamento, tunelamento, protocolos e planos de controle. Alm disso, novas aplicaes podero ser colocadas no controlador OpenFlow a qualquer momento na infraestrutura. Tambm permitir serem investigadas novas estruturas e formatos de endereamento e modelos de encaminhamentos. 1.2.2.3. Iniciativas Brasileiras Os parceiros brasileiros contribuem no projeto com a experincia na implantao de instalaes de experimentaes locais e na participao em diferentes projetos de pesquisa experimental em Internet do Futuro, embora com pouca ou nenhuma coalizo estratgica entre elas. O primeiro desses projetos a destacar-se o de pesquisa e desenvolvimento GIGA e suas instalaes experimentais em grande escala conhecido como rede GIGA, coordenado conjuntamente pelo CPqD e a RNP [Scarabucci et al. 2005]. O projeto GIGA atualmente se concentra em redes pticas e as denidas por software. Dever ser atualizado em breve com comutadores OpenFlow de 10G (o primeiro na Amrica do Sul) e uma soluo aberta (open-source) de roteamento de pacotes (o primeiro do mundo e neste momento disponvel para parceiros selecionados nos EUA e no Brasil) que roda sobre o NOX para controlar o encaminhamento de pacotes em redes com tecnologia OpenFlow habilitada. A rede GIGA conecta mais de 66 laboratrios de 23 instituies da Regio Sudeste do Brasil e est conectada com a rede nacional da RNP (Rede Ip). Atravs desta, interliga-se com redes de pesquisa e ensino em todo o mundo. A rede GIGA mantm um n GENI, ou seja, servidores, no CPqD. O segundo projeto de destaque o projeto Web Science [WEBSCIENCE, 2010],
19
apoiado pelo CNPq dentro do programa Institutos Nacionais de Cincia e Tecnologia (INCT). O projeto Web Science comeou efetivamente em 2010 e o subprojeto de Arquiteturas para a Internet do Futuro envolve a RNP, e 4 Universidades parceiras (UFF, UFPA, UNIFACS e USP), com experincia em redes pticas e sem o, estudos de simulao e emulao e monitoramento de rede. Um dos primeiros objetivos do projeto estabelecer ilhas experimentais nos laboratrios de cada parceiro e interlig-las em camada 2 atravs das redes de Ip e GIGA.
1.3. OpenFlow e Virtualizao

1.3.1. O OpenFlow A pesquisa na rea de arquiteturas de redes de computadores possui diversos desaos em relao implementao e experimentao de novas propostas em ambientes reais. Isso ocorre devido diculdade para o pesquisador possuir uma rede de testes prxima de uma rede real. Para isso foi desenvolvido o OpenFlow [McKeown et al. 2008], que prope um mecanismo para permitir que redes reais sejam utilizadas como um ambiente de experimentos. O OpenFlow uma proposta tecnolgica que, baseada na separao dos planos de controle e de dados em comutadores de pacotes, permite que pesquisadores executem seus experimentos em redes utilizadas no dia-a-dia, sem interferir no trfego de produo. A proposta fundamentado em comutadores Ethernet comerciais e dene um protocolo padro para controlar o estado destes comutadores (tabela de fuxos, estatsticas e etc.). O conceito de uxo o bloco fundamental que habilita aos pesquisadores denir o plano de encaminhamento na rede, conforme os objetivos denidos pelas novas propostas de arquiteturas e protocolos de rede. O OpenFlow tambm dene um novo elemento de rede, o controlador, e software de controle que executa nele, entre os quais o software NOX criado pelo grupo OpenFlow da U. Stanford (v. Seo 4.3.1.3). No OpenFlow proposto um mecanismo que executado em todos os comutadores ou roteadores de forma que se possa haver isolamento entre os trfegos, o experimental e o de produo. Assim, o OpenFlow possibilita que os pesquisadores reprogramem os comutadores, sem provocar interferncia na conguraes da rede de produo. Outro objetivo dessa proposta permitir que os fabricantes possam incluir as funcionalidades do OpenFlow nos seus comutadores sem necessitarem expor o projeto desses equipamentos. Alm disso, tais equipamentos devem possuir um custo baixo e desempenho semelhante aos j utilizados nas redes de produo, tanto nas universidades como nas redes de pesquisa, de forma que os administradores destas redes aceitem a substituio dos equipamentos j existentes. Com base no exposto, o projeto do OpenFlow tem como objetivo ser exvel para atender aos seguintes requisitos: possibilidade de uso em implementao de baixo custo e de alto desempenho; capacidade de suportar uma ampla gama de pesquisas cientcas; garantia de isolamento entre o trfego experimental e o trfego de produo;
20
consistncia com a necessidade dos fabricantes no exporem o projeto de suas plataformas. O OpenFlow explora a tabela de uxo que j existe nos comutadores atuais, e normalmente so utilizadas para implementar servios como NAT, rewall e VLANs. O comutador OpenFlow constitudo de uma tabela de uxos e um evento associado a cada entrada na tabela. Basicamente, a arquitetura do OpenFlow composto por trs partes: Tabela de Fluxos: Cada entrada na tabela de uxos contm uma ao associada, e consiste em Campos do cabealho (utilizado para denir um uxo), aes (dene como os pacotes devem ser processados e para onde devem ser encaminhados) e contadores (utilizados para estatsticas ou remoo de uxos inativos). Canal Seguro: Para que a rede no sofra ataques de elementos mal intencionados, o Secure Channel assegura conabilidade na troca de informaes entre o comutador e o controlador. A interface utilizada para acesso ao trfego o protocolo Secure Socket Layer (SSL). O NOX tambm suporta outras interfaces (passivas ou ativas), TCP e PCAP. Essas so bem teis em ambientes virtuais, pela simplicidade de utilizao, pois no necessitam de chaves criptogrcas. Protocolo OpenFlow: Disponibiliza um protocolo aberto para estabelecer a comunicao entre o comutador e o controlador. Ao fornecer uma interface externa que atue sobre os uxos de um comutador, o Protocolo OpenFlow (OFP - OpenFlow Protocol) evita a necessidade de um comutador programvel. 1.3.1.1. Aplicaes Como visto anteriormente, o OpenFlow permite o experimento de novas propostas na rea de Redes de Computadores, utilizando uma infraestrutura de rede j existente. Dentre os possveis experimentos permitidos, podem ser citados os seguintes [McKeown et al. 2008]: Novos Protocolos de Roteamento: Os algoritmos de um protocolo de roteamento podem ser implementados para executarem no controlador de uma rede OpenFlow. Assim, quando um pacote do experimento chegar a um comutador, ele encaminhado para o controlador, que responsvel por escolher a melhor rota para o pacote seguir na rede a partir dos mecanismos do protocolo de roteamento proposto. Aps isso, o controlador adiciona entradas na Tabela de Fluxos de cada comutador pertencente rota escolhida. Os prximos pacotes desse uxo que forem encaminhados na rede no necessitaro serem enviados para o controlador; Mobilidade: Uma rede OpenFlow pode possuir pontos de acesso sem-o, permitindo que clientes mveis utilizem sua infraestrutura para se conectarem a Servidores ou Internet. Assim, mecanismos de handoff podem ser executados no Controlador realizando alterao dinmica das tabelas de uxo dos comutadores de acordo com a movimentao do cliente, permitindo a redenio da rota utilizada;
21
Redes No-IP: Como visto anteriormente, um comutador OpenFlow pode ser desenvolvido para analisar campos arbitrrios de um pacote, permitindo exibilidade na denio do uxo. Assim, podem ser testadas, por exemplo, novas formas de endereamento e roteamento. Nos comutadores do tipo 0, os pacotes No-IP podem ser denidos pelo endereo MAC de origem ou destino ou a partir de um novo Tipo de Ethernet ou IP; Redes com Processamento de Pacotes: Existem propostas de protocolos que realizam processamento de cada pacote de um uxo como, por exemplo, os protocolos de Redes Ativas. Esse tipo de proposta pode ser implementado no OpenFlow forando que cada pacote que um comutador receba seja enviado para o Controlador para ser processado. Outra alternativa enviar esses pacotes para processamento por um comutador programvel, como o caso de um roteador programvel baseado em NetFPGA [Lockwood et al. 2007]. 1.3.1.2. Modos de funcionamento dos Switch Existem dois tipos de comutadores OpenFlow. O primeiro consiste em um comutador OpenFlow dedicado, que no suporta encaminhamento comum de Nvel 2 e Nvel 3. O segundo tipo consiste em um comutador ou roteador comercial com OpenFlow habilitado que, alm de suportar as funcionalidades do OpenFlow, realiza as funes comuns de um comutador ou roteador. Esses dois tipos so detalhados abaixo. Comutador OpenFlow Dedicado Esse tipo de comutador, exemplicado na Figura 1.7, um elemento que apenas encaminha o trfego entre as portas do comutador de acordo com a Tabela de Fluxos congurada remotamente via controlador. O uxo pode ser denido de diferentes formas, por exemplo, um uxo pode ser denido como todos os pacotes provenientes de certa porta TCP ou os pacotes com um determinado endereo MAC de destino. Alm disso, alguns comutadores OpenFlow podem tratar pacotes que no utilizam o IPv4, vericando campos arbitrrios de seu cabealho. Isso mostra a exibilidade do OpenFlow para suportar diferentes tipos de experimentos. Para cada entrada da tabela de uxos denida uma ao para ser tomada com os pacotes oriundos de um determinado uxo. As trs aes bsicas que todos Comutadores OpenFlow devem suportar so as seguintes: encaminhar os pacotes do uxo para uma ou vrias portas especcas. Isso permite que os pacotes sejam roteados pela rede; encapsular os pacotes e encaminh-los para o Controlador utilizando o Canal Seguro de comunicao. Essa ao pode ser executada no momento do envio do primeiro pacote de um uxo, que ainda no tenha sido denido nas Tabelas de Fluxo dos comutadores, com o objetivo do Controlador congurar os comutadores
22
Figura 1.7. Comutador OpenFlow Dedicado
com esse novo uxo. Alm disso, a ao pode ser realizada em um experimento no qual necessrio processamento adicional nos pacotes de um uxo; descartar o pacote. Essa ao pode ser utilizada em aplicaes de segurana para impedir, por exemplo, ataques de negao de servio. Uma entrada na Tabela de Fluxos possui trs campos, como apresentado na Figura 1.8a. O primeiro identica o cabealho que dene o uxo. Por exemplo, no cabealho dos comutadores OpenFlow (comutadores tipo 0), um uxo pode ser denido por 10 parmetros. Esses parmetros podem ser o MAC e IP de origem ou destino, as portas TCP usadas, entre outros como mostra a Figura 1.8b. Em outras geraes de comutadores OpenFlow, esses parmetros podem ser denidos arbitrariamente, permitindo o experimento de protocolos que no utilizam o IP.
(a)
(b) Figura 1.8. Cabealhos que denem um uxo em comutadores dotipo 0.
23
O segundo campo identica a ao a ser tomada e o terceiro armazena as estatsticas do uxo. Essas estatsticas podem ser o nmero de pacotes ou bytes referentes ao uxo que passaram pelo comutador e o intervalo de tempo desde a ltima vez em que um pacote do uxo foi identicado pelo comutador. Esse ltimo importante, por exemplo, para remoo de um uxo da tabela caso esteja inativo.
Comutador com OpenFlow Habilitado Esse tipo de comutador consiste nos equipamentos que j realizam encaminhamento normal de Nvel 2 e Nvel 3, mas adicionaram o OpenFlow com uma funcionalidade. Assim, o trfego de produo pode ser encaminhado utilizando o encaminhamento normal e permanece isolado do trfego experimental, que utiliza o mecanismo do OpenFlow. Para isso, esses comutadores podem adicionar outra ao alm das trs aes bsicas citadas anteriormente: encaminhar os pacotes do uxo pelo pipeline normal do comutador. Nessa ao, um uxo identicado como no sendo referente ao OpenFlow ser processado utilizando o encaminhamento normal. Como alternativa ao uso da ao anterior, um comutador pode isolar o trfego de produo do trfego OpenFlow atravs do uso de VLANs. Alguns comutadores podem suportar tanto essa alternativa como a outra.
1.3.1.3. Controle usando NOX O NOX [Gude et al. 2008] uma proposta de sistema operacional para redes, possuindo como objetivo facilitar o gerenciamento de redes de grande escala. O conceito de sistema operacional de rede pode ser entendido pela analogia com os sistemas operacionais utilizados nos computadores. As ideias bsicas dos sistemas operacionais de computadores so oferecer uma interface de alto nvel para as aplicaes utilizarem os recursos de hardware e tambm controlar a interao entre essas aplicaes. A interface de alto nvel tornou os programas mais fceis de serem desenvolvidos e de executarem em diferentes plataformas de hardware. Isso ocorre porque os programadores no precisam mais se preocupar com interaes de baixo nvel da aplicao com o hardware e podem escrever seus programas utilizando primitivas genricas que funcionam em diversas arquiteturas. Em redes de computadores, o gerenciamento realizado por conguraes de baixo nvel que depende do conhecimento da rede, anlogo s aplicaes desenvolvidas sem os sistemas operacionais. Como exemplo, o controle de acesso aos usurios de uma rede utilizando uma ACL (Access Control List - Lista de Controle de Acesso), necessita do conhecimento do endereo IP do usurio, que um parmetro de baixo nvel dependente da rede.
24
Portanto, existe a necessidade de um sistema operacional de redes que fornea interfaces para controlar e observar uma rede, semelhantes s interfaces de leitura e escrita em diversos recursos oferecidos atravs de um sistema operacional de computador [Gude et al. 2008]. Assim, o sistema operacional de redes dever fornecer uma interface genrica de programao que permite o desenvolvimento de aplicaes de gerenciamento da rede. Esse sistema centraliza o gerenciamento da rede, necessitando haver uma grande preocupao com sua escalabilidade. O NOX um sistema operacional de rede que procura atender os requisitos j citados. Esse sistema foi desenvolvido para ser executado nos controladores de redes OpenFlow. Apesar do objetivo principal do OpenFlow ser o experimento de novas propostas, o NOX pode ser utilizado tambm no gerenciamento de redes de produo. A Figura 1.9 ilustra os principais componentes de uma rede baseada no NOX. Esse tipo de rede possui um ou mais servidores executando o NOX. Cada um realiza o papel do controlador OpenFlow. Esses controladores possuem aplicaes executando a partir do NOX. Todos os controladores compartilham uma nica viso da rede, que mantida na base de dados de um dos servidores.
Figura 1.9. Componentes de uma rede baseada no NOX
A viso da rede montada com base em informaes da rede coletadas pelo NOX e usada na tomada de decises pelas aplicaes de gerenciamento. As informaes coletadas podem ser a topologia dos comutadores, a localizao dos elementos da rede (ex. usurios, clientes, middleboxes) e os servios oferecidos (ex. HTTP ou NFS). As aplicaes iro manipular o trfego da rede a partir da congurao remota dos comutadores OpenFlow. Esse controle realizado no nvel de uxo, ou seja, sempre quando um determinado controle realizado no primeiro pacote de um uxo todos os outros pacotes desse uxo sofrero a mesma ao. O funcionamento da rede baseada no NOX ocorre da seguinte forma: ao receber um pacote, o comutador verica o cabealho do pacote para ver se ele est denido em sua Tabela de Fluxos. Se estiver denido, o comutador executa a ao especicada na Tabela
25
de Fluxos e atualiza os contadores referentes estatstica do uxo. Seno, encapsula o pacote e o envia para o NOX. O NOX ento ser responsvel por adicionar uma entrada na Tabela de Fluxos do comutador, identicando o uxo referente aquele pacote. Dependendo da aplicao, o NOX pode no adicionar essa entrada, forando que os comutadores enviem sempre para o NOX os pacotes que receberem. Como exemplo de aplicao que pode ser desenvolvida para o NOX, pode ser citado o gerenciamento de consumo de energia [Gude et al. 2008]. Por exemplo, nesse tipo de gerenciamento, pode ser reduzida a velocidade de enlaces subutilizados ou esses enlaces podem ser simplesmente desligados. Com a Viso da Rede do NOX, na qual conhecida uma viso global da rede e as rotas em uso, pode-se adquirir conhecimento necessrio para realizar tais aes. Alm disso, essas aes podem ser auxiliadas por aplicaes desenvolvidas para o NOX, como reduo de velocidade dos enlaces ou migrao dos uxos de um comutador que ser desligado para outro comutador em uso. Alm do NOX ainda h outro tipos de controladores para redes OpenFlow, como caso do BEACON [BEACON 2011] que baseado na linguagem JAVA, e do DIFANE [Yu et al. 2010] que um controlador distribudo. 1.3.2. Virtualizao A virtualizao uma tcnica que permite que um sistema execute processos oferecendo a cada um deles a iluso de executar sobre recursos dedicados. Inicialmente um mecanismo de isolamento, ela representa um fator de uso eciente da crescente capacidade computacional disponvel [Egi et al. 2010] e a integra arquiteturas onde elementos comuns a um conjunto de processos virtualizados possuem apenas uma cpia em execuo, acessada de forma compartilhada [Bhatia et al. 2008]. O conceito foi estendido do mbito de ns para os demais elementos de uma rede de computadores, dando origem virtualizao de redes [Chowdhury and Boutaba 2010]. Em um processo paralelo quele descrito para a virtualizao tradicional, a aplicao da virtualizao de redes passou a permitir que os componentes de uma rede fsica particionassem sua capacidade de maneira a realizar simultaneamente mltiplas funes, estabelecendo infraestruturas lgicas distintas e mutuamente isoladas. Assim como no caso da virtualizao de sistemas, a virtualizao de redes tambm permitiu que as arquiteturas de redes se tornassem mais ecientes. Funes que tradicionalmente eram gerenciadas de forma distribuda passaram a ser projetadas para uma execuo e administrao centralizadas. o caso do encaminhamento do trfego IP: podem ser encontradas arquiteturas do estado-da-arte [Nascimento et al. 2010] em que decises de roteamento, originalmente tomadas de forma local por ns especializados, so encaminhados por comutadores a um sistema controlador, que executa em memria uma verso virtualizada da rede e dos respectivos elementos roteadores. Deriva decises da base de informaes de roteamento construda pela execuo desta rede virtual e as transmite aos comutadores, que reagem de acordo.
26
1.3.2.1. Virtualizao de Sistemas Uma soluo de virtualizao fornece aos sistemas, executando sob sua superviso, a abstrao de um ambiente computacional exclusivo sobre o qual eles esto operando (n convidado), quando de fato tem-se um computador (antrio) cujos recursos foram partilhados entre esses mesmos sistemas. Pode-se realizar a virtualizao de sistemas de duas formas: a virtualizao completa, em que cada convidado executa seu sistema operacional, e a virtualizao baseada em containers, em que o sistema operacional do antrio distribui e isola os recursos disponveis entre os sistemas convidados [Bhatia et al. 2008]. Ainda segundo Bhatia [Bhatia et al. 2008], na virtualizao completa, ilustrada na Figura 1.10, o antrio executa um Monitor de Mquinas Virtuais - MMV, tambm chamado hypervisor. responsabilidade do MMV prover abstrao de hardware (chamada de mquina virtual) para que seja possvel executar o sistema operacional convidado, bem como mapear cada requisio dos convidados a seus respectivos dispositivos virtuais, para o elemento fsico correspondente.
Figura 1.10. Virtualizao Completa
Tambm existe uma variao desta tcnica chamada paravirtualizao, que consiste em otimizar a emulao de hardware provida pelo MMV com vistas a um ganho de desempenho. Nesta abordagem, porm, os sistemas operacionais convidados devem ser modicados para que possam ser executados, o que no acontece na virtualizao completa. Em um sistema baseado em containers, apresentado na Figura 1.11, uma imagem de sistema operacional virtualizada compartilhada entre todos os convidados - o que pode ser especialmente eciente em cenrios em que se deseja apenas executar de forma isolada diversas cpias do mesmo software. Ainda assim, os ns virtuais podem ser individualmente gerenciados, tal como na virtualizao completa.
27
Figura 1.11. Virtualizao utilizando Container
A virtualizao empregada atravs de ferramentas que apresentam diferenas entre si e possuem suas vantagens e desvantagens. Atualmente, h uma gama enorme de softwares livres e empresas que fornecem solues com esse conceito. Neste minicurso, so comentados apenas as ferramentas Xen e o OpenVz, por serem as mais relevantes no contexto atual.
XEN O Xen um monitor de mquina virtual (VMM ou hypervisor), em software livre, para arquiteturas x86. Originrio de um projeto de pesquisa da Universidade de Cambridge, sua primeira verso foi criada em 2003, quatro anos antes de ser comprada pela Citrix System, em 2007. Ele apresenta uma soluo para virtualizao um pouco diferente das conhecidas. Seu conceito consiste em criar um hypervisor, responsvel por controlar os recursos das mquinas virtuais, mas que no possui drivers de dispositivos. Dessa forma, no possvel rodar um sistema operacional diretamente no hypervisor. Assim, faz-se necessrio que um sistema seja invocado para fazer a comunicao entre o hypervisor e os sistemas hspedes. A Figura 1.12 apresenta uma viso geral do Xen. Esse sistema inicial chama-se domnio 0. Ele consiste em uma mquina virtual que executa um ncleo Linux modicado e possui privilgios para acessar dispositivos de entrada e sada s outras mquinas virtuais, onde podem rodar outros sistemas operacionais, chamados domnio U. Elas so criadas, inicializadas e desligadas atravs do domnio 0. Possuem um driver virtual para acesso aos recursos de hardware. O domnio 0 possui os drivers dos dispositivos da mquina fsica, alm de dois drivers especiais que tratam as requisies de acesso rede e ao disco enviadas pelas
28
Figura 1.12. Viso Geral do Arquitetura XEN
mquinas virtuais. Assim, toda requisio de uso da mquina real feita por uma mquina do domnio U deve ser tratada pelo domnio 0 antes de ser enviada ao hypervisor. Originalmente, o Xen foi desenvolvido com o objetivo de implementar a tcnica de para-virtualizao, e, para isso, era necessrio modicar os sistemas hspedes para darlhes a conscincia de rodarem sobre um hypervisor. Essa estratgia foi tomada visando ganhos em desempenho, mas limitou a difuso do Xen aos sistemas Unix, de cdigo aberto. OPENVZ O OpenVZ uma soluo de virtualizao em nvel de sistema operacional. Cria ambientes virtuais isolados, que funcionam como servidores convencionais, porm, utilizando um nico hardware em comum. Estes ambientes virtuais seguros so conhecidos como VE (Virtual Environment) ou como VPS (Virtual Private Server). VPSs podem ser reinicializados independentes uns dos outros. Todos possuem hostname, root access e endereo IP prprio, ou seja, o que um servidor real normalmente possui, sendo assim uma soluo extremamente convel e funcional de virtualizao. As capacidades bsicas dos VPSs so: Dynamic Real-time Partitioning: artio de um nico servidor fsico em dezenas de VPSs, cada um com funcionalidade total; Resource Management: atribuio e controle dos recursos dos VPSs. Realocao de recursos em tempo real; Mass Management: gerenciamento unicado de uma grande quantidade de servidores fsicos e virtuais (VPSs). Como pode ser visto na Figura 4.13, um servidor fsico pode conter diversos VPSs
29
Figura 1.13. Arquitetura de virtualizao utilizada pelo openVZ
(Virtual Private Servers). Cada VPS possui isolamento total uns dos outros, inclusive com uma viso nica de seus Ambientes Virtuais (VEs). O OpenVZ prov uma soluo para Provedor de Servios de Hospedagem possibilitando que: Centenas de usurios possuam seus prprios servidores privados (Virtual Private Servers) compartilhando um nico servidor fsico; Prov para cada usurio uma garantia de qualidade de servio; Transferncia transparente dos ambientes virtuais dos usurios para outros servidores fsicos, sem nenhum tipo de recongurao manual. O Virtual Private Server se comporta como um nico servidor, onde: Cada VPS possui seus prprios processos, usurios e prov acesso completo de root via shell Cada VPS possui seu prprio endereo IP, nmero de portas, rewall e roteamento; Cada VPS possui seus prprios arquivos de congurao para o sistema e aplicaes, como tambm suas prprias bibliotecas de sistema. 1.3.2.2. Virtualizao de Redes Assim como a virtualizao prov o compartilhamento de recursos de um n computacional por mltiplos sistemas, a virtualizao de redes (VR) um mtodo para que mltiplas arquiteturas de rede heterogneas compartilhem o mesmo substrato fsico - neste caso, componentes de uma rede como roteadores, comutadores, etc.
30
Segundo Chowdhury [Chowdhury and Boutaba 2010], existem quatro abordagens para a implementao de VR: as Redes Locais Virtuais (VLANs), as Redes Privadas Virtuais (VPNs) e as redes de sobreposio (Overlay). Em [Sherwood et al. 2010a] , apresenta-se uma quarta, a partir do conceito de redes programveis. Redes Locais Virtuais (VLANs) Uma VLAN um agrupamento lgico de dispositivos ou usurios que podem ser unidos por funo, departamento ou aplicativo, independentemente da localizao de seus segmentos fsicos. A congurao de VLANs feita no comutador, e possivelmente no roteador, atravs de software proprietrio do fabricante. Com efeito, numa rede local a comunicao entre as diferentes mquinas governada pela arquitetura fsica. Graas s redes virtuais (VLANs), possvel livrar-se das limitaes da arquitetura fsica (constrangimentos geogrcos, restries de endereamento, etc), denindo uma segmentao lgica (software), baseada num agrupamento de mquinas com critrios como endereos MAC, nmeros de porta ou protocolo. Foram denidos vrios tipos de VLAN, de acordo com o critrio de comutao e o nvel em que se efetua: VLAN de nvel 1 (Port-Based VLAN) - dene uma rede virtual em funo das portas de conexo no comutador; VLAN de nvel 2 (MAC Address-Based VLAN) - consiste em denir uma rede virtual em funo dos endereos MAC das estaes; VLAN de nvel 3 - distinguem-se vrios tipos de VLAN de nvel 3: VLAN por sub-rede (Network Address-Based VLAN), que associa sub-rede de acordo com o endereo IP fonte dos datagramas e VLAN por protocolo (em ingls ProtocolBased VLAN) que permite criar uma rede virtual por tipo de protocolo, por exemplo: TCP/IP, IPX e AppleTalk, agrupando assim todas as mquinas que utilizam o mesmo protocolo numa mesma rede. A VLAN permite denir uma nova rede acima da rede fsica e a esse respeito oferece mais exibilidade para a administrao e modicaes da rede porque qualquer arquitetura pode ser alterada por simples parametrizao dos comutadores. E ainda, um ganho em segurana, porque as informaes so encapsuladas em um nvel suplementar e so eventualmente analisadas. A VLAN oferece tambm reduo da divulgao do trfego sobre a rede. Redes Privadas Virtuais (VPNs) A ideia de utilizar uma rede pblica como a Internet em vez de linhas privativas para implementar redes corporativas denominada de VPN (Virtual Private Network) ou Rede Privada Virtual. As VPNs so tneis seguros entre pontos autorizados, criados atravs da
31
Internet ou outras redes pblicas e/ou privadas para transferncia de informaes, com proteo criptogrca, entre redes corporativas ou usurios remotos. A segurana a primeira e mais importante funo da VPN. Uma vez que dados privados sero transmitidos pela Internet, que um meio de transmisso inseguro, eles devem ser protegidos de forma a no permitir que sejam modicados ou interceptados. Outro servio oferecido pelas VPNs a conexo entre corporaes, as Extranets, atravs da Internet, alm de possibilitar conexes discadas e cifradas que podem ser muito teis para usurios mveis ou remotos, bem como liais distantes de uma empresa. Uma das grandes vantagens decorrentes do uso das VPNs a reduo de custos com comunicaes corporativas, pois elimina a necessidade de enlaces dedicados de longa distncia que podem ser substitudos pela Internet. As LANs podem, atravs de enlaces dedicados ou discados, conectarem-se a algum provedor de acesso local e interligarem-se a outras LANs, possibilitando o uxo de dados atravs da Internet. Esta soluo pode ser bastante interessante sob o ponto de vista econmico, sobretudo nos casos em que enlaces internacionais ou nacionais de longa distncia esto envolvidos. Outro fator que simplica a operacionalizao da WAN que a conexo LAN-Internet-LAN ca parcialmente a cargo dos provedores de acesso. 1.3.2.3. Redes de Sobreposio (Overlay) Uma rede de sobreposio uma rede virtual que cria uma topologia virtual no topo da topologia fsica de outras redes. Os ns em uma rede de sobreposio so unidos por meio de ligaes virtuais que correspondem a caminhos na rede subjacente. Na Figura 1.14 ilustra essa armao, na camada IP os ns correspondem aos roteadores e sistemas terminais, enquanto na camada Overlay, que uma rede de sobreposio, tem-se a topologia virtual. As redes de sobreposio so tipicamente programadas na camada de aplicao, embora vrias implementaes nas camadas inferiores da pilha de redes o faa existir. As redes de sobreposio no so restritas geogracamente e so bastante exveis e adaptveis a mudanas, se comparadas a qualquer outra rede. Como resultado, as redes sobrepostas tm sido usadas para implantar novos recursos e extenses na Internet.
Figura 1.14. Modelo de Rede de Sobreposio
32
Muitos modelos de sobreposio tm sido propostos nos ltimos anos para resolver problemas que incluem: desempenho assegurado [Savage et al. 1999], disponibilidade de roteamento na internet [Andersen et al. 2001], multicast [Jannotti et al. 2000] [Chu et al. 2001], garantias de qualidade de servio [Subramanian et al. 2004], ataque de negao de servios [Andersen 2003], distribuio de contedo, compartilhamento de arquivos [Lua et al. 2005] e at sistemas de armazenamento [Dabek et al. 2001]. Redes de sobreposio tambm esto sendo usada como ambientes de teste, por exemplo PlanetLab [Peterson et al. 2009], Federica [Campanella 2011] e o GENI [GENI 2011], para desenvolvimento e avaliao de novas arquiteturas. 1.3.2.4. Virtualizao de Rede com OpenFlow Similar virtualizao de computadores, a virtualizao de redes promete melhorar a alocao de recursos alm de permitir que seus operadores possam checar suas redes antes de eventuais mudanas, e tambm que clientes compartilhem o mesmo equipamento de forma controlada e isolada. Portanto, analogamente, a rede em si deve ter uma camada de abstrao de hardware, similar ao que acontece na virtualizao de computadores. Esta camada deve ser facilmente fativel, para que mltiplas redes completamente diferentes possam ser executadas simultaneamente em cima, sem interferir uns aos outros, sobre uma variedade de hardwares diferentes abaixo, incluindo comutadores, roteadores, pontos de acesso e assim por diante. Ou seja, acima desta camada de abstrao de hardware, tm-se novos protocolos e formatos de endereamento rodando independentemente e sua prpria fatia, uma mesma rede fsica, e na parte de baixo da camada de virtualizao, novos hardwares, podendo ser desenvolvidos para diferentes ambientes e diferentes velocidade, mdia (com o e sem o) e energia. De acordo com Sherwood [Sherwood et al. 2010a], a camada de abstrao de hardware provida pelo OpenFlow e como camada de virtualizao se tem FlowVisor. Similar virtualizao de computadores, o FlowVisor uma camada de abstrao que reside entre o hardware e o software dos componentes da arquitetura, conforme ilustrado na Figura 1.15. Portanto, a integrao FlowVisor e OpenFlow permite que em uma rede OpenFlow possam ser criados vrias fatias de recursos de redes rodando simultaneamente e isoladamente. O FlowVisor um controlador especializado que atua como um procurador (proxy) transparente entre os comutadores de uma rede OpenFlow e seus mltiplos controladores. Todas as mensagens do protocolo OpenFlow tanto aquelas originrias dos comutadores para os controladores quanto as dos controladores para os comutadores, so interceptadas atravs do FlowVisor. Desse modo, os controladores no necessitam de modicaes e, devido interceptao transparente do FlowVisor, os mesmos acreditam estar se comunicando diretamente com os dispositivos da rede que constitui o plano de dados [Sherwood et al. 2010b]. Devido existncia da interface entre os planos de dados e o de controle, a tcnica empregada permite a partio do plano de dados em fatias que esto sob a gerncia do FlowVisor [Sherwood et al. 2009].
33
Figura 1.15. Comparao entre o FlowVisor como camada de virtualizao com a virtualizao computacional [Sherwood et al. 2009]
Cada fatia est vinculado a um controlador. O FlowVisor dene uma fatia como um conjunto de uxos tambm chamado de espao de uxo (ou owspace). Devido verso atual do protocolo OpenFlow permitir a denio de um uxo como uma combinao de dez campos do cabealho de pacote incluindo informaes das camadas fsica, de enlace, de rede e de transporte, o FlowVisor possibilita que se implemente fatias com um elevado nvel de granularidade, no que diz respeito caracterizao do owspace [Sherwood et al. 2010a] . Alm disso, as fatias podem ser denidas por aes de negao, unio e interseco. A Figura 1.16 ilustra o particionamento da rede em fatias. Nesta gura, alm da fatia da rede de produo, tm-se mais duas fatias identicadas por Alice e Bob. Os crculos enumerados em ordem crescente indicam a dinmica de execuo durante o processamento das mensagens interceptadas pelo FlowVisor. Inicialmente, o FlowVisor intercepta as mensagens provenientes de um determinado controlador convidado no ambiente de controle (1). Utilizando a poltica do espao de uxos denida para aquela fatia (2), o FlowVisor reescreve a mensagem do controlador transparentemente para a fatia da rede que compe o plano de dados (3). As mensagens originrias dos comutadores para o plano de controle (4), por sua vez, so novamente interceptadas pelo FlowVisor e reescritas para o respectivo controlador de acordo com a poltica que dene o espao de uxos. O particionamento da rede possibilita que as aes desenvolvidas em uma de suas fatias no interram negativamente nos demais, mesmo que estes estejam compartilhando a mesma infraestrutura fsica. Em arquiteturas mais tradicionais, a rede fatiada atravs da tcnica de VLAN (Virtual Local Area Network), porm, com a diversidade dos modelos de redes, a estrutura de VLANs torna os experimentos, como IP Mobility ou Wireless Handover, por exemplo, bastante difceis de gerenciar.
34
Figura 1.16. Gerenciamento de slices por meio do FlowVisor [Sherwood et al. 2009]
As caractersticas inerentes ao FlowVisor, como a virtualizao transparente, o forte isolamento entre as fatias e a sua rica poltica de denio de owspaces tornam o mesmo uma ferramenta extremamente eciente no que diz respeito virtualizao e implementao de redes programveis orientadas a software.
1.4. Requisitos para Construo de um Ambiente para Experimento e Virtualizao de Redes

Iniciativas [FIRE 2011] [GENI 2011] [AKARI 2009] vm construindo infraestruturas para testar novos protocolos, servios e aplicaes em ambientes de larga escala, visando solucionar esses desaos da Internet atual e compor a arquitetura da chamada Internet do Futuro. Por essas razes, denir estratgias corretas para construo e operao destes ambientes de teste para Internet do Futuro considerado uma etapa vital. Alm disso, o ambiente deve combinar exibilidade a um conjunto mnimo de restries e um completo controle do ambiente para seus pesquisadores [Kim et al. 2009]. Deste modo, o OpenFlow vem se destacando como arcabouo capaz de habilitar experimentos de novas tecnologias utilizando redes reais de produo. Nesta mesma linha, a virtualizao vem como uma ferramenta essencial, para permitir o acesso compartilhado de recursos, seja de rede ou computacional. Portanto nesta seo, observam-se as informaes importantes para construo de uma rede para experimentao, levando em considerao a utilizao de OpenFlow e virtualizao. Vericam-se o modo que se descrevem, os hardwares utilizados dentro desta infraestrutura, tipos de enlaces, software de virtualizao e ferramentas para anlise de trfegos e gerao de trfego
35
1.4.1. Tipos de Hardwares Para construo do ambiente de teste, necessrio principalmente hardware que suporte virtualizao e OpenFlow. Para isso, so necessrios dispositivos especiais para que o desempenho da rede virtual no tenha uma inuncia nos experimentos realizados, e que seja possvel sua otimizao de forma programvel. Entre esses dispositivos esto interfaces de redes programveis e comutadores programveis com OpenFlow habilitado. Interface de Rede Programvel O NetFPGA [Lockwood et al. 2007] uma plataforma aberta que permite estudantes e pesquisadores desenvolverem prottipos de sistemas de redes em alta velocidade e sistemas de acelerao de redes via hardware, alm de prottipos de comutadores ou roteadores IP para Internet do Futuro. O NetFPGA consiste em um placa de desenvolvimento recongurvel, interface de ligao ao PC, utilizando PCI e PCI-e, dois processadores PowerPC, e software que possibilita o desenvolvimento de novas funcionalidades. H duas verses da placa: a mais antiga possui quatro interfaces de 1 Gbps Ethernet RJ-45 e um vazo que de 8Gbps; a mais nova tem quatro interfaces 10 Gbps Ethernet SFP+, e vazo at 80 Gbps. Alm disso, totalmente compatvel com Linux e OpenFlow. Switches Programveis O OpenFlow um arcabouo que permite o gerenciamento da tabela de encaminhamento de comutadores Ethernet, desacoplando a lgica de controle do equipamento do hardware de encaminhamento de pacotes, permitindo assim o conceito chamado de SoftwareDened Networking (SDN) [Greene 2009]. Esta separao no s permite um modelo de inovao aberta tanto no plano de controle quanto no plano de encaminhamento, mas tambm permite a virtualizao do plano de encaminhamento em fatias ou redes lgicas. Deste modo, so necessrios equipamentos que possuam o OpenFlow habilitado. No entanto, o protocolo Openow ainda est em fase de padronizao nos comutadores e algum fabricantes j disponibilizam verses de comutadores com OpenFlow habilitado, como o caso dos modelos Pronto 3290 para solues at 1 Gbps Ethernet e o Pronto 3790 para 10 Gbps Ethernet e SFP+. Tambm h o projeto Indigo [INDIGO 2011] que uma implementao aberta do OpenFlow que permite rodar sobre comutadores fsicos baseados em chipsets da Broadcom. A cada comutador suportado desenvolvido um rmware para essa linha de produto. Este rmware sobrescreve o original do comutador, instalando a nova imagem com OpenFlow habilitado. Dentre os comutadores compatveis, temos, alm dos modelos da linha Pronto, os modelos GSM7328 (24 x 1 GbE) e GSM7352 (48 x 10 GbE) da linha Netgear. Servidores de Alto Desempenho Os servidores tambm so uma parte importante dentro do substrato, pois deles so virtualizados recursos como: processador, armazenamento e E/S. Para isso, so necessrios servidores de alto capacidade computacional para que no haja perda de desempenho no nvel virtualizado e suporte quantidade de usurios locais e tambm os federados. Observando esses requisitos, as linhas de servidores do tipo blade surgem como uma excelente
36
soluo para oferecer essa capacidade computacional. Blade uma nova forma de tecnologia computacional que permite a alta densidade de componentes e recursos incluindo servidores, armazenamento e interfaces de comunicao integradas em um mesmo chassis. A vantagem do uso de servidores blade a possibilidade do crescimento incremental mediante a demanda de usurios, devido a sua caracterstica modular, baseada em containers de servidores, comutadores e armazenamento. O seu capacidade computacional pode ser incrementado com introduo de novas lminas blade, que so servidores que so inseridos no chassis e incluem recursos de processamento e memria. Alm disso, outra vantagem a sua otimizao para uso de virtualizao com barramento em altssimas taxas de transferncia, e implementao de grupos de recursos dentro de conjunto virtualizado. O uso de blades est ligado principalmente virtualizao de servidores e computao em nuvem. 1.4.2. Arcabouos de Controle O arcabouo de controle o corao de qualquer infraestrutura de experimentao baseada em virtualizao. Porm, muitos arcabouos so limitados a certos tipos de recurso e a um tipo de comunidade de pesquisa. Com base nisso, so apresentados alguns arcabouos de controle que devem ser selecionados de acordo com o tipo de infraestrutura que se est oferecendo: ProtoGENI (GENI) O ProtoGENI [ProtoGENI 2011] atualmente dirigido pela Universidade de Utah. um arcabouo que pretende controlar a integrao em larga escala de infraestruturas existentes e em construo no GENI. Esses ambientes de teste so compostos principalmente por elementos embarcados e programveis nas redes backbone, PCs com hardwares programveis e uma variedade de redes sem o, redes de acesso e clusters programveis. Atualmente, o ProtoGENI est usando RSpec para descrever seus ns, enlaces e interfaces. Esses recursos so mapeados para o Emulab que aplica os mapas virtuais de recursos em ns locais e vlans. ORCA(GENI) O ORCA [ORCA 2011] [BEN 2011] framework de cdigo fonte aberto, utilizado para gerenciar e controlar a programabilidade de substratos (hardware) compartilhados, que podem incluir, servidores, storages, redes e outros componentes. O ORCA foi desenvolvido como um prottipo arcabouo GENI. No ORCA, h uma coleo dinmica de controladores de interao que trabalham juntas para o aprovisionamento e congurao de recursos para as fatias requisitadas pelos seus usurios, de acordo com as polticas dos participantes. Atualmente, o ORCA foi estendido para gerenciar um ambiente de teste em uma rede ptica metropolitana. Tambm est em processo de integrao a seleo para utilizao de prottipos para redes de sensores e sem o, de modo que o ORCA oferea a maior variedade possvel de ambientes de teste.
37
FEDERICA (FIRE) O FEDERICA [Szegedi et al. 2009] uma iniciativa composta de roteadores, comutadores e computadores para experimentaes em Internet do Futuro. Ele baseado nas redes acadmicas de alguns pases europeus e na rede pan-europeia GEANT. O arcabouo FEDERICA capaz de alocar recursos para mltiplas fatias e diferentes redes a serem utilizadas pelos pesquisadores que possuem o controle completo dos recursos de sua fatia. Ele composto de pequenas ferramentas e outros recursos de instrumentao que vo desde a gerncia e controle de mquinas virtuais alocao de circuitos m-a-m camada 2, camada 1 ou MPLS. PII (FIRE) O objetivo do projeto PII [Paul et al. 2011] criar uma federao de instalaes experimentais entre diferentes plos de inovao regional na Europa. Isso permite que as empresas participantes possam testar novos servios de comunicao e aplicaes na Europa como um todo. O arcabouo tambm ter como objetivo federar redes para experimentao distribudas por laboratrios espalhados pela Europa, assim provendo um ambiente de teste realstico para novos conceitos de servios, tecnologias de rede e modelos de negcios. Os mecanismos de seu arcabouo incluem regras e procedimentos para alcanar nveis de teste e colaborao dentro dessas federaes de infraestruturas dentro da Europa. 1.4.3. Monitorao e Medio Medio e monitoramento so atividades que observam o estado operacional do ambiente de teste que est sendo usado, de modo que se possa obter informaes sobre o desempenho dos recursos disponveis no ambiente, e vericar a disponibilidade do recurso ou componente. O objetivo disso oferecer a outros sistemas uma viso dos recursos da infraestrutura, para auxiliar decises como a possibilidade de alocao de recurso, bem como sua escolha e disponibilizao. Portando, dentro dos requisitos para construo dessas ambientes de teste, esses elementos so essenciais. A seguir, so apresentados alguns softwares relacionados a caractersticas de medio e monitoramento. PerfSONAR O perfSONAR (PERFormance Service-Oriented Network monitoring ARchitecture) uma arquitetura orientada a servios (SOA) que foi projetada para o monitoramento de redes em ambientes interdomnios. No perfSONAR, existe um conjunto de servios bem denidos que realizam ou disponibilizam resultados de medies de desempenho em um ambiente federado. Esses servios atuam como uma camada intermediria entre as ferramentas de medies e as ferramentas de visualizao [Tierney et al. 2009]. Alm disso, o perfSONAR tambm deniu um protocolo comum entre os servios para permitir que sejam criados novos servios seguindo a padronizao deste protocolo, dando exibilidade arquitetura. Tambm, criou-se uma representao unicada para denir, armazenar e arquivar os dados relativos s medidas do experimento que mais
38
um componente chave, de modo que certo nvel de concordncia necessrio para fazer convergir esforos e melhorar a experincia, delidade e usabilidade das infraestruturas de experimentao em escala global. O pS-Performance Toolkit [Ps-Performace 2011] uma coleo de ferramentas de medida de desempenho de redes desenvolvida dentro do projeto perfSONAR. BWCTL O BWCTL [Hu et al. 2010] uma aplicao cliente/servidor que permite o agendamento de testes com polticas de medidas utilizando IPERF, THRULAY [Shalunov 2011] e NUTTCP [Fink and R. 2011]. Estes testes podem medir, por exemplo, a mxima largura de banda para TCP ou testes UDP para medir o atraso, a variao do atraso ou nvel de perda de datagrama na rede. BWCTL tem sido utilizado para testar as qualidades das reservas de circuitos. Neste caso, o seu cliente solicita e agenda um circuito, verica se foi criado ou no, e caso seja criado, ele verica se os desempenhos solicitados esto realmente disponveis. Real-Time Unied Measurement Framework O UMF (Unifed Measurament Framework) um arcabouo desenvolvido para oferecer capacidade de medies em tempo real a avaliaes de desempenho sobre vrios cenrios de infraestrutura, interfaces de integrao dos recursos de medio com os substratos e os framewoks de controle dos prottipos de GENI e outros sistemas que necessitem de suas medidas e a monitorao das condies dos recursos de um slice durante um experimento [UMF 2011]. Inicialmente, o UMF est sendo desenvolvido para alimentar informaes dos demais arcabouos de controle do GENI e de visualizao dos usurios pesquisadores. Na Figura 1.17, mostra o esquema de interao dos arcabouos com o UMF.
Figura 1.17. Esquema de interao do UMF com outros frameworks do GENI
UMF um arcabouo genrico para gerenciamento de ambiente de teste e coleta de mtricas de experimentos. Quando o experimento est sendo executado, os dados so medidos e coletados de acordo com a descrio do usurio. Pontos de medio so
39
denidos dentro de uma aplicao C/C++ ou automaticamente, baseados em arquivos de congurao XML. Os dados medidos so transmitidos usando codicao XDR e salvos em um banco de dados para anlise posterior. Um novo banco de dados de medio criado para cada experimento. O SQLite pode ser usado para manipular os dados ou estes podem ser exportados para gerao de grcos ou tabelas. No UMF, h medidores de desempenho (Performance Monitors) para os mais variados tipos de substratos fsicos, como: unidades externas de hardware, por exemplo, servidores com capacidade de armazenamento (storage), interface de Ethernet NetFPGA (10G - NetFPGA). Outras interfaces Ethernet seriam GPIB e sem o, e protocolos padres para medio como TL1, SNMP e NetConf. 1.4.4. Ferramentas para Gerncia de Virtualizao As ferramentas de gerncia so essenciais no desenvolvimento dos ambientes de experimentao, pois elas tm o papel de manipular, criar, congurar e remover recursos nestes ambientes. Portanto, abaixo, so apresentadas as principais ferramentas para gerenciamento de virtualizao, computao em nuvem e manipulao de fatias. LIBVIRT A LIBVIRT [Wu et al. 2010] existe como um conjunto de APIs projetadas para serem usadas como um aplicativo de gerenciamento. Por meio de um mecanismo especco de hypervisors, a LIBVIRT comunica-se com um hypervisor disponvel para executar as solicitaes da API. Deste modo, a LIBVIRT prov uma comum genrica e estvel camada para gerenciamento. A API pode acessar esse hypervisor permitindo o aprovisionamento, criao, modicao, controle, monitoramento, migrao, inicializao e nalizao da VM (virtual machine). No entanto, o suporte a todas essas operaes ir depender da tecnologia de virtualizao utilizada. Com a LIBVIRT, tm-se dois meios de controle distintos. O primeiro demonstrado na Figura 1.18, no lado esquerdo, em que o aplicativo de gerenciamento e os domnios existem no mesmo n. Nesse caso, o aplicativo de gerenciamento trabalha por meio da biblioteca libvirt para controlar os domnios locais. Outros meios de controle existentes so quando o aplicativo de gerenciamento e os domnios esto em ns separados, o que ilustrado na Figura 4.19, lado direito. Este modo usa um daemon especial chamado libvirtd que executado em ns remotos. Tal daemon iniciado automaticamente quando a libvirt instalada em um novo n e pode determinar, de forma automtica, os hypervisors locais e congurar drivers para eles. O aplicativo de gerenciamento se comunica por meio da libvirt local com o libvirt remoto atravs de um protocolo customizado [Bolte et al. 2010]. A API LIBVIRT foi construda para trabalhar atravs de mltiplos ambientes de virtualizao. Dentre as tecnologias de virtualizao temos: QEMU, LXC, OpenVZ, User Mode Linux, KVM, VirtualBox e VMWare. Alm disso, tambm consegue gerenciar as seguintes tecnologias de armazenamento: Storage IDE/SCSI/USB, FiberChannel, LVM, iSCSI e NFS.
40
Figura 1.18. Modos de controle de hypervisor [Wu et al. 2010]
EUCALYPTUS Eucalyptus [Nurmi et al. 2009] um arcabouo aberto para montagem e gerncia de ambientes de computao em nuvem utilizando virtualizao, sendo o seu foco a pesquisa acadmica. Ele prov uma implementao baseada em IaaS (Infraestructure as a Service), ou seja, infraestrutura como recurso nuvem. Os usurios do Eucalyptus so capazes de iniciar, controlar, acessar e nalizar mquinas virtuais (VMs). A atual verso do Eucalyptus suporta VMs, rodando sobre uma hypervisor XEN, mas h planos de utilizar KVM/QEMU e VMWare. O projeto Eucalyptus apresenta quatro caractersticas que o diferenciam de outras solues de computao em nuvem e virtualizao: o Eucalyptus foi projetada para ser simples, de modo que no h a obrigatoriedade da dedicao de recursos; o arcabouo foi projetado para encorajar extenses de software de terceiros; possui uma interface externa que baseada na API EC2 da Amazon; e o Eucalyptus prov uma rede sobreposta virtual que isola o trfego de rede de diferentes usurios, permitindo que clusters remotos paream partes da mesma rede local. A gerncia do Eucalyptus baseada em servios Web, o que oferece alguns benefcios arquitetura, como a exposio da API em forma bem conhecida e funcional como o WSDL (Web Service Description Language), denindo tanto as operaes que seus servios podem desempenhar, quanto as estruturas de dados de entrada e sada utilizadas. A arquitetura dene trs nveis de gerenciamento da infraestrutura de nuvem: Instace Manager (IM): Controla a execuo, inspeco e nalizao das instncias de VMs nos hospedeiros nos quais esto rodando; Group Manager (GM): Suas funcionalidades so as seguintes: escalonamento e gerenciamento de execuo de operaes sobre os IM, controle de operaes sobre a rede virtual sobreposta e reportagem de informaes sobre um conjunto de IMs; Cloud Manager (CM): Interage com os usurios e gerenciadores reportando informaes a respeito dos estados dos recursos da nuvem.
41
O Eucalyptus exvel e pode ser instalado em uma infraestrutura mnima (no mnimo duas mquinas), como tambm em milhares de ncleos e terabytes de armazenamento, Com total integrao sobre uma rede sobreposta de interligao das infraestruturas de nuvem. E-GENI O Enterprise-GENI [E-GENI 2011] uma arquitetura/arcabouo utilizada para gerenciar o uso de fatia em uma infraestrutura baseada em OpenFlow e FlowVisor. O objetivo do arcabouo criar uma interface para visualizao e gerncias de mltiplos experimentos em rede OpenFlow. A Figura 1.19 mostra como est denida a arquitetura do E-GENI.
Figura 1.19. Arquitetura do E-GENI [E-GENI 2011]
A arquitetura do E-GENI dividida em trs partes: OpenFlow-Based Substrate: Composto de switches que se comunicam utilizando o protocolo OpenFlow para uma aplicao do controlador; FlowVisor: Customizado para controlar slice de rede pelo isolamento e controle de trfego de experimentos individuais; Aggregate Manager: Uma aplicao integra o Clearinghouse, responsvel pela manipulao dos experimentos, ao E-GENI FlowVisor utilizando o protocolo SOAP, baseado no GENILight Protocol. O E-GENI vem sendo desenvolvido para integrar redes do tipo OpenFlow ao arcabouo GENI como mais uma alternativa dentro da infraestrutura de experimentao para Internet do Futuro do GENI.
42
1.5. Estudo de Caso

Com o propsito de criao de ambientes experimentais em Internet do Futuro, a comunidade acadmica vem orientando esforos considerveis na criao de ambientes de teste baseados em redes programveis. Baseada em trfegos reais de usurios, a criao de ambientes programveis permite uma abordagem mais realstica com relao escalabilidade da rede e seu comportamento interativo De maneira complementar a esta abordagem com ambientes de teste, este estudo de caso tem por objetivo demonstrar como possvel implementar uma rpida prototipagem de protocolos de rede que seja facilmente aplicvel a redes reais. Ou seja, por meio de um ambiente local, possvel implementar uma funcionalidade que possa ser imediatamente aplicada para testes num ambiente global possibilitando uma maior inovao em redes programveis. Como importante proposta no contexto de redes programveis, neste estudo de caso utiliza-se do arcabouo OpenFlow devido possibilidade de criao de uma infraestrutura de experimentao sobre uma rede de produo. Alm disso, por meio da utilizao do OpenFlow associado virtualizao, demonstra-se como possvel criar, utilizar e gerenciar vrias fatias sobre uma infraestrutura de rede compartilhada, possibilitando que vrios experimentos de protocolos possam ser executados de maneira simultnea. Por meio deste estudo de caso demonstra-se que possvel implementar uma nova funcionalidade, ou mesmo uma nova arquitetura de rede em ambientes locais baseados em software. Estas funcionalidades podem ento ser testadas por seus usurios por meio de largas topologias e com trfegos especcos. Posteriormente, os mesmos cdigos que implementam estas funcionalidades podem ser empregados em ambientes de teste reais. 1.5.1. Denio do Ambiente Para exemplicar a utilizao do OpenFlow associado virtualizao, esse estudo de caso tem como principal objetivo apresentar como se pode desenvolver um ambiente capaz de suportar simultaneamente vrios experimentos de protocolos compartilhando a mesma infraestrutura fsica.
1.5.1.1. Dados de Implementao do Ambiente O estudo de caso formado por um ambiente virtualizado, ou seja, os ns de equipamentos OpenFlow e hosts clientes da redes so elementos de virtualizao. Para implementar esse ambiente com suporte ao arcabouo OpenFlow, utiliza-se dois servidores: um com Xen Server para armazenar os servidores que contm os controladores que so utilizados em cada fatia do experimento e outro servidor utilizando apenas o sistema operacional Linux e o software Mininet [MiniNet 2011]. O Mininet utiliza virtualizao baseada em contineres para criar instncias virtuais de cada comutador (ou host cliente) que seja utilizado no experimento. Alm disso, utiliza-se um comutador para interligar o plano de controle (controlador) e plano de dados (comutadores). A Figura 1.20 ilustra o ambiente que foi desenvolvido para realizao do
43
estudo de caso.
Figura 1.20. Ambiente de teste do estudo de caso
A Tabela 1.1 apresenta, de forma resumida, as informaes e conguraes dos servidores utilizados no estudo de caso.
Tabela 1.1. Dados dos Servidores Dados Sistema Operacional Memria Interface de Rede 1GbE Armazenamento Virtualizao Servidor MiniNet Debian Lenny 5.0 4096 MB 2 320 GB SAS Continer Servidor de Controladores NOX Citrix XenServer 5.6 2048 MB 2 500 GB SATA XEN
No servidor de controladores tm-se trs maquinas virtuais (VM) rodando trs aplicaes diferentes no controlador. Cada controlador se comunica com o FlowVisor usando 3-tuplas de informaes: VLAN, IP e porta TCP do processo servidor do FlowVisor. Com o objetivo de isolar o trfego de cada controlador para eventuais anlises do comportamento das informaes de controle entre o controlador e o FlowVisor so divididas por VLANs, VM1 VLAN 100, VM2 VLAN 200 e VM3 VLAN 300. A Tabela 1.2 contm um resumo dos dados de congurao de cada VM de controlador.
44
Tabela 1.2. Conguraes das VMs com os Controladores NOX Dados Sistema Operacional Memria Interface de Rede 1GbE Endereamento IP VLAN Software Controlador Porta de Conexo com FlowvVisor Armazenamento Aplicao VM 1 Debian Lenny 5.0 512 MB 1 192.168.100.1 100 NOX 0.6 1515 4 GB Switch VM 2 Debian Lenny 5.0 512 MB 1 192.168.200.1 200 NOX 0.6 1516 4 GB Switch e SpanningTree VM 3 Debian Lenny 5.0 512 MB 1 192.168.300.1 300 NOX 0.6 1517 4 GB Switch e Routing
No Servidor Mininet, observa-se dois ambientes distintos virtualizados. O primeiro contm o aplicativo Mininet virtualizando a infraestrutura fsica de comutadores e clientes. E um segundo com o FlowVisor que realiza a criao, remoo e gerncia das fatias no plano de dados do Mininet. A Tabela 1.3 resume as conguraes do servidor Mininet.
Tabela 1.3. Dados do Servidor MiniNet Dados Sistema Operacional Memria Interface de Rede 1GbE Armazenamento Virtualizao de Rede Virtualizao Porta FlowVisor Servidor MiniNet Debian Lenny 5.0 4096 MB 2 320 GB SAS FlowVisor 0.6 Continer Virtuais LXC 6633
Mesmo utilizando a infraestrutura virtualizada de comutadores Openow, os testes aqui executados so totalmente compatveis se aplicados em uma ambiente real de comutadores OpenFlow. Deste modo, o ambiente desenvolvido aqui serve como um ponto de partida no desenvolvimento de uma nova soluo que depois pode ser aplicado em um ambiente maior com elementos OpenFlow reais. 1.5.1.2. Plano de Dados Para o planejamento do plano de dados, foi desenvolvido o um script 1 , que utilizado pelo Mininet, e contm a descrio da topologia e dos elementos que fazem parte da mesma, como: comutadores ou roteadores e hosts (clientes). Para isso utilizado uma API fornecida pela Mininet. A Figura 1.21 ilustra o plano de dados congurado no ambiente Mininet. Para este trabalho optou-se pelo emprego de uma topologia em malha 3x3. O objetivo ter um cenrio com uma quantidade de ns considerveis e que tambm posscripts para o Mininet, assim como as aplicaes NOX podem ser encontrados em http://www.gercom.ufpa.br/minicurso_sbrc
1O
45
Figura 1.21. Topologia e do plano de dados
sibilite ns em comum entre as fatias, de modo a observar entre eles o compartilhamento de recursos e isolamento.
1.5.1.3. Plano de Controle Para o plano de controle foi alocado trs fatias de planos de dados distintos, mostrado na Figura 1.22, nomeados de switch, switch_stp e switch_router. O comportamento de encaminhamento de pacote em cada fatia gerenciado por trs aplicaes NOX, tais como, Switch, Spanning_Tree e Routing. Nas extremidades tm-se os hosts utilizados para gerao de trfego no plano de dados, seja por meio de requisies ICMP ou utilizando uxos TCP ou UDP com uso da aplicao Iperf.
Figura 1.22. Slice dos Experimentos
46
Representando o controle lgico dos pesquisadores, tem-se trs controladores NOX, um em cada VM, associado a uma fatia do plano de dados. Abaixo apresentamos os comandos utilizados e executados em cada VM, para iniciar os controlares NOXs com sua aplicao respectiva:
# nox_core -v -i ptcp:1515 switch # nox_core -v -i ptcp:1516 switch spanning_tree # nox_core -v -i ptcp:1517 switch route
Os comandos acima indicam: iniciao do processo ncleo do NOX (nox_core), onde a opo -v indica o modo de depurao, a opo -i informa o protocolo de transporte e a porta ao qual o NOX estar escutando conexes dos comutadores do plano de dados, e, por m, a aplicao NOX utilizada. Cada um destas fatias deve conectar-se ao seu respectivo controlador NOX inicializado pelos comandos anteriores. As instrues a seguir, utilizando o comando fvctl, efetivam a criao das fatias:
# fvctl createSlice switch tcp:192.168.100.1:1515 research_switch@ufpa.br # fvctl createSlice switch_stp tcp:192.168.200.1:1516 research_switch_stp@ufpa.br # fvctl createSlice switch_router tcp:192.168.300.1:1517 research_router@ufpa.br
O comando fvctl permite a gerncia das fatias, portanto os parmetros dos comandos acima indicam: createSlice o tipo de ao que aplicado fatia; switch descreve o nome da fatia a ser criado; tcp:192.168.100.1:1515 apresenta o endereo do controlador vinculado fatia; e no nal dene-se o correio eletrnico do responsvel. Ao nal de cada entrada solicitada a criao de uma senha para fatia especca, provendo um controle de acesso a cada operao na fatia. O comando a seguir lista as fatias criadas atualmente:
# fvctl listSlices Enter roots password: Slice 0: root Slice 1: switch Slice 2: switch_stp Slice 3: switch_router
1.5.2. Aplicao Prtica A primeira aplicao apenas efetua o encaminhamento de pacote na camada 2, com um comportamento de comutador; a segunda, alm de efetuar o encaminhamento na camada 2 via comutador, tambm trata o aparecimento de ciclos na rede atravs do algoritmo SpanningTree; e, a terceira, habilita o roteamento de pacotes. Fatia Switch Para a fatia Switch, foi designado a topologia representada pela Figura 1.23. Nesta topologia, tm-se dois hosts clientes, um em cada extremidade da topologia da fatia, gerando uxo de pacotes entre eles.
47
Figura 1.23. Slice Switch
Os comandos abaixo alocam os recursos para o slice Switch. A denio inclui a especicao dos ns que compem o plano de dados e a caracterstica do uxo que percorre o plano de dados.
# fvctl addFlowSpace 00:00:00:00:00:01 10 dl_vlan=100 Slice:switch=4 # fvctl addFlowSpace 00:00:00:00:00:02 10 dl_vlan=100 Slice:switch=4 # fvctl addFlowSpace 00:00:00:00:00:03 10 dl_vlan=100 Slice:switch=4
Neste comando os parmetros so as ags, addFlowSpace, que adiciona o recurso identicado pelo Datapath, a prioridade de execuo (10) , onde quanto maior o valor da prioridade mais rpido a informao da fatia processada, e, por m, Slice:switch=4 que indica a qual fatia o recurso alocado. Nos comandos acima se tem a adio dos ns SW01, SW02 e SW03 formando a topologia da fatia Switch, neste caso os ns so identicados pelos endereos Datapath 00:00:00:00:00:01, 00:00:00:00:00:02 e 00:00:00:00:00:03, respectivamente. Para identicar os uxos acrescentados fatia foram utilizados elementos de camada 2, neste caso pelo vlan_id 100. O que se percebe que, dependendo da camada onde o experimento realizado, precisa-se de elementos dessa camada para identicar o uxo que faz parte daquela fatia. Nesta aplicao o comportamento do comutador consiste em analisar cada pacote e aprender sobre sua porta de origem, associando o endereo MAC de origem porta onde o mesmo est conectado. Caso o destino do pacote j esteja associado a uma dada porta, o pacote ser enviado diretamente, caso contrrio, o comutador realizar a ao de ood, ou seja, encaminha para todas as portas. Aps a incluso dos ns na fatia Switch, os ns OpenFlow passam a ser reconhecidos pelo NOX correspondente fatia, e a executar as aes da aplicao instanciada na mesma. Para ilustrar o funcionamento da aplicao Switch, aplica-se um uxo ICMP do tipo ECHO_REQUEST e ECHO_REPLY entre os hosts da fatia. Na primeira tentativa de comunicao so trocadas informaes de controle entre os comutadores da fatia e o controlador. Como o pacote desconhecido aplicada a todos os ns a ao FLOOD,
48
como mostra a Figura 1.24.
Figura 1.24. Encaminhamento dos primeiros pacotes
Para os pacotes seguintes que possuem o mesmo destino como o primeiro pacote, e como o controlador j aprendeu a porta que possui o MAC correspondente de destino, ele muda a ao de FLOOD para a porta correspondente, de modo a alcanar o n de destino. Como mostrado na Figura 1.25.
Figura 1.25. Tabela de uxo aps o conhecimento do n de destino
Fatia STP O protocolo STP possibilita a incluso de ligaes redundantes entre os comutadores, provendo caminhos alternativos no caso de falha de uma dessas ligaes. Nesse contexto, seu objetivo evitar a formao de ciclos entre os comutadores e permitir a ativao e desativao automtica dos caminhos alternativos.
49
Para a fatia denominado switch_stp, optou-se por implementar a topologia representada pela Figura 1.26. Nesta topologia tem-se um cenrio no qual h presena de ciclos no caminho entre os hosts nais. O objetivo, neste caso, tratar este problema por meio da implementao do algoritmo SpanningTree no ambiente do controlador.
Figura 1.26. Slice STP
A alocao de recursos fatia switch_stp feita de maneira similar ao que foi implementado para a fatia switch. Para este m, deve-se executar a seguinte sequncia de comandos:
# fvctl addFlowSpace 00:00:00:00:00:04 10 dl_vlan=200 Slice:switch_stp=4 # fvctl addFlowSpace 00:00:00:00:00:05 10 dl_vlan=200 Slice:switch_stp=4 # fvctl addFlowSpace 00:00:00:00:00:07 10 dl_vlan=200 Slice:switch_stp=4 # fvctl addFlowSpace 00:00:00:00:00:08 10 dl_vlan=200 Slice:switch_stp=4
Os comandos denem os recursos da fatia switch_stp, que neste caso so os uxos de pacotes com vlan_id igual a 200. E tambm os ns utilizados, tais como: SW4 (Datapath 00:00:00:00:00:04); SW5 (Datapath 00:00:00:00:00:05); SW7 (Datapath 00:00:00:00:00:07); e SW8 (Datapath 00:00:00:00:00:08). No mdulo STP, quando um novo comutador conecta-se ao controlador NOX, o mdulo registra o n e neste momento desabilita a operao de FLOOD em todas as suas portas. Periodicamente o mdulo realiza consultas com todos os enlaces para montar a lista de elementos da topologia. Esta lista utilizada para a construo da rvore geradora (Spanning Tree). De modo que, todos os comutadores candidatos so alocados em uma lista e ordenados (de maneira crescentemente) por meio de seu Datapath; O primeiro elemento removido da lista e denido como "comutador raiz"da rvore geradora. Este procedimento ento executado para todos os comutadores candidatos que compem a lista. O mdulo Spanning Tree, tambm utiliza o mdulo de descoberta do NOX, chamado Discovery, para localizar as ligaes dos comutadores com os seus ns
50
vizinhos. Como realizado no experimento anterior, foi gerado um uxo ICMP entre os hosts clientes que utilizam a fatia switch_stp. Uma vez encontrada a topologia, atravs do mdulo Discovery, o algoritmo calcula a melhor forma de desfazer o ciclo, desabilitando umas das portas do comutador que foi escolhida no clculo. Na Figura 1.27, os itens numerados de 1 a 5 mostram o processo de reconhecimento de caractersticas dos comutadores que compem a fatia, alm da convergncia da aplicao na habilitao (e no-habilitao) de portas.
Figura 1.27. Log do controlador sobre as decises do STP
O item 1 corresponde descoberta dos comutadores, neste momento o comando de non-ood enviado em todas as portas dos comutadores OpenFlow descobertos, representados por valores numricos. No item 2, o primeiro comutador selecionado, tem suas portas 1, 3 e 4 habilitadas para ood e a porta 2 desabilitada. Deste modo o algoritmo segue para os prximos comutadores candidatos conforme itens 3, 4 e 5 at que a rvore esteja formada e o protocolo convirja completamente, habilitando assim o trfego entre os dois hosts. A partir desse momento o encaminhamento dos dados igual ao do mdulo comutador. Fatia Roteamento Na fatia switch_router utiliza-se a aplicao de routing. Esta aplicao possui a capacidade de aplicar aos ns o comportamento de roteadores, efetuando encaminhamento na camada 3. A Figura 1.28 exibe como os recursos de rede que so visualizados pelo controlador NOX que est habilitado com a aplicao routing. Para aplicar os ns que fazem parte da fatia neste experimento, a seguinte congurao foi realizada:
51
Figura 1.28. Viso do controlador do fatia Roteamento
# fvctl addFlowSpace 00:00:00:00:00:01 10 dl_vlan=300 Slice:switch_router=4 # fvctl addFlowSpace 00:00:00:00:00:02 10 dl_vlan=300 Slice:switch_router=4 # fvctl addFlowSpace 00:00:00:00:00:03 10 dl_vlan=300 Slice:switch_router=4 # fvctl addFlowSpace 00:00:00:00:00:06 10 dl_vlan=300 Slice:switch_router=4 # fvctl addFlowSpace 00:00:00:00:00:09 10 dl_vlan=300 Slice:switch_router=4
Para esta fatia utilizou-se os comutadores SW01, SW02, SW03, SW06 e SW09. Cada host est endereado com sub-redes diferentes por meio das seguintes conguraes de endereamento IP listados pela Tabela 5.
Tabela 1.4. Endereamento IP dos hosts ligados ao slice Host Host02 Host04 Host05 Endereo IP 192.168.1.5 192.168.1.6 10.1.1.7 Sub-rede 192.168.1.0/24 192.168.1.0/24 10.1.1.0/24
Para testar o encaminhamento de pacotes via camada 3, utiliza-se dois uxos de pacotes, sendo o primeiro UDP e o segundo TCP. Desta forma, entre os hosts 02 e 04 tm-se um uxo TCP na porta 200 e entre os hosts 02 e 05 tm-se um uxo UDP na porta 100. O que se percebeu nesse experimento que na primeira tentativa de estabelecimento de comunicao entre os hosts, tanto para uxo TCP quanto UDP, so trocadas informaes de controle (comutador e controlador), para determinar o que fazer com esse uxo. Os primeiros pacotes so enviados para a la, atravs da ao IN_QUEUE, ilustrado na Figura 1.29, para evitar a perda de pacote, enquanto se determina a sua rota. Quando a rota determinada, so aplicadas as aes de encaminhamento para cada n OpenFlow do caminho encontrado, conforme ilustrado na Figura 1.30. De forma que
52
essa rota calculada apenas uma vez quando o primeiro pacote entra no roteador, os demais usam as aes que j foram aplicadas. O que se observa que quando um pacote destinado a um host que est nesta mesma sub-rede, o n age como um comutador, encaminhando o pacote sem alteraes para uma porta conhecida. Caso um pacote seja destinado para um endereo IP no qual o roteador conhece o prximo salto, o mesmo utiliza a rota previamente denida e aplica as aes de encaminhamento para cada comutador na rota determinada.
Figura 1.29. Aes aplicadas a tabela de uxo dos ns openow durante o primeiro pacote
Figura 1.30. Aps a passagem dos primeiro pacote
Tambm se observou que esta aplicao de roteamento no baseada em algoritmos especcos tais como de vetor de distncias ou estado de enlaces. O que se percebe a necessidade de melhorias e novas idias para a aplicao de roteamento. Nesse sentido,
53
existem exemplos de esforos vem sendo desenvolvido para aplicar essas caractersticas, como o caso da aplicao QuagFlow [Nascimento et al. 2010]. Por meio do QuagFlow possvel aplicar algoritmos de roteamento baseado no conjunto de aplicaes disponveis do Quagga [Quagga 2011], para uso no OpenFlow. Desse modo, algoritmos como RIP ou OSPF, implementados no Quagga, podem ser utilizados pelo NOX para atender aos requisitos mais exigentes de roteamento. 1.5.3. Concluso O estudo de caso mostrou que de uma maneira rpida e simplicada possvel construir infraestruturas prontas para experimento de protocolos baseadas em redes OpenFlow. Alm disso, uma excelente ferramenta para experimentao em Internet do Futuro (IF). Observou-se que com pequenos recursos possvel iniciar estes estudos para IF virtualizando todo plano de dados alinhado s necessidades de um ambiente real. Um ponto fraco da soluo seria a no disponibilidade de interfaces de mais alto nvel, como por exemplo interfaces web que facilitem a interao com FlowVisor. O que deixa a sua manipulao fortemente dependente do administrador da rede para criao da fatia do experimento com alta probabilidade de falha durante a insero de comandos.
1.6. Consideraes nais e o futuro em Pesquisa Experimental em Internet do Futuro

1.6.1. Consideraes Finais A virtualizao tornou-se a principal ferramenta para pesquisa de desenvolvimento e habilitao da Internet do Futuro em todas as comunicaes ou camadas computacionais dessas grandes infraestruturas. Com o uso da virtualizao na construo desses ambientes de teste foi possvel desacoplar a complexidade dos recursos fsicos dos servios oferecidos e apresentar simples interfaces com usurio, em localizaes geogrcas distintas e independentes de dispositivo de acesso. Alm disso, a virtualizao ter um papel importante, pois ela permitir a comparao das novas tecnologias que esto sendo desenvolvidas para Internet do Futuro, com as tecnologias atuais. Tambm garantir que tecnologias desenvolvidas no passado possam ser disponveis nessa moderna infraestrutura. Com isso, a construo dos arcabouos para esses ambientes de teste est sendo desenvolvida com base na virtualizao, seja ela baseada na virtualizao do substrato, seja na infraestrutura fsica que contm todos os hardware e software para inicializar os recursos virtuais, bem como para a criao da infraestrutura virtual contendo os recursos virtuais e a topologia lgica, interligando-as. O arcabouo OpenFlow uma dessas solues, pois prov um protocolo aberto para programao do comportamento de uxos de pacote em diferentes comutadores e roteadores. A rede contendo OpenFlow pode ter o trfego particionado entre trfego de produo e trfego de experimentao, de maneira que pesquisadores possam controlar seus prprios uxos. A rede de produo permanecer isolada e processada da mesma maneira que antes do uso do OpenFlow.
54
Ainda, o OpenFlow integrado com a ferramenta FlowVisor capaz de criar e virtualizar elementos de redes de modo que uma mesma infraestrutura fsica possa ser compartilhada entre vrias topologias lgicas, onde cada uma possui sua prpria lgica de encaminhamento e tratamento de uxos de pacotes distintos. Por m, o OpenFlow possibilita de maneira rpida e simples a criao de uma infraestrutura para concepo de novos protocolos, como apresentada na seo de estudos de casos onde em um nico servidor, conseguimos simular uma infraestrutura de comutadores e roteadores OpenFlow. Tambm conseguimos aplicar os conceitos de virtualizao baseada em fatias de recursos e redes programveis. Este captulo apresentou o andamento da pesquisa experimental em Internet do Futuro no mundo e observou duas grandes tecnologias que estaro presentes nessas infraestruturas montadas em escala mundial. So elas: a virtualizao e o arcabouo OpenFlow. 1.6.2. Tendncias Futuras Nossa observao que esta busca pela Internet do Futura ainda est em sua fase inicial, porm se expandindo com rapidez em algumas regies do mundo. Liderando esta busca esto os EUA, a UE e o Japo, seguida por Coreia, China e Brasil. Nos EUA o programa GENI est iniciando a sua terceira fase, a chamada espiral 3, e as tendncias, nesta terceira fase, ser iniciar o suporte de pesquisadores nas infraestruturas de experimentao e a incrementao de recursos disponveis para uso entre seus usurios, atravs de integrao chamada meso-scale, envolvendo a participao de maior nmero de universidades interligadas pelas grandes redes de pesquisa, Internet2 e NLR. Alm disso, a nfase ser em ambientes de redes mveis 4G na periferia, integradas por redes pticas e Ethernet nas redes xas, e a nfase no uso de tecnologia OpenFlow, para possibilitar experimentao com redes denidas por software. O GENI est sendo complementado pelo novo programa Future Internet Architectures (FIA), lanado em 2010 pela NSF, para fomentar pesquisa em novas arquiteturas, que poderiam ser validadas no ambiente GENI. J na Europa, o programa FIRE, que deu incio no nal de 2010 segunda rodada de grandes projetos, incluindo OFELIA, o primeira projeto europeu com OpenFlow. Diferente dos EUA, onde foram separados os programas FIA (pesquisa em arquiteturas) e GENI (ambiente de teste), os europeus misturam ambos facetas no mesmo projeto, atravs do estudo de casos de uso dos ambientes montados. No Japo, representado pelo projeto AKARI, que est na em seu segundo perodo desenvolvimento, tendncia futura para incio das construes de seus ambientes de teste e as primeiras demonstraes experimentais. O objetivo que para o nal de 2016 oferecer um prottipo da nova gerao de rede para disponibilidade aos pesquisadores. OpenFlow tambm importante no Japo e a empresa NEC est apostando na importncia desta tecnologia para seu portflio de produtos das categorias comutador e controlador. Por m, no Brasil, a pesquisa em Internet do Futuro iniciou atravs de projetos isolados, como o projeto Horizon [Horizon 2011] e o projeto Webscience [WebScience 2010] que prev a construo de uma rede para experimentao em arquiteturas de Internet do
55
Futuro. Este ltimo projeto servia como uma das bases para a proposta de cooperao com um consrcio europeu, atravs do projeto FIBRE submetido s Chamadas Coordenadas em TIC entre Brasil e a UE. O projeto FIBRE, se conrmado, tornar possvel a construo de uma instalao experimental compartilhada de larga escala, que permita a experimentao em infraestrutura de rede e aplicaes distribudas. Isso consistir em um novo ambiente de teste baseado em OpenFlow no Brasil e uma melhoria dos recursos dos projetos OFELIA e OneLab, atualmente em desenvolvimento na Europa. Alm disso, possibilitar a federao de ambientes de teste dos parceiros brasileiros e europeus para permitir aos pesquisadores que usem recursos de ambos em um mesmo experimento. Tal iniciativa demonstrar o potencial das instalaes ao mostrar aplicaes baseadas em OpenFlow, estabelecidas sobre os recursos das instalaes federadas. Portanto, aumentar a colaborao e a troca de conhecimentos entre pesquisadores europeus e brasileiros no campo de Internet do Futuro.
Agradecimentos
Este trabalho esta sendo apoiado por recursos nanciados pelas seguintes instituies: FAPESPA, CAPES, CNpQ e RNP.
Referncias
[AKARI 2009] AKARI (2009). New generation network architecture: Akari conceptual design. Technical report, National Institute of Information and Communications Technology. http://akari-project.nict.go.jp/eng/concept-design/AKARI_fulltext _e_preliminary.pdf. [Andersen et al. 2001] Andersen, D., Balakrishnan, H., Kaashoek, F., and Morris, R. (2001). Resilient overlay networks. SIGOPS Oper. Syst. Rev., 35:131145. [Andersen 2003] Andersen, D. G. (2003). Mayday: distributed ltering for internet services. In Proceedings of the 4th conference on USENIX Symposium on Internet Technologies and Systems - Volume 4, USITS03, pages 33, Berkeley, CA, USA. USENIX Association. [Balakrishnan et al. 2004] Balakrishnan, H., Lakshminarayanan, K., Ratnasamy, S., Shenker, S., Stoica, I., and Walsh, M. (2004). A layered naming architecture for the internet. SIGCOMM Comput. Commun. Rev., 34:343352. [Banniza et al. 2009] Banniza, T.-R., Boettle, D., Klotsche, R., Schefczik, P., Soellner, M., and Wuenstel, K. (2009). A european approach to a clean slate design for the future internet. Bell Lab. Tech. J., 14:522. [BEACON 2011] BEACON (2011). Java-based openow controller. Disponvel em: http://www.openowhub.org/display/Beacon/Beacon+Home.Acessado em: 20/02/11. [BEN 2011] BEN (2011). Breakable experimental network. Disponvel em: https://geniorca.renci.org/trac. Acesso em: 20/02/2011.
56
[Bhatia et al. 2008] Bhatia, S., Motiwala, M., Muhlbauer, W., Mundada, Y., Valancius, V., Bavier, A., Feamster, N., Peterson, L., and Rexford, J. (2008). Trellis: a platform for building exible, fast virtual networks on commodity hardware. In Proceedings of the 2008 ACM CoNEXT Conference, CoNEXT 08, pages 72:172:6, New York, NY, USA. ACM. [Bi 2011] Bi, J. (2011). Future internet related research activities in china. Disponvel em: http://www.apan.net/meetings/Hanoi 2010/Session/Slides/FutureInternet/3-1.pdf . Acesso em 20/02/2011. [Bolte et al. 2010] Bolte, M., Sievers, M., Birkenheuer, G., Niehorster, O., and Brinkmann, A. (2010). Non-intrusive virtualization management using libvirt. In Design, Automation Test in Europe Conference Exhibition (DATE), 2010, pages 574 579. [BonFIRE 2011] BonFIRE (2011). Building service testbeds on future internet research and experimentation. Disponvel em: http://www.bonre-project.eu/project . Acesso em: 20/02/2011. [Campanella 2011] Campanella, M. (2011). Federica: A virtualization based infrastructure for future and present internet research. In Akan, O., Bellavista, P., Cao, J., Dressler, F., Ferrari, D., Gerla, M., Kobayashi, H., Palazzo, S., Sahni, S., Shen, X. S., Stan, M., Xiaohua, J., Zomaya, A., Coulson, G., Magedanz, T., Gavras, A., Thanh, N. H., and Chase, J. S., editors, Testbeds and Research Infrastructures. Development of Networks and Communities, volume 46 of Lecture Notes of the Institute for Computer Sciences, Social Informatics and Telecommunications Engineering, pages 123132. Springer Berlin Heidelberg. 10.1007/978-3-642-17851-1_9. [Chowdhury and Boutaba 2010] Chowdhury, N. M. K. and Boutaba, R. (2010). A survey of network virtualization. Comput. Netw., 54:862876. [Chu et al. 2001] Chu, Y., Rao, S., Seshan, S., and Zhang, H. (2001). Enabling conferencing applications on the internet using an overlay muilticast architecture. SIGCOMM Comput. Commun. Rev., 31:5567. [Clack 2011] Clack, D. C. (2011). Toward the design of a future internet. technical report: National science fundation. Disponvel em: http://groups.csail.mit.edu/ana/People/DDC/Future Internet 7-0.pdf. National Science Fundation. [CREW 2011] CREW (2011). Cognitive radio experimentation world. Disponvel em: http://www.crew-project.eu/. Acesso em: 20/02/2011. [Dabek et al. 2001] Dabek, F., Kaashoek, M. F., Karger, D., Morris, R., and Stoica, I. (2001). Wide-area cooperative storage with cfs. SIGOPS Oper. Syst. Rev., 35:202 215. [E-GENI 2011] E-GENI (2011). Enterprise geni. Disponvel http://OpenFlow.org/wk/index.php/E-GENI Acesso em: 20/02/2011. em:
57
[Egi et al. 2010] Egi, N., Greenhalgh, A., Handley, M., Hoerdt, M., Huici, F., Mathy, L., and Papadimitriou, P. (2010). A platform for high performance and exible virtual routers on commodity hardware. SIGCOMM Comput. Commun. Rev., 40:127128. [Eide et al. 2006] Eide, E., Stoller, L., Stack, T., Freire, J., and Lepreau, J. (2006). Integrated scientic workow management for the emulab network testbed. In Proceedings of the annual conference on USENIX 06 Annual Technical Conference, pages 3333, Berkeley, CA, USA. USENIX Association. [Feldmann 2007] Feldmann, A. (2007). Internet clean-slate design: what and why? SIGCOMM Comput. Commun. Rev., 37:5964. [FIND 2011] FIND (2011). Future internet design. http://www.nets-nd.net. [Fink and R. 2011] Fink, B. and R., S. (2011). Nuttcp. Disponvel em: ftp://ftp/lcp.nrl.navy.mil/pub/nuttcp/2006. Acesado em: 20/02/2011. [FIRE 2008] FIRE (2008). Future internet research and experiment: Area 6. Disponvel em: http://www.futureInternet.eu/leadmin/documents/bled_documents/experiemental_facilities/FIREIssues-paper-2.2.pdf. [FIRE 2010] FIRE (2010). Future internet research and experimentation: An overview of european re initiative and its projects. Technical report, Disponvel em: http://cordis.europa.eu/fp7/ict/re/docs/re-brochure-201_en.pdf. [FIRE 2011] FIRE (2011). Future internet research and experimentation. http://cordis.europa.eu/fp7/ict/re/. FP7 - Seventh Framework Programme. [GENI 2011] GENI (2011). http://www.geni.net. Global environment for network innovations.
[GENI-Sys 2008] GENI-Sys (2008). Geni system overview. Disponvel em: http://groups.geni.net/geni/attachment/wiki/GeniSysOvrvw/GENISysOvrvw092908.pdf. [Greene 2009] Greene, K. (2009). Tr10: Software-dened networking. http://www.technologyreview.com/printer_friendly_article.aspx?id=22120. [Gude et al. 2008] Gude, N., Koponen, T., Pettit, J., Pfaff, B., Casado, M., McKeown, N., and Shenker, S. (2008). Nox: towards an operating system for networks. SIGCOMM Comput. Commun. Rev., 38:105110. [Horizon 2011] Horizon (2011). Horizon project: A new horizon to the internet. Disponvel em: http://www.gta.ufrj.br/horizon/. Acesso em: 20/02/2011. [Hu et al. 2010] Hu, J.-W., Chen, H.-M., Liu, T.-L., Tseng, H.-M., Lin, D., Yang, C.-S., and Yeh, C. (2010). Implementation of alarm correlation system for hybrid networks based upon the perfsonar framework. In Advanced Information Networking and Applications Workshops (WAINA), 2010 IEEE 24th International Conference on, pages 893 898.
58
[INDIGO 2011] INDIGO (2011). Disponvel http://www.OpenFlowhub.org/display/Indigo/Indigo+-+Open Flow+for+Hardware+Switches. Acesso em: 20/02/2011.
em:
[Jain 2006] Jain, R. (2006). Internet 3.0: ten problems with current internet architecture and solutions for the next generation. In Proceedings of the 2006 IEEE conference on Military communications, MILCOM06, pages 153161, Piscataway, NJ, USA. IEEE Press. [Jannotti et al. 2000] Jannotti, J., Gifford, D. K., Johnson, K. L., Kaashoek, M. F., and OToole, Jr., J. W. (2000). Overcast: reliable multicasting with on overlay network. In Proceedings of the 4th conference on Symposium on Operating System Design & Implementation - Volume 4, OSDI00, pages 1414, Berkeley, CA, USA. USENIX Association. [Joseph and Lewis 2008] Joseph, W. and Lewis, C. (2008). Green: The new computing coat of arms? IT Professional, 10:1216. [Kim et al. 2009] Kim, D. Y., Mathy, L., Campanella, M., Summerhill, R., Williams, J., Shimojo, S., Kitamura, Y., and Otsuki, H. (2009). Future internet: Challenges in virtualization and federation. Advanced International Conference on Telecommunications, 0:18. [Krishnamurthy et al. 2001] Krishnamurthy, B., Wills, C., and Zhang, Y. (2001). On the use and performance of content distribution networks. In Proceedings of the 1st ACM SIGCOMM Workshop on Internet Measurement, IMW 01, pages 169182, New York, NY, USA. ACM. [Liu et al. 2009] Liu, J., Cho, S., Han, S., Kim, K., Ha, Y., Choe, J., Kamolphiwong, S., Choo, H., Shin, Y., and Kim, C. (2009). Establishment and trafc measurement of overlay multicast testbed in koren, thairen and tein2. In Proceedings of the 6th International Conference on Mobile Technology, Application & Systems, Mobility 09, pages 42:142:7, New York, NY, USA. ACM. [Lockwood et al. 2007] Lockwood, J. W., McKeown, N., Watson, G., Gibb, G., Hartke, P., Naous, J., Raghuraman, R., and Luo, J. (2007). Netfpgaan open platform for gigabit-rate network switching and routing. In Proceedings of the 2007 IEEE International Conference on Microelectronic Systems Education, MSE 07, pages 160161, Washington, DC, USA. IEEE Computer Society. [Lua et al. 2005] Lua, E. K., Crowcroft, J., Pias, M., Sharma, R., and Lim, S. (2005). A survey and comparison of peer-to-peer overlay network schemes. Communications Surveys Tutorials, IEEE, 7(2):72 93. [McKeown 2011] McKeown, N. (2011). Clean http://cleanslate.stanford.edu/. Stanford Univesity. slate research program.
[McKeown et al. 2008] McKeown, N., Anderson, T., Balakrishnan, H., Parulkar, G., Peterson, L., Rexford, J., Shenker, S., and Turner, J. (2008). Openow: enabling innovation in campus networks. SIGCOMM Comput. Commun. Rev., 38:6974.
59
[MiniNet 2011] MiniNet (2011). Rapid prototyping for software-dened networks. Disponvel em: http://yuba.stanford.edu/foswiki/bin/view/OpenFlow/Mininet. Acessado em: 20/02/11. [Moskowitz and Nikander 2005] Moskowitz, R. and Nikander, P. (2005). Host identity protocol architecture. Internet draf, IETF. [Moskowitz et al. 2005] Moskowitz, R., Nikander, P., Jokela, P., and Henderson, T. (2005). Host identity protocol. Internet draf, IETF. [Nascimento et al. 2010] Nascimento, M. R., Rothenberg, C. E., Salvador, M. R., and Magalhes, M. F. (2010). Quagow: partnering quagga with openow. In Proceedings of the ACM SIGCOMM 2010 conference on SIGCOMM, SIGCOMM 10, pages 441 442, New York, NY, USA. ACM. [Nurmi et al. 2009] Nurmi, D., Wolski, R., Grzegorczyk, C., Obertelli, G., Soman, S., Youseff, L., and Zagorodnov, D. (2009). The eucalyptus open-source cloud-computing system. In Proceedings of the 2009 9th IEEE/ACM International Symposium on Cluster Computing and the Grid, CCGRID 09, pages 124131, Washington, DC, USA. IEEE Computer Society. [OFELIA 2011] OFELIA (2011). Openow in europe - linking infrastructure and applications. Disponvel em: http://www.fp7-ofelia.eu/. Acesso em: 20/02/2011. [OMF 2011] OMF (2011). control and management framework. http://omf.mytestbed.net. Acesso em: 20/02/2011. Disponvel:
[ORCA 2011] ORCA (2011). Open resource control architecture. Disponvel em: http://groups.geni.net/ geni/wiki/ORCABEN. Acesso em: 20/02/2011. [Paul et al. 2011] Paul, S., Pan, J., and Jain, R. (2011). Architectures for the future networks and the next generation internet: A survey. Comput. Commun., 34:242. [Peterson et al. 2006] Peterson, L., Muir, S., Roscoe, T., and Klingaman, A. (2006). Planetlab architecture: An overview. Disponvel em: http://www.planetlab.org/les/pdn/pdn-06-031/pdn-06-031.pdf, PLANTLAB. [Peterson et al. 2009] Peterson, L., Sevinc, S., Lepreau, J., and et al. (2009). Slicebased facility architecture, draft version 1.04. Disponivel em: http://svn.planetlab.org/attachment/wiki/GeniWrapper/sfa.pdf. [ProtoGENI 2011] ProtoGENI (2011). Disponvel http://groups.geni.net/geni/wiki/ProtoGENI. Acesso em: 20/02/2011. em:
[Ps-Performace 2011] Ps-Performace (2011). ps-performace toolkit. Disponvel em: http://www.internet2.edu/performance/toolkit. Acesso em: 20/02/2011. [Quagga 2011] Quagga (2011). Quagga routing suite. http://www.quagga.net/. Acesso em: 14/03/2011. Disponvel em:
60
[Rexford and Dovrolis 2010] Rexford, J. and Dovrolis, C. (2010). Future internet architecture: clean-slate versus evolutionary research. Commun. ACM, 53:3640. [Savage et al. 1999] Savage, S., Anderson, T., Aggarwal, A., Becker, D., Cardwell, N., Collins, A., Hoffman, E., Snell, J., Vahdat, A., Voelker, G., and Zahorjan, J. (1999). Detour: informed internet routing and transport. Micro, IEEE, 19(1):50 59. [Scarabucci et al. 2005] Scarabucci, R. R., Stanton, M. A., de Barros, M. R. X., Salvador, M. R., Rossi, S. M., Sim?, F. D., Rocha, M. L., da Silva Neto, I. L., Rosolem, J. B., Fudoli, T. R. T., Mendes, J. M. D., Castro, N. F., Machado, I., Reggiani, A. E., Paradisi, A., and Martins, L. (2005). Project giga-high-speed experimental ip/wdm network. Testbeds and Research Infrastructures for the Development of Networks & Communities, International Conference on, 0:242251. [Shalunov 2011] Shalunov, S. (2011). Thrulay - network capacity tester. Disponvel em: http://shlang.com/thrulay/, Acesso em: 20/02/2011. [Sherwood et al. 2010a] Sherwood, R., Chan, M., Covington, A., Gibb, G., Flajslik, M., Handigol, N., Huang, T.-Y., Kazemian, P., Kobayashi, M., Naous, J., Seetharaman, S., Underhill, D., Yabe, T., Yap, K.-K., Yiakoumis, Y., Zeng, H., Appenzeller, G., Johari, R., McKeown, N., and Parulkar, G. (2010a). Carving research slices out of your production networks with openow. SIGCOMM Comput. Commun. Rev., 40:129130. [Sherwood et al. 2009] Sherwood, R., Gibb, G., Yap, K., Appenzeller, G., McKeown, N., and Parulkar, G. (2009). Flowvisor: A network virtualization layer. Disponvel em: http://OpenFlowswitch.org/downloads/technicalreports/OpenFlow-tr2009-1owvisor.pdf. [Sherwood et al. 2010b] Sherwood, R., Gibb, G., Yap, K.-K., Appenzeller, G., Casado, M., McKeown, N., and Parulkar, G. (2010b). Can the production network be the testbed? In Proceedings of the 9th USENIX conference on Operating systems design and implementation, OSDI10, pages 16, Berkeley, CA, USA. USENIX Association. [Spiral2 2010] Spiral2 (2010). Geni spiral 2 overview. Disponvel em: http://groups.geni.net/geni/attachment/wiki/SpiralTwo/GENIS2Ovrvw060310.pdf. [Stoica et al. 2004] Stoica, I., Adkins, D., Zhuang, S., Shenker, S., and Surana, S. (2004). Internet indirection infrastructure. IEEE/ACM Trans. Netw., 12:205218. [Subramanian et al. 2004] Subramanian, L., Stoica, I., Balakrishnan, H., and Katz, R. H. (2004). Overqos: an overlay based architecture for enhancing internet qos. In Proceedings of the 1st conference on Symposium on Networked Systems Design and Implementation - Volume 1, pages 66, Berkeley, CA, USA. USENIX Association. [Szegedi et al. 2009] Szegedi, P., Figuerola, S., Campanella, M., Maglaris, V., and Cervello-Pastor, C. (2009). With evolution for revolution: managing federica for future internet research. Communications Magazine, IEEE, 47(7):34 39.
61
[Tierney et al. 2009] Tierney, B., Metzger, J., Berkeley, L., Laboratory, N., Boote, J., Boyd, E., Brown, A., Carlson, R., Zekauskas, M., and Internet, J. Z. (2009). perfsonar: Instantiating a global network measurement framework. Disponvel em: http://acs.lbl.gov/ tierney/papers/perfsonar-LBNL-report.pdf. [UMF 2011] UMF (2011). Embedding real-time substrate measurements for crosslayer communications. Disponvel em: http://groups.geni.net/geni/wiki/Embeddedem: 20/02/2011. [WebScience 2010] WebScience (2010). Brazilian institute for web science research. Disponvel em: http://webscience.org.br/les/INCTportugues2010.pdf. Acesso em:20/02/2011. [Wu et al. 2010] Wu, S., Deng, L., Jin, H., Shi, X., Zhao, Y., Gao, W., Zhang, J., and Peng, J. (2010). Virtual machine management based on agent service. In Parallel and Distributed Computing, Applications and Technologies (PDCAT), 2010 International Conference on, pages 199 204. [Yu et al. 2010] Yu, M., Rexford, J., Freedman, M. J., and Wang, J. (2010). Scalable ow-based networking with difane. SIGCOMM Comput. Commun. Rev., 40:351362.
62
Captulo
2
Explorando Redes Sociais Online: Da Coleta e Anlise de Grandes Bases de Dados s Aplicaes
Fabrcio Benevenuto, Jussara M. Almeida e Altigran S. Silva
Resumo Redes sociais online tm se tornado extremamente populares, levando ao surgimento e crescente popularizao de uma nova onda de aplicaes na Web. Associado a esse crescimento, redes sociais esto se tornando um tema central de pesquisas em diversas reas da Cincia da Computao. Este mini-curso oferece uma introduo ao pesquisador que pretende explorar esse tema. Inicialmente, apresentamos as principais caractersticas das redes sociais mais populares atualmente. Em seguida, discutimos as principais mtricas e anlises utilizadas no estudo dos grafos que formam a topologia das redes sociais. Finalmente, sumarizamos as principais abordagens para coleta e tratamento de dados de redes sociais online e discutimos trabalhos recentes que ilustram o uso de tais tcnicas. Abstract Online social networks have become extremely popular, causing the deployment and increasing popularity of a new wave of applications on the Web. Associated with this popularity growth, online social networks are becoming a key theme in several research areas. This short course offers an introduction to the researcher who aims at exploring this theme. Initially, we present the main characteristics of current online social network applications. Then, we discuss the main metrics and analyses employed to study the graphs that represent the social network topologies. Finally, we summarize the main approaches used to collect and process online social network datasets, and discuss recent work that illustrates the use of such approaches.
64
2.1. Introduo
Desde seu incio, a Internet tem sido palco de uma srie de novas aplicaes, incluindo email, aplicaes par-a-par, aplicaes de comrcio eletrnico assim como vrios servios Web. Atualmente, a Web vem experimentando uma nova onda de aplicaes associada proliferao das redes sociais online e ao crescimento da popularidade da mdia digital. Vrias redes sociais online (OSNs - Online Social Networks) surgiram, incluindo redes de prossionais (ex., LinkedIn), redes de amigos (ex., MySpace, Facebook, Orkut), e redes para o compartilhamento de contedos especcos tais como mensagens curtas (ex., Twitter), dirios e blogs (ex., LiveJournal), fotos (ex., Flickr), e vdeos (ex., YouTube). Redes sociais online tm atrado milhes de usurios. De acordo com a Nielsen Online [99], mdia social, termo usado em referncia a contedo criado e disseminado via interaes sociais, passou na frente de email como a atividade online mais popular. Mais de dois teros da populao online global visita ou participa de redes sociais e blogs. Como comparao, se o Facebook fosse um pas, este seria o terceiro pas mais populoso do mundo, graas aos seus 500 milhes de usurios registrados [5]. Tanta popularidade est associada a uma funcionalidade comum de todas as redes sociais online que permitir que usurios criem e compartilhem contedo nesses ambientes. Este contedo pode variar de simples mensagens de texto comunicando eventos do dia-a-dia at mesmo a contedo multimdia, como fotos e vdeos. Como conseqncia, as estatsticas sobre contedo gerado pelos usurios nesses stios Web so impressionantes. Por exemplo, o Facebook compartilha mais de 60 bilhes de fotos, que ocupam mais de 1.5 PB de espao [10]. A quantidade de contedo que o YouTube armazena em 60 dias seria equivalente ao contedo televisionado em 60 anos, sem interrupo, pelas emissoras norte-americanas NBC, CBS e ABC juntas [12]. De fato, o YouTube foi acessado por mais de 100 milhes de usurios apenas em Janeiro de 2009 [1], com uma taxa de upload de 10 horas de vdeo por minuto [14]. Apesar de tanta popularidade e da enorme quantidade de contedo disponvel, o estudo de redes sociais ainda est em sua infncia, j que esses ambientes esto experimentando novas tendncias e enfrentando diversos novos problemas e desaos. A seguir sumarizamos alguns elementos motivadores para o estudo de redes sociais online. Comercial: Com usurios passando muito tempo navegando em redes sociais online, esses stios Web tm se tornado um grande alvo para propagandas. De fato, em 2007, 1,2 bilhes de dlares foram gastos em propagandas em redes sociais online no mundo todo, e esperado que este nmero triplique at 2011 [21]. Alm disso, usurios de redes sociais online compartilham e recebem uma grande quantidade de informao, inuenciando e sendo inuenciados por seus amigos [40]. Conseqentemente, redes sociais online esto se tornando cada vez mais um alvo de campanhas polticas [59] e de diversas outras formas de marketing viral, onde usurios so encorajados a compartilhar anncios sobre marcas e produtos com seus amigos [78]. Sociolgica: No passado o estudo de redes sociais era um domnio de socilogos e antroplogos, que utilizavam, como ferramentas tpicas para se obter dados,
65
entrevistas e pesquisas com usurios voluntrios [113]. Como conseqncia, muitos desses estudos foram realizados com base em amostras de dados pequenas e possivelmente pouco representativas. Com a popularizao de aplicaes de redes sociais online, surgiu a oportunidade de estudos nesse tema com o uso de grandes bases de dados, coletadas de tais aplicaes. Sistemas como Facebook, Twitter, Orkut, MySpace e YouTube possuem milhes de usurios registrados e bilhes de elos que os conectam. Redes sociais online permitem o registro em larga escala de diversos aspectos da natureza humana relacionados comunicao, interao entre as pessoas e ao comportamento humano, em geral: elas permitem que as pessoas interajam mais, mantenham contato com amigos e conhecidos e se expressem e sejam ouvidas por uma audincia local ou at mesmo global. De fato, redes sociais online vm funcionando como um novo meio de comunicao, modicando aspectos de nossas vidas. Melhorias dos sistemas atuais: Assim como qualquer sistema Web, redes sociais online so vulnerveis a novas tendncias e esto sujeitas a experimentarem uma rpida transferncia de seus usurios para outros sistema, sem aviso prvio. Por exemplo, inicialmente o MySpace experimentou um crescimento exponencial no nmero de usurios. Entretanto, este crescimento foi seguido por uma forte queda depois de abril de 2008 devido a um aumento no nmero de usurios do Facebook [108]. Um outro exemplo o Orkut, que inicialmente cresceu muito rapidamente em diversos lugares, mas que teve sua popularidade concretizada somente em alguns pases. Dentre esses pases, o Brasil o com maior nmero de usurios registrados [11]. Vrias razes podem explicar este tipo de fenmeno, incluindo a interface e novas utilidades do sistema, problemas de desempenho e caractersticas dos usurios, etc. Finalmente, o grande volume de dados disponveis em diferentes redes sociais online abre um novo leque de opes para pesquisas relacionadas recuperao de contedo, onde estratgias de busca e recomendao de usurios e contedo so cada vez mais importantes. Outro aspecto importante est relacionado ao trfego gerado pelas redes sociais online. Intuitivamente, existe uma diferena crucial entre publicar contedo na Web tradicional e compartilhar contedo atravs de redes sociais online. Quando as pessoas publicam algum contedo na Web, elas tipicamente fazem isso para que todos os usurios da Internet, em qualquer lugar, possam acessar. Por outro lado, quando usurios publicam contedo em redes sociais online, eles geralmente possuem uma audincia em mente, geralmente, seus amigos. Algumas vezes, a audincia explicitamente denida por um usurio ou pela poltica do sistema. Conseqentemente, redes sociais online constituem uma classe nica de aplicaes com potencial para remodelar os padres de trfego na Internet. Estudar aspectos de sistemas relacionados a redes sociais pode ser de grande importncia para a prxima gerao da infra-estrutura da Internet e para o projeto de sistemas de distribuio de contedo mais ecientes, ecazes e robustos [71, 102]. Segurana e contedo indesejvel: Redes sociais online esto cada vez mais se tornando alvo de usurios maliciosos ou oportunistas que enviam propagandas no
66
solicitadas, spam, e at mesmo phishing. O problema se manifesta de diversas maneiras, tais como a incluso de vdeos contendo spams em listas de vdeos mais populares [29, 26], o envio de spam no Twitter [24], a incluso de metadados (particularmente tags) que no descrevem adequadamente o contedo associado (p.ex: tag spamming) [27], etc. Contedo no solicitado consome a ateno humana, talvez o recurso mais importante na era da informao. Em ltima instncia, o rudo e o distrbio causados por alguns usurios reduzem a efetividade da comunicao online.
Redes sociais online so ambientes perfeitos para o estudo de vrios temas da computao, incluindo sistemas distribudos, padres de trfego na Internet, minerao de dados, sistemas multimdia e interao humano-computador. Alm disso, por permitir que usurios criem contedo, redes sociais vm se tornando um tema chave em pesquisas relacionadas organizao e tratamento de grandes quantidades de dados, alm de constiturem um ambiente ideal para extrao de conhecimento e aplicao de tcnicas de minerao de dados. Neste mini-curso apresentamos uma viso geral sobre redes sociais, oferecendo uma base necessria ao pesquisador que pretende explorar o tema. Inicialmente, apresentamos as principais caractersticas das redes sociais mais populares atualmente. Em seguida, discutimos as principais mtricas e anlises utilizadas no estudo dos grafos que formam a topologia das redes sociais. Finalmente, sumarizamos as principais abordagens utilizadas para coletar e tratar dados de redes sociais online e discutimos trabalhos recentes que utilizaram essas tcnicas.
2.2. Denies e Caractersticas de Redes Sociais Online

Esta seo apresenta uma viso geral sobre as redes sociais online, suas principais caractersticas e mecanismos de interao entre os usurios. 2.2.1. Denio O termo rede social online geralmente utilizado para descrever um grupo de pessoas que interagem primariamente atravs de qualquer mdia de comunicao. Conseqentemente, baseado nessa denio, redes sociais online existem desde a criao da Internet. Entretanto, neste trabalho, ns utilizaremos uma denio um pouco mais restrita, adotada em trabalhos anteriores [35, 85]. Ns denimos uma rede social online como um servio Web que permite a um indivduo (1) construir pers pblicos ou semipblicos dentro de um sistema, (2) articular uma lista de outros usurios com os quais ele(a) compartilha conexes e (3) visualizar e percorrer suas listas de conexes assim como outras listas criadas por outros usurios do sistema. Com base nessa denio, existem vrias redes sociais online disponveis na Web, que variam de acordo com seus objetivos primrios. A Tabela 2.1 apresenta uma lista com vrias redes sociais online populares atualmente, juntamente com seus principais propsitos. Uma lista atualizada e exaustiva de redes sociais online, com mais de 150 stios Web, pode ser encontrada em [8].
67
Nome Orkut Facebook MySpace Hi5 LinkedIn YouTube Flickr LiveJournal Digg Twitter LastFM
Propsito Amizades Amizades Amizades Amizades Professionais Compartilhamento de vdeos Compartilhamento de fotos Blogs e dirios Compartilhamento de (bookmarks) Troca de mensagens curtas Compartilhamento de rdio/msicas
URL http://www.orkut.com http://www.facebook.com http://www.myspace.com http://www.hi5.com http://www.linkedin.com http://www.youtube.com http://www.ickr.com http://www.livejournal.com http://digg.com http://twitter.com http://www.last.fm
Tabela 2.1. Algumas Redes Sociais Online Populares
2.2.2. Elementos das Redes Sociais Online Nesta seo, discutimos vrias funcionalidades oferecidas pelas principais aplicaes de redes sociais online atuais. O objetivo desta seo no prover uma lista completa e exaustiva de funcionalidades, mas apenas descrever as mais relevantes. Pers dos usurios: Redes sociais online possuem muitas funcionalidades organizadas ao redor do perl do usurio, na forma de uma pgina individual, que oferece a descrio de um membro. Pers podem ser utilizados no s para identicar o indivduo no sistema, mas tambm para identicar pessoas com interesses em comum e articular novas relaes. Tipicamente, pers contm detalhes demogrcos (idade, sexo, localizao, etc.), interesses (passatempos, bandas favoritas, etc.), e uma foto. Alm da adio de texto, imagens e outros objetos criados pelo usurio, o perl de um usurio na rede social tambm contm mensagens de outros membros e listas de pessoas identicadas como seus amigos na rede. Pers so geralmente acessveis por qualquer um que tenha uma conta na rede social online ou podem ser privados, de acordo com as polticas de privacidades denidas pelo usurio. Recentemente, Boyd e colaboradores [34] mostraram que, para a maior parte dos usurios de redes sociais online, existe uma forte relao entre a identidade do indivduo real e seu perl na rede social. Atualizaes: Atualizaes so formas efetivas de ajudar usurios a descobrir contedo. Para encorajar usurios a compartilhar contedo e navegar por contedo compartilhado por amigos, redes sociais online geralmente fazem as atualizaes imediatamente visveis aos amigos na rede social. Burke e colaboradores [39] conduziram um estudo utilizando dados de 140,000 novos usurios do Facebook para determinar que atividades como atualizaes so vitais para que novos usurios contribuam para o sistema. Como atualizaes podem receber comentrios de outros usurios, elas tambm so formas especiais de comunicao em redes sociais online.
68
Comentrios: A maior parte das aplicaes de redes sociais online permite que usurios comentem o contedo compartilhado por outros. Alguns sistemas tambm permitem que usurios adicionem comentrios nos pers de outros usurios. Comentrios so um meio primordial de comunicao em redes sociais online, e tambm podem ser interpretados como expresso de relaes sociais [19, 47]. Como exemplo, usurios do YouTube podem comentar os vdeos armazenados por outros no sistema, enquanto que tanto no Facebook quanto no Orkut, usurios podem adicionar comentrios s fotos de outros. Da mesma forma, usurios do LiveJournal podem postar comentrios em blogs, etc. Avaliaes: Em muitas redes sociais online, o contedo compartilhado por um usurio pode ser avaliado por outros usurios. Avaliaes podem aparecer em diferentes nveis de granularidade e formas. No Facebook, por exemplo, usurios podem apenas gostar de uma postagem, clicando no boto I like this. De fato, estatsticas recentes indicam que cada usurio do Facebook avalia, em mdia, 9 objetos por ms [5]. Ja no YouTube, vdeos podem ser avaliados com at 5 estrelas, de forma similar avaliao empregada na categorizao de hotis. O YouTube ainda prov uma avaliao binria (positiva ou negativa) para os comentrios recebidos por vdeos, na tentativa de ltrar comentrios ofensivos ou contendo alguma forma de spam. Avaliaes de contedo so teis de vrias formas. Como exemplo, elas ajudam usurios de sistemas como o YouTube a encontrar e identicar contedo relevante. Avaliaes podem ainda ajudar administradores a identicar contedo de baixa qualidade ou mesmo contedo inapropriado. Alm disso, avaliaes podem ser utilizadas para identicar contedo em destaque, para suportar sistemas de recomendao, etc. Uma rede social online que coloca as avaliaes dos usurios no centro do sistema o Digg. O Digg permite que usurios avaliem URLs, notcias ou estrias e utiliza aquelas mais votadas para expor o contedo mais popular [77]. Listas de Favoritos: Vrias aplicaes sociais utilizam listas de favoritos para permitir que usurios selecionem e organizem seu contedo. Listas de favoritos ajudam usurios a gerenciar seu prprio contedo e podem ser teis para recomendaes sociais. Como exemplo, usurios podem manter listas de vdeos favoritos no YouTube e de fotos favoritas no Flickr. Nesses sistemas, usurios podem navegar na lista de favoritos de outros usurios para buscar novos contedos [42]. Conseqentemente, listas de favoritos tambm facilitam a descoberta de contedo e a propagao de informao. Sistemas como o Orkut e o Twitter tambm provem listas de favoritos (fs). Listas de Mais Populares (Top Lists): Tipicamente, redes sociais online que tm o compartilhamento de contedo como elemento central do sistema, como o YouTube que centrado no compartilhamento de vdeos, provem listas de contedo mais popular ou usurios mais populares. Geralmente, essas listas so baseadas em avaliaes ou outras estatsticas do sistema relativas ao contedo (ex: nmero de visualizaes, avaliaes, ou comentrios) ou relativas aos usurios (ex: nmero de assinantes).
69
Metadados: Em vrias aplicaes de redes sociais online, tais como o YouTube e o Flickr, usurios tipicamente associam metadados, como ttulo, descrio e tags, ao contedo compartilhado. Metadados so essenciais para recuperao de contedo em redes sociais online, uma vez que grande parte dos servios de informao (p.ex: busca, organizao de contedo, recomendao, propaganda) ainda utilizam os metadados (particularmente as tags) como principal fonte de dados [33].
2.3. Teoria de Redes Complexas

da rea de redes complexa Redes sociais online so inerentemente redes complexas. Consequentemente, vrios estudos recentes analisaram as caractersticas de diferentes redes sociais online utilizando como base teorias existentes da rea de redes complexas [15, 87, 50, 72, 79, 23, 28]. De fato, o estudo de redes complexas cobre um grande nmero de reas e sua teoria tem sido utilizada como ferramenta para entender vrios fenmenos, incluindo o espalhamento de epidemias [88], propagao de informao [115], busca na Web [38], e consequncias de ataques a redes de computadores [17]. A seguir, vrias propriedades estatsticas e mtricas comumente utilizadas para analizar e classicar rede complexas so apresentadas na seo 2.3.1. As sees 2.3.2 e 2.3.3 discutem propriedades especcas comumente associadas a vrias redes complexas, a saber, redes small-world e redes power-law, respectivamente. Uma reviso detalhada sobre mtricas e teoria de redes complexas pode ser encontrada na referncia [93]. 2.3.1. Mtricas para o Estudo de Redes Complexas Uma rede um conjunto de elementos, que chamamos de vrtices ou nodos, com conexes entre eles, chamadas de arestas. A estrutura topolgica de uma rede pode ser ento modelada por um grafo, que, por sua vez, pode ser caracterizado a partir de diversas mtricas, discutidas a seguir. Assume-se que o leitor tenha um conhecimento sobre a terminologia utilizada em teoria de grafos. 2.3.1.1. Grau dos Vrtices Uma caracterstica importante da estrutura de uma rede a distribuio dos graus de seus vrtices. Tal distribuio j foi caraterizada em vrias redes (ex: redes de emails[64], a topologia da Internet [56], a Web [22], e redes neurais [36]) como seguindo uma lei de potncia. Em outras palavras, a probabilidade de um nodo ter grau k proporcional a k , Consequentemente, uma mtrica comumente utilizada para comparar diferentes redes o expoente , obtido atravs de uma regresso linear. Valores tpicos para o expoente cam entre 1.0 e 3.5 [54]. Para redes direcionadas, comum analisar as distribuies doso grau dos nodos em ambas as direes, isto , a distribuio do grau de entrada e a distribuio do grau de sada. Como exemplo, a Figura 2.1 mostra as distribuies dos graus de entrada (esquerda) e de sada (direita) para um grafo formado a partir das interaes entre usurios de vdeos do YouTube [23, 28]. Note que a curva da regresso linear, utilizada para se calcular o expoente , tambm exibida nesses grcos. Ferramentas como o Gnuplot [6] e o Matlab [9] podem ser utilizados para realizar a regresso e calcular o valor de . Para
70
105 10 # de nodos
4
= 2.096 fit, R2 = 0.987 # de nodos
106 10
5
= 2.759 fit, R2 = 0.987
103 10
2
104 103 102 101 100 0 10
101 100 0 10 10 10 10 Grau de entrada

1 2 3
10
101 102 Grau de saida
103
Figura 2.1. Distribuies dos Grau sde Entrada e de Sada em um Grafo de Interaes entre Usurios atravs de Vdeos do YouTube
vericar a acurcia da regresso, comum medir o coeciente de determinao R2 [109]. Quanto mais prximo o valor de R2 for de 1 (regresso perfeita), menor ser a diferena entre o modelo de regresso e os dados reais.
2.3.1.2. Coeciente de Agrupamento O coeciente de agrupamento (clustering coefcient) de um nodo i, cc(i), a razo entre o nmero de arestas existentes entre os vizinhos de i e o nmero mximo de arestas possveis entre estes vizinhos. Como exemplo, a Figura 2.2 mostra o valor do coeciente de agrupamento para o nodo escuro em trs cenrios diferentes1 . No primeiro, todos os vizinhos do nodo esto conectados entre si e, conseqentemente, o cc do nodo 1. No segundo cenrio, existe apenas 1 aresta entre os vizinhos do nodo dentre as 3 possveis, deixando o nodo com cc = 1/3. No ltimo cenrio, no h nenhuma aresta entre os vizinhos do nodo escuro e, portanto, o cc do nodo 0.
Figura 2.2. Clculo do Coeciente de Agrupamento de um Nodo em Trs Cenrios Diferentes
Podemos notar que o coeciente de agrupamento representa uma medida da densidade de arestas estabelecidas entre os vizinhos de um nodo. O coeciente de agrupamento
1 Arestas
tracejadas no existem e apenas ilustram as possveis conexes entre os vizinhos do nodo
escuro.
71
de uma rede, CC, calculado como a mdia dos coeciente de agrupamento de todos os seus nodos. 2.3.1.3. Componentes Um componente em um grafo um conjunto de nodos, onde cada nodo possui um caminho para todos os outros nodos do conjunto. Para grafos direcionados, um componente chamado de fortemente conectado (SCC - Strongly Connected Component) quando existe um caminho direcionado entre cada par de nodos do conjunto. Um componente fracamente conectado (WCC - Weakly Connected Component) se o caminho no direcionado. Um trabalho que se tornou referncia no estudo de componentes em redes complexas aborda a estrutura da Web representada por um grafo em que nodos so pginas Web e arestas so elos existentes entre as pginas [38]. Os autores propem um modelo que representa como os componentes no grafo da Web se relacionam. Este modelo, aplicado somente em grafos direcionados, possui um componente central que o SCC, chamado tambm de core, e outros grupos de componentes que podem alcanar o SCC ou serem alcanados por ele. O modelo cou conhecido como bow tie [38], pois a gura que ilustrada o modelo lembra uma gravata borboleta.
(a) Web
(b) Frum de Java
(c) Interaes com vdeo Figura 2.3. Estrutura dos Componentes da Web [38], do Frum de Java [118] e do Grafo de Interaes de Usurios do YouTube [28]
Este modelo tem sido utilizado por outros estudos como forma de comparar a organizao dos componentes de um grafo direcionado [118, 28]. A Figura 2.3, por exemplo, ilustra o uso do modelo bow tie para comparar a estrutura dos componentes de trs
72
redes diferentes, a saber, a rede Web, uma rede formada pelas conexes estabelecidas em um Frum de Java e a rede estabelecidas entre usurios do YouTube. O componente central, core, das guras corresponde frao dos nodos do grafo que fazem parte do SCC. O componente in contm os nodos que apontam para algum nodo do core, mas no so apontados por nodos desse componente. Finalmente, o componente out corresponde aos nodos que so apontados por nodos do core. Note que h diferenas estruturais signicativas entre as 3 redes: a rede Web muito mais balanceada, em termos do tamanho dos componentes, enquanto que, para as outras duas, o componente in contm um percentual muito maior dos nodos.
2.3.1.4. Distncia Mdia e Dimetro A distncia mdia de um grafo o nmero mdio de arestas em todos todos os caminhos mnimos existentes entre todos os pares de nodos do grafo. Normalmente, a distncia mdia computada apenas no SCC para grafos direcionados ou no WCC para grafos no direcionados, j que no existe caminho entre nodos localizados em componentes diferentes. Outra mtrica relacionada o dimetro do grafo. O dimetro denido como a distncia do maior caminho mnimo existente no grafo e, em geral, tambm computado somente para nodos do WCC ou do SCC.
2.3.1.5. Assortatividade De acordo com Newman [92], assortatividade uma medida tpica de redes sociais. Uma rede exibe propriedades assortativas quando nodos com muitas conexes tendem a se conectar a outros nodos com muitas conexes. Para caracterizar a assortatividade de uma rede, medimos o grau mdio de todos os vizinhos dos nodos com grau k, dado por knn(k). A assortatividade ou disassortatividade de uma rede geralmente estimada avaliando os valores de knn(k) em funo de k. Valores crescentes indicam assortatividade, isto , nodos com graus maiores tendem a se conectar a nodos com um nmero maior de conexes. Valores decrescentes de knn(k) em funo de k, por sua vez, indicam uma rede disassortativa.
2.3.1.6. Betweenness Betweeness uma medida relacionada centralidade dos nodos ou de arestas na rede. O betweeness B(e) de uma aresta e denido como o nmero de caminhos mnimos entre todos os pares de nodos em um grafo que passam por e [95]. Se existem mltiplos caminhos mnimos entre um par de nodos, cada caminho recebe um peso de forma que a soma dos pesos de todos os caminhos seja 1. Conseqentemente, o betweenness de uma aresta e pode ser expressado como: B(e) = e (u, v) (u, v)
uV,vV
(1)
73
onde (u, v) representa o nmero de caminhos mnimos entre u e v, e e (u, v) representa o nmero de caminhos mnimos entre u e v que incluem e. O betweenness de uma aresta indica a importncia dessa aresta no grafo em termos de sua localizao. Arestas com maior betweenness fazem parte de um nmero maior de caminhos mnimos e, portanto, so mais importantes para a estrutura do grafo. De forma similar, o betweenness pode ser computado para um nodo ao invs de uma aresta. Neste caso, a medida do betweenness mede o nmero de caminhos mnimos que passam pelo dado nodo. Nodos que possuem muitos caminhos mnimos que passam por eles possuem maior betweenness, indicando uma maior importncia para a estrutura da rede. 2.3.1.7. Reciprocidade Uma forma interessante de se observar a reciprocidade de um nodo i em um grafo direcionado medindo a porcentagem dos nodos apontados por i que apontam para ele. Em outras palavras, a reciprocidade (R(i)) dada por: R(i) = |O(i) I(i)| |O(i)| (2)
onde O(i) o conjunto de nodos apontados por i e I(i) o conjunto de nodos que apontam para i. Outra mtrica interessante de ser observada o coeciente de reciprocidade , uma mtrica que captura a reciprocidade das interaes em toda a rede [60]. O coeciente de reciprocidade denido pelo coeciente de correlao entre entidades da matriz de adjacncia representativa do grafo direcionado. Em outras palavras, seja a matriz a denida como ai j = 1 se h uma aresta de i para j no grafo, e ai j = 0, caso contrrio. Denimos a reciprocidade da rede como :
i= j (ai j a)(a ji a) , 2 i= j (ai j a)
(3)
onde o valor mdio a = i= j ai j /N(N 1) e N o nmero de usurios no grafo. O coeciente de reciprocidade indica se o nmero de arestas recprocas na rede maior ou menor do que o de uma rede aleatria. Se o valor maior do que 0, a rede recproca; caso contrrio, ela anti-recproca. 2.3.1.8. PageRank O PageRank um algoritmo interativo que assinala um peso numrico para cada nodo com o propsito de estimar sua importncia relativa no grafo. O algoritmo foi inicialmente proposto por Brin and Page [37] para ordenar resultados de busca do prottipo de mquina de busca da Google. A intuio por trs do PageRank que uma pgina Web
74
importante se existem muitas pginas apontando para ela ou se existem pginas importantes apontando para ela. A equao que calcula o PageRank (PR) de um nodo i, PR(i), denida da seguinte forma: PR(v) Nv vS(i)
PR(i) = (1 d) + d
(4)
onde S(i) o conjunto de pginas que apontam para i, Nv denomina o nmero de arestas que saem do nodo v, e o parmetro d um fator que pode ter valor entre 0 e 1. O algoritmo do PageRank tem sido aplicado em outros contextos, como por exemplo, para encontrar usurios experientes em fruns especializados [118] e usurios inuentes no Twitter [116, 73]. Alm disso, existem outras modicaes do PageRank com propsitos especcos, como por exemplo, a deteco de spam na Web [66]. 2.3.2. Redes Small-World O conceito de redes small-world cou bastante conhecido com o famoso experimento de Milgram [84]. Este experimento consistiu de um grupo de voluntrios tentando enviar uma carta para uma pessoa alvo atravs de outras pessoas que eles conheciam. Milgram enviou cartas a vrias pessoas. As cartas explicavam que ele estava tentando atingir uma pessoa especca em uma cidade dos EUA e que o destinatrio deveria repassar a carta para algum que ele achasse que poderia levar a carta o mais prximo do seu destino nal, ou entreg-la diretamente, caso o destinatrio nal fosse uma pessoa conhecida. Antes de enviar a carta, entretanto, o remetente adicionava seu nome ao m da carta, para que Milgram pudesse registrar o caminho percorrido pela carta. Das cartas que chegaram com sucesso ao destino nal, o nmero mdio de passos requerido para o alvo foi 6, resultado que cou conhecido como o princpio dos seis graus de separao. Em termos das propriedades das redes sociais que discutimos, uma rede pode ser considerada small-world se ela tiver duas propriedades bsicas: coeciente de agrupamento alto e dimetro pequeno [114]. Estas propriedades foram vericadas em vrias redes como a Web [18, 38], redes de colaborao cientca [91, 94] em que pesquisadores so nodos e arestas ligam co-autores de artigos, redes de atores de lmes [20] em que atores so nodos e arestas ligam atores que participaram do mesmo lme, e redes sociais online [15, 87, 50, 79, 23, 28]. Em particular, Mislove e colaboradores [87] vericaram propriedades small-world em quatro redes sociais online: LiveJournal, Flickr, Orkut, e YouTube. 2.3.3. Redes Power-Law e Livres de Escala Redes cujas distribuies dos graus dos nodos seguem uma lei de potncia (Seo 2.3.1.1) so ditas redes power-law. Redes livres de escala (scale free) so uma classe de redes que seguem leis de potncia caracterizadas pela seguinte propriedade: nodos de grau alto tendem a se conectar a outros nodos de grau alto. Barabsi e colaboradores [22] propuseram um modelo para gerar redes livre de escala, introduzindo o conceito de conexo preferencial (preferential attachment). O modelo diz que a probabilidade de um nodo se conectar a outro nodo proporcional ao seu grau. Os autores do modelo ainda
75
mostraram que, sob certas circunstncias, este modelo produz redes que seguem leis de potncia. Mais recentemente, Li e colaboradores [80] criaram uma mtrica para medir se uma rede livre de escala ou no, alm de prover uma longa discusso sobre o tema.
2.4. Tcnicas de Coleta de Dados

Em um passado recente, redes sociais eram um domnio de socilogos e antroplogos, que utilizavam pesquisas e entrevistas com pequenos grupos de usurios como ferramentas de coleta de dados [113]. Com o surgimento das redes sociais online, a obteno de dados reais em larga escala se tornou possvel, e pesquisadores de diversas reas da computao comearam a realizar coletas de dados. Diferentes reas de pesquisa demandam diferentes tipos de dados e, por isso, existem vrias formas de se obter dados de redes sociais online. A Figura 2.4 apresenta possveis pontos de coleta de dados, que variam desde entrevistas com os usurios at instalao de coletores localizados em servidores proxy ou em aplicaes. A seguir discutimos essas diferentes abordagens, bem como trabalhos que ilustram o uso dessas estratgias. 2.4.1. Dados dos Usurios
Figura 2.4. Possveis Pontos de Coleta de Dados
Um mtodo comum de se analisar o uso de redes sociais online consiste em conduzir entrevistas com usurios desses sistemas. Em particular, esta estratgia tem sido bastante empregada pela comunidade da rea de interface homem-mquina [107, 69, 43, 32, 97], para a qual entrevistas estruturadas so as formas mais populares de obteno de dados. Como exemplo, atravs de entrevistas com usurios do Facebook, Joinson e seus colaboradores [69] identicaram vrias razes pelas quais usurios utilizam o sistema, tais como conexo social, compartilhamento de interesses, compartilhamento e recuperao de contedo, navegao na rede social e atualizao do seu estado atual. Chapman e Lahav [43] conduziram entrevistas e analisaram os padres de navegao de 36 usurios de quatro nacionalidades diferentes para examinar diferenas etnogrcas no uso de redes sociais online.
76
2.4.2. Dados de Pontos Intermedirios Existem duas tcnicas comuns utilizadas para coletar dados de pontos de agregao de trfego na rede. A primeira consiste em coletar os dados que passam por um provedor de servios Internet (ISP) e ltrar as requisies que correspondem a acessos s rede sociais online. A segunda consiste em coletar dados diretamente de um agregador de redes sociais. A seguir, discutimos alguns trabalhos que zeram o uso dessas estratgias. 2.4.2.1. Servidores Proxy
Figura 2.5. Exemplo de um Servidor Proxy Intermediando o Trfego entre Clientes e Servidores
Coletar dados de um servidor proxy tem sido uma estratgia utilizada em vrios estudos sobre o trfego da Internet [52, 65, 82, 117]. A Figura 2.5 ilustra como um servidor proxy funciona como um agregador de trfego de seus clientes, podendo ser utilizados para delimitar uma poro da rede, composta por computadores em uma mesma localizao geogrcas. Dado o crescente interesse por vdeos na Web, alguns trabalhos recentes utilizaram servidores proxy para obter dados do trfego gerado por sistemas de compartilhamento de vdeos, como o YouTube. Gill e colaboradores [61] caracterizaram o trfego do YouTube coletando dados de um servidor proxy localizado na universidade de Calgary, no Canad. Eles mostraram que requisies de HTTP GET, utilizadas para fazer o download de contedo do YouTube, correspondem a 99.87% do total das requisies que passam pelo servidor proxy. Eles ainda caracterizaram diversas mtricas relacionadas a estas requisies tais como a durao, a idade e a categoria dos vdeos. Mais recentemente, os mesmos autores caracterizam sesses de usurios no YouTube [62]. Eles mostraram que uma sesso tpica dura cerca de 40 minutos, caracterizando tambm o tempo entre sesses e os tipos de contedo transferidos em cada sesso. Finalmente, Zink e colaboradores [119] tambm estudaram o trfego de vdeos do YouTube coletado no servidor proxy de uma universidade. Eles tambm analisaram, via simulao, os benefcios da adoo de abordagens de caches locais e globais para vdeos bem como do uso de arquiteturas P2P para
77
distribuio de vdeos. De maneira geral, eles mostraram que essas abordagens poderiam reduzir signicativamente o volume de trfego, permitindo acesso aos vdeos de forma mais rpida. Em um trabalho recente, Schneider e colaboradores [105] extraram dados de redes sociais online de um provedor de acesso a Internet e reconstruram aes realizadas pelos usurios em suas navegaes por diferentes redes sociais online. Em outras palavras, eles criaram o que foi chamado de clickstream [44] para redes sociais online, capturando cada passo da navegao dos usurios do ISP. Eles discutiram amplamente a metodologia de reconstruo dos acessos dos usurios e, com base nesses dados, analisaram as seqncias de requisies realizadas pelos usurios vrios sistemas, incluindo o Facebook. 2.4.2.2. Agregadores de Redes Sociais Agregadores de redes sociais so sistemas que permitem acesso a vrias redes sociais simultaneamente, atravs de um portal nico. Esses sistemas ajudam usurios que utilizam vrias redes sociais online a gerenciar seus pers de uma forma mais simples e unicada [70, 106]. Ao se conectarem a um agregador de redes sociais online, usurios podem acessar suas contas atravs de uma interface nica, sem precisar se conectar em cada rede social separadamente. Isto feito atravs de uma conexo HTTP em tempo real realizada em duas etapas: a primeira etapa ocorre entre o usurio e o agregador de redes sociais, enquanto a segunda etapa ocorre entre o sistema agregador e as redes sociais. Agregadores tipicamente comunicam com redes sociais online atravs de APIs, como o OpenSocial [7], e todo o contedo exibido atravs da interface do sistema agregador. A Figura 2.6 descreve o esquema de interao entre os usurios, um sistema agregador e algumas redes sociais online. Atravs dessa interface, um usurio pode utilizar vrias funcionalidades de cada rede social que ele est conectado, tais como checar atualizaes de amigos, enviar mensagens e compartilhar fotos.
Figura 2.6. Ilustrao de um Usurio se Conectando a Mltiplas Redes Sociais Online Simultaneamente Atravs de um Portal Agregador
Recentemente, a partir de uma colaborao com um agregador de redes sociais online, ns coletamos dados da navegao dos usurios (i.e., clickstream) em 4 redes sociais online: Orkut, Hi5, MySpace e LinkedIn [30]. A Tabela 2.2 mostra o nmero de usurios, sesses e requisies HTTP para cada uma dessas redes. Baseados nesses dados e em dados coletados do Orkut, ns examinamos o comportamento dos usurios
78
nas redes sociais online, caracterizando as interaes estabelecidas entre eles atravs das vrias atividades realizadas.
# usurios # sesses Orkut 36.309 57.927 515 723 Hi5 MySpace 115 119 85 91 LinkedIn Total 37.024 58.860
# requisies 787.276 14.532 542 224 802.574
Tabela 2.2. Sumrio dos Dados Obtidos de um Agregador de Redes Sociais Online
2.4.3. Dados de Servidores de Redes Sociais Online Idealmente, servidores de aplicaes de redes sociais online so os locais mais adequados para a coleta de dados, uma vez que eles tm uma viso completa de todas as aes e atividades realizadas por todos os usurios do sistema um dado perodo de tempo. Entretanto, o acesso a dados armazenados por estes servidores, ainda que anonimizados, tipicamente muito difcil. Dentre os poucos trabalhos que utilizaram dados obtidos diretamente de servidores de redes sociais online, podemos citar o estudo de Chun e seus colaboradores [47] sobre as interaes textuais entre os usurios do Cyworld, uma rede social bastante popular na Coria do Sul. Eles compararam as propriedades estruturais da rede de amizades explcita criada naquela aplicao com as propriedades da rede implcita estabelecida a partir de trocas de mensagens no livro de visitas do Cyworld, discutindo diversas similaridades e diferenas. Citamos tambm o trabalho de Baluja e colaboradores, que utilizaram dados do histrico de navegao de usurios do YouTube para criar um grafo onde cada vdeo um nodo e arestas ligam vdeos freqentemente vistos em seqncia. Baseados nesse grafo, eles criaram um mecanismo capaz de prover sugestes de vdeos personalizadas para os usurios do YouTube. Finalmente, Duarte e seus colaboradores [53] caracterizaram o trfego em um servidor de blogs do UOL (www.uol.com.br), enquanto ns estudamos a navegao dos usurios em um servidor de vdeos do UOL, chamado UOL Mais [25]. Dada a diculdade em se obter dados diretamente de servidores de redes sociais online, uma estratgia comum consiste em visitar pginas de redes sociais com o uso de uma ferramenta automtica, que chamamos de crawler ou rob, e coletar sistematicamente informaes pblicas de usurios e objetos. Tipicamente, os elos entre usurios de uma rede social online podem ser coletados automaticamente, permitindo que os grafos de conexes entre os usurios sejam reconstrudos. Essa estratgia tem sido amplamente utilizada em uma grande variedade de trabalhos, incluindo estudos sobre a topologia das redes sociais online [87, 16], padres de acesso no YouTube [41] e interaes reconstrudas atravs de mensagens trocadas pelos usurios [112]. A seguir discutimos vrios aspectos relacionados coleta de dados de redes sociais online.
79
Figura 2.7. Exemplo de Busca em Largura em um Grafo
2.4.3.1. Coleta por Amostragem Idealmente, sempre mais interessante coletar o grafo inteiro de uma rede social online para evitar que a coleta seja tendenciosa a um grupo de usurios da rede. Entretanto, na maior parte das vezes, no h uma forma sistemtica de se coletar todos os usurios de uma rede social online. Para esses casos necessrio coletar apenas parte do grafo. Uma abordagem comumente utilizada, chamada snowball (ou bola de neve), consiste em coletar o grafo de uma rede social online seguindo uma busca em largura, como ilustra a Figura 2.7. A coleta inicia-se a partir de um nodo semente. Ao coletar a lista de vizinhos desse nodo, novos nodos so descobertos e ento coletados no segundo passo, que s termina quando todos os nodos descobertos no primeiro passo so coletados. No passo seguinte todos os nodos descobertos no passo anterior so coletados, e assim sucessivamente. Recomenda-se o uso de um grande nmero de nodos sementes para evitar que a coleta no que restrita a um pequeno componente do grafo. Um ponto crucial sobre a coleta por snowball a interrupo da coleta em um passo intermedirio, antes que todos os nodos alcanvels pela busca em largura sejam atingidos. Esta interrupo pode ter que ser forada para tornar a coleta vivel. Em particular, a busca completa em componentes muito grandes pode gastar um tempo excessivamente longo e proibitivo. Entretanto, importante ressaltar que o resultado de uma coleta parcial pode gerar medidas tendenciosas, tais como distribuies de graus dos nodos com uma tendncia maior para valores grandes, o que pode, em ltima instncia, afetar as anlises e concluses observadas. Em outras palavras, os dados obtidos via coleta por snowball com interrupo precisam ser tratados e analisados com cautela. Em outras palavras, o tipo de anlise a ser feita precisa ser considerado. Por exemplo, se realizarmos 3 passos da coleta, podemos calcular, com preciso, o coeciente de agrupamento dos nodos semente. Entretanto, se quisermos computar o coeciente de agrupamento mdio de toda a rede ou outras mtricas globais como distribuio de graus, distncia mdia, etc., a coleta por snowball pode resultar em nmeros tendenciosos caso ela no inclua pelo menos um componente completo representativo da rede completa [76, 16]. Uma abordagem bastante difundida consiste em coletar o maior componente fracamente conectado (WCC) do grafo. Mislove e colaboradores [87] argumentam que o
80
maior WCC de um grafo estruturamente a parte mais interessante de ser analisada, pois o componente que registra a maior parte das atividades dos usurios. Alm disso, eles mostram que usurios no includos no maior WCC tendem a fazer parte de um grande grupo de pequenos componentes isolados ou at mesmo totalmente desconectados. A coleta de um componente inteiro pode ser realizada com uma estratgia baseada em um esquema de busca em largura ou busca em profundidade. Quanto maior o nmero de sementes utilizadas maior a chance de se coletar o maior componente do grafo. Em trabalhos recentes, ns realizamos uma busca por palavras aleatrias no YouTube para vericar se o componente coletado era o maior componente [28, 23]. Como a maior parte dos usurios encontrados nessas buscas estavam no WCC do nosso grafo, os resultados desse teste sugeriram que o componente coletado era o maior WCC. Mislove e colaboradores [87] argumenta que o maior WCC de um grafo estruturamente a parte mais interessante de ser analisada, pois o componente que registra a maior parte das atividades dos usurios. Alm disso, eles mostram que usurios no includos no maior WCC tendem fazer parte de um grande grupo de pequenos componentes isolados ou at mesmo totalmente desconectados.
Figura 2.8. Exemplo de Coleta do WCC em um Grafo Direcionado
Note que, em algumas redes sociais online como o Twitter ou o Flickr, o conceito de amizade direcionado. Ou seja, um usurio u pode seguir um outro usurio v, sem necessariamente ser seguido por ele. Em casos como estes, ou seja, em grafos direcionados, necessrio percorrer as arestas do grafo em ambas as direes a m de coletar o WCC completamente. Caso contrrio, se coletarmos o grafo seguindo as arestas em apenas uma direo, no garantido que consigamos coletar todos os nodos do WCC. A Figura 2.8 mostra que o conjunto de nodos coletados quando seguimos as arestas em ambas as direes maior do que quando seguimos apenas uma das direes. Em algumas redes no possvel percorrer o grafo em ambas as direes e, portanto, no possvel coletar o maior WCC. Essa limitao tpica de estudos que envolvem a coleta da Web [38]. Ti-
81
picamente, a Web freqentemente coletada seguindo apenas uma direo dos elos entre pginas, j que no possvel determinar o conjunto de pginas que apontam para uma pgina. Uma outra estratgia de coleta por amostragem em redes baseada em caminhadas aleatrias (random walks) [100]. A idia bsica consiste em, a partir de um nodo semente v, prosseguir selecionando aleatoriamente um dos vizinhos de v, e assim sucessivamente at que um nmero pre-denido B de nodos tenham sido selecionados. Um mesmo nodo pode ser selecionado mltiplas vezes. Esta a estratgia de caminhada aleatria mais comum disponvel na literatura embora existam outras abordagens que diferem em termos de como os vizinhos so selecionados [81, 101] Assim como a coleta por snowball, a coleta atravs de caminhadas aleatrias tambm tem suas limitaes: a preciso das estimativas depende no somente da estrutura do grafo mas tambm da caracterstica sendo estimada. Em particular, dependendo da estrutura do grafo, a coleta pode car presa"dentro de um subgrafo. Neste caso, as estimativas podem ser imprecisas se as caractersticas do subgrafo no forem representativas da rede como um todo. Para mitigar este problema, Ribeiro e Towsley propuseram uma estratgia de coleta por caminhas aleatrias chamado Frontier sampling, que comea com m nodos sementes[100]. Eles ainda propuseram estimadores sem tendncia para vrias mtricas de redes complexas, incluindo o coeciente de agrupamento global da rede, usando as arestas coletadas pelo mtodo proposto. 2.4.3.2. Coleta em Larga Escala A coleta de grandes bases de dados de redes sociais online geralmente envolve o uso de coletores distribudos em diversas mquinas. Isso acontece no s devido ao processamento necessrio para tratar e salvar os dados coletados, mas tambm para evitar que servidores de redes sociais interpretem a coleta de dados pblicos como um ataque a seus servidores. Uma forma de se realizar tal coleta, conforme descrito em [45], est representada na Figura 2.9. A estratgia consiste em utilizar (1) uma mquina mestre que mantm uma lista centralizada de usurios a serem visitados e (2) mquinas escravas, que coletam, armazenam e processam os dados coletados para identicar novos usurios. Novos usurios identicados pelas mquinas escravas so repassados para a mquina mestre, que por sua vez, distribui novos usurios a serem coletados para as mquinas escravas. 2.4.3.3. Coleta por Inspeo de Identicadores Como discutido anteriormente, idealmente, a coleta de uma rede social online deveria incluir a rede completa e no somente uma poro dela. Em alguns sistemas como o MySpace e o Twitter possvel realizar uma coleta completa. Esses sistemas atribuem um identicador (ID) numrico e seqencial para cada usurio cadastrado. Como novos usurios recebem um identicador seqencial, podemos simplesmente percorrer todos os IDs, sem ter que vericar a lista de amigos desses usurios em busca de novos IDs para coletar.
82
Figura 2.9. Exemplo de Coleta Realizada de Forma Distribuda
Recentemente, ns realizamos uma coleta do Twitter seguindo essa estratgia. Ns solicitamos aos administradores do Twitter a permisso para realizar uma coleta em larga escala. Em resposta, eles adicionaram os endereos IPs de 58 mquinas sob nosso controle em uma lista branca, com permisso para coletar dados. Cada uma das 58 mquinas, localizadas no Max Planck Institute for Software Systems (MPI-SWS), na Alemanha2 , teve permisso para coletar dados a uma taxa mxima de 20 mil requisies por hora. Utilizando a API do Twitter, nosso coletor investigou todos os 80 milhes de IDs de forma seqencial, coletando todas as informaes pblicas sobre esses usurios, bem como seus elos de seguidores e seguidos e todos os seus tweets. Dos 80 milhes de contas inspecionadas, ns encontramos cerca 55 milhes em uso. Isso acontece porque o Twitter apaga contas inativas por um perodo maior do que 6 meses. No total, coletamos cerca de 55 milhes de usurios, quase 2 bilhes de elos sociais e cerca de 1.8 bilhes de tweets. Ao inspecionar as listas de seguidores e seguidos coletadas, ns no encontramos nenhum identicador acima dos 80 milhes inspecionados, sugerindo que ns coletamos todos os usurios do sistema na poca. Esses dados foram utilizados recentemente em dois trabalhos, um sobre deteco de spammers no Twitter [24] e o outro sobre medio de inuncia no Twitter [40]. Torkjazi e colaboradores [108] tambm exploraram o uso de IDs sequenciais para inspecionar o surgimento de novos usurios no MySpace.
2 Esta
coleta foi realizada durante uma visita de 5 meses ao MPI-SWS
83
2.4.3.4. Coleta em Tempo Real Redes sociais online possibilitam que usurios comuns expressem suas opinies sobre os mais diversos assuntos, e propaguem informaes que consideram relevantes em tempo real. interessante notar como a interatividade e a avaliao do uxo de informaes em tempo real passou a ser um fator importante para vrias aplicaes Web, que monitoram fenmenos dinmicos ocorridos na Web. Como exemplo, Google e Bing j indexam tweets pblicos como forma de prover busca por informao em tempo real. Do ponto de vista cientco, informaes disponibilizadas em tempo real na Web tm sido utilizadas de diferentes formas. O Google Insights3 , por exemplo, permite que o usurio consulte informaes geogrcas e temporais relacionadas ao volume de uma determinada consulta, permitndo tambm que o usurio salve essas informaes em formato CSV. De fato, informaes extradas em tempo real do Google Insights foram utilizadas para demonstrar que o volume de buscas na Web permite monitorar eventos tais como o nvel de desemprego e a ocorrncia de doenas em tempo real [46, 63]. Em particular, Ginsberg e colaboradores [63] propuseram um mtodo para monitorar ocorrncias de gripe baseado em buscas realizadas no Google. Eles mostraram que, em reas com grande populao de usurios de mquinas de buscas, o volume de buscas relacionadas gripe proporcional ocorrncia da doena. Em um trabalho recente, Sakaki e colaboradores [103] mostraram o poder da informao disponibilizada em tempo real nas redes sociais online propondo um mecanismo para deteco de ocorrncias de terremotos baseado em monitoramento do Twitter. A abordagem, que consiste em simplesmente identicar tweets relacionados a terremotos por regio, foi capaz de enviar alertas sobre terremotos mais rapidamente do que agncias meteorolgicas. Mais recentemente, Tumasjan e colaboradores [110] mostraram que opinies identicadas em tweets relacionados eleio federal alem foi capaz de reetir o sentimento poltico registrado fora das redes sociais. Para o caso especco do Twitter, bastante simples coletar informaes em tempo real, uma vez que o sistema oferece uma API com diversas opes relacionadas coleta de dados em tempo real. Como exemplo, para coletar em tempo real uma amostra aleatria de tweets pblicos basta executar o seguinte comando em algum terminal UNIX, fornecendo o usurio e senha de um usurio registrado no Twitter.
curl http://stream.twitter.com/1/statuses/sample.json -uLOGIN:SENHA
2.4.3.5. Utilizando APIs No contexto de desenvolvimento Web, uma API tipicamente um conjunto de tipos de requisies HTTP juntamente com suas respectivas denies de resposta. Em aplicaes de redes sociais online comum encontrarmos APIs que listam os amigos de um usurio, seus objetos, suas comunidades, etc. APIs so perfeitas para a coleta de dados de redes sociais online, pois oferecem
3 http://www.google.com/insights/search
84
Figura 2.10. Exemplo da API do Twitter: http://twitter.com/users/show/fbenevenuto.xml
os dados em formatos estruturados como XML e JSON. Como exemplo, a Figura 2.10 mostra o resultado de uma busca por informaes de um usurio no Twitter. Alm dessa funo, o Twitter ainda oferece vrias outras funes em sua API. Com a API do Twitter possvel coletar 5000 seguidores de um usurio atravs de uma nica requisio. A coleta dessa informao atravs do stio Web convencional necessitaria de centenas de requisies, visto que o Twitter s mostra alguns seguidores por pgina. Alm disso, cada pgina conteria uma quantidade muito grande de dados desnecessrios, que deveriam ser tratados e excludos. Vrios sistemas possuem APIs, incluindo Twitter, Flickr, YouTube, Google Mapas, Yahoo Mapas, etc. Com tantas APIs existentes, comum ver aplicaes que utilizam duas ou mais APIs para criar um novo servio, que o que chamamos de Mashup. Uma interessante aplicao chamada Yahoo! Pipes [13], permite a combinao de diferentes APIs de vrios sistemas para a criao automatizada de Mashups.
2.4.3.6. Ferramentas e Bibliotecas Desenvolver um coletor pode ser uma tarefa bastante complicada devido diversidade de formatos de pginas. Entretanto, coletar redes sociais online , e m geral, diferente de coletar pginas da Web tradicional. As pginas de uma rede social online so, em geral, bem estruturadas e possuem o mesmo formato, pois so geradas auto maticamente, enquanto que, na Web tradicional, as pginas podem ser criadas por qualquer pessoa em qualquer formato. Alm disso, como cada indivduo ou objeto em uma rede social, em geral, possui um identicador nico, temos certeza sobre quais as informaes obtivemos quando coletamos uma pgina. Existem vrias ferramentas que podem ser utilizadas para se coletar dados de redes sociais online. Como cada pesquisa requer um tipo de coleta e cada coleta de dados possui sua particularidade, desenvolver o prprio coletor pode ser necessrio. A Figura 2.11 mostra o uso da biblioteca LWP na linguagem Perl. Este cdigo realiza a coleta dos seguidores de um usurio no Twitter atravs de sua API. De maneira similar, o cdigo
85
em Python da Figura 2.12 utiliza a biblioteca URLLIB para realizar a mesma tarefa. O resultado da execuo dos coletores a lista de seguidores de um usurio do Twitter em formato XML, como ilustra a Figura 2.13.
Figura 2.11. Exemplo de Uso da Biblioteca LWP em Perl
Figura 2.12. Exemplo de Uso da Biblioteca URLLIB em Python
2.4.3.7. tica dos Coletores importante ressaltar que o uso de ferramentas automticas de coleta (coletores ou robs), se feito sem o devido cuidado, pode causar problemas de sobrecarga nos servidores alvos da coleta, o que, em ltima instncia, pode afetar a qualidade de servio da aplicao alvo. Para evitar que isto acontea, muitos servidores adotam um protocolo conhecido como Robots.txt, no qual stios Web regulamentam o que pode e o que no pode ser coletado do sistema. Este mtodo bastante utilizado pelos administradores de sistemas para informar aos robs visitantes quais diretrios de um stio Web no devem ser coletados. Ele se aplica a qualquer tipo de coleta, seja ela parte de uma pesquisa sobre redes sociais online, ou um dos componentes centrais de uma mquina de busca como o Google [37]. O Robots.txt nada mais do que um arquivo que ca no diretrio raiz dos stios e contm regras para coleta. Estas regras podem ser direcionadas a robs especcos ou podem ser de uso geral, tendo como alvo qualquer rob. Ao visitar um site, os robs devem primeiramente buscar pelo arquivo Robots.txt a m de vericar suas permisses. Exemplos desses arquivos so: http://portal.acm.org/robots.txt http://www.google.com/robots.txt
86
Figura 2.13. Resultado da Execuo dos Coletores em Perl e Python
http://www.globo.com/robots.txt http://www.orkut.com.br/robots.txt http://www.youtube.com/robots.txt http://www.robotstxt.org/robots.txt A seguir mostramos um exemplo simples de regra em um arquivo Robots.txt. Essa regra restringe todos os crawlers de acessarem qualquer contedo no sistema. User-agent: * Disallow: / possvel ainda especicar restries a alguns robs especcos ou restringir o acesso a alguns diretrios especcos. Como exemplo, o stio Web www.globo.com oferece restries para todos os robs nos seguintes diretrios. User-agent: * Disallow: Disallow: Disallow: Disallow: Disallow: Disallow: Disallow: Disallow: Disallow: /PPZ/ /Portal/ /Java/ /Servlets/ /GMC/foto/ /FotoShow/ /Esportes/foto/ /Gente/foto/ /Entretenimento/Ego/foto/
87
R obots.txt
No caso de coleta de redes sociais online, importante vericar no s o arquivo dos sistemas, mas tambm os termos de uso do sistema.
2.4.4. Dados de Aplicaes Em uma tentativa bem sucedida de enriquecer a experincia dos usurios de redes sociais online, o Facebook realizou uma de suas maiores inovaes: abriu sua plataforma para desenvolvedores de aplicaes [4]. Com esta inovao, desenvolvedores so capazes de criar diferentes tipos de aplicaes. Com o sucesso no Facebook, outros sistemas como Orkut e MySpace tambm adotoram essa estratgia. Como consequncia, o nmero e a variedade de aplicaes criadas nestes sistemas cresceram signicativamente. O Facebook sozinho possui atualmente mais de 81,000 aplicaess4 [2]. Empresas como a Zynga, especializadas em desenvolver essas aplicaes, contam com mais de 80 milhes de usurios registrados em suas aplicaes [2].
Figura 2.14. Funcionamento de Aplicaes no Facebook e no Orkut
A Figura 2.14 mostra o funcionamento de uma aplicao terceirizada em execuo em redes sociais online como o Facebook ou o Orkut. Aplicaes so caracterizadas pela presena de um servidor da rede social intermediando toda a comunicao entre o cliente e o servidor da aplicao. Tipicamente, o cliente envia a requisio ao servidor da rede social online, que a repassa ao servidor da aplicao. Ento, o servidor da aplicao manda de volta a resposta ao servidor da rede social, que a repassa ao cliente [90]. Aplicaes podem ser utilizadas para o estudo de interaes entre os usurios que utilizam as aplicaes e tambm podem ser teis para coletar outras informaes dos usurios, tais como lista de amigos e atividades executadas durante uma sesso. Alguns trabalhos zeram uso dessa estratgia para estudar os usurios de redes sociais online. Nazir e colaboradores [89] analisaram caractersticas de aplicaes no Facebook, desenvolvendo e lanando suas prprias aplicaes. Em particular, eles estudaram a formao
4 Uma
grande lista de aplicaes do Facebook pode ser encontrada na seguinte referncia [3].
88
de comunidades online a partir de grafos de interao entre os usurios de suas aplicaes. Mais recentemente, os mesmos autores estudaram vrias caractersticas relacionadas ao desempenho de suas aplicaes no Facebook [90].
2.5. Extrao de Informao

A extrao e o tratamento de informao a partir dos dados coletados so etapas essenciais para permitir diferentes anlises incluindo identicao de padres de comportamento de usurios em diferentes sistemas, identicao de tpicos de interesse dos usurios, etc. Nesta seo, discutimos brevemente os principais desaos relacionados a essas etapas. Em particular, a identicao de entidades nomeadas, tais como pessoas, organizaes e produtos, encontradas em pores de texto, assim como a derivao de relacionamentos entre estas entidades, representam importantes problemas, com diversas aplicaes interessantes. O nosso objetivo nesta seo no detalhar todas as particularidades e solues para estes problemas, que so tipicamente abordados por pesquisadores de outras reas tais como Bancos de Dados, Recuperao de Informao, Minerao de Dados e Processamento de Linguagem Natural. Entretanto, reconhecendo a necessidade de expertises complementares para o estudo de redes sociais online, achamos benco para o leitor o contato, ainda que supercial, com estes tpicos. 2.5.1. Viso Geral As redes sociais online so atualmente importantes plataformas para produo, processamento e uxo de informao. Tal informao pode se originar dentro das redes ou fora delas e pode ser utilizada como fonte primria ou complementar para derivar conhecimento sobre a prpria rede, seus membros, seus temas, suas comunidades, etc. No entanto, esta informao quase sempre ocorre em um formato textual, no estruturado, em linguagem natural e at mesmo em estilo telegrco ou informalmente codicado. Isso um grande empecilho para que esta informao possa ser processada de maneira automtica e para que dela se possa derivar conhecimento latente. Como exemplo, uma mesma entidade (p.ex: uma pessoa ou uma localidade) pode ser referenciada de vrias formas, devido s variaes introduzidas por diferentes formas de graa, aspectos regionais ou culturais, uso de abreviaturas, erros tipogrcos e outras razes associadas com o uso convencional. Em contextos j bastante explorados como stios e pginas da Web, tcnicas de reas como Recuperao de Informao, Minerao de Dados e Processamento de Linguagem Natural tm sido aplicadas com muito sucesso para extrair informao e derivar conhecimento de corpus textuais. No entanto, no contexto de redes sociais online, este corpus tem uma natureza totalmente diversa. De fato, nestas redes, o corpus textual formado por micro-documentos como tweets, blog posts, comentrios, feeds, tags, cujo tratamento deve ser necessariamente diferente do que normalmente aplicado a, por exemplo, pginas Web. Alm disto, dado o carter informal de vrias informaes disponibilizadas em redes sociais online, tcnicas de processamento de linguagem natural so difceis de serem aplicadas devido ausncia de padres lingusticos. Alm disso, nos corpora textuais encontrados em redes sociais online existe muito lixo e rudo informacional (palavras escritas erradas, de baixa qualidade sinttica ou semntica) dicultando esta tarefa ainda mais.
89
Por exemplo, tcnicas de extrao aberta de informaes na Web [55] que se baseiam em modelos lingusticos gerais de como relacionamentos so expressos em um idioma, so o estado da arte em extrao de entidades e relacionamentos de pginas Web. No entanto, como os modelos utilizados nestas tcnicas so construdos a partir de caractersticas lingusticas atravs da identicao de partes de discurso nos documentos-alvo, elas dicilmente poderiam ser aplicadas em micro-documentos (por exemplo, tweets), onde estas caractersticas podem no se apresentar. Apesar das diculdades mencionadas, a extrao de informaes contidas no corpus textual de redes sociais pode ajudar a responder de forma automtica e efetiva questes como: Quem fala com quem sobre que assunto? Quem so os atores principais nas redes? Onde esto localizados? Que assuntos e tpicos emergem, se disseminam e desaparecem nos eco-sistemas sociais digitais? Que indivduos e grupos promovem e suprimem estes assuntos e tpicos? Qual a polaridade (positiva, negativa ou neutra) das opinies emitidas na rede sobre assuntos, pessoas, empresas, etc.? Um Exemplo: Observatrio da Web Um exemplo de como a identicao de entidades uma tarefa importante para a anlise de redes sociais online o Observatrio das Eleies 20105 , que uma instncia do Observatrio da Web [104], projeto desenvolvido no mbito do InWeb (Instituto Nacional de Cincia e Tecnologia para a Web). Este observatrio foi desenvolvido para monitorar, em tempo real, o que estava sendo veiculado sobre as eleies de 2010 nas vrias mdias e pelos vrios usurios da Web. O seu objetivo era ajudar a traar um panorama do cenrio eleitoral do ponto de vista das informaes e das opinies que circulavam na Web e nas redes sociais online, incluindo jornais, revistas, portais e o Twitter. Foi implementado como um portal utilizando dezenas de ferramentas softwares inditas de captura e anlise de dados baseadas em cdigo livre ou aberto. As entidades correlatas ao contexto das eleies foram o alvo principal do monitoramento. Isso inclua alm dos candidatos presidncia, polticos com inuncia na eleio, como o ex-presidente Lula. Em muitos casos, o monitoramento era concentrado em eventos, ou seja, acontecimentos importantes no contexto observado, tais como um debate, por exemplo, e que pudessem ter um grande efeito no contedo das fontes observadas. A partir da identicao das entidades no textos coletados em tempo real, possvel gerar uma srie de produtos de anlise e visualizao. Um exemplo de um destes produtos apresentado na Figura 2.15.
5 http://www.observatorio.inweb.org.br/eleicoes2010.
90
Figura 2.15. Exemplo de Visualizao de Dados Gerados a Partir da Identicao de Entidades no Observatrio das Eleies.
No observatrio, antes da extrao propriamente dita, realizado um prprocessamento dos textos coletados, incluindo a padronizao da codicao dos caracteres, a eliminao de cdigo HTML, cabealhos e anncios de pginas coletadas atravs de feeds, e o uso de mtodos tradicionais de pr-processamento de textos [83] tais como a remoo de stop words (palavras de pouco valor informacional como artigos, preposies e conjunes) e o stemming, que consiste na extrao dos radicais das palavras do texto. A identicao de entidades nos textos feita atravs da ferramenta Illinois Named Entity Tagger [98], que utiliza tcnicas de processamento de linguagem natural para identicar referncias a entidades (pessoas, organizaes, locais, etc.) em texto livre. Apos a fase de identicao, segue-se uma fase de desambiguao de entidades. Isso necessrio porque os mtodos identicao de entidades tm diculdade, em geral, de diferenciar Jos Serra de Serra da Piedade, ou Lula presidente de Lula Molusco. Para isso, um mtodo de classicao foi utilizado para aprender a associar entidades a determinados contextos. A Figura 2.16 ilustra um RSS feed processado para identicao de entidades pelo Observatrio das Eleies. As tags so usadas como identicadores para distinguir as duas entidades em todos os textos processados. A pr-candidata do PT Presidncia da Repblica <Person2> Dilma Rousseff </Person2> , quer juntar ao seu redor o maior nmero de legendas que hoje esto na base aliada do presidente <Person1> Luiz Incio Lula da Silva </Person1>
Figura 2.16. Exemplo de RSS Feed com Entidades Identicadas no Observatrio das Eleies
91
2.5.2. Identicao de Entidades O problema de identicao de entidades nomeadas (Named Entity Recognition NER) consiste em encontrar palavras que ocorrem em um documento ou trecho de texto no estruturado e que faam referncia a entidades do mundo real. Este problema tem sido estudado em vrios contexto como identicao de nomes de pessoas e companhias em notcias, identicao de genes e protenas e publicaes biomdicas, etc. [48]. A Figura 2.17(a) ilustra o resultado tpico da aplicao de um mtodo de extrao de entidades. <pessoa> Odorico Paraguau <pessoa> foi <cargo> prefeito </cargo> eterno de <local> Sucupira </local>, cidadezinha localizada em algum lugar da <local> Bahia </local>, a qual governou com muita sabedoria e inteligncia. Dotado de uma habilidade incrvel com as palavras fruto de seu curso na <organizao> Universidade de Sourbone </organizao>), cativava as massas numa poca em que os comcios no tinham nem fanfarra, quanto mais bandas completas.6 (a) Odorico pessoa Paraguau foi pessoa outro prefeito cargo (b) eterno de outro outro Sucupira local
Figura 2.17. Exemplo de um trecho de texto com entidades identicadas (a) e como uma sequncia rotulada (b)
Uma abordagem comum para o problema de NER a de rotulamento de sequncias. Um documento representado como uma sequncia x de tokens x1 , . . . , xn e um classicador associa x a uma sequncia paralela de rtulos y = y1 , . . . , yN , onde cada yi um rtulo pertencente a um conjunto Y . Uma atribuio correta dos rtulos permite a identicao direta das entidades. Por exemplo, na sequncia ilustrada na Figura 2.17(b), cada token recebe um rtulo, sendo que um rtulo especial outro associado aos tokens que no so partes de nomes de entidades. A construo do classicador pode ser feita usando tcnicas de aprendizagem de mquina, ou seja, utilizando dados de treinamento que representam exemplos de mapeamento de sequncias x para sequncias y. Isso feito, em geral, atravs de documentos manualmente anotados de forma similar ao que est ilustrado na Figura 2.17(b). Estes classicadores so gerados pelo no aprendizado de modelos sequenciais tais como Hidden Markov Models [58] ou Conditional Random Fields [74] ou suas variaes (por exemplo, [49]). 2.5.3. Resoluo de Entidades Uma vez que as referncias a entidades so identicadas em um certo corpus, algumas aplicaes podem requerer ainda que sejam estabelecidas correspondncias entre referncias distintas que se reram a uma mesma entidade do mundo real. Este problema conhecido como Resoluo de Entidades [31]. Existem na realidade dois subproblemas relacionados ao problema de resoluo
92
de entidades, os quais ilustramos pelos trechos de texto apresentados na Figura 2.18. D1 O Acre o estado mais oeste do Brasil, seu territrio inteiramente recoberto pela Floresta Amaznica. tambm bero de grandes nomes como <pessoa>Marina Silva</pessoa>, poltica, e <pessoa>Glria Perez</pessoa>, novelista. Ao lado da ento ministra da Casa Civil, <pessoa>Dilma Rousseff</pessoa>, <pessoa>Lula</pessoa> acabou recebendo uma amostra do leo na <pessoa>Marina</pessoa> da <pessoa>Glria</pessoa>, no Rio, para onde o evento foi transferido. A candidata <pessoa>Dilma</pessoa>, vencedora do primeiro turno das eleies, telefonou hoje para a candidata <pessoa>Marina</pessoa> do PV e a parabenizou pelo seu desempenho nas urnas.
Figura 2.18. Exemplo de um Trecho de Texto com Entidades Identicadas (a) e como uma Sequncia Rotulada (b).
D2
D3
O primeiro subproblema consiste em determinar o conjunto de referncias distintas no corpus que so utilizadas para se referir a mesma entidade no mundo real. Este caso de Marina Silva em D1 e Marina em D3 , e tambm de Dilma Rousseff em D2 e Dilma em D3 . Este subproblema conhecido como Identicao [31] ou Coreferncia [68]. Note que este problema tambm pode ser causado por erros de escrita, formatao, etc., ou mesmo pelo uso de apelidos (p.ex., Dilma) e anforas (p.ex., a ministra). O segundo subproblema consiste em distinguir quando referncias muito similares, ou at mesmo exatamente iguais, se referem a diferentes entidades do mundo real. Esse o caso de Marina em D3 e em D2 e tambm de Glria Perez em D3 e Glria em D2 . Este problema chamado de Desambiguao [31]. Note que neste caso especco o problema foi causado por uma falha do processo de identicao de entidades em D2 . Tais problemas so comuns e, dependendo do domnio de aplicao, podem ser exacerbados pelo uso de abreviaes. A soluo do problema de resoluo de entidades pode ser determinante para a qualidade dos resultados obtidos a partir da anlise das entidades extradas. Por outro lado, se neglicenciado, este problema pode comprometer o conhecimento derivado destes resultados. Por exemplo, as anlises realizadas pelo Observatrio das Eleies poderiam ser seriamente afetadas se referncias ao candidato Jos Serra e Serra da Piedade no sofressem desambiguao. Na literatura recente, o problema de resoluo entidades tem sido tratado atravs do clculo da similaridade entre os atributos associados s entidades (no caso de bancos de dados) [51] ou utilizando, quando possvel, grafos de co-ocorrncia de entidades [31]. Em corpora textuais, ferramentas lingusticas tm sido usadas para soluo deste problema [96]. No caso do Observatrio das Eleies, o problema foi tratado atravs de uma soluo simples baseada em classicao usando centroides [67], que neste caso so usado para representar o contexto em que determinada entidade tipicamente encontrada
93
em termos de vocabulrio recorrente.
2.6. Bases de Dados Disponveis na Web

Vrios trabalhos que coletaram dados de redes sociais online oferecem disponibilizam os dados coletados para a comunidade acadmica. A seguir, algumas bases contendo dados pblicos disponveis na Web so relacionadas. Dados sobre Orkut, Flickr, LiverJournal e YouTube. Foram utilizados no trabalho [87] e esto disponveis em http://socialnetworks.mpi-sws.org/ data-imc2007.html Dados sobre os vdeos de duas categorias inteiras do YouTube. Coletados em 2007 e utilizados no artigo [41]. Disponvel em http://an.kaist.ac.kr/ traces/IMC2007.html. Dados do Flickr coletados ao longo do tempo. Esses dados foram utilizados na referncia [86] e esto disponveis em http://socialnetworks.mpi-sws. org/data-wosn2008.html. Dados sobre a popularidade de vdeos do YouTube com registro do crescimento e fontes dos acessos ao longo do tempo. Foram utilizados na referncia [57] e esto disponvis em http://vod.dcc.ufmg.br/traces/youtime/. Grafo completo contendo 55 milhes de usurios do Twitter e cerca de 1.8 bilhes de tweets. Esses dados foram utilizados nas referncias [40, 24] e esto disponveis no endereo http://twitter.mpi-sws.org/. Dados sobre o grafo de amizade e postagens de amostra de usurios do Facebook. Utilizados na referncia [111] e disponveis em http://socialnetworks. mpi-sws.org/data-wosn2009.html. Coleo de usurios do YouTube, manualmente classicados como spammers, promoters ou usurios legtimos. Esses dados foram utilizados nos seguintes trabalhos [26, 29, 75]. A base de dados est disponvel em http://homepages. dcc.ufmg.br/~fabricio/testcollectionsigir09.html. Coleo de dados do Del.icio.us e do Digg. Coleo utilizada em diferentes artigos e disponvel em http://www.public.asu.edu/~mdechoud/ datasets.html.
2.7. Concluses
Redes sociais online se tornaram extremamente populares e parte do nosso dia a dia, causando o surgimento de uma nova onda de aplicaes disponveis na Web. A cada dia, grandes quantidades de contedo so compartilhadas, e milhes de usurios interagem atravs de elos sociais. Apesar de tanta popularidade, o estudo de redes sociais ainda est em sua infncia, j que estes ambientes esto ainda experimentando novas tendncias e enfrentando diversos novos problemas e desaos.
94
Redes sociais online compem ambientes perfeitos para o estudo de vrios temas da computao, incluindo sistemas multimdia e interao humano-computador. Alm disso, por permitir que usurios criem contedo, aplicaes de redes sociais vm se tornando um tema chave em pesquisas relacionadas organizao e tratamento de grandes quantidades de dados, alm de constiturem um ambiente ideal para extrao de conhecimento e aplicao de tcnicas de minerao de dados. Este trabalho oferece uma introduo ao pesquisador que pretende explorar o tema. Inicialmente, foram apresentadas as principais caractersticas das redes sociais mais populares atualmente. Em seguida, discutimos as principais mtricas e tipos de anlises utilizadas no estudo dos grafos que formam a topologia das redes sociais. Finalmente, sumarizamos as principais abordagens utilizadas para se obter dados de redes sociais online e discutimos trabalhos recentes que utilizaram essas tcnicas.
Agradecimentos
Este trabalho foi parcialmente nanciado pelo Instituto Nacional de Cincia e Tecnologia para a Web (InWeb), pelo CNPq, FAPEMIG e UOL (www.uol.com.br).
Referncias
[1] comscore: Americans viewed 12 billion videos online in may 2008. http:// www.comscore.com/press/release.asp?press=2324. Acessado em Maro/2010. [2] Developer analytics. http://www.developeranalytics.com. Acessado em Maro/2010. [3] Facebook application directory. http://www.facebook.com/apps. Acessado em Maro/2010. [4] Facebook platform. http://developers.facebook.com. Acessado em Maro/2010. [5] Facebook Press Room, Statistics. http://www.facebook.com/press/ info.php?statistics. Acessado em Maro/2010. [6] Gnuplot. http://www.gnuplot.info/. Acessado em Agosto/2010. [7] Google OpenSocial. http://code.google.com/apis/opensocial/. Acessado em Maro/2010. [8] List of social network web sites. http://en.wikipedia.org/wiki/ List_of_social_networking_websites. Acessado em Maro/2010. [9] Matlab. http://www.mathworks.com/products/matlab/. Acessado em Agosto/2010. [10] Needle in a Haystack: Efcient Storage of Billions of Photos. Facebook Engineering Notes, http://tinyurl.com/cju2og. Acessado em Maro/2010.
95
[11] New york times. a web site born in u.s. nds fans in brazil. http:// www.nytimes.com/2006/04/10/technology/10orkut.html. Acessado em Maro/2010. [12] New york times. uploading the avantgarde. http://www.nytimes. com/2009/09/06/magazine/06FOB-medium-t.htm. Acessado em Julho/2010. [13] Yahoo! pipes. Agosto/2010. http://pipes.yahoo.com/pipes. Acessado em
[14] YouTube fact sheet. http://www.youtube.com/t/fact_sheet. Acessado em Maro/2010. [15] L. Adamic, O. Buyukkokten, and E. Adar. A social network caught in the web. First Monday, 8(6), 2003. [16] Y.-Y. Ahn, S. Han, H. Kwak, S. Moon, and H. Jeong. Analysis of topological characteristics of huge online social networking services. In World Wide Web Conference (WWW), pages 835844, 2007. [17] R. Albert, H., Jeong, and A. Barabasi. Error and attack tolerance of complex networks. Nature, 406(6794):378382, 2000. [18] R. Albert, H. Jeong, and A. Barabasi. Diameter of the world wide web. Nature, 401:130131, 1999. [19] N. Ali-Hasan and L. Adamic. Expressing social relationships on the blog through links and comments. In AAAI Conference on Weblogs and Social Media (ICWSM), 2007. [20] A. Amaral, A. Scala, M. Barthelemy, and E. Stanley. Classes of small-world networks. 97(21):1114911152, 2000. [21] B. Williamson. Social network marketing: ad spending and usage. EMarketer Report, 2007. http://tinyurl.com/2449xx. Acessado em Maro/2010. [22] A. Barabasi and R. Albert. Emergence of scaling in random networks. Science, 286(5439), 1999. [23] F. Benevenuto, F. Duarte, T. Rodrigues, V. Almeida, J. Almeida, and K. Ross. Understanding video interactions in YouTube. In ACM Conference on Multimedia (MM), pages 761764, 2008. [24] F. Benevenuto, G. Magno, T. Rodrigues, and V. Almeida. Detecting spammers on twitter. In Annual Collaboration, Electronic messaging, Anti-Abuse and Spam Conference (CEAS), 2010. [25] F. Benevenuto, A. Pereira, T. Rodrigues, V. Almeida, J. Almeida, and M. Gonalves. Characterization and analysis of user proles in online video sharing systems. Journal of Information and Data Management, 1(2):115129, 2010.
96
[26] F. Benevenuto, T. Rodrigues, V. Almeida, J. Almeida, and M. Gonalves. Detecting spammers and content promoters in online video social networks. In Intl ACM Conference on Research and Development in Information Retrieval (SIGIR), pages 620627, 2009. [27] F. Benevenuto, T. Rodrigues, V. Almeida, J. Almeida, M. Gonalves, and K. Ross. Video pollution on the web. First Monday, 15(4), April 2010. [28] F. Benevenuto, T. Rodrigues, V. Almeida, J. Almeida, and K. Ross. Video interactions in online video social networks. ACM Transactions on Multimedia Computing, Communications and Applications (TOMCCAP), 5(4):125, 2009. [29] F. Benevenuto, T. Rodrigues, V. Almeida, J. Almeida, C. Zhang, and K. Ross. Identifying video spammers in online social networks. In Workshop on Adversarial Information Retrieval on the Web (AIRWeb), pages 4552, 2008. [30] F. Benevenuto, T. Rodrigues, M. Cha, and V. Almeida. Characterizing user behavior in online social networks. In ACM SIGCOMM Internet Measurement Conference (IMC), pages 4962, 2009. [31] I. Bhattacharya and L. Getoor. Collective entity resolution in relational data. ACM Trans. Knowl. Discov. Data, 1, 2007. [32] J. Binder, A. Howes, and A. Sutcliffe. The problem of conicting social spheres: effects of network structure on experienced tension in social network sites. In ACM SIGCHI Conference on Human factors in Computing Systems (CHI), pages 965 974, 2009. [33] S. Boll. Multitubewhere web 2.0 and multimedia could meet. IEEE MultiMedia, 14(1):913, 2007. [34] D. Boyd. Why Youth (Heart) Social Network Sites: The Role of Networked Publics in Teenage Social Life. Cambridge, MA, 2007. [35] D. Boyd and N. Ellison. Social network sites: Denition, history, and scholarship. Journal of Computer-Mediated Communication, 13(1-2), 2007. [36] V. Braitenberg and A. Schz. Cortex: Statistics and Geometry of Neuronal Connectivity. Springer-Verlag, 1998. [37] S. Brin and L. Page. The anatomy of a large-scale hypertextual web search engine. Computer Networks and ISDN Systems, 30(1-7):107117, 1998. [38] A. Broder, R. Kumar, F. Maghoul, P. Raghavan, S. Rajagopalan, R. Stata, A. Tomkins, and J. Wiener. Graph structure in the web. Computer Networks, 33:309320, 2000. [39] M. Burke, C. Marlow, and T. Lento. Feed me: Motivating newcomer contribution in social network sites. In ACM SIGCHI Conference on Human factors in Computing Systems (CHI), pages 945954, 2009.
97
[40] M. Cha, H. Haddadi, F. Benevenuto, and K. Gummadi. Measuring user inuence in twitter: The million follower fallacy. In In 4th International AAAI Conference on Weblogs and Social Media (ICWSM), 2010. [41] M. Cha, H. Kwak, P. Rodriguez, Y.-Y. Ahn, and S. Moon. I tube, you tube, everybody tubes: Analyzing the worlds largest user generated content video system. In ACM SIGCOMM Conference on Internet Measurement (IMC), pages 114, 2007. [42] M. Cha, A. Mislove, and K. Gummadi. A measurement-driven analysis of information propagation in the Flickr social network. In World Wide Web Conference (WWW), pages 721730, 2009. [43] C. Chapman and M. Lahav. International ethnographic observation of social networking sites. In ACM SIGCHI Conference on Human factors in Computing Systems (CHI), pages 31233128, 2008. [44] P. Chatterjee, D. L. Hoffman, and T. P. Novak. Modeling the clickstream: implications for web-based advertising efforts. Marketing Science, 22(4):520541, 2003. [45] D. Chau, Pandit, S. Wang, and C. Faloutsos. Parallel crawling for online social networks. In World Wide Web Conference (WWW), pages 12831284, 2007. [46] H. Choi and H. Varian. Predicting the present with google trends. http://bit. ly/2iujV3. Accessed in Jan/2011, 2009. [47] H. Chun, H. Kwak, Y. Eom, Y.-Y. Ahn, S. Moon, and H. Jeong. Comparison of online social relations in volume vs interaction: a case study of Cyworld. In ACM SIGCOMM Internet Measurement Conference (IMC), pages 5770, 2008. [48] W. Cohen and S. Sarawagi. Exploiting Dictionaries in Named Entity Extraction: Combining Semi-Markov Extraction Processes and Data Integration Methods. In Proc. 10th ACM SIGKDD Intl. Conf. on Knowl. Discov. and Data Mining, pages 8998, 2004. [49] E. Cortez, A. S. da Silva, M. A. Gonalves, and E. S. de Moura. Ondux: ondemand unsupervised learning for information extraction. In Proceedings of the 2010 international conference on Management of data, SIGMOD 10, pages 807 818, 2010. [50] X. Dale and C. Liu. Statistics and social network of YouTube videos. In Intl Workshop on Quality of Service (IWQoS), 2008. [51] J. de Freitas, G. L. Pappa, A. S. da Silva, M. A. Gonalves, E. S. de Moura, A. Veloso, A. H. F. Laender, and M. G. de Carvalho. Active learning genetic programming for record deduplication. In IEEE Congress on Evolutionary Computation, pages 18, 2010. [52] F. Duarte, F. Benevenuto, V. Almeida, and J. Almeida. Locality of reference in an hierarchy of web caches. In IFIP Networking Conference (Networking), pages 344354, 2006.
98
[53] F. Duarte, B. Mattos, A. Bestavros, V. Almeida, and J. Almeida. Trafc characteristics and communication patterns in blogosphere. In Conference on Weblogs and Social Media (ICWSM), 2007. [54] H. Ebel, L. Mielsch, and S. Bornholdt. Scale free topology of e-mail networks. Physical Review E, 66(3):35103, 2002. [55] O. Etzioni, M. Banko, S. Soderland, and D. S. Weld. Open information extraction from the web. Commun. ACM, 51(12):6874, December 2008. [56] M. Faloutsos, P. Faloutsos, and C. Faloutsos. On power-law relationships of the Internet topology. In Annual Conference of the ACM Special Interest Group on Data Communication (SIGCOMM), pages 251262, 1999. [57] F. Figueiredo, F. Benevenuto, and J. Almeida. The tube over time: Characterizing popularity growth of youtube videos. In Proceedings of the 4th ACM International Conference of Web Search and Data Mining (WSDM), 2011. [58] D. Freitag and A. McCallum. Information Extraction with HMM Structures Learned by Stochastic Optimization. In Proc. of the 17th Nat. Conf. on Art. Intell. and 12th Conf. on Innov. Appl. of Art. Intell., pages 584589, 2000. [59] E. Gabrilovich, S. Dumais, and E. Horvitz. Newsjunkie: Providing personalized newsfeeds via analysis of information novelty. In World Wide Web Conference (WWW), pages 482490, 2004. [60] D. Garlaschelli and M. Loffredo. Patterns of link reciprocity in directed networks. Physical Review Letters, 93(26):268701, 2004. [61] P. Gill, M. Arlitt, Z. Li, and A. Mahanti. YouTube trafc characterization: A view from the edge. In ACM SIGCOMM Conference on Internet Measurement (IMC), pages 1528, 2007. [62] P. Gill, M. Arlitt, Z. Li, and A. Mahanti. Characterizing user sessions on YouTube. In IEEE Multimedia Computing and Networking (MMCN), 2008. [63] J. Ginsberg, M. H. Mohebbi, R. S. Patel, L. Brammer, M. S. Smolinski, and L. Brilliant. Detecting inuenza epidemics using search engine query data. Nature, 457:10124, 2009. [64] L. Gomes, J. Almeida, V. Almeida, and W. Meira. Workload models of spam and legitimate e-mails. Performance Evaluation, 64(7-8), 2007. [65] K. Gummadi, R. Dunn, S. Saroiu, S. Gribble, H. Levy, and J. Zahorjan. Measurement, modeling, and analysis of a peer-to-peer le-sharing workload. In ACM Symposium on Operating Systems Principles (SOSP), 2003. [66] Z. Gyngyi, H. Garcia-Molina, and J. Pedersen. Combating web spam with trustrank. In Intl. Conference on Very Large Data Bases (VLDB), pages 576587, 2004.
99
[67] E.-H. Han and G. Karypis. Centroid-based document classication: Analysis and experimental results. In Proceedings of the 4th European Conference on Principles of Data Mining and Knowledge Discovery, pages 424431, 2000. [68] J. Hobbs. Coherence and coreference*. Cognitive science, 3(1):6790, 1979. [69] A. Joinson. Looking at, looking up or keeping up with people?: motives and use of Facebook. In ACM SIGCHI Conference on Human factors in Computing Systems (CHI), pages 10271036, 2008. [70] R. King. When your social sites need networking, BusinessWeek, 2007. http: //tinyurl.com/o4myvu. Acessado em Maro/2010. [71] B. Krishnamurthy. A measure of online social networks. In Conference on Communication Systems and Networks (COMSNETS), 2009. [72] R. Kumar, J. Novak, and A. Tomkins. Structure and evolution of online social networks. In ACM SIGKDD Intl Conference on Knowledge Discovery and Data Mining (KDD), 2006. [73] H. Kwak, C. Lee, H. Park, and S. Moon. What is twitter, a social network or a news media? In Intl World Wide Web Conference (WWW), 2010. [74] J. D. Lafferty, A. McCallum, and F. C. N. Pereira. Conditional random elds: Probabilistic models for segmenting and labeling sequence data. In Proceedings of the Eighteenth International Conference on Machine Learning, ICML01, pages 282289, 2001. [75] H. Langbehn, S. Ricci, M. Gonalves, J. Almeida, G. Pappa, and F. Benevenuto. A multi-view approach for detecting spammers and content promoters in online video social networks. Journal of Information and Data Management, 1(3):116, 2010. [76] S. Lee, P. Kim, and H. Jeong. Statistical properties of sampled networks. Physical Review E, 73(30):102109, 2006. [77] K. Lerman. Social information processing in news aggregation. IEEE Internet Computing, 11(6):1628, 2007. [78] J. Leskovec, L. A. Adamic, and B. A. Huberman. The dynamics of viral marketing. ACM Transactions on the Web (TWEB), 1(1):228237, 2007. [79] J. Leskovec and E. Horvitz. Planetary-scale views on a large instant-messaging network. In World Wide Web Conference (WWW), 2008. [80] L. Li, D. Alderson, J. Doyle, and W. Willinger. Towards a theory of scale-free graphs: Denition, properties, and implications. Internet Mathematics, 2(4), 2005. [81] L. Lovsz. Random Walks on Graphs: A Survey. Combinatorics, 2:146, 1993.
100
[82] A. Mahanti, D. Eager, and C. Williamson. Temporal locality and its impact on web proxy cache performance. Performance Evaluation Journal, 42(2-3):187 203, 2000. [83] C. D. Manning, P. Raghavan, and H. Schtze. Introduction to Information Retrieval. Cambridge University Press., 2008. [84] S. Milgram. The small world problem. Psychology Today, 2:6067, May 1967. [85] A. Mislove. Online Social Networks: Measurement, Analysis, and Applications to Distributed Information Systems. PhD thesis, Rice University, Department of Computer Science, 2009. [86] A. Mislove, H. Koppula, K. Gummadi, P. Druschel, and B. Bhattacharjee. Growth of the ickr social network. In ACM SIGCOMM Workshop on Social Networks (WOSN), pages 2530, 2008. [87] A. Mislove, M. Marcon, K. Gummadi, P. Druschel, and B. Bhattacharjee. Measurement and analysis of online social networks. In ACM SIGCOMM Conference on Internet Measurement (IMC), pages 2942, 2007. [88] C. Moore and M. Newman. Epidemics and percolation in small-world networks. Physical Review E, 61(5):5678, 2000. [89] A. Nazir, S. Raza, and C. Chuah. Unveiling facebook: A measurement study of social network based applications. In ACM SIGCOMM Conference on Internet Measurement (IMC), pages 4356, 2008. [90] A. Nazir, S. Raza, D. Gupta, C. Chua, and B. Krishnamurthy. Network level footprints of facebook applications. In ACM SIGCOMM Conference on Internet Measurement (IMC), pages 6375, 2009. [91] M. Newman. The structure of scientic collaboration networks. 98(2):404409, 2001. [92] M. Newman. Assortative mixing in networks. Physical Review E, 89(20):208701, 2002. [93] M. Newman. The structure and function of complex networks. SIAM Review, 45:167256, 2003. [94] M. Newman. Coauthorship networks and patterns of scientic collaboration. 101(1):52005205, 2004. [95] M. Newman and M. Girvan. Finding and evaluating community structure in networks. Physical Review E, 69(2):26113, 2004. [96] V. Ng. Shallow semantics for coreference resolution. In Proceedings of the 20th International Joint Conference on Articial Intelligence, pages 16891694, 2007.
101
[97] J. Otterbacher. helpfulness in online communities: a measure of message quality. In ACM SIGCHI Conference on Human factors in Computing Systems (CHI), pages 955964, 2009. [98] L. Ratinov and D. Roth. Design challenges and misconceptions in named entity recognition. In Proceedings of the Thirteenth Conference on Computational Natural Language Learning, CoNLL 09, pages 147155, 2009. [99] N. O. Report. Social networks & blogs now 4th most popular online activity, 2009. http://tinyurl.com/cfzjlt. Acessado em Maro/2010. [100] B. Ribeiro and D. Towsley. Estimating and Sampling Graphs with Multidimensional RandomWalks. In Proceedings ACM SIGCOMM Internet Measurement Conference, 2010. [101] C. P. Robert and G. Casella. Monte Carlo Statistical Methods. Springer-Verlag, second edition, 2005. [102] P. Rodriguez. Web infrastructure for the 21st century. WWW09 Keynote, 2009. http://tinyurl.com/mmmaa7. Acessado em Maro/2010. [103] T. Sakaki, M. Okazaki, and Y. Matsuo. Earthquake shakes twitter users: realtime event detection by social sensors. In WWW 10: Proceedings of the 19th international conference on World wide web, pages 851860, 2010. [104] W. Santos, G. Pappa, W. Meira Jr., D. Guedes, A. Veloso, V. Almeida, A. Pereira, P. Guerra, A. Silva, F. Mouro, T. Magalhes, F. Machado, L. Cherchiglia, L. Simes, R. Batista, F. Arcanjo, G. Brunoro, N. Mariano, G. Magno, M. T. Ribeiro, L. Teixeira, A. S. Silva, B. W. Reis, and R. H. Silva. Observatrio da web: Uma plataforma de monitorao, sntese e visualizao de eventos massivos em tempo real. In Anais do XXXVII Seminrio Integrado de Hardware e Software, SEMISH10, pages 110120, 2010. [105] F. Schneider, A. Feldmann, B. Krishnamurthy, and W. Willinger. Understanding online social network usage from a network perspective. In ACM SIGCOMM Internet Measurement Conference (IMC), pages 3548, 2009. [106] S. Schroeder. 20 ways to aggregate your social networking proles, Mashable, 2007. http://tinyurl.com/2ceus4. Acessado em Maro/2010. [107] J. Thom-Santelli, M. Muller, and D. Millen. Social tagging roles: publishers, evangelists, leaders. In ACM SIGCHI Conference on Human factors in Computing Systems (CHI), pages 10411044, 2008. [108] M. Torkjazi, R. Rejaie, and W. Willinger. Hot today, gone tomorrow: On the migration of myspace users. In ACM SIGCOMM Workshop on Online social networks (WOSN), pages 4348, 2009. [109] K. S. Trivedi. Probability and statistics with reliability, queuing and computer science applications. John Wiley and Sons Ltd., Chichester, UK, 2002.
102
[110] A. Tumasjan, T. Sprenger, P. Sandner, and I. Welpe. Predicting elections with twitter: What 140 characters reveal about political sentiment. 2010. [111] B. Viswanath, A. Mislove, M. Cha, and K. Gummadi. On the evolution of user interaction in facebook. In Proceedings of the 2nd ACM SIGCOMM Workshop on Social Networks (WOSN09), 2009. [112] B. Viswanath, A. Mislove, M. Cha, and K. P. Gummadi. On the evolution of user interaction in Facebook. In ACM SIGCOMM Workshop on Online Social Networks (WOSN), pages 3742, 2009. [113] S. Wasserman, K. Faust, and D. Iacobucci. Social Network Analysis: Methods and Applications (Structural Analysis in the Social Sciences). Cambridge University Press, 1994. [114] D. Watts. Small Worlds: the Dynamics of Networks Between Order and Randomness. Princeton University Press, 1999. [115] D. Watts. A simple model of global cascades on random networks. 99(9):5766 5771, 2002. [116] J. Weng, E.-P. Lim, J. Jiang, and Q. He. Twitterrank: nding topic-sensitive inuential twitterers. In ACM international conference on Web search and data mining (WSDM), pages 261270, 2010. [117] C. Williamson. On lter effects in web caching hierarchies. ACM Transactions on Internet Technology (TOIT), 2(1):4777, 2002. [118] J. Zhang, M. Ackerman, and L. Adamic. Expertise networks in online communities: Structure and algorithms. In World Wide Web Conference (WWW), pages 221230, 2007. [119] M. Zink, K. Suh, Y. Gu, and J. Kurose. Watch global, cache local: YouTube network traces at a campus network - measurements and implications. In IEEE Multimedia Computing and Networking (MMCN), 2008.
Captulo
3
Web das Coisas: Conectando Dispositivos Fsicos ao Mundo Digital
Tiago C. de Frana, Paulo F. Pires, Luci Pirmez, Flvia C. Delicato, Claudio Farias
Abstract In the near future the number of physical devices (also called smart objects) connected to the internet will be massive. Those devices can be wireless sensors, mobile phones or any other electronic device of people's daily lives. The Web of Things (WoT) proposal is to integrate smart objects into the Web so that user will be able to access those physical objects via URLs, browse them, and reuse the resources provided by them in the building of composite Web applications, called mashups. This short course introduces the concepts and technologies involved in the WoT. Following, we present the underlying software architecture currently employed in WoT projects. Finally, we present practical examples of application development using the Sun SPOT platform. Resumo Brevemente ser imenso o nmero de dispositivos fsicos (chamados objetos inteligentes) conectados a internet. Esses dispositivos podem ser sensores sem fio, celulares ou qualquer outro aparelho eletrnico do cotidiano das pessoas. A Web das Coisas (WoT, do ingls, Web of Things) prope que os objetos inteligentes sejam integrados a Web, permitindo, desta forma, que os usurios possam acessar tais objetos atravs de URLs, realizando pesquisas e reutilizando os recursos dos mesmos em aplicaes Web chamadas mashups. Este minicurso introduz os conceitos e tecnologias da WoT e apresenta a arquitetura de software subjacente atualmente empregada. Em seguida, so apresentados exemplos prticos de construo de aplicaes baseadas no paradigma da WoT utilizando a plataforma Sun SPOT.
104
3.1. Introduo
Graas ao impressionante progresso no campo de dispositivos embarcados, objetos fsicos tais como eletrodomsticos, mquinas industriais, sensores sem fio e atuadores podem atualmente se conectar a internet. Exemplos desses pequenos e versteis dispositivos so: Chumby [Chumby 2011], Gumstix [Gumstix 2011], Sun SPOTs [Sun 2011], Ploggs [Ploggs 2011], Nabaztag [Nabaztag 2011], Pokens [Pokens 2011], etc. Segundo a Aliana IPSO (do ingls, IP for Smart Objects), em um futuro prximo um grande nmero de dispositivos embarcados ir suportar o protocolo IP [Hui 2008]. Assim, muitos objetos do dia a dia (como geladeiras, equipamentos de arcondicionado, dentre outros) brevemente estaro conectados diretamente a internet. A conexo desses objetos do dia a dia com a internet denominada Internet das Coisas (do ingls, Internet of Things - IoT) [Duquennoy 2009]. A IoT oferece novas oportunidades de projetos para aplicaes interativas as quais, alm de conter documentos estticos, contero informao em tempo real referentes a lugares e objetos do mundo fsico. Recentemente surgiu um novo paradigma de desenvolvimento de aplicaes inspirado na idia da IoT, conhecido como Web das Coisas (do ingls Web of Things WoT) [Duquennoy 2009], [Guinard 2010]. Esse novo conceito se baseia no uso de protocolos e padres amplamente aceitos e j em uso na Web tradicional, tais como HTTP (Hypertext Transfer Protocol) e URIs (do ingls, Uniform Resource Identifier). O objetivo da WoT alavancar a viso de conectividade entre o mundo fsico e o mundo digital, fazendo com que a Web atual passe a englobar tambm objetos do mundo fsico (chamados objetos inteligentes, do ingls smart things) os quais passaro a ser tratados da mesma forma que qualquer outro recurso Web. Na WoT, o protocolo HTTP no utilizado apenas como protocolo de comunicao para transportar dados formatados em conformidade com alguma especificao (como no caso das tecnologias de servios Web). Em vez disso, o protocolo HTTP utilizado como mecanismo de suporte padro a toda interao com os objetos inteligentes. Essa interao ocorre por meio dos principais mtodos (GET, POST, PUT e DELETE) desse protocolo, os quais permitem que as funcionalidades dos objetos sejam expostas em interfaces Web bem definidas. Tais interfaces so construdas de acordo com os princpios REST (do ingls, Representational State Transfer) [Fielding 2000], [Guinard e Trifa 2009] os quais permitem que os servios dos objetos inteligentes sejam expostos como recurso em uma abordagem ROA (do ingls, Resource-Oriented Architecture) [Guo 2010], [Mayer 2010]. Alm da padronizao e simplificao no processo de desenvolvimento, a utilizao do protocolo HTTP tambm elimina problemas de compatibilidade entre diferentes fabricantes, protocolos e formatos especficos [Duquennoy 2009]. A realizao da viso da WoT requer, portanto, que a World Wide Web atual seja estendida de modo que objetos do mundo real e dispositivos embarcados possam ser incorporados a ela de forma transparente. Essa extenso obtida atravs da utilizao do protocolo HTTP e dos princpios REST na criao de APIs (do ingls, Application Programming Interface) RESTful que faam com os objetos inteligentes se tornem recursos Web. A forma como tais objetos inteligentes so representados e expostos como recursos na Web tem diferentes granularidades, podendo um recurso ser definido como sendo um objeto ou dispositivo sensor individual, como uma rede de
105
sensores sem fio (RSSF), ou at mesmo como dados agregados oriundos de diferentes RSSFs. Alm disso, atravs do uso de plataformas de middleware, por exemplo, podem ser providos servios no topo dos recursos conectados a Web, de modo a facilitar a rpida combinao de mltiplos recursos para criar aplicaes de valor agregado denominadas mashups fsicos [Delicato et al. 2010], [Guinard et al. 2009]. Esses mashups so aplicaes ad-hoc da Web 2.0 que permitem colaborao e compartilhamento de informaes atravs da composio de recursos disponveis na Web [Bezerra et al. 2009]. O objetivo geral deste minicurso apresentar o estado da arte no desenvolvimento de aplicaes para a Web das Coisas. Seus objetivos especficos so: (i) fornecer uma viso geral do conceito de Internet das Coisas e sua evoluo para a Web das Coisas; (ii) apresentar a arquitetura de software atualmente empregada nos projetos de Web das Coisas; (iii) apresentar solues atuais da WoT; e, por fim, (iv) apresentar como aplicaes baseadas no conceito da Web das Coisas podem ser desenvolvidas. A plataforma alvo abordada no curso para os dispositivos embarcados ser a Sun SPOT [Sun SPOT 2011].
3.2. Da Internet das Coisas a Web das Coisas

Espera-se que em um futuro prximo tanto computadores como objetos fsicos estejam conectados a internet [Atzori et al. 2010]. Essa interconexo de dispositivos na internet, chamada Internet das Coisas (IoT, do ingls Internet of Things), possibilitar que tais dispositivos sejam utilizados remotamente por humanos ou at mesmo por outros dispositivos [Tan e Wang 2010]. Dentre as propostas existentes na IoT, est a Web das Coisas, a qual prope a adoo dos padres Web a fim de oferecer uma base comum para que diferentes tipos de dispositivos possam ser beneficiados pelas tecnologias existentes na Web, alm de facilitar o desenvolvimento de aplicativos para tais dispositivos. Nesta Seo so descritas as principais caractersticas da Internet das Coisas, seguida da apresentao da Web das Coisas. 3.2.1. Internet das Coisas Atualmente, a Internet das Coisas (IoT) vem ganhando grande destaque no cenrio das telecomunicaes e est sendo considerada a revoluo tecnolgica que representa o futuro da computao e comunicao [Tan e Wang 2010], [Atzori et al. 2010]. Devido a importncia da IoT, o Conselho Nacional de Inteligncia dos EUA (NIC) a considera como uma das seis tecnologias civis mais promissoras e que mais impactaro a nao no futuro prximo. O NIC prev que em 2025 todos os objetos do cotidiano (por exemplo, embalagens de alimento, documentos e mveis) podero estar conectados a internet [NIC 2008]. Graas ao paradigma IoT, estima-se que uma grande quantidade de objetos estaro conectados internet, se tornando os maiores emissores e receptores de trfego da rede. Esses objetos podem ser quaisquer dispositivos, tais como eletrodomsticos, pneus, sensores, atuadores, telefones celulares, entre outros, que possam ser identificados e interligados a internet para trocar informaes e tomar decises para atingir objetivos comuns [Atzori et al. 2010]. A ITU (International Telecommunication Union) Internet Reports (2005) apontou que na Internet das Coisas qualquer objeto capaz de ser conectado em rede poder se comunicar a qualquer tempo e em qualquer lugar. A Figura 3.1 mostra as novas dimenses do mundo das tecnologias da
106
comunicao e informao da internet no futuro. Nessa figura possvel observar o que pode ser conectado a internet, quando pode ser conectado e onde pode se conectar. Obviamente, a ampla difuso do paradigma IoT acarretar um forte impacto na vida cotidiana dos usurios. Isso ocorrer porque diversas aplicaes estaro a disposio desses usurios, entre elas: aplicaes de controle de ambiente; aplicaes de assistncia a vida em ambientes de sade; aplicaes de automao e produo industrial, logstica, segurana, entre outras [Atzori et al. 2010], [Yun e Yuxin, 2010]. As mudanas proporcionadas pela IoT tambm traro novas oportunidades de negcio que, impulsionadas pelas demandas da populao, contribuiro de maneira inestimvel para a economia [ITU Internet Reports 2005], [Tan e Wang 2010], [Yongjia 2010].
Figura 3.1 - Uma Nova Dimenso, adaptado de [ITU Internet Reports 2005]
O termo IoT recebeu diferentes definies na literatura. Algumas definies e pesquisas focaram no termo internet [Atzori et al. 2010] e observaram a IoT do ponto de vista de redes [Atzori et al. 2010] . Outras definies focaram no termo genrico coisas e as pesquisas que focam nesse termo buscam a integrao de objetos em um arcabouo comum. Tambm surgiram definies que focaram em questes semnticas, observando a IoT do ponto de vista da comunicao entre dispositivos distintos. De fato, para a TIC (Tecnologia da Informao e Comunicao), a expresso composta Internet das Coisas representa uma rede mundial de objetos heterogneos e endereveis, interligados e se comunicando atravs de protocolos de comunicao padronizados. A Figura 3.2 ilustra o fato exposto acima, de que o paradigma da IoT pode ser visto de acordo com trs vises principais: uma focada nas coisas, outra focada na semntica e ainda outra cujo foco a internet [Atzori et al. 2010]. Os trabalhos focados nas coisas buscam apresentar propostas que garantam o melhor aproveitamento dos recursos dos dispositivos e sua comunicao [Atzori et. al 2010]. Por outro lado, os trabalhos que apresentam propostas focadas na semntica dos objetos da IoT so importantes devido a grande quantidade de itens que estaro conectados a internet em um futuro prximo. Tais trabalhos apresentam propostas que esto focadas na representao, armazenamento, interconexo, pesquisa e organizao da informao gerada na IoT, buscando solues para a modelagem das descries que permitam um tratamento adequado para os dados gerados pelos objetos [Atzori et al. 2010].
107
Os trabalhos que focam na viso orientada a internet procuram criar modelos e tcnicas para a interoperabilidade dos dispositivos em rede. Um exemplo o padro IPSO (IP for Smart Objects), o qual apresenta a proposta 6LowPAN, na qual o protocolo IP adaptado para ser utilizado em dispositivos que possuem recursos de hardware reduzidos [RFC4944 2007], [Hui e Culler 2008].
Figura 3.2 - "Internet of Things" como resultado de diferentes vises [Atzori et al. 2010]
Apesar de existirem diversos trabalhos na literatura que tratam temas relacionados IoT, ainda necessrio superar uma srie de desafios tecnolgicos e sociais para que tal paradigma seja amplamente utilizado e difundido. Um tipo de desafio tecnolgico est relacionado com os baixos recursos computacionais e de energia dos dispositivos da IoT. Portanto, os trabalhos nessa rea, alm de apresentarem propostas que sejam escalveis, dado que ser potencialmente enorme o nmero de dispositivos que faro parte da IoT, precisam tambm apresentar solues que utilizem os recursos dos dispositivos de forma eficiente. Um outro tipo de desafio consiste na definio de modelos de desenvolvimento de aplicaes que tratem questes tais como a padronizao do acesso aos servios e informaes oferecidos pelos dispositivos, segurana e privacidade, modelo de programao, etc. O paradigma Web das Coisas, descrito na seo a seguir, se preocupa em apresentar solues para esse tipo de desafio. 3.2.2. Web das Coisas A incluso de dispositivos fsicos e aparelhos eletrnicos (redes de sensores sem fio, telefones celulares, etc.) na internet traz consigo inmeras possibilidades de novas aplicaes, as quais podem utilizar as informaes e servios desses dispositivos com diferentes propsitos. Entretanto, a maioria dos objetos so atualmente conectados a internet (e algumas vezes a Web) utilizando softwares e interfaces proprietrias, o que
108
torna onerosa a criao de aplicaes que integram dados e servios providos por diferentes dispositivos [Guinard 2010]. Alm disso, o uso das linguagens, protocolos e interfaces especficas de cada tipo de dispositivo tambm faz com que o desenvolvimento de aplicativos para os mesmos seja uma tarefa complexa, pois necessrio que o desenvolvedor possua conhecimento especializado para cada dispositivo utilizado no projeto. Dessa forma, para facilitar o desenvolvimento de servios no topo desses dispositivos, permitindo tambm que os servios e os dados dos mesmos sejam compostos em diferentes aplicaes, necessrio utilizar uma linguagem comum a diferentes dispositivos [Guinard e Trifa 2009], [Guinard 2010]. A WoT prope que os protocolos Web sejam utilizados como linguagem comum para integrao de dispositivos fsicos no meio digital. A incluso dos dispositivos fsicos na Web permite que os seus dados e servios sejam reutilizados em diferentes aplicaes [Duquennoy et al. 2009]. A integrao dos dispositivos a Web ocorre no nvel de aplicao, isto , acima da conectividade de rede [Guinard et al. 2010]. Tal integrao permite que ferramentas e tcnicas da Web (por exemplo, navegadores, ferramentas de busca e sistemas de cache), linguagens da Web (por exemplo, HTML e JavaScript) e tcnicas de interao com o usurio (por exemplo, navegao, vinculao e bookmarking) possam ser aplicadas para objetos do mundo real [Guinard e Trifa 2009], [Guinard et al. 2010]. Desta forma, a WoT possibilita a agregao de valor s informaes providas pelos objetos fsicos atravs da utilizao de todos os recursos disponveis na Web (por exemplo, cache, balanceamento de carga, indexao e pesquisa), o que por sua vez alavanca a concretizao da viso da IoT [Guinard e Trifa 2009]. Atualmente possvel encontrar trabalhos que apresentam propostas de sistemas que integram objetos com a internet. Um exemplo so os projetos que promovem a integrao de redes de sensores com a internet, tais como o SenseWeb [SenseWeb 2011] e o Pachube [Pachube 2011]. Ambos oferecem uma plataforma para que as pessoas compartilhem os dados coletados por sensores atravs de servios Web. Porm, essas abordagens no so to abrangentes quanto proposta da Web das Coisas, pois elas utilizam servidores que recebem e armazenam dados de sensores de forma centralizada. A WoT por outro lado, preconiza que qualquer objeto fsico pode enviar seus dados para pontos descentralizados e esses dados podem ser utilizado e reutilizados em diferentes aplicaes [Guinard 2010]. Uma possvel abordagem para implementar o conceito de WoT so os padres WS-* (como o SOAP). Os WS-* geralmente utilizam o protocolo HTTP para realizar tarefas de comunicao na pilha de protocolos utilizada pelos dispositivos. Nesse caso, o HTTP utilizado para transportar a mensagem SOAP (a qual codificada em XML), evitando assim possveis problemas com firewalls, j que geralmente a porta 80 (usada pelo HTTP) liberada nos firewalls [Guinard e Trifa 2009], [Shelby 2010]. Contudo, a interoperabilidade obtida atravs do emprego dos padres WS-* alcanada atravs da adio de uma camada de software nas aplicaes. Tal adio implica uma maior complexidade de software, no sendo, desta forma, a soluo mais adequada para ser aplicada em dispositivos com recursos limitados [Guinard e Trifa 2009]. Diferentemente da abordagem WS-*, a Web das Coisas prope que a Web atual seja estendida de modo a incorporar objetos e dispositivos embarcados do mundo real como qualquer outro servio Web. A extenso da Web proposta pela WoT realizada
109
atravs da adoo do protocolo HTTP como protocolo de aplicao. Isso significa que esse protocolo deve ser utilizado como interface base para realizar toda a interao com os recursos disponveis [Guinard e Trifa 2009], [Shelby 2010], e no apenas para transportar passivamente as mensagens trocadas. Uma abordagem que est sendo bastante utilizada juntamente com protocolo HTTP na criao de sistemas distribudos na Web o estilo arquitetural REST [Mayer 2010] (do ingls, Representation State Transfer). Esse estilo arquitetural pode ser empregado para desenvolver sistemas que seguem uma arquitetura orientada a recursos (ROA, do ingls Resource Oriented Architecture) [Mayer 2010]. O REST define um conjunto de princpios que, ao serem adotados, do origem a sistemas RESTful. Os sistemas RESTful so menos acoplados, mais leves, eficientes e flexveis do que os sistemas Web baseados em WS-* e podem ser facilmente reutilizados [Guinard e Trifa 2009], [Sandoval 2009]. Alm disso, os princpios REST podem ser mapeados nos mtodos bsicos do protocolo HTTP (GET, POST, UPDATE e DELETE) para criar sistemas CRUD (Create, Read, Update, Delete) de uma aplicao RESTful. Os recursos dos sistemas RESTful so identificados e encapsulados por um URI. A utilizao do protocolo HTTP como protocolo de aplicao admite que os recursos possuam vrias representaes e permite que os clientes selecionem, dentre as representaes disponveis, aquela que melhor se adqe as necessidades da aplicao [Sandoval 2009]. Essas caractersticas fizeram do REST a opo mais adequada para construo de APIs Web para acesso a objetos do mundo real [Guinard e Trifa 2009], [Ostermaier et al. 2010]. A Web das Coisas emprega os princpios REST para disponibilizar as funcionalidades dos dispositivos inteligentes na Web utilizando duas abordagens. Na primeira abordagem, so implantados servidores Web embarcados em dispositivos inteligentes e as funcionalidades desses dispositivos so disponibilizadas na forma de recursos RESTful. Na segunda abordagem, quando um objeto inteligente no possui recursos de hardware suficientes para executar um servidor embarcado, possvel utilizar outro dispositivo como ponte para disponibilizar as funcionalidades do dispositivo inteligente na Web atravs de uma interface RESTful. Embora a utilizao de uma arquitetura RESTful permita que objetos fsicos se tornem parte da Web, a WoT tambm prope a utilizao de mecanismos que foquem no desenvolvimento e prototipagem de aplicativos interativos que faam com que os recursos dos objetos fsicos sejam utilizados em diferentes aplicaes [Guinard e Trifa 2009], [Guinard 2010]. Nesse sentido, os trabalhos da WoT propem que sejam utilizadas aplicaes da Web 2.0 chamadas mashups. Os mashups so aplicativos criados a partir da composio de recursos Web. Como qualquer aplicao da Web 2.0, os mashups so construdos com base em um conjunto de tecnologias (por exemplo, Atom [Atom 2011]) que do suporte ao desenvolvimento de interfaces altamente interativas e simples ao usurio, semelhante ao que acontece com aplicativos desktop [Bezerra et al. 2009]. Os mashups criados a partir da composio de dados e servios de dispositivos fsicos com outros recursos Web so chamados mashups fsicos. Esse tipo de mashup foca no reuso e prototipagem de objetos fsicos do mundo real em diferentes aplicaes. [Duquennoy et al. 2009], [Guinard 2010]. Logo, possvel resumir que na WoT o protocolo HTTP adotado como linguagem comum entre diferentes dispositivos e o seu emprego em conformidade com
110
o princpio arquitetural REST permite que as funcionalidades desses dispositivos sejam expostas como recursos Web que possuem interfaces bem definidas. Isso ir permitir que os dados e recursos dos dispositivos sejam reutilizados em diversas aplicaes. A funo dos mashups fsicos permitir que os usurios construam aplicaes formadas a partir da composio dos recursos e dados desses dispositivos os quais se tornam passveis de serem combinados e recombinados em tempo de execuo para resolverem requisitos de mais alto nvel.
3.3. Concretizando a Web das Coisas: REST & ROA

Para uma melhor compreenso da Web das Coisas, esta Seo apresenta os conceitos envolvidos com o desenvolvimento de aplicaes Web RESTful. Alm dos conceitos, tambm apresentada uma abordagem prtica da aplicao dos mesmos no contexto de aplicaes RESTful. 3.3.1. REST O termo REST, descrito por Roy Fielding (2000) em sua tese de doutorado, define um conjunto de princpios que podem ser aplicados na construo de sistemas com uma arquitetura orientada a recursos (ROA). O REST um estilo de arquitetura de software que pode ser aplicado no desenvolvimento de sistemas denominados sistemas RESTful [Sandoval 2009]. ROA e REST so utilizados na concepo da implementao de sistemas focados em recursos [Mayer 2010]. Um recurso pode ser qualquer componente de uma aplicao que seja importante o suficiente para ser endereado na Web atravs de pelo menos uma URI. Ou seja, um recurso tudo aquilo que deve ser acessado pelo cliente e transferido entre o mesmo e um servidor [Mayer 2010]. Por exemplo, um recurso pode ser uma lista de cursos de uma instituio, ou mesmo cada curso dessa instituio, os quais possuem disciplinas que por sua vez so subrecursos do curso e assim por diante. Esta Subseo aborda os princpios REST, o modelo de arquitetura orientada a recursos e a construo de sistemas RESTful. 3.3.1.1. Princpios REST Os princpios REST podem ser facilmente empregados (e explicados) com o protocolo HTTP [Pautasso 2009]. Por esse motivo, esse protocolo tem sido amplamente utilizado no desenvolvimento de sistemas RESTful [Lucchi et al. 2008]. O HTTP um protocolo da camada de aplicao para sistemas de hipermdia, colaborativos e distribudos, baseado no modelo de comunicao requisio/resposta que pode ser utilizado para realizar diferentes tarefas. O HTTP um protocolo sem manuteno de estado (stateless) e define como feita a troca de mensagens entre o cliente e o servidor; ou seja, esse protocolo define como um cliente requisita recursos em um servidor e como este responde a tais requisies. O HTTP define um conjunto de mtodos que so utilizados nas requisies, dentre os quais se destacam os mtodos GET, POST, PUT e DELETE [Lucchi et al. 2008]. Outra caracterstica importante desse protocolo a negociao da representao de dados, a qual pode ser feita atravs da utilizao dos cabealhos (por exemplo, Accept ou Accept-Language) da requisio. A Figura 3.3 mostra o formato de uma requisio HTTP. Nessa figura possvel observar os campos do cabealho de uma requisio HTTP contendo o mtodo GET, o caminho (path) do recurso solicitado e a verso do protocolo HTTP. Uma requisio
111
contendo o mtodo GET pode possuir dados includos no path da requisio. Esses dados so separados do path do recurso pelo caractere de interrogao ? e diferentes dados so separados pelo caractere & (cada dado possui uma varivel e um valor os quais so separados pelo sinal de igualdade). O campo Host especifica o endereo do servidor na internet e o nmero da porta do recurso solicitado. O campo User-Agent contm informaes sobre o agente de usurio (nessa figura, o agente o mozilla/5.0) que originou a requisio. O campo Accept indica quais representaes o cliente espera receber (nesse caso as representaes podem ser HTML, XML OU JSON [JSON 1999]). O campo Connection permite que o emissor da requisio especifique algumas informaes concernentes a uma requisio em particular (o valor keep-alive que aparece na requisio apresentada na figura utilizado para indicar que uma conexo do protocolo de transporte deve permanecer aberta para ser reusada no envio e recepo de mltiplas requisies e respostas). Para maiores detalhes sobre o protocolo HTTP ver [RFC2068 1997] e [RFC2616 1999].
Figura 3.3 - Requisio HTTP contendo o mtodo GET
Como o HTTP possibilita a utilizao de diferentes representaes, as aplicaes podem ser construdas independentemente da forma como os dados sero transferidos [RFC2616 1999]. As caractersticas do HTTP fornecem o suporte necessrio para a realizao dos princpios REST. Esses princpios so: identificao nica e global para os recursos, uma interface uniforme de acesso aos recursos, endereabilidade dos recursos (permite que os mesmos sejam vinculados), suporte a mltiplas e independentes representaes para o recurso e interao sem manuteno de estado [Sandoval 2009]. O princpio da identificao dos recursos est relacionado ao uso de URIs que fornecem endereos nicos e globais para identificao de um recurso [Pautasso et al. 2008]. URIs tambm so utilizadas para indicar o escopo da informao provendo meios que permitem a navegao entre recursos que interagem entre si. Isso significa que um identificador pode indicar os subrecursos relacionados com um recurso em um dado momento. Por exemplo, o path do recurso /spot-1265/light presente na requisio da Figura 3.3 indica que light um subrecurso de spot-1265. Uma URI tambm utilizada para enderear a interao entre recursos sem a necessidade do uso do corpo da resposta. No contexto da Web, o uso de URIs possibilita a utilizao de links para recursos os quais podem ser estabelecidos utilizando esquemas bem conhecidos [Mayer 2010]. O princpio da interface uniforme define que o servidor deve ser capaz de determinar o que deve ser feito ao receber uma requisio HTTP em uma URI apenas
112
observando do mtodo presente nessa requisio [Pautasso et al. 2008], [Mayer 2010]. Os mtodos das requisies HTTP (GET, POST, PUT ou DELETE) so utilizados para indicar ao provedor do recurso a ao que deve ser realizada. Assim, cada mtodo representa uma ao especfica sobre o recurso, podendo ser executadas quatro aes (operaes): obter a representao de um recurso (GET), criar um novo recurso (POST), alterar um recurso (PUT) e remover um recurso (DELETE). Essas operaes geralmente so descritas como sendo o CRUD (Create, Retrieve, Update e Delete) da aplicao [Sandoval 2009]. Por exemplo, o mtodo GET da requisio exemplificada na Figura 3.3 indica ao servidor (localizado em www.labnet.ufrj.br) que o cliente espera receber uma representao do recurso /light o qual subrecurso de /spot-1265. Essa figura um exemplo de uma requisio que est em conformidade com os princpios de endereabilidade e interface uniforme. O princpio da vinculao de recursos est relacionado com o uso da abordagem HATEOAS (do ingls, Hypermedia as Engine Of Application State). Nessa abordagem, a vinculao dos recursos realizada atravs de links que so criados a partir das URIs dos recursos. Os links podem apontar para qualquer recurso na Web, at mesmo recursos externos ao provedor que est sendo acessado em um dado momento. Isso possvel graas a utilizao de um esquema de nomes global que possibilita que qualquer recurso Web seja ligado a outro. Tal caracterstica permite que o servidor oferea links para que o cliente mude de um estado da aplicao para outro, tornando a aplicao dinmica. Ou seja, as aplicaes so consideradas como uma mquina de estado onde cada pgina representa um estado e os links representam todas as possveis transies de estado a partir do estado corrente. Sempre que possvel, os links de navegao entre recursos relacionados devem ser disponibilizados na representao do primeiro recurso acessado. Por exemplo, considere um sistema de uma instituio de ensino que possui um recurso chamado lista_cursos, o qual lista todos os cursos dessa instituio quando tal recurso acessado. O provedor do recurso deve oferecer links criados a partir da URI de identificao de cada recurso que representa um curso da instituio. Esses links so oferecidos com o objetivo de permitir que cada curso possa ser acessado a partir da representao obtida do recurso lista_cursos. O princpio da representao de um recurso define como sero os formatos das mensagens trocadas entre cliente e servidor. A representao de um recurso representa o valor do dado no momento em que foi recebida a requisio [Sandoval 2009]. Um recurso pode possuir vrias representaes. As opes de representaes de recurso permitem que o consumidor do recurso escolha, entre as representaes disponveis, aquela que ele deseja receber. Exemplos de representaes de recurso so o XML, JSON, HTML, entre outros. A especificao das representaes que o cliente deseja receber podem ser passadas no campo Accept do cabealho HTTP. Por exemplo, o campo Accept da requisio apresentada na Figura 3.3 indica trs opes de representaes que o cliente espera receber, as quais so: text/html (indicando formato HTML), application/xml (formato XML) e application/json (indicando formato JSON). O ltimo princpio REST define que um servidor deve ser stateless, ou seja, sem estado. Esse princpio define que no pode haver manuteno de informaes sobre o usurio em sesses no lado do servidor. Assim, cada requisio enviada ao provedor do recurso deve ter todas as informaes necessrias para a sua compreenso. Se alguma informao deve ser mantida sobre um recurso, esta deve ser mantida no lado do cliente. Essa abordagem est relacionada principalmente a escalabilidade do sistema,
113
pois se um servidor mantivesse as sesses com informaes para cada usurio ele poderia ter seu desempenho afetado quando estivesse tratando de muitos acessos concorrentes [Pautasso et al. 2008]. Alm disso, esse princpio diminui a dependncia do cliente com relao ao provedor do recurso, pois as requisies submetidas so independentes de um servidor especfico. Um exemplo dessa situao ocorre quando um cliente que recebeu um link ao acessar o recurso em um servidor, o qual ficou inativo logo aps responder ao cliente (por problemas de hardware, por exemplo) e foi automaticamente substitudo por outro servidor, pode utilizar esse link, pois ele ir funcionar da mesma forma que antes e a troca do servidor ser transparente para o usurio [Webber et al. 2010]. 3.3.2. ROA Apesar dos princpios REST terem sido apresentados neste minicurso juntamente com o uso das estruturas de URI e dos mecanismos do HTTP, como tambm fazem muitos outros autores ([Sandoval 2009], [Webber et al. 2010], [Mayer 2010]), o REST independe de tecnologia e seus princpios no esto obrigatoriamente interligados a Web. O REST tambm no um si uma arquitetura, mas possui termos genricos que podem ser utilizados para definir uma arquitetura. A falta de uma arquitetura que possa ser empregada no desenvolvimento de aplicaes que seguem os princpios REST pode levar o desenvolvedor ou arquiteto de software a empregar de forma equivocada esses princpios [Pautasso et al. 2008]. Por exemplo, as aplicaes que empregam os princpios REST podem se tornar um hbrido de REST com RPC (Remote Procedure Call) [Richardson e Ruby 2007], [Pautasso et al. 2008], o que no desejvel. Em 2007, Richardson e Ruby apresentaram uma arquitetura orientada a recursos (do ingls, Resource-Oriented Architecture ROA) especificando em detalhes como empregar os princpios REST juntamente com as tecnologias da Web (HTTP e URI) em um modelo de boas prticas que podem ser aplicadas no desenvolvimento de servios RESTful. Esta Subseo apresenta as principais caractersticas dos conceitos e propriedades de ROA conforme propostos por [Richardson e Ruby 2007]. 3.3.2.1. URIs Em uma abordagem ROA, as URIs dos recursos devem possuir uma correspondncia intuitiva com o recurso que elas identificam e a sua estrutura deve variar de forma previsvel. Por exemplo, as URIs http://www.labnet.nce.ufrj.br/rssf/temperatura, http://www.labnet.nce.ufrj.br/alunos/john ou http://www.labnet.nce.ufrj.br/redes/ redesemfio/zigbee permitem que o cliente infira quais so os subrecursos disponveis em um diretrio da URI. Ou seja, ao observarem essas URIs, os clientes esperaro que um dado de temperatura possa ser acessado a partir do diretrio rssf/temperatura e que um aluno (por exemplo, John) possa ser acessado a partir do diretrio alunos. Outra caracterstica relacionada ao uso de URIs abordada em ROA diz respeito ao relacionamento entre URIs e recursos. Um recurso deve possuir no mnimo uma URI, mas nada impede que ele possua vrias. Porm, sempre que possvel, um recurso deve possuir apenas uma URI. Isso porque, utilizar vrias URIs para identificar o mesmo recurso diminui a importncia de uma URI, pois dificulta o relacionamento da URI com o recurso que ela identifica [Richardson e Ruby 2007]. Por exemplo, se um recurso possui vrias URIs ser mais difcil para um proxy HTTP, por onde passam as requisies de uma rede, identificar se uma resposta contendo uma representao de um
114
recurso j est armazenada em seu cache. Do ponto de vista de um usurio, mais difcil associar a URI com um recurso quando este possui vrios URIs. 3.3.2.2. Endereabilidade A propriedade ROA que define que um recurso deve ser enderevel pode ser facilmente observada na Web. Essa propriedade est relacionada com o uso de uma URI para identificar e localizar um recurso de um sistema RESTful. A endereabilidade tambm comum para as aplicaes REST-RPC (aplicaes que so um hbrido entre REST e RPC), pois toda aplicao na Web precisa ser enderevel para poder ser acessada. Richardson e Ruby (2007) apontaram que, para o usurio final, a endereabilidade o aspecto mais importante das pginas ou servios Web. Um recurso enderevel pode ser acessado sempre que sua URI for utilizada na Web. Por exemplo, esses recursos podem ser acessados atravs de links de hipertexto, ou mesmo quando a URI enviada de um usurio para outro atravs do e-mail. Ser enderevel tambm permite que um documento enviado como resposta a uma requisio possa ser mantido em cache nos proxies HTTP. Por exemplo, a pgina endereada pela URI http://www.labnet.nce.ufrj.br/projetos/webofthings pode ser mantida em cache para ser devolvida como reposta a uma segunda requisio HTTP que passe por esse proxy e que seja enviada para a mesma URI. 3.3.2.3. Sem Estado Enquanto o REST define que uma aplicao RESTful deve ser sem estado, ROA define como construir uma aplicao sem estado. Ser sem estado significa que uma requisio HTTP deve ser independente de outras requisies anteriores. Para que isso seja possvel, as requisies HTTP devem ser auto-contidas, ou seja, uma requisio HTTP deve ter em si toda informao necessria para que possa ser processada. Um servidor que no mantm estado deve ser capaz de processar uma requisio sem precisar utilizar informaes de requisies anteriores. Se uma informao suficientemente importante para ser mantida como uma sesso no servidor, ento esta informao deve ser transformada em um recurso. Apesar da expresso sem estado, ROA define dois tipos de estado: o estado da aplicao, o qual deve ser mantido no cliente; e o estado do recurso, que deve ser mantido no servidor. Um exemplo de estado da aplicao pode ser observado nos sistemas de busca da Web (por exemplo, o sistema de busca do Google). Nesses sistemas, o cliente faz uma busca enviando os parmetros da consulta (geralmente esses parmetros so passados na URI) para o provedor do recurso. Ao receber o resultado da consulta, o cliente poder navegar entre pginas que mostram esses resultados. A navegao ocorre quando o cliente passa de uma pgina contendo um subconjunto do resultado da busca para outra pgina contendo outro subconjunto do resultado dessa busca. Para tanto, o cliente mantm os parmetros da consulta (as palavras chave utilizadas) e a identificao da pgina atual na qual est localizado (pgina um, dois, trs, etc.). Ao navegar entre as pginas que contm o resultado da busca, o cliente deve incluir nas requisies os parmetros da consulta e a pgina que est querendo acessar. Dessa forma, o servidor s precisar tratar o estado da aplicao ao receber uma requisio. O estado do recurso deve ser mantido no servidor e deve ser igual para todos os clientes. Por exemplo, quando um servio de fotos da Web (como o Flickr) salva uma
115
nova foto, essa deve ser considerada um novo recurso. Essa figura ganha sua prpria URI e por isso poder ser acessada nas prximas requisies. Ao ser transformada em um recurso, a figura poder ser pesquisada, acessada, alterada ou apagada pelos clientes. A figura parte do estado do recurso e permanece no servidor at que o cliente que possui as permisses necessrias a apague. 3.3.2.4. Representao As representaes de um recurso podem ser enviadas tanto do cliente para o servidor quanto do servidor para o cliente. As representaes so enviadas pelo cliente quando este deseja criar ou atualizar um recurso no servidor ( isso que acontece quando um cliente envia uma foto para ser salva no Flickr). O sentido contrrio do envio de uma representao ocorre quando um cliente envia uma requisio para o servidor interessado em obter uma representao de um recurso. Quando o cliente deseja obter uma representao de um recurso do servidor, esse cliente deve ser o mais explcito possvel sobre qual representao deseja receber, j que um recurso pode possuir mais de uma representao. ROA define duas formas de especificar uma representao. A primeira forma utilizar a URI para indicar qual a representao que o cliente deseja receber. Por exemplo, na requisio http://twitter.com/statuses/public_timeline.{xml, json, rss} a URI utilizada para especificar o tipo de representao (XML, JSON ou RSS). Segundo Richardson e Ruby (2007) utilizar URI a forma mais explcita com que o cliente anuncia o tipo de representao que ele espera receber. A segunda forma de especificar a representao utilizar os cabealhos Accept ou Accept-Language do protocolo HTTP para indicar ao servidor a representao (XML ou JSON, por exemplo) ou o idioma (ingls, portugus, etc.) do recurso que o cliente deseja receber. 3.3.2.5. Links e Conectividade As representaes dos recursos podem ser utilizadas para fornecer links para outros recursos relacionados com o primeiro recurso acessado. Por exemplo, quando uma busca feita no servio de busca do Google, a representao enviada para o cliente contm links para cada resultado dessa consulta. O termo conectividade definido pelo ROA um sinnimo de HATEOAS, visto que o conceito o mesmo: os recursos podem conter links para outros recursos em suas representaes. 3.3.2.6. Interface Uniforme Em uma abordagem ROA as operaes realizadas sobre os recursos so mapeadas nos quatro mtodos bsicos do protocolo HTTP. O mtodo GET utilizado para recuperar a representao de um recurso. A resposta a uma requisio GET inclui em seu corpo uma representao do recurso. O mtodo DELETE utilizado para apagar um recurso j existente. A resposta para uma requisio DELETE pode conter uma mensagem indicando o status da operao solicitada ou apenas um cdigo HTTP. Em ROA os mtodos utilizados para criar recursos so o PUT e o POST. O PUT tambm utilizado para atualizar um recurso j existente. Apesar do ROA especificar as situaes quando utilizar o mtodo POST ou PUT para criar um novo recurso, muitos sistemas RESTful utilizam apenas o POST com essa finalidade, visto que o mtodo PUT tambm utilizado para atualizar um recurso [Sandoval 2009], [Webber et al.
116
2010]. As requisies PUT e POST podem conter em seu corpo uma representao do recurso que ser criado ou atualizado. Alm desses mtodos, ROA define como utilizar os mtodos HEAD e OPTIONS do HTTP para obter informaes sobre um recurso. O HEAD utilizado para obter metadados sobre um recurso sem que a resposta para uma requisio possua a representao completa desse recurso. O OPTIONS utilizado para verificar qual mtodo HTTP um recurso suporta. A resposta a uma requisio que contm o mtodo OPTIONS fornece o subconjunto da interface uniforme (HTTP) que este recurso suporta atravs do cabealho Allow (por exemplo, Allow: GET, HEAD indicam que um recurso suporta esses dois mtodos). Outra definio apresentada em ROA diz respeito aos efeitos que uma requisio causa sobre um recurso. As requisies podem ser seguras (Safe) ou idempotente. As requisies seguras so aquelas que so utilizadas para obter uma representao de um recurso ou alguma outra informao sobre esse recurso sem causar alterao no estado do servidor. Por exemplo, uma requisio GET pode ser enviada centenas de vezes para obter uma representao de um recurso sem que nenhuma dessas requisies cause alteraes no recurso solicitado. As requisies que alteram o estado do recurso so consideradas idempotente quando outras requisies iguais a primeira no so capazes de causar uma alterao diferente a causada pela primeira requisio. O conceito de idempotente anlogo ao da matemtica, que utiliza esse termo para indicar, por exemplo, que na multiplicao o zero idempotente, pois qualquer nmero multiplicado por zero sempre vai ser igual zero. Analogamente, uma requisio idempotente se a alterao ocasionada por essa requisio for mantida mesmo que outras requisies semelhantes sejam enviadas em seguida. Por exemplo, ao apagar um recurso ele continuar sem existir ainda que outras requisies DELETE sejam enviadas para esse recurso. 3.3.3. Desenvolvimento de Servios RESTful Desenvolver um servio Web RESTful no diferente de desenvolver uma aplicao Web tradicional. necessrio se preocupar com os requisitos do negcio, satisfazer as necessidades dos usurios os quais manipularo os dados e lidar com limitaes de hardware e arquiteturas de software. A principal diferena, contudo, que o foco reside na identificao dos recursos e na abstrao sobre as aes especficas a serem tomadas por esses recursos. possvel comparar o desenvolvimento de servios Web RESTful com o desenvolvimento orientado a objetos, pois existem algumas similaridades. No desenvolvimento orientado a objetos realizada a identificao dos dados que se deseja representar juntamente com as aes que esse objeto pode realizar. Porm, as similaridades acabam na definio da estrutura do dado, porque com os servios Web RESTful existem chamadas especficas que fazem parte do prprio protocolo de troca de mensagens. Os princpios do desenvolvimento de um servio web RESTful podem ser resumidos em quatro passos: 1. Levantamento de requisitos Esse passo similar s tradicionais prticas de coleta de requisitos do desenvolvimento de software.
117
2. Identificao de recursos Esse passo similar ao desenvolvimento orientado a objetos onde realizada a identificao dos objetos, mas sem se preocupar com a troca de mensagens entre objetos. 3. Definio de representao de recursos Para viabilizar a troca de mensagens entre clientes e servidores, necessrio definir o tipo de representao que ser usada. Geralmente o XML utilizado, porm atualmente o formato JSON est sendo cada vez mais popular [Sandoval 2009]. Porm, qualquer forma de representao de recursos pode ser utilizada. Por exemplo, possvel utilizar o XHTML ou qualquer outra forma binria de representao, embora seja necessrio deixar os requisitos serem os guias das escolhas sobre as representaes. 4. Definio de URI O ltimo passo a definio do ponto de acesso ao recurso, o qual consiste em especificar as URIs para que os clientes possam enderear os servidores a fim de trocar as representaes de recursos. Esse processo de desenvolvimento no feito de forma esttica, pelo contrrio, ele deve ser realizado atravs de passos iterativos os quais giram em torno dos recursos [Sandoval 2009]. Por exemplo, pode acontecer que, durante a etapa de definio das URIs, descobre-se que uma das repostas da URI no coberta em um recurso identificado. Nesse caso, deve-se voltar para definir um recurso adequado. Na prtica, o que acontece que na maioria dos casos os recursos j definidos cobrem os requisitos da aplicao, ento basta combinar os recursos dentro de meta-recursos para tratar os novos requisitos [Sandoval 2009]. 3.3.3.1. Requisitos do Servio Web de Exemplo Para explicar melhor como funciona o desenvolvimento de servios RESTful, descrita nesta Subseo a modelagem de um desses servios. O servio Web RESTful modelado uma aplicao Web de um laboratrio de faculdade formado por um grupo de pessoas (usurios) onde cada pessoa responsvel por um ou vrios trabalhos. Esse simples exemplo permite que seja apresentado o emprego dos princpios REST na prtica, sem preocupaes com regras complexas de lgica do negcio. A modelagem da aplicao feita seguindo um processo orientado a objetos [Sandoval 2009] e apenas o necessrio para o entendimento do desenvolvimento de sistemas RESTful apresentado. Desta forma, vrias questes existentes na modelagem de software e assuntos afins foram omitidas. Considere-se que, aps a etapa inicial de levantamento de requisitos, foram especificados os seguintes casos de uso da aplicao (essas so as principais funcionalidades da aplicao): (i) um usurio pode criar uma conta com um nome de usurio e uma senha; (ii) um usurio pode publicar os trabalhos sob sua responsabilidade (uma publicao nesse caso consiste de uma pgina Web contendo uma descrio do trabalho); (iii) qualquer pessoa, registrada ou no, pode ver os trabalhos publicados na pgina do laboratrio; (iv) qualquer pessoa, registrada ou no, pode ver o perfil dos usurios; (v) os usurios cadastrados podem atualizar seus dados (por exemplo, alterando sua senha); e (vi) qualquer pessoa pode pesquisar por termos para encontrar publicaes cadastradas.
118
Nas prximas Subsees so endereados desenvolvimento de nosso sistema Web de exemplo. 3.3.3.2. Identificao de Recursos
os
passos
seguintes
do
A especificao dos recursos dos servios uma etapa posterior a listagem dos casos de uso. Com base nos requisitos, possvel perceber que sero necessrios usurios e trabalhos. O recurso usurios retorna um usurio ou uma lista de usurios. Alm disso, cada usurio pode publicar seus trabalhos. Assim, tambm sero necessrios recursos para um trabalho e para uma lista de trabalhos. Com base nessa observao os seguintes recursos foram identificados: usurio, lista de usurio, trabalho e lista de trabalhos. 3.3.3.3. Representao de Recursos Nesta etapa so definidas as representaes dos recursos da aplicao. Sabe-se que o protocolo HTTP permite a definio de qualquer tipo de representao (inclusive formatos proprietrios de dados). Contudo, recomendado que sejam utilizadas estruturas padres, entre as quais esto o XML e o JSON. Logicamente, essa escolha deve ser feita com base nos requisitos da aplicao, os quais iro ditar que tipo de representaes devem ser providas [Sandoval 2009]. Sempre que possvel, desejvel que sejam fornecidas vrias representaes para um mesmo recurso. Assim, os consumidores do recurso podero escolher dentre as opes disponveis, aquela que mais adequada para ele. O formato ideal de uma representao uma questo de concepo. necessrio considerar quais aes sero realizadas pelo servidor e a finalidade com a qual os clientes utilizaro os recursos. Como regra geral, XML deve sempre ser considerada como potencial representao, porque muitas linguagens oferecem bibliotecas para processar streams XML [Sandoval 2009] (isso facilita o processamento das mensagens e favorece a interoperabilidade entre as aplicaes). Aps a definio do formato, necessrio definir o encadeamento (linkability) das representaes. O encadeamento das representaes define o um tipo de mecanismo de descoberta de recursos, o qual permite que os recursos possam ser ligados a outros recursos. Por exemplo, a lista de usuarios retornada pelo provedor dos recursos pode conter URIs (disponibilizada por meio de links) para cada elemento usurio da lista. O servidor do exemplo desta Subseo ir utilizar XML e JSON para representar os recursos. A representao XML ser utilizada pelo servidor para enviar uma representao do estado de um recurso. O cliente utiliza o XML para criar e atualizar os recursos no lado do servidor. O JSON ser utilizado apenas no envio de representaes de recurso do servidor para o cliente. A Figura 3.4 ilustra uma representao do recurso usuario no formato XML. Apenas o contedo dos elementos nome, nome_usuario e senha so armazenados no servidor, pois eles so parte de um recurso do usurio. O nome indica apenas o nome do usurio. O nome_usuario deve ser nico em todo sistema, pois ele ser utilizado para identificar o usurio. O elemento link utilizado para apontar algum recurso no servio Web e esse link criado pelo servidor com base em nome_usuario.Um link para um recurso pode ser associado a esse recurso assim que o mesmo criado ou quando uma representao do recurso solicitada. Por exemplo, o link para o usurio identificado pelo nome_usuario johnSmith pode ser criado assim que o provedor do recurso
119
recebe uma requisio para criar esse novo usuario ou quando o provedor recebe uma requisio para um recurso que lista todos os usurios do sistema.
<usuario> <nome> john </nome> <nome_usuario> johnSmith </nome_usuario> <senha> abc123 </senha> <link> /johnSmith </link> </usuario> Figura 3.4 - Representao XML do recurso usuario
A segunda estrutura criada define uma lista de usurios (Figura 3.5). O documento XML da Figura 3.5 declara uma lista de usurios dentro do elemento usuarios. Nessa estrutura possvel observar o conceito de encadeamento na prtica: com a lista de usurios possvel buscar por um usurio especfico usando o valor do elemento link. Por exemplo, o primeiro usuario da lista apresentada na Figura 3.5 (identificado por johnSmith) pode ser acessado no path /johnSmith. Dessa forma, quando o cliente obtiver uma representao contendo os usurios do sistema ele poder acessar cada usuario da lista atravs do seu respectivo link.
<usuarios> <contagem> 50 </contagem> <link></link> <usuario> <nome> john </nome> <nome_usuario> johnSmith </nome_usuario> <senha> abc123 </senha> <link> /johnSmith </link> </usuario> ... <usuario> <nome> henrique </nome> <nome_usuario> hribeiro </nome_usuario> <senha> ribeir0123 </senha> <link> /hribeiro </link> </usuario> </usurios > Figura 3.5 - Representao XML do recurso lista de usurios
A estrutura da representao do recurso trabalho utilizada na incluso de um novo trabalho. Essa estrutura apresentada naFigura 3.6. Um trabalho possui o identificador (id_trabalho), o corpo da mensagem (definido pelo elemento conteudo), e o usurio que postou a mensagem. Dependendo do que se pretende fazer com essa representao, no ser necessrio passar todas as informaes desse recurso para o servidor. Por exemplo, quando um cliente cria um novo recurso trabalho, ele no sabe qual o valor do identificador (id_trabalho), pois na abordagem apresentada aqui, tal valor ser criado no lado do servidor. Dessa forma, a estrutura com representao do trabalho ser passada para o servidor, o qual ir definir o valor de id_trabalho. A Figura 3.7 apresenta a estrutura XML de representao da lista de trabalhos. Essa estrutura contm uma coleo de trabalhos, e cada trabalho contm o usurio que o postou.
120
<trabalho> <id_trabalho> WebOfThings </id_trabalho> <conteudo> A Web englobando o mundo fsico... </conteudo> <link> /webofthings </link> <usuario> <nome> tiago </nome> <nome_usuario> tcruzfranca </nome_usuario> <senha> abc123 </senha> <link> /tcruzfranca </link> </usuario> </trabalho> Figura 3.6 - Representao XML do recurso trabalho <trabalhos> <contador> 50 </contador> <link> /trabalhos </link> <trabalho> <id_trabalho> smarbuild </id_trabalho> <conteudo> edifcios inteligentes... </conteudo> <link> /smartbuild </link> <usuario> <nome> claudio </nome> <nome_usuario> cmiceli </nome_usuario> <senha> m1c3l1 </senha> <link> /cmiceli </link> </usuario> </trabalho>
...
<trabalho> <id_trabalho> sutil </id_trabalho> <conteudo> ... </conteudo> <link> /sutil </link> <usuario> <nome> jaime </nome> <nome_usuario> jaime </nome_usuario> <senha> 224466 </senha> <link> /jaime </link> </usuario> </trabalho> </trabalhos> Figura 3.7 - Representao XML do recurso trabalhos
As representaes JSON possuem os mesmos elementos chaves para os mesmos recursos. Uma definio da representao JSON do recurso usuario pode ser vista na Figura 3.8, enquanto a representao JSON do recurso lista_usuarios pode ser vista na Figura 3.9. A Figura 3.10 apresenta a estrutura JSON de representao de todos os usurios.
{"usuario":{"nome_usuario":"juan","senha":"123456", "link":"/usuario/juan"}}
Figura 3.8 - Representao JSON do recurso usurio
121
{"lista_usuarios":{"contador":"6","usuarios":[{"nome_usuario":"igor","senha":"zw u987","link":"/usuario/igor"},...,{"nome_usuario":"jane","senha":"abc000","link":"/ usuario/paula"}]}}

Figura 3.9 - Representao JSON do recurso lista_usuarios
{"usuarios":[{"nome_usuario":"hsalmon","senha":"123456","link":"/usuario/ hsalmon"},...,{"nome_usuario":"erico","senha":"987456","link":"/usuario/ erico"}]}

Figura 3.10 - Representao JSON de todos os recursos usuario
A representao JSON do trabalho apresentada na Figura 3.11 e a Figura 3.12 apresenta a estrutura JSON de lista_trabalhos.
{"trabalho":{"id_trabalho":"id_1","conteudo":"algumConteudo","link":"/trabalhos/i d_1","usuario":{"usuario":{"nome_usuario":"renato","senha":"rttr0ll","link":"/usuar io/renato"}}}
Figura 3.11 - Representao JSON do recurso trabalho
{"lista_trabalhos":{"contador":"6","link":"/trabalhos","trabalhos":[{"id_trabalho":"id _1","conteudo":"algum-conteudo","link":"/trabalho/id_1", "usuario":{"nome_usuario":"smelo","senha":"t3nbal","link":"/usuario/smelo"}}, ...,{"id_trabalho":"id_2", "conteudo":"algum_conteudo", "link":"/trabalho/ id_2", "usuario":{" nome_usuario ":"mmelo", "senha":"4pi4rab", "link":"/usuarios/ mmelo"}}]}}
Figura 3.12 - Representao JSON de lista_trabalhos
3.3.3.4. Definio de URI A definio das URIs uma etapa crucial, pois elas definiro a API do sistema. A API definida deve ser lgica, hierrquica, e o mais estvel possvel. Uma boa API aquela que utilizada facilmente e no muda com freqncia. Alm disso, a idia de uma API RESTful manter uma URI nica e confivel para cada recurso. Na definio da URI, a primeira coisa necessria um endereo Web, no nosso exemplo utilizaremos o endereo http://www.dcc.ufrj.br/. Ainda, sero adotadas duas convenes na definio das URIs RESTful. Primeiro, os itens e identificadores que no mudam sero nomeados utilizando palavras-chave como parte da URI (por exemplo, a palavra usurios foi utilizada para definir a URI que aponta para o recurso lista de usurios). A segunda conveno a utilizao de palavras-chaves entre chaves {}. Ao aplicar essa conveno para definir a lista de URIs para os recursos, as URIs obtidas so: http:// www.dcc.ufrj.br /usuarios - uma requisio com o mtodo GET enviada para essa URI ir retornar uma lista de usurios. Se o mtodo POST for utilizado, ser criado um novo usuario. Nesse caso, o corpo da mensagem conter uma representao XML do usurio que deve ser criado. Os outros mtodos (PUT e DELETE) no sero suportados, pois as listas de usurios no podem ser alteradas ou apagadas;
122
http:// www.dcc.ufrj.br /usuarios/{nome_usuario} - uma requisio contendo o mtodo GET enviada para essa URI ir retornar uma representao de um usurio contendo um identificador nome_usuario. Se o mtodo PUT for utilizado, o recurso acessado (usuario) ser atualizado. J o mtodo DELETE utilizado para excluir um usurio; http://www.dcc.ufrj.br/trabalhos - uma requisio com o mtodo GET enviada para essa URI retornar uma lista com todos os trabalhos. Se o mtodo POST for utilizado, um novo trabalho ser criado; http://www.dcc.ufrj.br/trabalhos/{id_trabalho} se o mtodo GET for utilizado, o acesso a essa URI retornar uma representao para um trabalho associado ao id_trabalho enviado. O mtodo DELETE ir indicar ao servidor que o cliente espera que o trabalho seja apagado. Os mtodos POST e PUT no sero utilizados para esse recurso; e http://www.dcc.ufrj.br/trabalhos/usuarios/{nome_usuario} se o mtodo GET for utilizado em uma requisio submetida para essa URI, uma lista de todos os trabalhos do usurio com o nome_usuario ser retornada (nenhum outro mtodo suportado).
O uso adequado da URI (conforme os princpios REST e ROA) fornece a informao semntica necessria para interao com os recursos. O uso inadequado da URI pode causar interpretaes confusas. Por exemplo, quando uma URI utilizada para indicar o tipo de representao do recurso, como faz o twitter, por exemplo, dvidas podem ser geradas no consumidor do recurso. O twitter oferece diferentes representaes atravs da URI http://twitter.com/statuses/public_timeline.{xml, json, rss}. Essa abordagem poder gerar dvidas no cliente que consome o recurso, pois segundo os princpios REST o protocolo de comunicao deveria ser utilizado para indicar o tipo de representao desejado. Por exemplo, o que aconteceria se uma requisio HTTP indicando que o cliente espera receber uma representao XML atravs do campo Accept do HTTP fosse submetida para a URI http://twitter.com/statuses/public_timeline.json? No seria possvel especificar se a representao obtida poderia ser um XML ou um JSON. A pesar disso, ROA incentiva o uso de URI para indicar o tipo de representao de um recurso que o servidor deve retornar, porque essa seria a forma mais simples e explcita do cliente indicar o tipo de representao que espera receber. A definio sobre qual abordagem usar para indicar a representao do recurso uma deciso do desenvolvedor ou arquiteto de software. Essa deciso deve ser tomada com base na observao de qual ser a melhor abordagem para os usurios do sistema. Por exemplo, uma abordagem semelhante a do twitter pode facilitar o desenvolvimento de clientes (aplicaes que vo utilizar esse recurso), pois, para recursos que so apenas para leitura, possvel utilizar somente uma requisio HTTP (com o mtodo GET) contendo o tipo de representao embutida na URI. Enviar esse tipo de requisio mais fcil do que instanciar uma nova requisio HTTP e modificar o cabealho Accept a cada nova requisio.
123
3.3.4. Descritor WADL A linguagem WADL (Web Application Description Language) uma especificao formal baseada em XML utilizada para descrever aplicaes Web baseadas no protocolo HTTP [Hadley 2006]. Quando os provedores de aplicaes Web RESTful desejavam fornecer descries sobre os recursos, eles utilizavam descries informais e personalizadas ou ofereciam bibliotecas para permitir que os clientes consumissem seus recursos [Hadley 2009], [Ferreira Filho 2010]. A WADL foi proposta para ser um padro de descrio de aplicaes Web RESTful, cujo propsito semelhante ao do descritor WSDL utilizado para descrever servios SOAP [WSDL 2011]. Porm, a WADL foi criada especialmente para descrever interfaces RESTful [Ferreira Filho 2010]. Os principais benefcios na utilizao de descritores como o WADL a possibilidade de automatizar a criao de cdigo atravs de um formato padronizado e portvel que independe de linguagem ou aplicao especfica [Webber et al. 2010]. A Tabela 3.1 apresenta os principais elementos de um documento WADL juntamente com uma descrio de cada um deles [Hadley 2009], [Ferreira Filho 2010].
Tabela 3.1 Principais elementos de um descritor WADL Elemento application resources Descrio o elemento raiz e contm os demais elementos do documento WADL Esse elemento atua como um continer para cada recurso fornecido pela aplicao, a URI do provedor dos recursos indicado neste elemento atravs do atributo base Cada recurso descrito por este elemento que inclui o atributo path que identifica o recurso naquele provedor de recursos. Esse elemento descreve a entrada e a sada de um mtodo do protocolo HTTP que deve ser aplicado a um recurso. Esse elemento descreve a sada resultante da realizao de um mtodo do HTTP no recurso. Esse elemento descreve uma representao do estado de um recurso.
resource method response representation
A Figura 3.13 um exemplo de documento WADL gerado pela ferramenta Jersey [Jersey 2011] que uma ferramenta para implementao de servios RESTful utilizando a linguagem Java. No exemplo apresentada a descrio do recurso identificado pelo path /spot-1265/light e que pode retornar dois tipos de representao: XML e JSON. Apesar das vantagens do uso de um descritor, os defensores dos princpios REST vo de encontro idia de utilizar documentos formais que estabeleam contratos entre os clientes e os provedores de recursos. Segundo eles, a idia de utilizar descritores vem de uma mentalidade herdada dos servios Web baseados em SOAP cuja filosofia contrria ao REST. Segundo Webber et al. (2010), o emprego adequado de hipermdia como mecanismo de manuteno do estado da aplicao fornece toda semntica necessria para que o consumidor realize toda manipulao que deseja sobre os recursos. Desta forma, no seria necessria a utilizao de um contrato formal (como a WADL) o que resulta em um menor acoplamento entre cliente e servidor. Resumidamente, as principais desvantagens da utilizao de WADL so [Webber et al. 2010]: Existem poucas ferramentas para manipulao dessa linguagem;
124
As aplicaes Web passam a ser vistas como aplicaes estticas devido ao uso de uma linguagem de descrio de interfaces; H um aumento no acoplamento entre o cliente e o servidor, que acaba fazendo com que alteraes no lado do servidor gerem conseqncias no lado do cliente como acontece com os servios Web que utilizam WSDL; e A linguagem de descrio no fornece informaes suficientes para direcionar a interao com os recursos, isto , o consumidor do documento WADL no sabe qual interao que o servidor espera que ocorra sobre um recurso.
Figura 3.13 - Exemplo de documento WADL
3.3.5. REST versus WS-* SOAP O REST e os Servios Web WS-* (SOAP, WSDL, etc.) so tcnicas de integrao de aplicaes distribudas que visam manter o baixo acoplamento entre as partes envolvidas [Guinard e Trifa 2009]. Na Web das Coisas os princpios REST tm sido amplamente aplicados na integrao dos dispositivos inteligentes a Web porque esses princpios parecem ser mais adequados para dispositivos com poucos recursos de hardware [Wilde 2007], [Guinard e Trifa 2009]. Esta Subseo apresenta algumas comparaes entre REST e WS-* SOAP que podem facilitar a compreenso de tal escolha (maiores detalhes sobre essa comparao podem ser vistos em [Pautasso et al. 2008]). A primeira diferena entre o REST e o WS-* SOAP est na forma como o protocolo HTTP empregado. Com REST, o HTTP utilizado para definir a interao entre o cliente da aplicao e o provedor do recurso. Nesse caso, toda a semntica presente nos quatro mtodos (GET, POST, PUT, DELETE) do protocolo HTTP utilizada na definio da interface do sistema [Pautasso et al. 2008]. Os WS-* SOAP, por outro lado, utilizam o protocolo HTTP para transportar as mensagens no formato SOAP com objetivo de integrar aplicaes. Nessa abordagem, as mensagens SOAP so adicionadas ao corpo do HTTP para comunicao remota atravs de firewalls [Pautasso et al. 2008], [Guinard e Trifa 2009]. Nos WS-* SOAP o mtodo POST do HTTP utilizado na troca de mensagens entre clientes e servidores e a informao sobre qual funcionalidade deve ser executada est presente na mensagem SOAP e no na requisio HTTP [Pautasso et al. 2008]. por esse motivo que se diz que para os
125
servios Web SOAP o protocolo HTTP desempenha funcionalidade de transporte mesmo ele sendo um protocolo do nvel de aplicao. Enquanto as aplicaes WS-* SOAP utilizam a Web como meio de troca de mensagens, as aplicaes Web RESTful so parte da Web a qual vista como um terreno comum para as aplicaes [Pautasso et al. 2008]. Alm do HTTP, as mensagens SOAP tambm podem ser encapsuladas e transportadas dentro de outros protocolos (por exemplo, os protocolos TCP e SMTP podem ser utilizados para esse propsito) [Pautasso et al. 2008]. Isso possvel porque o SOAP possui um formato prprio de mensagem (baseado em XML), porm ele requer que outro protocolo seja utilizado para transferir essa mensagem. O formato da mensagem SOAP ocasiona um maior consumo de banda do que o ocasionado pelo protocolo HTTP, devido ao tamanho da mensagem SOAP [Tyagi 2006]. Esse um dos motivos para o REST apresentar vantagens para ser utilizado em dispositivos com pouca capacidade de hardware ou restrio de banda de rede disponvel [Tyagi 2006]. Alm disso, um formato pr-definido de mensagem fora o cliente a tratar aquele tipo de mensagem caso ele deseje utilizar um servio. Com REST possvel oferecer diferentes tipos de representaes. Assim, um cliente pode, por exemplo, escolher se para ele mais adequado receber uma representao JSON ou um XML. Porm, fornecer vrios formatos exige mais esforo no processo de desenvolvimento, pois diferentes tipos de mensagem precisam ser providos. Do ponto de vista do acoplamento, tanto REST quanto o SOAP fomentam o desenvolvimento de sistemas distribudos com acoplamento fraco entre as partes. Porm, avaliar qual das duas abordagens atinge esse objetivo conseguindo um menor acoplamento uma tarefa subjetiva, pois para definir o acoplamento vrios aspectos devem ser observados (como tempo/disponibilidade, clareza de localizao, e evoluo do servio) [Pautasso et al. 2008]. Geralmente o termo fraco acoplamento relacionado capacidade de fazer modificaes no provedor do servio sem afetar o cliente. Nesse caso, os servios Web RESTful so menos acoplados, pois as operaes sobre os recursos no mudam, j que tais operaes so baseadas nos mtodos do HTTP, os quais no mudam mesmo quando ocorre alguma alterao no servio. Contudo, quando acontecem mudanas nos parmetros passados nas mensagens, ambos (SOAP e REST) compartilham o mesmo nvel de acoplamento [Pautasso et al. 2008]. Outra diferena entre REST e SOAP est na forma como essas abordagens utilizam URIs. Com REST a URI no utilizada apenas para identificar o recurso, mas tambm para encapsular toda informao necessria para identificar e localizar os recursos sem a necessidade de um registro centralizado [Pautasso et al. 2009]. Entre outros benefcios, empregar URIs dessa forma permite que os recursos sejam marcados e que links hipermdia sejam fornecidos para o cliente para que o mesmo interaja com os recursos do sistema. O WS-* tambm utiliza URI, mas no da mesma forma que em uma abordagem REST, o que acarreta na necessidade de utilizao de outros mecanismos para agregar informao ao servio [Pautasso et al. 2009]. Prosseguindo com as comparaes entre os servios Web SOAP e as aplicaes RESTful, possvel observar diferenas entre a forma como os clientes consomem os servios. Com SOAP, os clientes utilizam um documento de descrio formal dos servios disponveis. Esse documento o WSDL (Web Service Description Language) [WSDL 2007]. O uso de descritores fornece aos clientes meios que permitem a gerao
126
automtica de cdigo para consumir esses servios. Porm, sua utilizao pode ocasionar falhas no cliente caso ocorram modificaes no servidor [Pautasso et al. 2008]. As aplicaes RESTful no precisam utilizar um contrato formal (apesar disso ser possvel, conforme apresentado na Subseo 3.3.4) entre o cliente e o servidor. Freqentemente os recursos de uma aplicao RESTful so descritos de forma textual ou por meio da documentao da API da aplicao [Pautasso et al. 2008]. Alm dessas abordagens, tambm surgiram alguns provedores de servios RESTful que oferecem bibliotecas (em diferentes linguagens de programao) para serem usadas pelos clientes que desejam consumir os recursos que o servidor oferece [Ferreira Filho 2010]. Por ser mais simples, por tornar as aplicaes criadas com base em seus princpios parte da Web permitindo que todos os recursos e disponveis na Web possam ser utilizados para o mundo fsico e por causa do menor tamanho das suas mensagens os princpios REST so considerados mais adequados para serem utilizados na integrao de dispositivos com baixa capacidade de hardware na Web [Wilde 2007]. Porm, ainda existe uma srie de desafios que precisam ser superados. Dentre eles destaca-se o modelo de pull da Web ocasionado pelo HTTP que no prev um modelo de comunicao assncrona onde o cliente notificado da ocorrncia de um evento.
3.4. Estendendo ROA para a Web das Coisas

Apesar do REST parecer adequado para dispositivos embarcados, estes nem sempre possuem um endereo IP (Internet Protocol) e no so, portanto, diretamente localizveis/endereveis na internet. No entanto, muito provvel que mais e mais dispositivos do mundo real se tornem habilitados para o IP e incorporem servidores HTTP (em especial com 6LoWPAN), tornando-os capazes de compreender as linguagens e protocolos da Web [Mayer 2010]. Desta forma, tais dispositivos podero ser diretamente integrados a Web e assim as suas funcionalidades sero acessadas atravs de interfaces RESTful. Embora tais dispositivos habilitados sejam susceptveis de serem amplamente distribudos em um futuro prximo, a integrao direta de dispositivos do mundo real com a Web ainda uma tarefa bastante complexa. Principalmente nos casos em que os dispositivos no suportam IP e/ou HTTP, como ocorre normalmente no contexto de redes de sensores sem fio (RSSF), por exemplo. Quando o endereo IP no suportado, necessrio utilizar um padro de integrao diferente. Nessas situaes, nas quais os dispositivos no so capazes de se comunicar via IP, possvel utilizar um dispositivo intermedirio chamado Smart Gateway. Smart Gateways possuem duas funes bsicas: fornecer uma interface RESTful com URIs que identificam e fornecem acesso aos objetos fsicos (dispositivos inteligentes) e seus subrecursos; e realizar a comunicao com os objetos fsicos utilizando as APIs destes. Em outras palavras, o Smart Gateway atua como uma ponte entre a Web e os dispositivos inteligentes, ao fornecerem uma interface Web RESTful de acesso aos recursos e subrecursos dos dispositivos e ao se comunicarem com tais dispositivos atravs de suas APIs. Cada gateway tem um endereo IP, executa um servidor HTTP e compreende os protocolos proprietrios dos diferentes dispositivos conectados a ele atravs do uso de controladores (drivers) dedicados. Como exemplo, considere uma requisio para um n sensor proveniente da Web atravs da API RESTful. O gateway mapeia essa requisio em uma solicitao da API proprietria do dispositivo e a transmite usando o
127
protocolo de comunicao que tal dispositivo compreende (por exemplo, usando o protocolo Zigbee). Um Smart Gateway pode suportar vrios tipos de dispositivos atravs de uma arquitetura de controladores. A Figura 3.14, mostra um exemplo de Smart Gateway que suporta trs tipos de dispositivos, comunicando-se com eles atravs de seus protocolos de comunicao correspondentes. Os Smart Gateways tambm podem ser usados para orquestrar a composio de vrios servios de baixo nvel em servios Web de mais alto nvel. Esses servios Web de mais alto nvel so mashups criados a partir da composio dos recursos dos dispositivos disponibilizados atravs da API RESTful oferecida pelo gateway. Por exemplo, se um dispositivo embarcado oferece monitoramento do consumo de energia dos aparelhos, o Smart Gateway poderia fornecer um servio que retorna a soma de todos os consumos de energia monitorados por todos os dispositivos embarcados conectados ao gateway.
Figura 3.14 - Smart Gateway, adaptado de [Guinard e Trifa 2009]
Outro dispositivo da WoT muito similar aos Smart Gateways so os Smart Hubs [Mayer 2010]. Os Smart Hubs permitem que sejam criadas infraestruturas que interligam dispositivos inteligentes Web a fim de prover servios avanados no topo desses dispositivos. Desta forma, os Smart Hubs oferecem a possibilidade de ter dispositivos interagindo entre si para que sejam fornecidas funcionalidades que vo alm do que cada dispositivo poderia prover individualmente. O Smart Hub utiliza servios de descoberta de dispositivos inteligentes a fim de obter e armazenar informaes sobre esses dispositivos. O processo de descoberta e armazenamento de informaes sobre novos dispositivos realizado pelo Hub conhecido como vinculao de recurso (attaching resource). Os Smart Hubs oferecem servios de consulta e publicao de recursos dentro da infraestrutura da WoT e so implementados para estabelecer conexes entre si de forma que seja mantida uma infraestrutura em rvore. Essa infraestrutura permite que os recursos de diferentes dispositivos no sejam centralizados em um nico Hub. Assim como os Smart Gateway, os Smart Hubs utilizam o conceito de controlador para se comunicarem com diferentes dispositivos utilizando as linguagens e protocolos destes [Trifa et al., 2009], [Mayer, 2010].
128
No contexto da WoT, um controlador um software utilizado para fazer a ponte entre o mundo fsico e a Web com o intuito de expor objetos inteligentes como servios RESTful. Um controlador tipicamente formado por: um mdulo que controla o dispositivo permitindo que o mesmo seja acessado a partir de um computador; e por um componente que disponibiliza um subconjunto de funcionalidades do dispositivo na Web, estabelecendo a comunicao entre clientes HTTP e esse dispositivo. Porm, a implementao de um controlador WoT pode diferir na forma como o dispositivo acessado pelo software. Um controlador pode atuar como um proxy reverso encaminhando requisies HTTP para um dispositivo que possui um servidor embarcado ou pode dissociar o processo de comunicao entre o cliente HTTP e o dispositivo (nesse caso, o objeto fsico acionado por meio de sua API para realizar a tarefa especificada na requisio HTTP). 3.4.1. Comunicao Orientada a Eventos Os Smart Hubs e Smart Gateway fornecem servios de comunicao orientada a eventos. Esse servio importante porque a comunicao com o protocolo HTTP sncrona (o modelo de comunicao requisio e resposta request/reply), o que no permite que o cliente seja notificado da ocorrncia de um evento. Um exemplo de evento pode ser observado quando sensores utilizados para monitorar a temperatura de uma rea detectam que est ocorrendo um incndio. No possvel prever quando ocorrer um incndio, por isso necessrio prover meios que permitam que o cliente saiba da ocorrncia dos eventos de interesse (no caso, a ocorrncia de incndio). Para monitorar a ocorrncia de um evento, os clientes podem consultar os dispositivos constantemente utilizando AJAX, por exemplo. Porm, essa abordagem no adequada, pois poderia fazer com que a bateria dos dispositivos se esgotasse rapidamente. Para evitar tal situao, possvel utilizar o Smart Gateway e o Smart Hub para fornecer um modelo de comunicao assncrona baseado no modelo publish/subscribe. Nesse modelo, o cliente publica um interesse para ser notificado com uma resposta assincronamente [Guinard et al. 2010]. Um modelo de comunicao assncrona que pode ser utilizado o Atom Publishing Protocol (AtomPub) [Atom 2004], [RFC4287 2005]. O Atom um formato XML que encapsula dados para serem publicados na Web (esse formato de disponibilizao de contedo chamado Syndication). O AtomPub o protocolo utilizado para publicar mensagens Atom. Nessa abordagem, o cliente deve assinar os feeds para monitorar as mensagens dos dispositivos. Assim, os clientes deixam de consultar os dispositivos e passam a consultar um servidor a parte. Os dispositivos, por sua vez, publicam os dados referentes a ocorrncia de um evento nesse servidor. Outros meios de comunicao assncrona tambm podem ser utilizados, tais como: e-mail, twitter e URIs de servios externos que devem ser acessados pelo gateway ou hub para publicao do evento. Por exemplo, se um usurio deseja que os dados do dispositivo sejam publicados em sua conta no twitter, ele deve fornecer informaes sobre a sua identificao e as credenciais do twitter. Ento, qualquer cliente que deseje obter as informaes do dispositivo precisa apenas se associar a conta do mesmo no twitter. Outra alternativa de comunicao assncrona na Web o modelo Comet, o qual pode ser utilizado para que o servidor envie dados para o cliente [Duquennoy et al.
129
2009]. Porm esse modelo consome mais recurso no lado do servidor, pois necessrio que o servidor armazene informaes sobre cada cliente para poder anunciar os dados referentes a um evento [Duquennoy et al. 2009].
3.5. Web das Coisas: Desenvolvendo Aplicaes na Plataforma Sun SPOT

Esta Seo descreve como dispositivos fsicos e suas funcionalidades podem ser disponibilizados na Web conforme as solues propostas na WoT. Para tal, so apresentados exemplos prticos utilizando os dispositivos embarcados Sun SPOT (Sun Small Programmable Object Technology), os quais so programados usando a linguagem Java [Sun SPOT 2011]. Nesta Seo tambm so apresentados dois mashups que compe os recursos dos SPOTs com outros recursos da Web. A Subseo 3.5.1 apresenta a plataforma Sun SPOT. A Subseo 3.5.2 apresenta como os objetos fsicos podem ser integrados a Web, incluindo exemplos prticos de como disponibilizar as funcionalidades de dispositivos Sun SPOT na forma de recursos RESTful. A Subseo 3.5.3 apresenta a construo de mashups fsicos que compem os dados e funcionalidades disponibilizados pelos SPOTs. 3.5.1. Introduo a Plataforma Sun SPOT O dispositivo Sun SPOT uma plataforma de sensores desenvolvida pela Sun Microsystems/Oracle [Sun SPOT, 2011]. Esse dispositivo acionado por cdigo Java e pode ser utilizado em diversos projetos com os mais variados propsitos. Eles podem, por exemplo, ser utilizado em carros robticos ou no monitoramento de fenmenos fsicos devido aos dispositivos de sensoriamento acoplados a eles [Sun SPOT, 2011]. Existem dois tipos de dispositivos Sun SPOT: os free-range SPOTs e a estao base [Sun SPOT, 2011]. A Figura 3.15 ilustra esses dois tipos de dispositivos (uma estao base e dois free-ranges SPOTs).
Figura 3.15 - Utilizando uma EB e dois free-range SPOTs
Os free-range SPOTs (ou simplesmente SPOTs) possuem uma bateria recarregvel, dispositivos de sensoriamento, sendo um de temperatura, outro de luminosidade e um acelermetro. Alm disso, eles tambm possuem dois botes (os botes podem ser utilizados para acender leds do SPOT ou at mesmo para mudar algum parmetro na aplicao), oito leds de trs cores (vermelho, verde e azul), quatro pinos genricos de entrada e sada (que podem ser utilizados para acoplar outros
130
dispositivos eletrnicos), quatro pinos de sada de alta tenso e uma interface USB [Sun SPOT, 2011]. Atualmente os SPOTs possuem as seguintes configuraes de hardware: um processador ARM de 32 bits que opera a uma freqncia de 400 MHz; 1 MB de memria RAM; 4 ou 8 MB de memria flash; e um Chipcon 2420 para comunicao a rdio em redes aderentes ao padro IEEE 802.15.4 dispondo de 11 canais de 2,4 GHz [Sun SPOT, 2011]. Os SPOTs podem ser identificados pelo seu endereo MAC IEEE de 64 bits. Alm disso, esse dispositivo oferece um protocolo de roteamento o LQRP (do ingls Link Quality Routing Protocol), o qual pode ser utilizado ou estendido pelo usurio. O cdigo Java da aplicao executado em uma mquina virtual chamada Squawk VM (Virtual Machine), compatvel com a plataforma Java ME (Micro Edition) na configurao CLDC1.1 (do ingls, Connected Limited Device Configuration), que permite que o cdigo seja executado sem depender de um sistema operacional. Portanto, a Squawk que realiza todas as funcionalidades necessrias para execuo de uma aplicao, a qual deve possuir uma classe que estende a classe MiDlet [Sun SPOT, 2011]. A estao base (EB) possui apenas uma interface de comunicao sem fio baseada em rdio e uma interface USB. A EB comunica-se com os free-range SPOTs usando o radio e com um dispositivo de maior poder computacional (um computador, por exemplo) via interface USB. Aplicaes para a plataforma Sun SPOT podem ser desenvolvidas em um computador pessoal e posteriormente instaladas nos SPOTs. Para tal, necessrio instalar no computador o JDK (Java Development Kit), o SDK (Sun Development Kit) e o Ant [Ant 2010], [Oracle 2010], [Sun SPOT 2011]. O Ant uma ferramenta que independe de sistema operacional e pode ser utilizada na automatizao do processo de compilao, implantao, gerao de documentos e execuo de uma aplicao. Essa ferramenta usada principalmente na construo de aplicaes Java e pode ser utilizada em conjunto com IDEs (Integrated Development Environment) [Ant 2010]. Desse modo, o desenvolvedor pode utilizar IDEs bem conhecidas tais como NetBeans [NetBeans, 2011] e Eclipse [Eclipse, 2011] para desenvolver aplicaes para Sun SPOT. A implantao do cdigo de uma aplicao nos SPOTs pode ser feita transferindo o cdigo atravs da interface USB ou utilizando uma abordagem OTA (over the air). A implantao do cdigo atravs do cabo USB exige que o SPOT esteja conectado fisicamente ao computador que contm o cdigo compilado. A implantao de cdigo via OTA utiliza o enlace de rede sem fio IEEE 802.15.4 para enviar o cdigo a um SPOT especfico. Utilizando essa ltima abordagem, a estao base utilizada para enviar esse cdigo e o endereo MAC do SPOT de destino deve ser especificado. Uma aplicao para Sun SPOT deve possuir uma classe que estende a classe MiDlet. A classe MiDlet possui trs mtodos abstratos que devem ser implementados pela classe que a estende: startApp(), pauseApp(), e destroyApp(boolean unconditional). O mtodo que executado inicialmente pela Squawk o startApp, sendo executado assim que o SPOT for iniciado. Os outros dois mtodos pauseApp e destroyApp podem conter uma implementao vazia. A Figura 3.16 mostra um exemplo bsico de uma classe que estende MiDlet. A Squawk executa uma aplicao por vez; isto significa que apenas uma classe estendendo MiDlet pode ser executada. Porm, a Squawk permite que uma aplicao execute vrias
131
threads de forma paralela. Maiores detalhes sobre a plataforma Sun SPOT podem ser obtidas em [Sun SPOT, 2011], onde tambm possvel obter informaes sobre um emulador que pode ser utilizado para testar a maioria dos projetos desenvolvidos para o Sun SPOT.
package br.ufrj.labnet; import import import import import import import import javax.microedition.midlet.*; java.io.IOException; com.sun.spot.io.j2me.udp.UDPConnection; com.sun.spot.io.j2me.udp.UDPDatagram; javax.microedition.io.Connector; javax.microedition.io.DatagramConnection; com.sun.spot.resources.transducers.ILightSensor; com.sun.spot.resources.Resources;
public class Exemplo extends MIDlet { public static DatagramConnection conn = null; public static int maxlen = 0; public static int port = 100; protected void startApp() throws MIDletStateChangeException { try { conn = (UDPConnection) Connector.open("udp://:" + port); int response = 0; ILightSensor lightSensor = (ILightSensor) Resources.lookup(ILightSensor.class); UDPDatagram dg = (UDPDatagram) conn.newDatagram(conn.getMaximumLength()); response = lightSensor.getValue(); dg.write(response); conn.send(dg); } catch (IOException ex) { ex.printStackTrace(); } } protected void pauseApp() {} protected void destroyApp(boolean unconditional) throws MIDletStateChangeException {} } //fim da classe Exemplo
Figura 3.16 - Classe de exemplo de uma aplicao para a plataforma Sun SPOT
3.5.2. Integrao de Dispositivos na Web Essa Subseo apresenta os procedimentos de como os dispositivos fsicos podem ser disponibilizados na forma de servios Web RESTful. A disponibilizao dos dispositivos pode ocorrer de duas formas: atravs da incluso de um servidor embarcado executado diretamente no dispositivo; ou por meio de Smart Gateways, que permitem que at mesmo os dispositivos que no possuem um servidor embarcado (devido a restries de hardware ou por restrio do projeto) tenham suas funcionalidades disponibilizadas na Web [Trifa et al. 2009]. Os dispositivos que possuem um servidor embarcado podem ter seus recursos acessados por requisies HTTP. Alm disso, o servidor tambm permite que esses
132
recursos sejam acessados por meio de uma interface RESTful [Guinard e Trifa 2009]. No caso dos dispositivos no suportarem a pilha de protocolo IP, necessrio fazer uso de um proxy para receber as requisies Web da rede TCP/IP e enviar tais requisies para o dispositivo por meio do enlace da rede utilizado pelo mesmo[Guinard e Trifa 2009]. Nesse proxy podem ser implementadas outras funcionalidades as quais agregam valor aos servios do dispositivo. Por exemplo, o proxy pode implementar servios de descoberta, que permitem que os dispositivos de um mesmo tipo sejam adicionados (quando estiverem na rea de atuao do proxy) e removidos do proxy (se o dispositivo se tornar inacessvel) [Guinard e Trifa 2009], [Mayer 2010]. A Subseo 3.5.2.1 apresenta um servidor embarcado para plataforma Sun SPOT que permite que as funcionalidades desse dispositivo sejam providas na forma de servios RESTful. Nessa mesma Subseo apresentado um proxy que permite que requisies Web sejam encaminhadas para os SPOTs. A Subseo 3.5.2.2 apresenta o prottipo de um Smart Gateway e demonstra a associao de dois SPOTs ao Gateway. Um SPOT possui um servidor embarcado enquanto o outro SPOT no. Dessa forma, exemplificado um cenrio bsico da incluso de dispositivos fsicos na Web. A Subseo 3.5.2.3 apresenta como os SPOTs associados ao Smart Gateway so acessados na Web. A Subseo 3.5.2.4 mostra como obter representaes dos estados dos recursos atravs de exemplos dessas representaes. 3.5.2.1. Tcnica de Implementao de Servidores Web em Dispositivos Embarcados A utilizao de servidores embarcados em objetos fsicos permite que as funcionalidades de tais objetos sejam disponibilizadas como recursos Web. Porm, as metodologias utilizadas na criao de servios Web no foram projetadas para serem empregadas em dispositivos que possuem hardwares restritos e so alimentados por bateria (por exemplo, sensores sem fio) [Shelby, 2010]. Portanto, para que os servidores Web sejam utilizados em dispositivos embarcados, eles devem atender uma srie de requisitos. Em [Shelby, 2010] foram apresentados os requisitos e padronizaes para servidores embarcados. Um exemplo de requisito a ser atendido de forma padronizada a compresso das mensagens do protocolo HTTP. Esta Subseo apresenta as principais caractersticas de um servidor embarcado desenvolvido para a plataforma Sun SPOT disponibilizado entre os projetos de demonstrao que acompanham a nova verso do SDK lanada em Outubro de 2010 [Gupta 2010], [Gupta e Simmons, 2010], [Sun SPOT, 2011]. Esse servidor faz parte do projeto WebOfThings e est disponvel em [Sun SPOT, 2011]. O projeto WebOfThings da plataforma Sun SPOT segue os drafts Chopan (Compressed HTTP Over PANs, 2009) e Reverse HTTP (2009) e a RFC 5785 (2010) da IETF [Gupta 2010], [Gupta e Simmons, 2010]. O draft Chopan descreve como o protocolo HTTP pode ser compactado em mensagens binrias a fim de reduzir o tamanho das mensagens que utilizam esse protocolo. As mensagens HTTP compactadas so transmitidas sobre UDP em redes sem fio de baixa taxa de transmisso e pequena largura de banda como, por exemplo, as redes IEEE 802.15.4/ZigBee. O draft Reverse HTTP descreve um mtodo que permite que as requisies HTTP sejam enviadas para dispositivos que no podem ser acessados diretamente (por exemplo, dispositivos que estejam atrs de um firewall ou de NAT - network address translation). A RFC 5785
133
descreve como servios Web podem obter meta-informaes sobre o servidor acessando o path /.well-know/ que simboliza as localizaes dos recursos. O projeto WebOfThings prov uma soluo para que as funcionalidades dos SPOTs sejam disponibilizadas sob a forma de recursos Web. Conforme apresentado na Subseo 3.5.1, os SPOTs se comunicam entre si e com a EB utilizando padro IEEE 802.15.4 e esses dispositivos no suportam o protocolo IP. Por isso, no projeto WebOfThings a EB (conectada a um computador que capaz de se comunicar utilizando o protocolo IP) utilizada para receber as requisies Web retransmitindo-as para os SPOTs [Gupta 2010], [Gupta e Simmons, 2010]. Para isso, a EB deve manter uma referncia para cada SPOT. Para tal, a EB utiliza como registro de identificao do SPOT parte do endereo fsico (MAC) desse SPOT. O servio de descoberta o responsvel por realizar o registro dos SPOTs na EB. Esse servio envia mensagens em broadcast em uma porta pr-definida e aguarda mensagens de algum SPOT que deseja se registrar. A mensagem de registro de um SPOT deve conter sua identificao. Essa identificao utilizada para disponibilizar o SPOT como um recurso Web e as funcionalidades desse SPOT so subrecursos do mesmo. Por exemplo, o dispositivo de sensoriamento de temperatura do spot-1265 (identificao de um SPOT) um subrecurso desse SPOT. Aps a etapa de registro, os SPOTs podem receber requisies Web. As requisies advindas da Web so enviadas para a estao base, a qual faz uso da URI da requisio para identificar qual recurso est sendo solicitado. Um exemplo de URI http://localhost:8888/spot-1265/light. O trecho spot-1265 utilizado para identificar o SPOT, enquanto o trecho light utilizado para identificar qual o recurso desse SPOT que o cliente deseja acessar (nesse caso, o recurso o dispositivo de sensoriamento de luminosidade desse SPOT). Aps a EB identificar qual SPOT est sendo solicitado na requisio HTTP, ela comprime a requisio recebida e a retransmite atravs do enlace de rede sem fio IEEE 802.15.4 para o respectivo SPOT e fica aguardando uma resposta do dispositivo solicitado (como exemplificado na Figura 3.17).
Figura 3.17 - Tratamento de uma requisio HTTP para um SPOT que contm um servidor embarcado.
Quando uma requisio HTTP recebida pelo SPOT, o servidor HTTP utilizado para descompactar essa requisio e criar um objeto contendo todas as informaes includas nessa mensagem (por exemplo, o objeto criado, dentre outras
134
informaes, pode ter o path de um recurso e o mtodo presente na requisio). Esse objeto que representa a requisio HTTP utilizado para identificar o recurso solicitado por meio do path, alm de indicar qual operao deve ser realizada sobre esse recurso. As operaes que podem ser executadas sobre um recurso so: criar, recuperar, atualizar e apagar. Essas operaes so executadas com base no respectivo mtodo da requisio HTTP (GET, POST, PUT ou DELETE) em conformidade com a propriedade ROA e o princpio REST de interface uniforme. necessrio ressaltar que os recursos no precisam tratar todos os mtodos HTTP utilizados em servios RESTful. Por exemplo, os dispositivos de sensoriamento apenas enviam o valor sensoriado; logo esses recursos so acessados por requisies que contm o mtodo GET do HTTP e os demais mtodos no so suportados, pois no possuem utilidade para esse recurso. Os leds por outro lado, podem retornar uma representao contendo as cores com que eles esto acesos (por exemplo, utilizando valores RGB red, green, blue) quando recebem uma requisio com o mtodo GET. Ou podem alterar sua cor com base em parmetros de uma requisio que contm o mtodo PUT. Aps o tratamento da requisio HTTP, o servidor do SPOT envia uma mensagem de resposta HTTP com um cdigo de sucesso ou um cdigo de erro (por exemplo, um 200 OK que indica que o contedo da requisio foi processado com sucesso ou um 404 que indica que o recurso no foi encontrado). As mensagens HTTP de sucesso podem conter uma representao do recurso solicitado (por exemplo, as requisies HTTP que contm o mtodo GET). Nesse caso, o prprio recurso retorna uma representao (em HTML, JSON ou XML, por exemplo) que includa na mensagem de resposta HTTP. Em seguida, a mensagem HTTP de resposta deve ser compactada e enviada para a EB onde ser descompactada e enviada ao cliente que fez a requisio. A Figura 3.18 e a Figura 3.19 apresentam as principais classes do projeto WebOfThings que fazem com que os SPOTs disponibilizem suas funcionalidades na Web na forma de servios RESTful. A Figura 3.18 apresenta as principais classes do projeto WebOfThings que so executadas na EB. Essas classes implementam as funcionalidades que permitem que os SPOTs registrados sejam acessados como qualquer servio Web RESTful. Nessa classe criada uma instncia de NanoAppServer. Em NanoAppServer esto implementadas as funcionalidades que permitem que as requisies sejam encaminhadas para o SPOT adequado, como se esse dispositivo fosse um recurso Web. A classe Main tambm instancia TCPHandle passando a referncia do objeto NanoAppServer criado anteriormente. TCPHandle tem como objetivo receber as requisies HTTP advindas da Web em uma porta pr-definida. Para cada requisio advinda da Web, TCPHandle devolve uma resposta via Web ao emissor de tal requisio. Por exemplo, ao receber uma requisio HTTP advinda da Web, TCPHandle cria um objeto do tipo HttpRequest que contm todas as informaes da requisio HTTP recebida da Web. Para tal, TCPHandle utiliza o mtodo esttico parse da classe HttpRequest passando como parmetro a requisio HTTP recebida da Web. A instncia de HttpRequest que equivale a requisio HTTP advinda da Web possui todos os campos da mensagem HTTP compactados (por exemplo, os campos do cabealho da requisio so representados por bytes especficos). Em seguida, TCPHandle acessa NanoAppServer para obter a resposta para essa requisio HTTP.
135
Em NanoAppServer acessado o mtodo processRequest da classe MainApp passando como parmetro a instncia de HttpRequest criada anteriormente. Em MainApp utilizado o path do recurso que identifica o SPOT que deve ser acessado (por exemplo, spot-1265). Esse path passado para a instncia de DeviceManager que identifica se o SPOT solicitado est entre os SPOTs cadastrados na EB. Se um SPOT for identificado, a instncia de HttpRequest encaminhada para esse SPOT por meio do mtodo sendAndGetResponse de UDP6Forwarder. O mtodo sendAndGetResponse de UDP6Forwarder encaminha a requisio e aguarda a resposta do SPOT. Finalmente, a resposta enviada pelo SPOT entregue por TCPHandler ao cliente que fez a requisio (qualquer erro em algumas das etapas anteriores far com que uma resposta contendo um cdigo de erro seja enviada para o cliente Web).
Figura 3.18 - Principais classes do projeto WebOfThings executadas na Estao Base
A Figura 3.19 apresenta as principais classes que so executadas no Sun SPOT para que as funcionalidades dessa plataforma sejam disponibilizadas como recursos RESTful. A classe WoTServer estende MIDlet, logo essa classe MIDlet utilizada pela Squawk para iniciar a aplicao. Em WoTServer instanciada a classe NanoAppServer que implementa as funcionalidades do servidor HTTP. Nos SPOTs, NanoAppServer armazena as instncias das classes que implementam as funcionalidades dos recursos, bem como uma identificao para cada uma dessas instncias. Essa identificao utilizada para relacionar um recurso com o path de uma requisio. Por exemplo, uma instncia da classe LightSensor que permite que o dispositivo de sensoriamento de luminosidade seja disponibilizado como recurso Web identificada pela String /light e uma requisio para esse recurso deve conter o path /light, pois esse path que ser utilizado para identificar o recurso. Cada classe que implementa as funcionalidades de um recurso deve estender WebApplication (por exemplo, a classe LightSensor estende a classe WebApplication). A classe WebApplication uma classe abstrata que define a interface necessria para as classes que implementam as funcionalidades de um recurso.
136
Figura 3.19 - Principais Classes do projeto WebOfThings Executadas nos SPOTs
Em WoTServer tambm instanciada a classe UDP6Handler que realiza a tarefa de comunicao utilizando os nveis de rede da plataforma Sun SPOT. As mensagens no nvel de rede so recebidas em UDP6Handler e o contedo de cada mensagem um array de bytes que equivale a requisio HTTP compactada. Esse array de bytes passado para o mtodo esttico parse da classe HttpRequest que retorna uma referncia para um objeto do tipo HttpRequest que representa a requisio descompactada. UDP6Handler faz uso do objeto que equivale a requisio para obter um objeto HttpResponse que equivale a resposta adequada para a requisio recebida. Em seguida, UDP6Handler solicita que a resposta HTTP seja compactada para finalmente envi-la EB. As classes HttpRequest e HttpResponse estendem a classe abstrata HttpMessage e contm todas as funcionalidades necessrias para manipulao das requisies e respostas, respectivamente. A classe HttpMessage contm os mtodos que realizam a compresso e descompresso das mensagens HTTP (cabealhos, tipos MIME, entre outros). A classe HttpRequest fornece todos os mtodos para acesso aos cabealhos e parmetros da requisio HTTP (por exemplo, obteno do mtodo da requisio HTTP). Os objetos do tipo HttpResponse so criados com base no recurso indicado no path da requisio (por exemplo, uma requisio utilizada para obter uma representao do valor da temperatura faz com que uma resposta seja gerada na instncia da classe que implementa as funcionalidades desse recurso). Quando um recurso no existe ou o mtodo indicado na requisio no suportado pelo recurso, criada uma instncia de HttpResponse com um cdigo de erro. A Figura 3.20 apresenta o diagrama de seqncia das mensagens trocadas durante a execuo do servidor embarcado nos SPOTs: da etapa de inicializao ao tratamento das requisies dos clientes que desejam obter uma representao de algum recurso disponibilizado. A classe WoTServer instancia a classe NanoAppServer e todas
137
as classes dos recursos. Em seguida, as instncias das classes que implementam os recursos so passadas para NanoAppServer juntamente com o path que os identifica atravs do mtodo registerApp dessa classe. A prxima classe a ser instanciada UDP6Handler que recebe um parmetro do tipo int e uma referncia para a instncia de NanoAppServer. O parmetro int indica a porta onde deve ser aberta a conexo no nvel de rede da plataforma Sun SPOT. Essa porta deve ser a mesma utilizada pela EB para encaminhar as requisies Web para o SPOT.
Figura 3.20 - Diagrama de seqncia das mensagens trocadas durante a execuo do servidor embarcado nos SPOTs
O objeto do tipo UDP6Handler deve permanecer em um lao contnuo ouvindo mensagens na porta indicada. As requisies e respostas HTTP trafegam no enlace de rede sem fio dentro de datagramas. A comunicao utilizando datagramas realizada atravs dos mtodos da classe UDPConnection que estende a interface DatagramConnection disponvel no SDK. Aps receber o datagrama, UDP6Handler passa o contedo do datagrama como parmetro do mtodo esttico parse da classe HttpRequest a fim de receber uma referncia para um objeto do tipo HttpRequest que representa a requisio HTTP recebida (mensagem 5 do diagrama de seqncia). A referncia para o objeto que representa a requisio utilizada por UDP6Handler para obter um objeto HttpResponse que equivale a resposta para essa requisio. Essa referncia do objeto que representa a requisio passada para NanoAppServer atravs do mtodo getResponse (mensagem 6 do diagrama de seqncia). Ento, NanoAppServer utiliza a instncia do objeto que representa a requisio como parmetro do mtodo findMatchingAppAndAdjustPath para buscar entre a coleo dos recursos aquele que est sendo solicitado. Nesse momento, extrado o path da requisio o qual identifica o recurso desejado. Quando o recurso solicitado identificado, a instncia da classe que implementa as funcionalidades do
138
recurso processa a requisio gerando uma resposta adequada (se ocorrer algum erro, uma resposta criada contendo um cdigo de erro). Finalmente, a resposta compactada (mensagem 7 do diagrama de seqncia) atravs do mtodo toByteArray da classe HttpResponse que repassa a tarefa de compresso para a classe HttpMessage. Um array de bytes obtido desse processo o qual inserido no datagrama, atravs do mtodo write. Ento o datagrama que contm a resposta HTTP enviado atravs do mtodo send em UDP6Handler. 3.5.2.2. Implementao de Gateways Esta Subseo contm uma descrio do prottipo de um Smart Gateway desenvolvido a partir da extenso do proxy reverso apresentado na Subseo 3.5.2.1. A descrio desse prottipo tem como objetivo fornecer uma viso mais aprofundada sobre um Smart Gateway. No prottipo, dois tipos de dispositivos foram conectados ao gateway atravs do uso de controladores. Ambos os dispositivos so Sun SPOTs, porm um dispositivo possui um servidor embarcado e o outro no. No segundo caso, o gateway se comunica com o SPOT utilizando a API deste atravs de um controlador desenvolvido para tal finalidade. Desta forma, pretende-se exemplificar como um dispositivo que no possui servidor embarcado pode ter seus recursos disponibilizados na Web atravs de um Smart Gateway. A Figura 3.21 mostra os principais componentes do gateway. Os controladores de cada dispositivo possuem um mdulo de descoberta personalizado para o tipo de dispositivo que controla. Os controladores enviam mensagens em broadcast periodicamente em uma porta pr-definida. Os dispositivos que querem se associar ao gateway devem responder a essas mensagens enviando uma resposta para o controlador. Quando um novo dispositivo adicionado ao Smart Gateway, o path de acesso a esse novo recurso negociado entre um mdulo do gateway que faz a gerncia de paths e o controlador do dispositivo a fim de evitar paths repetidos. Normalmente o path segue a seguinte estrutura: /{tipoDispositivo}/dispositivo-id/recurso (por exemplo, /spotapi/spot-0f40/temperature). Outro mdulo apresentado na Figura 3.21 o DespacharRequisicao. Esse mdulo utiliza as URIs das requisies para obter a informao necessria para selecionar o controlador do tipo de recurso (dispositivo) que est sendo solicitado (o tipo de dispositivo pode ser um SPOT com servidor embarcado, por exemplo). Nessa etapa, uma referncia de um objeto Java contendo as informaes da requisio passada para o controlador. O controlador, por sua vez, utiliza as informaes da requisio para adquirir o recurso diretamente no dispositivo solicitado. O recurso obtido do dispositivo devolvido ao componente DespacharRequisicao, o qual retorna uma resposta contendo o dado solicitado ao cliente que submeteu a requisio. Se algum erro ocorrer durante esse processo, uma resposta contendo um cdigo de erro devolvida ao cliente.
139
Figura 3.21 - Componentes bsicos do Smart Gateway e de dois tipos de dispositivo (um SPOT com servidor embarcado e o outro sem sendo a comunicao realizada atravs da API deste)
As principais classes do Smart Gateway utilizadas para registrar e identificar controladores, alm de encaminhar requisies da Web para esses controladores so apresentadas na Figura 3.22. Nessa figura, a classe MainApp chamada a cada nova requisio. As requisies so encaminhadas para o controlador adequado com base no path dessas requisies. A Figura 3.23 apresenta as principais classes de um controlador. Tais classes sero explicadas no contexto de um exemplo. O controlador utilizado para SPOTs que possuem um servidor embarcado foi desenvolvido de forma anloga, mas apresentado na Subseo 3.5.2.1. Os controladores estendem a classe WebApplication e devem ser registrados na classe MainApp quando uma instncia do controlador juntamente com o path que ser utilizado para identific-lo so passados para NanoAppServer. Os controladores so Singletons, isto , s existe uma instncia de cada controlador por Smart Gateway. A classe DeviceDiscovery implementada como uma Thread que executa em intervalos pr-definidos a tarefa de enviar anncios sobre o gateway a fim de cadastrar novos dispositivos dinamicamente. Essa classe tambm utilizada para controlar a sada de dispositivos que no possam mais ser alcanados (devido ao esgotamento da bateria do dispositivo, ou por qualquer outro motivo). Por exemplo, se um dispositivo conectado no responder a trs anncios consecutivos ele pode ser considerado
140
inalcanvel, enquanto nos dois primeiros anncios o controlador pode considerar que tal dispositivo est em modo sleep para economizar energia.
Figura 3.22 - Principais classes do Smart Gateway
Figura 3.23 - Principais classe de um controlador
A classe DeviceManager mantm uma lista de todos os dispositivos e realiza o acesso aos recursos dos mesmos atravs da classe DeviceAccess. Uma requisio identifica atravs do path um recurso (representado pelo controlador), um dispositivo especfico (considerado subrecurso do controlador) e alguma funcionalidade do dispositivo (considerada seu subrecurso). Por exemplo, o path /spotApi/spot0f40/temperatura, a primeira parte do path /spotApi identifica o controlador desse
141
tipo de dispositivo. A segunda parte /dispositivo-0f40 identifica o SPOT onde 0f40 so os quatro ltimos dgitos do endereo MAC desse SPOT. Por ltimo, o trecho /temperatura utilizado para identificar o dispositivo de sensoriamento de temperatura desse SPOT. A classe Device contm toda informao necessria para que seja realizado um acesso especfico a um dispositivo. Uma nova instncia dessa classe criada e adicionada a lista de DeviceManager sempre que um novo dispositivo encontrado. A classe DeviceAccess utilizada para acessar os dispositivos por meio da API dos mesmos. Essa classe acessa o dispositivo utilizando os dados de uma instncia de Device. Um controlador pode evitar o acesso contnuo aos tipos de dispositivo que representa utilizando cache dos dados com o objetivo de diminuir o consumo de energia desses dispositivos. Um controlador utilizado para acessar SPOTs por meio da API destes pode enviar mensagens de anncio do gateway na porta 201. Neste trabalho, os SPOTs que se comunicam com o Smart Gateway utilizando apenas a API enviam uma mensagem JSON contendo as seguintes informaes: MAC, nome, timestamp e uma lista contendo as funcionalidades (recursos) dos SPOT. A Figura 3.24 ilustra a estrutura JSON utilizada para prover as informaes necessrias para que os SPOTs sem servidor embarcado possam se cadastrar no gateway. A Figura 3.25 apresenta a estrutura da mensagem utilizada por esses SPOTs para se associarem a um gateway. A Figura 3.26 mostra as classes dos SPOTs que so acessadas por meio de sua API.
{"gateway_id":MAC_gateway,timestamp:timestamp}
Figura 3.24 - Estrutura JSON utilizada no servio de descoberta do controlador que se comunicam com os SPOTs por meio da API destes
{"spot-api:{MAC:0014.4F01.0000.0F20,nome:spot-api,timestamp: 1300223762980,recursos:{temperatura:/temperature,luminosidade:l ight}}

Figura 3.25 - Estrutura JSON de anncio de capacidade enviada pelos SPOTs que no possuem servidor embarcado para o gateway
Figura 3.26 - Diagrama de classes dos SPOTs que no possuem servidor embarcado
A classe SpotAPI a classe executada pela Squawk, pois estende MiDlet. A classe SPOT_Advertise responsvel pelas tarefas de associao a um Smart Gateway. A classe Resource responsvel por acessar o recurso adequado quando recebe uma mensagem do gateway. A classe SPOTCommunication utilizada para ouvir e responder mensagens direcionadas aos recursos. Na implementao realizada neste prottipo o SPOT fica ouvindo na porta 200 mensagens cujo contedo um documento
142
JSON. O JSON indica qual tipo de dado (temperatura ou de luminosidade) que o SPOT deve retornar. 3.5.2.3. Exposio de Dispositivos como Recursos REST Como visto extensivamente ao longo deste Captulo, na Web das Coisas as funcionalidades dos dispositivos so acessadas por meio de URIs. Dessa forma, os recursos de um SPOT associado a um gateway devem ser acessados atravs de uma URI. Tal URI utilizada para localizar o gateway, identificar um dispositivo e especificar um recurso do mesmo. A URI permite que os recursos sejam identificados de forma nica na Web e fazem com que os SPOTs sejam vistos como recursos do gateway enquanto as suas funcionalidades so vistas como seus subrecursos [Mayer 2010]. A URI de acesso ao recurso de um SPOT tem o formato http://{endereo do gateway}/{identificao do controlador}/{identificao do SPOT}/{recurso do SPOT}. O endereo do Smart Gateway o identifica na Web; a identificao do controlador indica o tipo de dispositivo associado ao gateway que o cliente deseja acessar; e a identificao do SPOT indica qual dispositivo associado ao gateway que deve ser acessado (os SPOTs so identificados pelos quatro ltimos dgitos do seu endereo MAC). O recurso especificado na URI indica qual funcionalidade do SPOT o cliente deseja acessar. Por exemplo, o acesso ao sensor de temperatura do SPOT cujos quatro ltimos dgitos do MAC so 1265 pode ser feito atravs da URI http://localhost:8888/spotserver/spot-1265/light, onde /light identifica o subrecurso do SPOT. Os SPOTs que no possuem servidor embarcado tambm so identificados por uma URI com o formato semelhante. Por exemplo, de forma similar ao exemplo do SPOT que possui servidor embarcado, o SPOT sem servidor embarcado que possui os quatro ltimos dgitos do MAC 0F20 pode ser acessado em http://localhost:8888/spotapi/other-0f20/temperature, onde other-0f20 identifica um SPOT e /temperatura identifica a funcionalidade desse dispositivo que se deseja acessar. Esse uso de URI tambm permite que o sistema fornea links para que os clientes naveguem entre os subrecursos de um recurso. Por exemplo, uma requisio enviada para http://localhost:8888/spotserver/spot-1265 retorna uma listagem com links para todos os recursos disponveis nesse SPOT. Esses links permitem que o cliente mude da representao do estado de um recurso para outras representaes de diferentes recursos. Alm disso, tambm possvel utilizar links que conduzem o cliente nas interaes que podem ser realizadas com o recurso. 3.5.2.4. Representao de Estado Os dispositivos conectados a Web fornecem dois tipos de representao de recursos: HTML e JSON. A representao HTML foi adotada para simplificar a interao dos clientes (humanos) como os recursos disponibilizados, permitindo a navegao dentro da estrutura por meio de links para os recursos filhos (subrecursos). Esse tipo de representao HTML retornado pelo gateway e pelo SPOT que possui um servidor embarcado. O gateway retorna um HTML contendo uma lista com os dispositivos conectados a ele separados por tipo. Cada dispositivo da lista possui um link associado a ele que permite que o usurio acesse tal dispositivo (a Figura 3.27 mostra um exemplo da pgina principal do gateway). Os SPOTs que possuem um
143
servidor embarcado enviam uma representao HTML contendo seus subrecursos com links para cada um deles (ver Figura 3.28). As representaes JSON so disponibilizadas quando um SPOT que no possui servidor embarcado acessado ou quando uma requisio especificando que a representao deve ser JSON submetida a um SPOT com servidor embarcado. No caso dos SPOTs sem servidor embarcado, a representao JSON utilizada pelo SPOT para retornar seus dados ou a listagem dos seus recursos (a Figura 3.29 mostra um exemplo de dado de temperatura retornado por um desses SPOTs).
Figura 3.27 - Representao HTML da pgina inicial do Smart Gateway
Figura 3.28 - Listagem dos recursos disponveis em um SPOT com servidor embarcado
{"resource":{"typeOfResource":"temperature","scale":"Celsius","value","32", "timestamp":"1300223762980","deviceId":"temperatura","link":"/temperatura "}}

Figura 3.29 - Representao JSON do recurso temperatura
3.5.3. Tcnicas de implementao de Mashups Fsicos Essa Subseo apresenta dois exemplos de composio, em mashups fsicos, dos recursos dos dois SPOTs (com e sem servidor embarcado) conectados ao Smart Gateway. Os mashups fsicos tm como objetivo compor as informaes e funcionalidades dos dispositivos inteligentes em servios mais sofisticados agregandolhes valor. Os mashups aqui apresentados foram desenvolvidos com a ferramenta Presto
144
[Presto 2010] a qual utiliza a EMML [EMML 2010] que uma linguagem padro de desenvolvimento de mashups. O primeiro mashup apresenta os dados dos dois SPOTs em um grfico (ver Figura 3.30). Esse grfico apresenta a variao da temperatura das ltimas doze amostras obtidas antes do momento da requisio. Para a construo do mashups, foi implementado um servio Web que acessa os dispositivos de sensoriamento de temperatura dos SPOTs a cada hora e armazena a representao do recurso acessado em um repositrio (para esses exemplos foi utilizado um banco de dados relacional) que atua como histrico de dados. importante lembrar que as representaes de recursos dos dois SPOTs foram obtidas como as de qualquer outro recurso na Web. O SPOT responsvel pela gerao dos dados representados pela linha laranja do grfico foi colocado dentro de um ambiente fechado que possui ar condicionado. O SPOT responsvel pela gerao dos dados representados pela linha azul do grfico foi colocado em uma ambiente aberto (e obviamente sem ar condicionado) para coletar a temperatura do ambiente. A integrao na Web permitiu que os dados dos SPOTs fossem utilizados em grficos que podem ser visualizados na maioria dos navegadores Web. O mashup criado possibilita, por exemplo, que o responsvel pela central do ar condicionado tenha uma visualizao de alto nvel sobre os dados de temperaturas obtidos pelos sensores, permitindo que esse usurio possa avaliar de forma simples e rpida se o sistema de refrigerao est mantendo a temperatura interna do laboratrio independentemente da variao de temperatura do ambiente externo.
Figura 3.30 - Grfico de Temperaturas coletadas pelos SPOTs colocados em diferentes ambientes em um intervalo de 12 horas
A Figura 3.31 apresenta a integrao de um SPOT com um mapa Web [Google Maps Api 2010]. O mapa possui uma marcao com um cone em uma localidade prdefinida. Quando esse cone acionado atravs de um clique do mouse, aberta uma caixa com uma mensagem contendo a temperatura do local em que se encontra o SPOT no momento do clique. Quando o usurio clica no cone apresentado no mapa, obtida uma representao JSON de um dado coletado pelo dispositivo de sensoriamento do
145
SPOT. Essa representao contm o valor da temperatura monitorada pelo dispositivo de sensoriamento, o horrio em que o dado foi coletado e uma descrio do local onde o sensor est localizado (nesse caso, dentro de um laboratrio). A localizao no mapa foi fornecida manualmente atravs da insero das coordenadas geogrficas do local. possvel utilizar algum mecanismo (um GPS, por exemplo) que fornea coordenadas geogrficas de forma automatizada para o mashup. Porm, como o objetivo aqui apenas ilustrar a integrao de recursos da Web com dispositivos fsicos, as coordenadas geogrficas da localizao do SPOT foram fornecidas manualmente. O mashup apresentado na Figura 3.31 permite que o administrador de um sistema possa realizar alguma ao remotamente com base na informao oferecida pelo mashup. Por exemplo, o administrador de vrios servidores espalhados por diversas instituies de ensino do pas poderia desligar remotamente um servidor caso a temperatura de um local onde tal servidor se encontra estivesse acima do ideal para o bom funcionamento do mesmo. Essa ao emergencial seria tomada com base na informao do mashup que combina a localizao (oferecida pelo mapa) com o dado de temperatura (fornecido pelos sensores).
Figura 3.31 - Mashup fsico que apresenta em uma mapa da Web a localizao de um SPOT e o valor da temperatura local obtida atravs do acesso Web ao dispositivo de sensoriamento desse SPOT
3.6. Concluso
Neste trabalho foram descritos os princpios bsicos da Web das Coisas. As tecnologias Web foram apresentadas como base vivel para a integrao de dispositivos inteligentes entre si e desses com a Web. Foi apresentada uma arquitetura para a Web das Coisas baseada nos conceitos de REST e na abordagem de arquitetura orientada a recursos (ROA), e seus componentes foram descritos. Tambm foram apresentados projetos de implementao de alguns desses componentes. Graas ao baixo acoplamento, simplicidade e escalabilidade da arquitetura RESTful e a ampla disponibilidade de bibliotecas e clientes HTTP, tal arquitetura est
146
se tornando uma das mais onipresentes e leves dentre as arquiteturas de integrao de dispositivos [Guinard e Trifa 2009]. Devido a isso, o uso de padres Web para dar suporte a interao entre e com dispositivos inteligentes tem sido considerado uma promissora soluo. Embora HTTP introduza uma sobrecarga de comunicao e aumente a latncia mdia, os parmetros de qualidade providos em geral so suficientes que tais atrasos no prejudiquem a comunicao entre dispositivos. Entretanto, outros trabalhos buscaram solues de compresso desse protocolo a fim de reduzir o aumento da mensagem ocasionado pelo uso do HTTP, [Shelby, 2010], [Chopan,2009]. As vantagens oferecidas pela introduo de suporte para os padres da Web diretamente no nvel de dispositivo so benficas para o desenvolvimento de uma nova gerao de aplicaes que contero informaes do mundo real alm dos contedos estticos como acontece atualmente. O emprego dos padres Web tambm como base comum para diferentes dispositivos torna muito mais simples a programao dos mesmos. Aplicar os mesmos princpios de design que foram responsveis para o sucesso da Web, em particular abertura e simplicidade, pode alavancar significativamente a ubiqidade e versatilidade da Web como um terreno comum para dispositivos de rede e aplicaes. Alm disso, como a maioria das linguagens de programao suportam HTTP, percebe-se a enorme comunidade de desenvolvedores da Web como potenciais desenvolvedores de aplicaes para a Web das Coisas.
Agradecimentos
Este trabalho foi parcialmente suportado pelas agncias de fomento CNPq, FINEP e FAPERJ, sob os processos de nmero 201090/2009-0, 306938/2008-1 e 477229/2009-3 para Flvia C. Delicato; 480359/2009-1 e 311515/2009-6 para Paulo F. Pires; e 309270/2009-0, 4781174/2010-1, 01.100064.00 1979/09 e 101.360/2010 para Luci Pirmez.
Referncias
Ant. Apache Ant, 2010. Disponvel em <http://ant.apache.org/>. Acessado em 08 de maro de 2011. Atom. Atom Enable, 2004.Disponvel em <http://www.atomenabled.org/>. Acessado em 19 de Fevereiro de 2011. Atzori, L.; Iera, A.; Morabito, G. The Internet of Things: A survey, 2010. Computer Networks 54 (2010), p. 27872805. Bezerra, R. S.; Santos, C. R. P.; Granville, L. Z.; Bertholdo L. M.; Tarouco, L. R. Um Sistema de Gerenciamento de Redes Baseado em Mashups, 2009. Disponvel em: < http://www.sbc.org.br/bibliotecadigital/download.php?paper=1550>. Acessado em 14 de Novembro de 2010. Chumby, 2011. Disponvel em <http://www.chumby.com/>. Acessado em 5 de Janeiro de 2011. Delicato, F. C.; Pires, P. F.; Pirmez, L.; Batista, T. Wireless Sensor Networks as a Service, 2010. IEEE Engineering of Computer Based Systems (ECBS), 2010 17th IEEE International Conference and Workshops, p. 410 417. Duquennoy, S.; Grimaud, G.; Vandewalle, J. The Web of Things: interconnecting devices with high usability and performance, 2009. In International Conferences on
147
Embedded Software and Systems. Disponvel em: <http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5066664>. Acessado em 05 de Novembro de 2010 Eclipse, 2011. Disponvel em <http://www.eclipse.org/>. Acessado em 08 de maro de 2011. EMML. Enterprise Mashup Markup Language, Open Mashup Alliance, 2010. Disponvel em <http://www.openmashup.org/>. Acessado em 18 de Novembro de 2010. Ferreira Filho, O. F. Servios semnticos: uma abordagem RESTful. Dissertao de mestrado, USP, 2010. Disponvel em <http://www.teses.usp.br/teses/disponiveis/3/3141/tde-11082010-120409/pt-br.php>. Acessado em 3 de Fevereiro de 2011. Fielding, Roy Thomas (2000), Architectural Styles and the Design of Network-based Software Architectures, Doctoral dissertation, University of California, Irvine. Google Maps API, 2010. Disponvel em <http://code.google.com/intl/ptBR/apis/maps/index.html>. Acessado em 3 de Maro de 2011. Guinard, D. e Trifa, V., Towards the Web of Things: Web Mashups for Embedded Devices., In Proceedings of Workshop on Mashups, Enterprise Mashups and Lightweight Composition on the Web, International World Wide Web Conferences, Madrid, Spain, 2009. Guinard, D. Towards Opportunistic Applications in a Web of Things. In IEEE International Conference on Pervasive Computing and Communications Workshops, 2010. Guinard, D.; Trifa, V.; Pham, T.; Liechti, O. Towards Physical Mashups in the Web of Things. In Proceedings of IEEE Sixth International Conference on Networked Sensing Systems, Pittsburgh, USA, June 2009. Guinard, D.; Trifa, V.; Wilde, E. Architecting a Mashable Open World Wide Web of Things. Em Technical Report, 663. Institute for Pervasive Computing, 2010. Disponvel em <http://www.bibsonomy.org/bibtex/2dcc3fabe2de456144254afdcc8e06776/flint63>. Acessado em 28 de Janeiro de 2011. Gumstix, 2010. Disponvel em <http://www.gumstix.com/>. Acessado em 5 de Janeiro de 2011. Guo, X.; Shen J.; Yin Z. (2010) On software development based on SOA and ROA. In Control and Decision Conference (CCDC), pages 1032 1035. Publishing Press. Gupta, V. The Web of Things and Sun SPOTs, 2010. Disponvel em <http://blogs.sun.com/vipul/entry/the_web_of_things_and>. Acessado em 20 de Fevereiro de 2011. Gupta, V.; Simmons, D. G. Building the Web of Things with Sun SPOTs, 2010. Disponvelem<http://www.sunspotworld.com/S314730_Sun_SPOTs_Web_Of_Thin gs/index.html>. Acessado em 20 de Fevereiro de 2011.
148
Hadley, J. H. WADL (Web Application Description Language). GlassFish, WADL, 2006. Disponvel em <http://wadl.java.net/wadl20060802.pdf>. Acessado em 12 de Dezembro de 2010. Hadley, J. H. WADL (Web Application Description Language). GlassFish, WADL, 2009. Disponvel em <http://wadl.java.net/>. Acessado em 3 de Fevereiro de 2011. Hui, J. W. e Culler D. E. Extending IP to Low-Power, Wireless Personal Area Networks. Internet Computing, IEEE 12, no. 4 (2008), p. 37-45. ITU Internet Reports. ITU Internet Reports 2005: The Internet of Things. Em International Telecomunications Union, 2005. Jersey, 2011. Disponvel em <http://jersey.java.net/>. Acessado em 16 de Maro de 2011. JSON. JavaScript Object Notation, 1999. Disponvel em < JavaScript Object Notation>. Acessado em 18 de Maro de 2011. Lucchi, R.; Millot, M.; Elfers, C. Resource Oriented Architecture and REST, Assessment of impact and advantages on INSPIRE, 2008. Mayer, S. Deployment and Mashup Creation Support for Smart Things, Institute for Pervasive Computing Department of Computer Science ETH Zurich, 2010. Disponvel em <http://www.vladtrifa.com/files/publications/Mayer10.pdf>. Acessado em 02 de Dezembro de 2010. Nabaztag, 2009. Disponvel em Acessado em 5 de Janeiro de 2011. <http://www.nabaztag.com/brasil/index.html>.
NetBeans, 2011. Disponvel em <http://netbeans.org/>. Acessado em 08 de Maro de 2011. NIC (National Intelligence Council), Disruptive Civil Technologies Six Technologies with Potential Impacts on US Interests Out to 2025 Conference Report CR 2008-07, 2008. Disponvel em <http://www.dni.gov/nic/NIC_home.html>. Acessado em 10 de Fevereiro de 2011. Oracle, JDK (Java SE Development Kit), 2010. Disponvel em <http://www.oracle.com/technetwork/java/javase/downloads/index.html>. Acessado em 08 de Maro de 2011. Ostermaier, B. Schlup, F. Romer, K. WebPlug: A framework for the Web of Things, em Pervasive Computing and Communications Workshops (PERCOM Workshops), 2010 8th IEEE International Conference, 2010, p. 690-695. Pautasso, C.; Zimmermann, O.; Leymann, F. RESTful Web Services vs. Big Web Services: Making the Right Architectural Decision. Em Proceeding of the 17th international conference on World Wide Web, 2008. Disponvel em <http://portal.acm.org/citation.cfm?id=1367606>. Acessado em 02 de Dezembro de 2010. Plogg. Wireless Energy Management, 2010. Disponvel <http://www.plogginternational.com/>. Acessado em 5 de Janeiro de 2011. em
Poken, 2010. Disponvel em <http://www.poken.com/>. Acessado em 5 de Janeiro de 2011.
149
Presto. Mashup Developer Community, 2010. Disponvel em <http://www.jackbe.com/enterprise-mashup/>. Acessado em 20 de Janeiro de 2011. Reverse HTTP. draft-lentczner-rhttp-00. IETF, 2009. Disponvel em <http://tools.ietf.org/html/draft-lentczner-rhttp-00>. Acessado em 21 de Janeiro de 2011. RFC 2068. Hypertext Transfer Protocol -- HTTP/1.1, 1997. Disponvel em <http://tools.ietf.org/html/rfc2068>. Acessado em 20 de Fevereiro de 2011. RFC 2616. Hypertext Transfer Protocol - HTTP/1.1, 1999. Disponvel <http://tools.ietf.org/html/rfc2616>. Acessado em 20 de Fevereiro de 2011. RFC 4287. The Atom Syndication Format, 2005. Disponvel <http://tools.ietf.org/html/rfc4287>. Acessado em 19 de Fevereiro de 2011. em
RFC 4944. Transmission of IPv6 Packets over IEEE 802.15.4 Networks, IETF 2007. Disponvel em <http://tools.ietf.org/html/rfc4944>. Acessado em 10 de Maro de 2011. RFC 5785. Defining Well-Known Uniform Resource Identifiers (URIs), 2010. Disponvel em <http://tools.ietf.org/html/rfc5785>. Acessado em 20 de Fevereiro de 2011. Richardson L.; Ruby, S. RESTful Web Services. OReilly Media, 2008, cap. 4, p. 79105. Sandoval, J. RESTful Java Web Services, Master core REST concepts and create RESTful web services in Java. Packt Publishing BIRMINGHAM MUMBAI 2009, p. 20-81. Shelby, Z. Embedded web services. Em Wireless Communications, IEEE , Volume 17, p. 52-57. 2010.
Sun SPOT World, Disponvel em: <http://www.sunspotworld.com/>. Acessado em 06 de Dezembro de 2010. Tan, L.; Wang, N. Future Internet: The Internet of Things, em Advanced Computer Theory and Engineering (ICACTE), 2010 3rd International Conference, vol. 5, p. 376-380. Trifa, V.; Wiel S.; Guinard, D.; Bohnert, T. Design and implementation of a gateway for web-based interaction and management of embedded devices, 2009. Disponvel em: <http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.155.4806>. Acessado em 15 de Fevereiro de 2011. Tyagi, S. RESTful Web Services. Oracle, 2006. Disponvel em <http://www.oracle.com/technetwork/articles/javase/index-137171.html>. Acessado em 3 de Maro de 2011. Webber, J.; Parastidis, S.; Robinson, I. REST in Practice, Hypermedia and Systems Architecture. OReilly, 2010, p. 86-95; 386-387. Wilde, E. Putting Things to REST, 2007. Disponvel em <http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.96.7936>. Acessado em 15 de Fevereiro de 2011.
150
Wilde, E.; Guinard, D.; e Trifa, V. Architecting a Mashable Open World Wide Web of Things, Institute for Pervasive Computing, ETH Zrich, Zrich, Switzerland, No. 663, February 2010 WSDL. Web Service Description Language, W3C, 2007. Disponvel <http://www.w3.org/TR/wsdl20/>. Acessado em 15 de maro de 2011. em
Yongjia, H. The Plan of Elderly Smart Community: Based on the Concept of Internet of Things, 2010.Em Management and Service Science (MASS), 2010 International Conference, p. 1-4. Yun, M.; Yuxin, B. Research on the architecture and key technology of Internet of Things (IoT) applied on smart grid, em Advances in Energy Engineering (ICAEE), 2010 International Conference, p. 69-72.
Captulo
4
Gerncia de Identidade na Internet do Futuro
Michele Nogueira, Aldri Santos, Jenny Torres, Angelita Zanella, Yuri Danielewicz
Abstract The Internet as a platform for ubiquitous communication has quickly advanced in the last years. New services have emphasized the limits of the current Internet and motivated the development of the Future Internet. New network architectures are more complex, more distributed and, ideally, more secure. However, as new technologies emerge, new requirements and security issues are highlighted. These issues emphasize the importance of identity management systems for the Future Internet in order to provide adequate dynamic services in relation to users personal data and requirements. Therefore, this short course presents the state of the art of Identity Management Systems on Future Internet, particularly on Next Generation Networks (NGN), highlighting the challenges, encryption methods used, specic devices applied, proposed architectures and future perspectives. Resumo A Internet como uma plataforma de comunicao ubqua tem evoludo rapidamente nos ltimos anos. Cada vez mais, os servios esto migrando para uma rede totalmente IP, enfatizando os limites da Internet atual e motivando a construo da Internet do Futuro. As novas arquiteturas de rede so mais complexas, mais distribudas e, idealmente, mais seguras. No entanto, como novas tecnologias tambm surgem, novos requisitos e preocupaes com segurana so ressaltados. Desta forma, a Internet do Futuro destaca a importncia da gerncia de identidade dos usurios nais em relao ao fornecimento e utilizao dos seus dados pessoais e a necessidade de acesso a uma arquitetura de servios dinmicos. Este minicurso apresenta uma viso geral sobre o estado da arte em pesquisas relacionadas ao gerenciamento de identidades na Internet do Futuro, particularmente nas redes da prxima gerao, enfatizando os desaos, os mtodos de criptograa utilizados, os dispositivos especcos, as arquiteturas propostas e perspectivas futuras.
152
4.1. Introduo
A Internet atual desempenha um papel fundamental na sociedade fornecendo intercmbio de informaes e ambiente de comunicao nas relaes comerciais e interaes sociais. Pessoas do mundo inteiro dependem hoje da Internet para manter o contato com a famlia e amigos, localizar, acessar e trocar informaes, desfrutando de comunicao multimdia e utilizando servios de software avanados. Com a popularizao da Internet, as expectativas aumentaram em relao s novas aplicaes e servios em diferentes reas, tais como sade, transporte automotivo e de emergncia. A grande utilizao da Internet atual tem demonstrado as suas restries e motivado o desenvolvimento da chamada Internet do Futuro. Uma das principais premissas para a Internet do Futuro a disponibilidade e ecincia de vrios servios e, acima de tudo, sua constante disponibilizao ao pblico [Paul et al. 2011]. A Internet do Futuro se diferencia da Internet existente pelo aumento da dependncia na informao distribuda, pelo controle descentralizado, e por avanos ditados pelo mercado e por regulamentaes, alm de uma forte exigncia de segurana [FOKUS 2009]. A Internet do Futuro caracterizada por quatro dimenses, ilustradas na Figura 4.1, sendo a Internet por e para as Pessoas, a Internet de Contedo, a Internet dos Servios e a Internet das Coisas, apoiadas por uma infraestrutura de rede, conhecida como Rede da Prxima Gerao [Chim et al. 2011, Gomez-Skarmeta et al. 2010, Weber et al. 2010].
Figura 4.1. Dimenses da Internet do Futuro e a infraestrutura de rede
Os conceitos e servios da Internet do Futuro possuem novas exigncias e produzem condies diferentes, tornando impossvel a utilizao direta de solues propostas para a Internet existente. A segurana um fator fundamental para a Internet do Futuro e para os seus servios por pretenderem ser universais e onipresentes. A heterogeneidade, dinamicidade, interdependncia e autonomia existentes entre os elementos da Internet do Futuro aumentam as vulnerabilidades de segurana e a diculdade de proteger a rede, os servios e as aplicaes contra entidades maliciosas. O gerenciamento de identidades tem atrado ateno nos ltimos anos como uma
153
forma eciente de prover conana entre as entidades da Internet do Futuro, e de proteger ou mitigar os efeitos de entidades maliciosas [Sabena et al. 2010, Sarma and Giro 2009]. O gerenciamento de identidade (do ingls, Identity Management ou IdM) identica as entidades, e controla o acesso a recursos por meio de restries impostas [Josang et al. 2005]. Existe um consenso entre os pesquisadores sobre o papel vital do gerenciamento de identidades em muitas aplicaes estratgicas, incluindo aquelas visionadas pela Internet do Futuro em diferentes contextos como entretenimento, sade, investigaes policiais, servios fornecidos pelo governo (governo eletrnico ou e-government), comrcio ubquo ou u-commerce, inteligncia empresarial e segurana corporativa. Em especco para as redes da prxima gerao, a gerncia de identidade desempenha um papel fundamental. Essas redes tm como base a transferncia de pacotes para prover servios, incluindo aqueles de telecomunicao, e para se beneciar de mltiplas tecnologias e infraestruturas de comunicao, sendo as funcionalidades relacionadas aos servios independentes das tecnologias subjacentes de transporte dos pacotes. Essas redes se caracterizam por uma forte separao entre as funes de controle relacionadas transmisso dos pacotes e ao provimento de servios. Elas tambm possuem acesso irrestrito de usurios a diferentes provedores de servios e uma variedade de sistemas de identicao para facilitar o controle da rede, alm de necessitarem apresentar caractersticas unicadas para um mesmo servio quando considerada a perspectiva do usurio. Para todas essas caractersticas, a gerncia de identidade pode auxiliar a rede tendo conhecimento do perl dos usurios, das caractersticas dos servios e das polticas de acesso, a m de prover os servios da forma mais eciente possvel aos usurios e garantindo a transparncia de operaes desempenhadas pela rede, como a garantia da qualidade de servio, a mobilidade, o uso de diferentes tecnologias e outras. Em face aos avanos e a importncia que o uso de identidades vem ganhando, a gerncia de identidades requer cada vez mais um suporte tecnolgico [Hansen et al. 2008]. Um sistema de gerncia de identidades (SGI) objetiva proporcionar assistncia tecnolgica para o controle e o monitoramento de identidades, entretanto, uma ferramenta holstica para todos os ns de gesto de identidade ainda inexistente. Os principais fatores que vm motivando e impulsionando o desenvolvimento de SGIs para a Internet do Futuro so descritos a seguir. Assistncia gerncia de vrias identidades digitais. Os usurios possuem atualmente muitas contas (identidades digitais), onde os dados de autenticao, tais como senhas ou PINs, tm de ser memorizados. Como o conceito de identicao universal e nico est longe de ser implementado, a quantidade de identidades digitais por pessoa tende a aumentar ainda mais no contexto da Internet do Futuro, quando uma maior quantidade de servios diferentes sero oferecidos. Os usurios precisam de apoio conveniente para gerir essas identidades e os correspondentes mtodos de autenticao. Auxlio na gerncia de informaes indesejadas ou na sobrecarga de informaes. Os usurios precisam de apoio prtico para situaes em que so abordados indesejadamente por outras pessoas ou at mesmo mquinas. A gesto de identidade pretende facilitar o uso inteligente dos contatos dos usurios por meio de mecanismos como o bloqueio de mensagens de spam.
154
Vulnerabilidades na garantia de autenticidade e o roubo de identidades. As redes de comunicao de hoje no garantem a autenticidade e facilitam o roubo de identidades. Os sistemas que suportam mtodos de autenticao, integridade e no repdio, tais como as assinaturas digitais, podem impedir o uso no autorizado despercebido de identidades digitais. No entanto, o uso eciente de sistemas de gerncia de identidades tambm pode assistir na preveno do uso no autorizado de identidades digitais. Falta de privacidade. Os usurios deixam rastros de dados usando redes de comunicao, sendo que a maioria dessas informaes gravada sem o seu conhecimento e sem qualquer possibilidade de evitar esses rastros, comprometendo a privacidade. Por meio de um sistema de gerenciamento de identidades, cada usurio pode controlar o quanto de suas informaes divulgado. O anonimato e pseudonimato so mtodos para controle e divulgao dessas informaes que esto em desenvolvimento e que so considerados em sistemas de gerncia de identidade atuais. Controle e o monitoramento de identidades nas redes da prxima gerao. Na perspectiva de infraestrutura de rede, o controle e o monitoramento de identidades auxilia no bom provimento de servios. Conhecer a identidade de entidades e consequentemente o perl dessas entidades, facilita a priorizao no transporte de pacotes, auxilia as operaes para garantir qualidade de servio (QoS), torna mais eciente a identicao de redes diferentes que compem a infraestrutura de rede e torna mais convel o controle de acesso. Entretanto, atualmente, diferentes arquiteturas de gerncia de identidade existem, requerendo uma unicao dos sistemas de controle e gerncia de identidades a m de garantir uma melhor ecincia das operaes da rede. Em geral, os sistemas de gerncia de identidade seguem trs paradigmas principais: o paradigma puro de identidade, o paradigma voltado ao acesso do usurio e o paradigma voltado a servios. O paradigma puro de identidade sugere a criao, a gesto e a supresso de identidades como operaes bsicas. O paradigma voltado ao acesso do usurio implica na autenticao para ter acesso a um servio. E o paradigma voltado ao servio personaliza a entrega de servios sob-demanda aos usurios e seus dispositivos. Esses paradigmas aplicam tcnicas e ferramentas adequadas para cada um deles. O uso de identidades digitais, biometria, cartes inteligentes e tcnicas de criptograa baseada em identidades so exemplos dessas tcnicas e ferramentas aplicadas [Josang et al. 2005]. Com base nessas consideraes, este minicurso apresenta uma viso geral sobre o estado da arte em pesquisas relacionadas ao gerenciamento de identidades na Internet do Futuro, com enfse no gerenciamento de identidades nas redes da prxima gerao. Este minicurso ressalta os desaos, os mtodos de criptograa utilizados, os dispositivos especcos, as arquiteturas propostas e as perspectivas futuras. Inicialmente, os conceitos de Internet do Futuro, de redes da prxima gerao e de sistema de gerenciamento de identidade so descritos. Em seguida, o minicurso est fundamentado sobre as redes da prxima gerao, ressaltando os requisitos de um sistema de gerncia de identidade para Internet do Futuro, o estado da arte das arquiteturas de gerncia de identidade, os desaos existentes e as perspectivas futuras. O minicurso ser concludo com a descrio das
155
principais ferramentas de gerncia de identidade e uma apresentao prtica sobre o uso de sistemas de cartes inteligentes multiaplicaes empregados para gerenciar e unicar identidades digitais, enfatizando as diculdades em utiliz-los e os problemas atuais.
4.2. Internet do Futuro

Nos ltimos anos, o termo Internet do Futuro tem despertado bastante interesse. Esse interesse vem se intensicando com o aumento de nanciamentos oriundos de organizaes comerciais, acadmicas e governamentais para a execuo de projetos de pesquisa e desenvolvimento. No h, entretanto, uma viso uniforme sobre o que a Internet do Futuro ser, nem existe um acordo sobre quais so os objetivos das diversas atividades concorrentes da Internet do Futuro. Embora muitas discusses neste contexto tenham como foco os aspectos tcnicos (por exemplo, questes relacionadas a como o endereamento ou o roteamento devem ser feitos na Internet do Futuro), um consenso nas discusses sobre a Internet do Futuro a perspectiva voltada a servios. Dessa forma, nesta seo a Internet do Futuro ser abordada sob uma perspectiva menos orientada a protocolo e mais orientada a servios. Para a maioria dos usurios, a Internet denida como um conjunto de servios. A maioria das pessoas associam a Internet com o fcil acesso informao e motores de pesquisa, a disponibilidade de vdeos, msicas ou servios de entretenimento e o acesso on-line a plataformas de negociao, servios de comunicao pessoal ou plataformas de redes sociais, visto que a maioria dos usurios da Internet no esto cientes da importncia da rede subjacente, ou seja, da infraestrutura de rede propriamente dita. Entretanto, entender como os usurios utilizaro a Internet do Futuro e a relao dos servios com as redes de comunicao subjacentes so primordiais para identicar os requisitos que a infraestrutura de rede deve apoiar. Primeiro, importante salientar que os servios da Internet do Futuro esto sendo construdos com base nas seguintes tecnologias: Acesso ubquo e de boa qualidade rede: Com a disponibilidade de redes pticas de alta qualidade e o aumento da largura de banda e da qualidade das redes sem o, assume-se que a conectividade ser cada vez mais onipresente e barata. Na verdade, assume-se que o acesso rede ser to difundido quanto o acesso atual eletricidade. Novas tcnicas da interao homem-computador: a disponibilidade da tecnologia de sensores compacta e barata e as novas tecnologias de visualizao revolucionaro a forma como se interage com os computadores. A interao com computadores atravs de gestos e visores embutidos nos objetos do cotidiano ir mudar a forma como se utiliza os computadores. Inovaes signicativas so esperadas nesta rea, como novas tcnicas de interao homem-computador para ajudar a distinguir produtos. Sensores e a disponibilidade de contexto rico em informaes: a tecnologia de sensores est permitindo novas formas de interao homem-mquina, como tambm novas aplicaes. Espera-se que os sensores sejam integrados em muitos produtos de uso dirio, dando acesso a informaes contextuais. O acesso ubquo aos dados fornecidos por sensores favorecer o desenvolvimento de novas aplicaes e servios.
156
Contedos e servios gerados pelo usurio (mashups): as tecnologias que permitem o fcil gerenciamento de contedos e servios gerados pelo usurio esto se desenvolvendo rapidamente. Estima-se que o prximo grande passo seja o desenvolvimento de tecnologias de mashup, permitindo que os usurios combinem facilmente contedos e servios existentes para fornecer novos formatos e servios integrados [Benslimane et al. 2008]. As tecnologias de Web semntica tm um grande potencial para fomentar o avano da tecnologia mashup, uma vez que elas tm evoludo a cada dia e tornam-se maduras e acessveis o suciente para o uso por uma grande quantidade de usurios.
Tendo como referncia o comportamento da maioria dos usurios da Internet, acredita-se que alguns avanos iro moldar a evoluo da Internet do Futuro. Dentre esses avanos, destacam-se os servios personalizados. Comeando com resultados de buscas personalizadas e sensveis ao contexto, considera-se que haver um nmero cada vez maior de produes da mdia direcionadas a grupos de interesse especiais, e servios de entretenimento que adaptam a msica preferida ou o estilo do lme ao humor dos usurios [Aldun et al. 2011, Chai et al. 2011, Choi et al. 2011]. Fortemente relacionadas com os servios personalizados esto as redes sociais, que associam usurios com interesses comuns. Elas representam digitalmente as relaes pessoais e fornecem uma referncia importante para as questes de identidade e de conana na Internet. Estima-se ainda que as redes sociais se tornaro mveis e cientes do contexto no futuro prximo. Outros avanos que devero auxiliar na denio da Internet do Futuro so a privacidade e o anonimato. Essas duas questes vm se tornando cada vez mais importantes para os usurios da Internet [Maghiros et al. 2006]. Apesar da conscincia para essas duas questes ainda ser pouco desenvolvida no contexto atual dos utilizadores da Internet, os primeiros sinais de mudana j so observados. Hoje, existe um mercado especializado de empresas que oferecem servios de privacidade na Internet para pessoas famosas, e espera-se que a sensibilidade dos usurios da Internet para as preocupaes ligadas privacidade e ao anonimato tambm aumente. Alm desses avanos, a era dos computadores pessoais instalados com um grande nmero de aplicaes est chegando ao m. No futuro, a tendncia ver muitos clientes usando a rede para prover desde o armazenamento de dados at o uso de aplicativos, os quais sero fornecidos como servios. Isso auxiliar os usurios a lidar melhor com atividades assessrias, como backups e atualizaes de software. Alm disso, o poder de computao pode ser acessado quando necessrio, atravs de servidores dedicados organizados em rede (por vezes, chamados de computao em nuvem [Li et al. 2009, Zhou et al. 2010]), reduzindo assim os custos de manuteno do sistema. Outras questes, como robustez, disponibilidade, conabilidade e segurana, sero de grande preocupao para os usurios da Internet uma vez que eles dependero cada vez mais desses servios [Heegaard and Trivedi 2009]. A Internet do Futuro precisa ser tratada como uma infraestrutura crtica semelhante s redes de energia ou fontes de gua fresca. No entanto, os meios para alcanar um elevado nvel de robustez na Internet do Futuro ser muito diferente comparado ao uso de estruturas de controle hierrquicas. A robustez na Internet do Futuro tende a ser alcanada usando abordagens distribudas.
157
4.2.1. Exemplos de servios da Internet do Futuro Espera-se que um grande nmero de novos servios sejam criados com o advento da Internet do Futuro. Essa subseo apresenta exemplos de servios da Internet do Futuro como forma de mostrar a importncia na evoluo da mesma e a necessidade de garantir um controle e monitoramento de identidades eciente e seguro. Essa subseo oferece uma viso geral dos novos servios, enfatizando que todos eles tm como suporte a infraestrutura de rede subjacente apresentada na subseo 4.2.2. Garantias de armazenamento distribudo At recentemente, o armazenamento de dados era realizado em mdias como discos rgidos ou DVDs e era considerado como armazenamento centralizado. Esse modelo de armazenamento possui vrias desvantagens. A informao, por exemplo, no est disponvel em todos os lugares, verses antigas dos arquivos geralmente no so arquivadas e os meios fsicos tm vida til limitada. Como muitos usurios de computadores pessoais no fazem backups regulares, existe um risco elevado de perda de dados de alto valor pessoal como fotos de frias, gravaes de udio ou vdeos pessoais. No futuro, estima-se que os dados pessoais iro ser armazenados em redes de armazenamento distribudo. Os servios de armazenamento iro oferecer virtualmente uma quantidade ilimitada de memria, e iro manter um histrico de todas as alteraes nos arquivos do usurio, alm de tornar os dados acessveis em qualquer lugar para uma ampla quantidade de dispositivos diferentes. Eles iro ainda prestar servios de privacidade, e oferecero garantias de armazenamento, atravs de um certo nmero de cpias redundantes, por exemplo. Vrios prottipos de servios de armazenamento totalmente distribudo j existem. Eles tm como base tecnologias par-a-par. Entretanto, esses prottipos normalmente no possuem algumas das caractersticas mencionadas como a privacidade e a disponibilizao dos dados a qualquer momento, em qualquer lugar e a qualquer dispositivo. Alm disso, a capacidade de armazenamento disponibilizada geralmente limitada. Os sistemas muitas vezes supem que os dispositivos de armazenamento cooperativos esto localizados em computadores tradicionais, e por isso no possuem interfaces que permitam a interao direta com dispositivos como cmeras, telas sensveis ao toque incorporadas aos dispositivos mveis ou roupas inteligentes. Armazenamento da vida cotidiana atravs de multimdia Com o armazenamento em rede tornando-se bastante disponvel e com a miniaturizao de microfones e cmeras, ser cada vez mais comum para as pessoas a gravao de grande parte dos acontecimentos de sua vida. Hoje, j existem pessoas carregando sempre uma cmera e registrando tudo o que vem. No entanto, esta tecnologia tem muito mais potencial. Os dados recolhidos por microtelefones e cmeras podem ser combinados com informaes provenientes do prprio uso de outros dispositivos tcnicos, como carros ou motos, e de sensores incorporados em objetos do quotidiano. Tal comportamento, ajudar a prover servios inovadores aos usurios, como buscas personalizadas e ecientes, assim como assistir o gerenciamento da infraestrutura de rede contribuindo para a qualidade dos servios. Atualmente, existem grupos de pes-
158
quisa que investigam os efeitos de comportamentos sociais nos servios fornecidos pela Internet [Benevenuto et al. 2009, Boccaletti et al. 2006]. Tambm existem iniciativas que aplicam o conhecimento adquirido na caracterizao do comportamento dos usurios desenvolvendo solues para gerncia de redes orientada ao contexto e ao comportamento dos usurios [Boldrini et al. 2010, Hui et al. 2011, Li and Sandrasegaran 2005]. Entretanto, os principais desaos existentes nessa abordagem so a integrao de vrias fontes de dados e a indexao automatizada para a sustentao da recuperao eciente da informao relevante. Por razes bvias, a proteo de privacidade ecaz deve ser implementada em solues que seguem essa abordagem. Servios de sade Os servios mdicos fornecidos por prossionais vm sofrendo grandes modicaes. A disponibilidade de dispositivos baratos de monitoramento em rede da sade e os avanos nos sensores embarcados em todos os objetos do dia-a-dia dar aos mdicos detalhes sobre nossos corpos. Pessoas com riscos especiais providenciaro acesso direto aos dados sobre as funcionalidades essenciais de seus corpos, alm de se visionar a disponibilizao de servios de monitoramento do corpo on-line, facilitando uma assistncia rpida em caso de emergncia. Com a disponibilidade de maiores quantidades de dados mdicos, haver uma tendncia da personalizao da medicina. A medicina personalizada comea com a seleo de combinaes de frmacos otimizados para uma condio especca do paciente, oferecendo a oportunidade de produzir medicamentos personalizados, combinando produtos qumicos de maneiras especcas para otimizar os efeitos positivos para o paciente, reduzindo assim os efeitos colaterais indesejados. No contexto dos servios de sade, pode-se tambm vislumbrar novas formas de diagnstico on-line. Perguntas como "Estou grvida?"poderiam ser respondidas por um sistema de busca semntica, permitindo que o sistema tenha acesso aos dados coletados por sensores instalados no banheiro, por exemplo. Muitas tarefas de diagnstico padro podem ser potencialmente oferecidas como servios on-line conectados a mashups mdicos integrando fabricantes farmacuticos, comerciantes, comunidades on-line e sistemas de busca semntica especializados. Servio de entretenimento personalizado Com a Internet do Futuro, existe uma forte tendncia sobre a personalizao dos servios de entretenimento. As ofertas on-line de msicas, lmes ou jogos no levar apenas em conta as preferncias estticas em relao aos diferentes estilos de msica ou de tipos de jogos, mas tambm consideraro o contexto mais amplo, e em especial o humor, as habilidades e os interesses dos usurios. As estaes de rdio on-line proporcionaro a msica que melhor corresponda s atividades atuais. Dependendo se o usurio est cozinhando ou limpando a cozinha, ele receber diferentes estilos de msicas e as msicas tocadas podem at ser selecionadas com base no tempo disponvel para a realizao da atividade. Em geral, esperado um crescimento da interao entre os objetos do mundo real e os objetos que s existem em mundos virtuais. As chamadas interfaces de realidade
159
mista permitiro novas formas de participar de jogos multiparticipantes on-line. Os jogos multiparticipantes j so utilizados por milhes de usurios, e os nmeros ainda tendem a crescer. Nestes jogos a interao social fundamental, pois os jogadores formam grupos a m de resolver problemas juntos. Com a integrao da realidade virtual e o mundo real, os grupos formados e a interao entre os participantes levam a novas experincias e informaes que podem inclusive serem utilizadas para um gerenciamento eciente da infraestrutura de rede. 4.2.2. Redes da prxima gerao As redes da prxima gerao, do ingls Next Generation Networks ou NGN, so visionadas como uma resposta aos operadores e fornecedores de redes e servios a m de substituir as redes de telefonia existentes, bem como introduzir uma nova plataforma de servios convergentes entre as redes xas e as redes mveis [Akyildiz et al. 2006, Park and Rappaport 2007, Prasad et al. 2008, Song and Jamalipour 2005]. geralmente um consenso que a principal diferena entre as redes de telecomunicaes tradicionais e as redes da prxima gerao seja a mudana de um paradigma de redes de comunicao voltadas a aplicaes especcas, separadas e verticalmente integradas para um paradigma de uma nica rede capaz de executar qualquer servio. A NGN est essencialmente relacionada ao fornecimento de novos servios que sero disponibilizados de forma pervasiva e ubqua, ou seja, em qualquer lugar, a qualquer hora e em qualquer dispositivo, atravs de qualquer meio de acesso escolhido pelo cliente. Espera-se das redes da prxima gerao uma coexistncia e intercomunicao entre as redes com o (xDSL, Metro Ethernet, FTTH, ISDN e outras), as redes sem o (2G, 3G, WLAN, WiMAX/WiBro e outras), bem como as redes por satlites e as redes de radiodifuso, todas interligadas por um backbone de redes que utilizam o protocolo IP (Internet Protocol) e pela Internet. Neste ambiente de rede heterogneo, alm dos desaos tradicionais com segurana, QoS (Quality of Service) e tarifao, os novos desaos como mobilidade generalizada, descoberta e seleo de rede devem existir [Song and Jamalipour 2005]. Fornecer uma gerncia ecaz, segura e eciente do ambiente e da operao das redes da prxima gerao um enorme desao. Esta subseo apresenta um breve panorama das redes da prxima gerao tendo como base a denio e arquitetura funcional usada pela ITU-T (International Telecommunication Union, Standadization Sector) [ITU-T 2004]. Uma NGN uma rede baseada em pacotes de suporte transferncia de diferentes tipos de trfego, como voz, vdeo e dados [Sakellari p053]. A Figura 4.2 apresenta uma viso geral da arquitetura funcional da NGN [ITU-T 2004]. Essa rede espera integrar os servios oferecidos pelas redes tradicionais e os inovadores servios IP em uma nica plataforma de servios, sendo que essa integrao deve ser mais transparente possvel para o usurio nal [Salsano et al. 2008]. A NGN faz uma forte distino lgica e fsica entre a rede de servios, a rede de transporte de dados (tambm chamada de rede de base ou ncleo da NGN) e a rede de acesso. A rede de servios possui funcionalidades relacionadas aos servios, independentes das tecnologias de transporte subjacentes. As funcionalidades da rede de servios se concernem s aplicaes e aos servios oferecidos s entidades. A rede de transporte de dados consiste dos equipamentos de roteamento de pacotes (roteadores, switches e gateways) e das funcionalidades voltadas ao transporte
160
Figura 4.2. Arquitetura funcional das redes da prxima gerao
de dados oferecendo transferncia fsica de informaes entre as entidades envolvidas no processo de comunicao (como os usurios, os computadores ou os dispositivos mveis). A rede de acesso composta pelas vrias tecnologias de acesso ao meio de comunicao existentes como as tecnologia de comunicao com o e sem o. A rede de servio composta por vrios servidores, tais como servidor Web, os servidores de Autenticao, Autorizao e Contabilidade, do ingls Authentication, Authorization and Accounting (AAA), o servidor SIP Proxy, o servidor LDAP, entre outros. Ela responsvel apenas pelo fornecimento dos servios e das aplicaes para os usurios da NGN. A conexo entre a rede de servios e a rede de transporte de dados pode ser implementada por meio de gateways. A rede de transporte de dados em uma NGN representa a espinha dorsal do transporte tal como existe nas redes tradicionais. Ela se preocupa com a transferncia de informaes entre as entidades pares e deve suportar os diferentes servios oferecidos pela rede de servios. Alm da transferncia de pacotes, as funcionalidades voltadas ao controle e gerenciamento da infraestrutura de rede tambm so implementadas na rede de base [Choi and Hong 2007, Kim and Shin 2008]. A rede de base tambm responsvel por tornar transparente para os usurios e servios a convergncia de redes e tecnologias. A rede de acesso em NGN derivada das tecnologias de acesso existentes. Para acomodar vrios meios de acesso, esta rede separada da rede de base, servindo como um
161
nvel intermedirio entre os equipamentos dos usurios e o ncleo da rede da prxima gerao. Cada tecnologia de acesso dever ser usada tal como foi previamente especicada. Dessa forma, a rede de acesso consiste na prtica de um conjunto de redes diferentes tais como redes sem o ad hoc, redes de comunicao por satlite, redes cabeadas e outras. A arquitetura das redes da prxima gerao precisa oferecer uma exibilidade de congurao para suportar vrias tecnologias de acesso. Ela precisa tambm de um apoio distribudo e de mecanismos de controle e de gerncia de identidade abertos. Estes devem proporcionar uma separao e identicao nos servios oferecidos pela operao da rede de transporte e melhorar a oferta de servios diversicados da NGN. As funcionalidades voltadas gerncia de rede permitem ao operador da NGN controlar a rede e prover os servios da NGN com a qualidade, segurana e conabilidade esperadas. As funcionalidades de gerncia so aplicveis s redes de transporte e de servios da NGN, e cobrem as reas de gerncia de falhas, congurao, contabilizao, desempenho e segurana. As funes de usurio nal so formadas por interfaces que permitem ao usurio se conectar rede de acesso da NGN, por meio de equipamentos mveis ou xos.
4.3. Gerncia de Identidade

Desde o incio de sua histria, o ser humano sente a necessidade de estabelecer relaes comerciais. Os povos primitivos j utilizavam o comrcio, na forma de escambo, atravs do qual trocavam os alimentos que possuam em excesso por outros de que necessitavam. Ao longo da histria, as relaes comerciais passaram por profundas mudanas, que possibilitaram a evoluo dessas relaes e a criao de novas oportunidades. O desenvolvimento da Internet gerou uma revoluo nas relaes comerciais, aproximando pessoas e criando novas necessidades de produtos e servios. Com o surgimento do mundo virtual, novas ferramentas foram desenvolvidas, o que gerou mudanas na forma de relacionamento e nos conceitos envolvidos nas transaes. Para que as relaes comerciais sejam estabelecidas, necessrio que as partes envolvidas possuam algum nvel de conhecimento sobre a outra parte. Conhecer a outra parte importante para saber que nvel de conana pode ser depositado nela e se ela idnea, pressupondo assim, se ir cumprir ou no a sua parte na transao. Nas relaes tradicionais, em que h algum tipo de contato direto entre as partes, a troca de informaes ocorre de forma natural. At mesmo a impresso causada pelo contato entre as partes pode inuenciar no estabelecimento de conana entre elas. Nos novos servios fornecidos pelas redes da prxima gerao, assim como nos servios virtuais em geral, ainda mais importante conhecer a outra parte envolvida na comunicao ou nas transaes. No contexto do mundo virtual, a resposta para perguntas relacionadas ao parceiro comercial ou provedor de servios envolvem conceitos sobre entidade, identidade, identicador e credencial. Conhecer esses conceitos importante para compreender como acontecem as operaes de autenticao e autorizao, e como elas podem ser aplicadas no provimento de servios da Internet do Futuro. Para que uma transao acontea, necessrio que haja algum nvel de conana entre as partes. Quando essa conana no pode ser estabelecida diretamente, neces-
162
sria a interao por meio de um intermedirio convel para ambas as partes (tambm chamado de terceira parte), como demonstrado na Figura 4.3. Nas relaes comerciais tradicionais, o papel do intermedirio feito por um ador em uma locao, por exemplo, ou por uma instituio nanceira nos casos de compra com cheque ou carto de crdito. No mundo virtual, muitos negcios so feitos sem o contato direto entre as partes. Neste caso, para que as relaes de conana sejam estabelecidas, importante o envolvimento de uma terceira parte. Esta terceira parte responsvel por fornecer informaes sobre o parceiro, dando origem ao conceito de identicao.
Figura 4.3. Relao comercial envolvendo um intermedirio
As identidades das partes envolvidas na transao so controladas e monitoradas por sistemas de gerncia de identidade (SGIs). Estes so programas ou frameworks que administram uma coleo de identidades, realizam sua autenticao, gerenciam seu uso e as informaes vinculadas identidade [Maliki and Seigneur 2007]. Os SGIs tradicionais so utilizados como mecanismos de autenticao e autorizao, sendo esse primeiro mecanismo responsvel por estabelecer a conana entre o sistema e a identidade informada, e o segundo responsvel por fornecer identidade permisses para realizar determinadas aes no sistema. Alm disso, os sistemas tradicionais criam pers relacionados s identidades e armazenam informaes sobre o seu uso. No entanto, novos modelos tm sido propostos, alguns otimizados para atender aos objetivos do usurio, outros otimizados para tratar de questes relacionadas infraestrutura de redes ou requisitos das aplicaes e servios. Essa mudana de paradigma necessria para atender s novas caractersticas resultantes da NGN. 4.3.1. Entidade, identidade e credencial Considerando a importncia da identicao, esta subseo descreve os conceitos envolvidos no processo de identicao, tais como entidades, identidades, identicadores e credenciais. Sistema um conjunto de software e hardware que armazena informaes sobre entidades, credenciais, identidades e processamento das operaes relacionadas aos seus ciclos de vida. Pode ser uma rede de servios armazenando informaes sobre seus clientes, por exemplo. Um sistema geralmente protege seus dados ou servios e, portanto, utiliza autenticao e autorizao. Entidade pode ser um pessoa, um servio de rede, um dispositivo computacional em rede ou um dispositivo de telefonia mvel. As entidades existem no mundo
163
real. Elas usam credenciais e possuem um ciclo de vida separado do ciclo de vida de qualquer identidade, identicador ou credencial associada. Identidade um instrumento utilizado por uma entidade para fornecer informaes sobre si para o sistema. Ao contrrio da entidade, a identidade um conceito virtual e no existe no mundo real. Uma identidade sempre est associada a uma entidade e geralmente formada por um identicador nico. O identicador utilizado para provar a propriedade da identidade (por meio de credenciais) e fornecer informaes (perl) a um sistema. O sistema ir utilizar essas informaes para tomar decises sobre a entidade associada. Uma entidade pode ter vrias identidades, usando identidades diferentes para acessar sistemas diversos, a menos que esses sistemas se comuniquem e troquem informaes sobre as entidades. Identidades diferentes tambm podem ser utilizadas para acessar um nico sistema, quando a entidade o utiliza para ns diferentes. Por exemplo, um usurio pode ter uma identidade de usurio comum e outra como um contador da empresa. Identicador o ndice nico de uma identidade. Normalmente, um identicador usado pelo sistema para referenciar uma identidade. Deve ser exclusivo dentro de um sistema, mas pode ser reutilizado em vrios sistemas. Credencial utilizada para provar uma identidade em um sistema. Podem haver vrios tipos de credenciais, mas todas so utilizadas para provar a um sistema (com um nvel aceitvel de segurana) que uma entidade tem realmente o direito de usar determinada identidade. Algumas credenciais so estabelecidas entre a entidade e o sistema (como uma senha) e algumas so emitidas por uma terceira parte (como um passaporte). A Figura 4.4 demonstra a relao entre entidade, identidade, identicador, credencial e sistema.
Figura 4.4. Relao entre entidade, identidade, identicador e credencial
Os conceitos de identicadores e credenciais podem parecer confusos e em alguns, casos at podemos usar um no lugar do outro. A principal diferena entre identicadores e credenciais o fato de que um identicador deve necessariamente ser nico e a credencial no. Apesar de ser nico, o identicador pode ser a unio de outros itens no nicos.
164
As credenciais podem ser geradas automaticamente pelo sistema (como as senhas temporrias geradas pelo sistema quando um usurio a esquece) ou podem ser criadas a partir de caractersticas particulares, como as caractersticas biomtricas, por exemplo. Podem ser utilizados tambm mtodos hbridos, ou seja, mtodos que utilizam tanto a criao manual de uma identidade quanto a sua gerao automtica. Os mtodos hbridos permitem ao usurio escolher seu identicador e, caso este j esteja em uso, o sistema oferece identicadores alternativos. Uma viso sobre algumas possveis fontes e tipos de informao so mostradas na Figura 4.5.
1 e apenas 1 por sistema 0 ou mais
Informaes Pessoais
Itens Pblicos
Nome Sobrenome Data de nascimento Chave pblica PKI Assinatura Fotografia da face
Itens Privados
Chave Privada PKI Senhas PINs
Biometria
Impresso digital Scan da ris e retina Assinatura manuscrita Imagem da face
Gerados pelo Sistema

Nmero de Passaporte Nmero de Identidade Nmero de CPF
Identificador
Credenciais
Figura 4.5. Fontes de informao
Para que uma entidade consiga acessar o sistema, primeiramente ela informa o seu identicador. Isso necessrio para informar ao sistema quem est solicitando o acesso. O prximo passo fornecer provas de que essa entidade tem permisso para usar esse identicador, o que feito informando a credencial. Uma vez concedido o acesso, o sistema ir conceder alguns privilgios para que a entidade possa efetuar determinadas aes. Essa concesso de privilgios chamada de autorizao. Dentro deste contexto, h tambm o conceito de auditoria, que um registro do que aconteceu e quando aconteceu. A m de complementar os procedimentos descritos previamente, o sistema realiza um conjunto de registros, associando a entidade s suas aes. O ideal que os registros sejam comprobatrios, fornecendo informaes que possam ser utilizadas em caso de conitos. Esse conjunto de procedimentos descritos no pargrafo anterior descreve as quatro principais operaes de um SGI, a identicao, a autenticao, a autorizao e a auditoria. Um resumo desses procedimentos so descritos a seguir. Identicao a ao de uma entidade fornecer uma identidade ao sistema por meio de um identicador; Autenticao a ao do sistema vericar a legitimidade de uma identidade por meio da vericao de credenciais;
165
Autorizao a ao do sistema conceder privilgios a uma entidade aps a autenticao da sua identidade; Auditoria a ao de registrar as aes realizadas por uma entidade em um sistema, gerando uma prova tanto para as partes envolvidas quanto para terceiros. Detalhes sobre credenciais As credenciais podem existir em duas formas: privada e pblica. Uma credencial privada usada pela entidade para provar sua identidade, enquanto a credencial pblica usada pelo sistema para validar a anterior. Assim, uma credencial pode existir em pares: Credencial Privada qualquer informao usada pela entidade para informar quem ou o que . Pode ser secreta (como senha, PIN, chave secreta), elementos fsicos (token, carto corporativo, carto bancrio), ou caractersticas fsicas (biomtricas, como face, impresso digital). Credencial Pblica a contrapartida da credencial privada, utilizada para vericar se a credencial privada vlida. Por exemplo, uma fotograa uma credencial de vericao da face de uma pessoa (uma credencial biomtrica utilizada como uma credencial privada). Outros exemplos de credencial pblica so a assinatura, o hash de uma senha (verica se a senha informada gera o mesmo hash) ou uma chave pblica criptogrca, sendo a chave pblica uma reproduo matemtica da chave privada criptogrca. As credenciais so associadas a uma identidade especca, o que requer a criao de um vnculo entre a credencial e a identidade. Esses vnculos so criados a partir de mecanismos que geram uma associao entre partes de informaes. Um sistema pode acessar uma base de dados atravs de um vnculo ou de outro mecanismo sugerido pela entidade. Os vnculos de informaes podem ser criados pelo prprio sistema ou por uma terceira parte. Exemplos de vnculos so informaes de uma base de dados ligando um usurio ao hash de sua senha, ou um certicado digital vinculado a uma chave pblica. Ou ainda, uma carteira de habilitao, que vincula a assinatura ou fotograa ao nome, associando nome ao endereo ou nome permisso para dirigir. 4.3.2. Ciclo de Vida Assim como entidades, identidades e identicadores, as credenciais possuem um ciclo de vida bem denido. Esse ciclo dene o que acontece nas diversas fases da sua existncia. O ciclo de vida das entidades envolve os mesmos conceitos do ciclo de vida das pessoas: criao, vida e morte. O problema est em sincronizar esse ciclo de vida s suas identidades e credenciais, considerando os estgios intermedirios, pois podem haver regras especcas a serem aplicadas de acordo com a idade, como votar aos 16 anos e dirigir aos 18. As entidades tambm podem ser mquinas ou telefones celulares. Neste caso, a credencial criada quando o equipamento produzido e ativada aps a compra. preciso ter cuidado tambm com dispositivos compostos, por exemplo, deve-se denir se o telefone
166
o aparelho celular ou apenas o carto SIM (Subscriber Identity Module ou mdulo de identicao do assinante). Na verdade cada um tem sua prpria identidade, e podem ser rastreados individualmente ou ser adicionados a uma lista negra. As identidades so associadas s entidades. O estgio de criao geralmente marcado pelo seu registro no sistema. J o estgio de morte no pode ser um simples m, uma vez que os registros podem precisar ser guardados depois que a conta for cancelada. O perodo de vida pode incluir atualizaes da credencial e suspenses, por exemplo. As identidades podem ser suprimidas mesmo que a entidade associada ainda viva. Uma pessoa pode encerrar uma conta no banco, por exemplo, ou pode continuar mesmo que a entidade tenha sido extinta, a m de manter os registros. J um identicador um ponteiro nico para uma identidade e geralmente possui o mesmo ciclo de vida da identidade associada. No entanto, os identicadores podem ser retidos indenidamente, para garantir que no sejam realocados, o que poderia causar confuso ou permitir fraudes posteriormente. Frequentemente as credenciais e os vnculos tm seus prprios ciclos de vida, separados do ciclo de vida da entidade/identidade associada. As senhas podem existir apenas por 90 dias e geralmente so vlidas por menos de 10 anos. Criao As credenciais e os vnculos so emitidos por provedores para as entidades, ou pelo menos acordado entre eles. Um provedor pode ser um sistema, quando emite credenciais para que os usurios possam ser autenticados, ou um intermedirio convel tanto para o sistema quanto para a entidade, a m de gerar um vnculo adequado para autenticao entre as duas partes. O vnculo pode incluir datas, para controlar o perodo de validade da credencial. A emisso da credencial pode ser solicitada pelo usurio ao solicitar um vnculo, como solicitao de um passaporte ou aquisio de um certicado digital, ou desencadeada por eventos do tipo registro de nascimento, ao chegar a uma certa idade, a conexo de um dispositivo rede, por exemplo. Vida Algumas vezes as credenciais e seus vnculos necessitam de manuteno, como alteraes regulares da senha, renovao dos certicados digitais, dos passaportes ou da carteira de habilitao. A renovao uma forma simplicada do processo completo de registro. As caractersticas dinmicas das credenciais permitem que seu valor conhecido mude durante a sua vida. As credenciais tambm podem ser suspensas. Isso similar revogao de um certicado digital, exceto pelo fato de que reversvel. Morte As credenciais podem morrer porque expiraram ou porque foram revogadas. Elas geralmente tm uma data de expirao denida e depois desse perodo no ser mais vlida.
167
Alguns sistemas podem exigir que uma credencial no expire, pelo menos durante um perodo. Por exemplo, o controle de imigrao pode insistir que um passaporte seja vlido por mais que seis meses a partir da data de entrada. As credenciais tambm podem ser canceladas precocemente, devido a algum problema, como a no existncia da entidade, a mudana nas circunstncias ou a credencial compromentida, esquecida ou descoberta por um fraudador. A maior diculdade com relao revogao e suspenso que a credencial em si no traz informaes sucientes sobre a sua validade, para isso necessrio utilizar recursos externos, tais como as listas de revogao para vericar sua validade. Se a origem tornar-se indisponvel ou apenas tiver informaes sobre as credenciais revogadas por um perodo de tempo, h uma grande probabilidade de que uma credencial seja ressuscitada. Neste caso ser impossvel resolver conitos relacionados a seu uso histrico. 4.3.3. Sigle Sign-On A autenticao nica, ou single sign-on, possibilitada devido aos benefcios que ela oferece aos usurios, como a convenincia de no terem que lembrar de diferentes dados de autenticao para mltiplos sistemas e devido aos diversos problemas que mltiplas autenticaes acarretam, como ter que redenir senhas dezenas de vezes. A autenticao nica vem sendo considerada como um bom mecanismo de autenticao para as redes NGN. Esse tipo de autenticao auxiliaria o controle de acesso aos diferentes tipos de rede e ao ambiente heterogneo resultante da NGN. Alm disso, a autenticao nica parece promissora em relao aos possveis benefcios que ela traria para a Internet do Futuro como um todo, visto que diferentes servios sero disponibilizados e uma nica autenticao facilitaria o uso desses servios. A autenticao nica pode ser implementada de vrias formas. Uma soluo temporria armazenar informaes de logon do usurio para outros servios. Dessa forma, quando o usurio faz logon, ele ganha acesso a todos os servios adicionais. A vantagem disso que no necessrio acessar diretamente outros sistemas. Porm, isso pode violar polticas de segurana ou contratos. Uma alternativa integrar os servios protegidos com a soluo de autenticao nica, de modo que um logon fornea as credenciais que podem ser automaticamente armazenadas no cliente e informadas quando necessrio a outros servios. Exemplos disso so o padro Kerberos e o SiteMinder da Computer Associates. Todas as solues que usam autenticao nica, como as solues de e-mail (Gmail), armazenamento de arquivo (Google Docs), agenda e criao de pginas (Google sites) da Google, por exemplo, devem utilizar as mesmas credenciais (no caso, senhas) para todos os servios. Isso permite o uso de senhas mais seguras (desde que o sistema force o usurio a usar uma senha mais complexa), uma vez que o usurio dever lembrar apenas uma credencial. 4.3.4. Usurios, Provedores de Identidade e Provedores de Servios Como mostra a Figura 4.6, em um sistema de gerncia de identidade tpico, podemos identicar trs entidades envolvidas: os usurios, o provedor de identidade e os provedores de servios.
168
Usurio (U) uma entidade que utiliza um servio fornecido por um provedor de servios. Os usurios utilizam SGIs para acessar servios que exigem a certicao de seus atributos por uma terceira parte. Isso comum em acessos que envolvem a Internet, pois os usurios no conam na segurana da transmisso de dados. Quando uma informao sensvel, como o nmero do carto de crdito, informaes mdicas ou credenciais, so transmitidas para uma empresa desconhecida, o usurio hesita em usar a Internet. Portanto, a gerncia de identidade tem por objetivo aumentar a conana em processos que envolvem a Internet. Provedor de identidade (IdP) uma entidade que controla as credenciais do usurio e prov servios de autenticao. As companhias que fornecem algum grau de identicao, como as Autoridades Certicadoras, normalmente fornecem alguns servios que se enquadram na denio de SGI. Tais servios geralmente integram uma cadeia de segurana exigida por algum tipo de negcio on-line, como um servidor de autenticao ou criptograa SSL. Provedor de servios (PS) ou parte convel uma entidade que oferece um ou mais servios possveis de serem acessados pelos usurios e utiliza os servios de uma IdP para autenticar um usurio. Os motivos que levam os provedores de servios a implantar um SGI coincidem, em partes, com os motivos que levam os usurios a utiliz-lo. As organizaes tambm atribuem importncia s possibilidades de aumento de segurana. Alm disso, importante para ambas as partes ter certeza sobre a autenticidade do parceiro de comunicao. Especialmente quando se pode evitar fraudes utilizando este meio. A Figura 4.6 ilustra a interao entre essas trs entidades do sistema de gerncia de identidade. Na gura, o usurio solicita um servio a um provedor de servios. Este por sua vez cona em um provedor de identidades, que fornece informaes de autenticao sobre o usurio.
Figura 4.6. Partes de um sistema de gerncia de identidade
169
Regulamentos, tais como proteo da privacidade, devem ser respeitados por provedores de servios. Uma SGI pode ajudar a organizao a garantir e simplicar o cumprimento da legislao. Por inuenciar a quantidade e a qualidade dos dados transmitidos, a quantidade de informaes pessoais fornecidas pelo usurio deve ser reduzida, por meio do uso de pseudnimos e credenciais. Os pseudnimos so identicadores de entidade. Uma entidade titular do pseudnimo pode ser identicada por meio dele. Denomina-se pseudonimato o uso de pseudnimos como identicadores.
4.4. Requisitos de um Sistema de Gesto de Identidade na Internet do Futuro

Esta seo tem por objetivo denir os requisitos de SGIs que melhor satisfazem s necessidades da Internet do Futuro. Como mencionado anteriormente, segurana, privacidade e identidade so alguns dos maiores desaos do desenvolvimento da nova Internet. SGIs decientes podem agravar problemas de segurana j existentes e criar novas oportunidades para obter informaes pessoais de usurios [Dhamija and Dusseault 2008]. Especialistas tm indicado consistentemente privacidade, segurana e usabilidade como requisitos essenciais de um SGI [Glsser and Vajihollahi 2008].
Privacidade Privacidade um requisito importante em todos os contextos da Internet do Futuro para que haja compatibilidade legal. A Internet de servios assim como toda a infraestrutura de comunicao tm que cumprir leis e regulamentos relativos a direitos e privilgios dos usurios e provedores. Dessa forma, as preocupaes com a privacidade so o principal fator para adoo de sistemas de gerncia de identidade. Como a Internet do Futuro pode envolver a transferncia de informaes sensveis para diferentes partes, proteger a privacidade permite evitar que informaes pessoais dos usurios sejam usadas de forma indevida, causando a perda de autonomia e liberdade. Questes de privacidade Rastreamento de usurios entre domnios. Alguns SGIs tm a capacidade de rastrear um usurio em todos os stios web que ele visita. Para manter a privacidade, necessrio que o usurio permanea annimo ou use pseudnimos, para escolher IdPs que no integrem todas as transaes de todos os PSs e, nalmente, no auditem as aes do usurio. Muitos SGIs implementam partes dessa abordagem. No entanto, espera-se que no contexto da Internet do Futuro, SGIs devero implementar o mximo de anonimato e pseudonimato possvel em todas os nveis: rede de servio, rede de base e rede de acesso. Acesso s informaes sobre aes dos usurios. Nos SGIs atuais, o IdP envolvido sempre que uma operao de autenticao necessria em um provedor de servio. Dessa forma, o IdP pode guardar vestgios de todas as aes do usurio. Alm disso, em muitos sistemas, o usurio no envolvido em todas as trocas de informaes de identidade entre o IdP e o PS. Em novos SGIs, necessrio preservar a privacidade das aes dos usurios.
170
Proporcionalidade e subsidiariedade violadas com frequncia. Muitas das leis de privacidade tm como base o princpio da proporcionalidade e subsidiariedade. Esses princpios estabelecem que a quantidade de dados pessoais coletados seja proporcional ao objetivo para o qual eles so coletados, garantindo sempre a privacidade dos usurios. Muitas vezes os provedores de servios violam esses princpios. Esses provedores devem ser precisos com relao s informaes pessoais necessrias para oferecer um servio, e no devem solicitar mais informaes do que as necessrias. Torna-se dessa forma imprescindvel a utilizao de formas annimas para oferecer o mesmo servio. Segurana Um SGI deve ser to robusto quanto possvel em relao a ataques contra disponibilidade, integridade e condencialidade dos seus servios e informaes. Isso especialmente importante devido grande concentrao de informaes do usurio que so armazenadas e detalhadas. Todavia, h sempre o risco de espionagem, manipulao e roubo de identidade. Se algum est usando uma identidade estrangeira sem autorizao, pode ser difcil ou at impossvel para a pessoa autorizada provar que no era ela quem estava agindo. Fraude digital no facilmente detectvel pelo parceiro contratual. No apenas a identidade que est sendo capturada, mas tambm a reputao ligada identidade. Um SGI deve prevenir o roubo de reputao to bem quanto deve prevenir o plgio e permitir o no-repdio, se necessrio. Um requisito bsico para segurana que a autenticao seja exigida antes de todo acesso a dados que seja disponibilizado para as pessoas autorizadas. A forma de autenticao depende do tipo de dado e da ao efetuada. O tipo e grau de segurana exigido depende do signicado e do valor dos dados processados. Quando h apenas a coleta de informaes, como em uma navegao na web, a segurana pode no ser to importante como quando uma pessoa administra seu histrico mdico. Devido a quantidade de informaes de identidade armazenadas e administradas por organizaes, a segurana tambm um requisito essencial para o PS. Os frameworks de SGIs atuais implementam tcnicas, mtodos e polticas para a segurana de informaes de identidades. No entanto, ainda existem vrias vulnerabilidades [Alpr et al. 2011] como as descritas a seguir. Questes de Segurana O IdP um ponto nico de falhas. Os sistemas de gerncia de identidade exigem que o usurio e o PS atribuam alto grau de conana ao IdP. Todas as informaes da identidade so armazenadas nos IdPs, e os usurios no podem fazer nada alm de conar neles para preservar sua privacidade e as informaes de sua identidade. Essa caracterstica tambm pode ser usada para transformar um SGI em um sistema de vigilncia em massa. Se o IdP se tornar uma autoridade, ento ele pode acessar diretamente todos os dados armazenados e relacionados aos servios aceitos por esse IdP. Os sistemas de gerncia de identidade devem impor a exigncia de que o usurio controle parte dos dados necessrios para efetuar login no PS. Alm disso, o IdP precisa ser implementado ou seguir alguma forma de organizao distribuda que preveja redundncia e conablidade em caso de falhas ou de ataques
171
que possam comprometer as informaes das entidades. O risco de phishing. Muitos dos SGIs atuais apenas oferecem um meio de autenticar o usurio, sendo impossvel para o usurio autenticar o IdP ou o PS. Isso necessrio para prevenir ataques de phishing, em que os atacantes induzem o usurio a revelar sua identidade e credenciais. Para prevenir ataques de phishing importante que os usurios possam autenticar o PS e o IdP. A autenticao mtua precisa, ento, ser incorporada aos SGIs. Quantidade de identidades por usurio. Uma das maiores vantagens dos SGIs para usurios a autenticao simples, que no obriga os usurios a lembrarem de todos os nomes de usurio e senhas, exceto aquele utilizado para obter acesso ao IdP. A partir dessa perspectiva, os usurios devem conar em apenas um IdP para acessar seus servios. Todavia, usar apenas um IdP signica que, se ele for comprometido, todos os dados da identidade tambm sero comprometidos. Portanto, aconselhvel que os usurios distribuam as informaes de suas identidades em mltiplos IdPs. Para permitir determinar quais IdPs e qual a quantidade ideal de identidades, estima-se a necessidade de se desenvolver um modelo que capture aspectos relevantes como caractersticas dos servios, dos usurios, comportamento da rede e outros.
Usabilidade Tornar os SGIs simples e fceis de usar reduz as barreiras para sua adoo. A usabilidade refere-se a eccia, ecincia e satisfao com que usurios especcos alcanam objetivos em um ambiente particular[Levin et al. 2009]. O IEEE dene usabilidade como facilidade com que um usurio pode aprender a operar, gerar entradas para, e interpretar as sadas de um sistema ou componente. A usabilidade geralmente mais importante para usurios privados do que para organizaes prossionais. Qualquer melhoria na usabilidade mais uma questo de acessibilidade. A ausncia de usabilidade pode causar um impacto negativo na funcionalidade, segurana e privacidade. Apesar de muitos SGIs armarem que so desenvolvidos tendo o usurio em mente, eles ainda apresentam muitos problemas de usabilidade [Alpr et al. 2011]. Considerando o ambiente heterogneo da Internet do Futuro e a complexidade que possa ocasionar a falta de usabilidade, os SGIs para a Internet do Futuro precisam ser fceis de usar e suas operaes devem ser o mais transparente possvel para o usurio. Questes de usabilidade Independncia de localizao. Um aspecto importante de usabilidade que est faltando nos SGIs atuais a independncia de localizao. O sistema de identidade deve permitir ao usurio criar, administrar e usar sua identidade independentemente da sua localizao e dos dispositivos que ele esteja usando. Deve ser possvel ao usurio acessar um PS usando o SGI no apenas do seu computador pessoal, mas de qualquer lugar. Os sistemas de gerncia de identidade no podem depender de dados armazenados em um nico equipamento do usurio, ainda mais considerando
172
as redes da prxima gerao, a popularizao de dispositivos portteis e a facilidade de acesso a diferentes tipos de rede de comunicao. Distino de identidades. Os usurios podem ter diversas identidades, mesmo que o escopo seja o mesmo. Essa distino de identidades gera diferentes responsabilidades ou pers. Usurios podem ter diferentes pers que o permitem fazer aes diferentes em um determinado servio. Alm disso, o impacto das aes do usurio dependem do seu perl. Os SGIs atuais no permitem aos usurios administrar esses perls facilmente. Basicamente, os usurios so forados a manter e administrar vrios identicadores para separar diferentes pers. Os cenrios de uso comum criam um problema porque no h como indicar qual perl, ou qual identidade, o usurio quer usar para acessar determinado servio. Os sistemas de gerncia de identidade devem fornecer uma forma para os usurios conhecerem e selecionarem qual a melhor identidade a utilizar mesmo que uma assinatura no tenha sido solicitada explicitamente. Mltiplas credenciais. Um caso especial da questo anterior quando transaes exigem a cooperao de vrios servios, possivelmente de mltiplos PSs. O problema surge se o usurio precisa apresentar credenciais para mais de um servio, e as credenciais dependem do perl que o usurio assume. O usurio precisa ter todas as credenciais exigidas para efetuar a transao, mas pode apresent-las apenas se estiver autenticado e usando o perl correto. Os sistemas de gerncia de identidade devem prover uma forma de determinar automaticamente o conjunto completo de credenciais e os pers que o usurio pode assumir abrangendo aquelas credenciais. Administrao de pers de usurios. Quando um usurio acessa um servio, frequentemente envolve o processamento de informaes pessoais. Algumas dessas informaes podem ser armazenadas no IdP, enquanto que outras informaes esto armazenadas no PS. Muitos PSs armazenam as mesmas informaes para um determinado usurio a m de permitir que um perl possa ser administrado e alterado. Isso pode ser til para permitir ao usurio atualizar seus dados sempre que sentir necessidade. A questo se os SGIs podem simplicar a administrao do perl do usurio para usurios nais to bem quanto os PSs e IdPs. Funcionalidade, conabilidade, auxlio legalidade, acessibilidade e interoperabilidade so requisitos gerais que tambm devem ser considerados na implementao de um SGI [ICPP 2003, Weber et al. 2010].
Funcionalidade A principal funcionalidade de um SGI ajudar o usurio a administrar sua identidade. O SGI tem que oferecer a possibilidade de administrar identidades parciais e dados da identidade. O processo tcnico de criao do conjunto de dados de entrada e de atualizao ou excluso devem ser implementados. Esse conjunto de dados de entrada tambm deve incluir assinaturas digitais, certicados ou credenciais.
173
Isso tambm necessrio para o SGI que possui interfaces para comunicao com parceiros, especialmente em redes de comunicao. O SGI pode atuar como um gateway para comunicao digital. Atuando como gateway, ele pode gerenciar a troca de dados entre todos os parceiros de comunicao. Os sistemas de gerncia de identidade incluem a funcionalidade gateway por denio, pois a gerncia de identidade sempre um processo entre o usurio e outra parte. Para PSs e IdPs, os requisitos bsicos de funcionalidade no diferem em grande parte dos usurios. Tipicamente, as organizaes devem gerenciar informao de identidades de membros e associados, ou seja, diferentes tipos de identidades. As funes para controlar essa complexidade e mant-los atualizados fazem parte dos requisitos bsicos de funcionalidade que devem ser considerados na proposio de um SGI.
Conabilidade Este um pr-requisito para todas as transaes que denem se um usurio cona no PS ou no sistema. Mesmo em sistemas em que o usurio tem controle total sobre o hardware, sotware e uxo de dados, certa quantidade de conana ainda necessria, porque a complexidade do sistema exige transparncia. Ento, a reputao do fornecedor de software e hardware se torna uma vantagem. Embora a ideia de conana dependa de vrios fatores, a privacidade, segurana e usabilidade so condies prvias para conabilidade. Alm disso, aspectos legais inuenciam na percepo de conana.
Auxlio legalidade Agncias responsveis pelo controle e aplicao de leis, tais como reparties policiais ou de prticas investigativas criminais, geralmente se interessam por coletar a maior quantidade possvel de informaes para gerar evidncias e tornar processos criminais mais fceis e ecazes. Qualquer SGI deve observar os requisitos legais para aplicao das leis nos pases em que sero usados. Entretanto, esses requisitos podem ser contraditrios em difernetes pases e at mesmo regies de um mesmo pas, pois resultam de culturas e realidades diferentes.
Acessibilidade Toda tecnologia deve ser acessvel para que seja amplamente aceita. Isso se aplica a todos os tipos de usurios. Entretanto, essa questo deve considerar se o SGI apenas adiciona uma sobrecarga rede ou se realmente melhora a funcionalidade e qualidade dos servios e transaes. Este um objetivo poltico em muitos pases em que o direito deciso sobre informaes pessoais um direito bsico, e como tal no deve depender da situao nanceira da pessoa. As organizaes devem olhar o SGI no como um custo, mas pela tica do custo-benefcio. Em outras palavras, os benefcios de um SGI precisam compensar os custos diretos e indiretos.
174
Interoperabilidade A compatibilidade e a integrao com sistemas j existentes um requisito bsico para um SGI. Os sistemas de gerncia de identidade devem implementar interfaces compatveis com padres internacionais. A m de serem largamente utilizados, essas interfaces devem ser aceitas e suportadas pelos rgos governamentais e agncias dominantes nos mercados visionados para o SGI. Essas partes interessadas iro procurar inuenciar qualquer padro para que possam suport-lo. inteiramente possvel que alguns agentes sejam resistentes a interfaces compatveis a m de proteger sua posio no mercado. Neste caso, a popularizao do SGI como um produto ser mais difcil. As regras de segurana podem regular tendncias isolacionistas no mercado. Alcanar interoperabilidade em diferentes contextos impossvel sem uma fundamentao coerente na cultura e sociedade em que os SGIs pretendem ser usados. Aqui podemos fazer uma analogia com o domnio de linguagens de programao e de ter uma semntica bem denita para a linguagem de programao. Caso contrrio, diferentes implementaes na mesma linguagem iro produzir diferentes interpretaes de alguns conceitos da linguagem conduzindo a uma operao inconsistente do mesmo programa em diferentes implementaes.
4.5. Iniciativas de gerncia de identidade para as redes da prxima gerao

Como mencionado na Seo 4.1, o foco deste minicurso apresentar o estado da arte das principais iniciativas voltadas gerncia de identidade na Internet do Futuro, especialmente aquelas focada nas redes da prxima gerao. Com base na literatura, ns classicamos essas iniciativas em projetos e arquiteturas, alianas e especicaes consolidadas. As prximas subsees so organizadas segundo esta classicao e descrevem as iniciativas encontradas na literatura com base nas publicaes existentes. 4.5.1. Projetos e arquiteturas Esta subseo apresenta os principais projetos relacionados gerncia de identidade na Internet do Futuro. Alm de uma descrio geral desses projetos, as arquiteturas de SGIs propostas ou em desenvolvimento por alguns desses projetos so apresentadas.
PRIME - Gerncia de privacidade e identidade para Europa O projeto PRIME [PRIME 2010] aborda a falta de infraestrutura de gerncia de identidade para a Internet, identicando suas principais carncias, tais como segurana e privacidade, e visando denir um equilbrio dos requisitos emergentes para os SGIs. O objetivo do projeto consiste em desenvolver um prottipo de trabalho para melhorar a privacidade dos SGIs, permitindo gerenciar as mltiplas identidades que um consumidor pode obter atravs de suas interaes pela Internet. Exemplos de interaes so as operaes comerciais realizadas atravs da Internet [Androulaki et al. 2009]. A meta principal do PRIME adotar tecnologias emergentes para Internet do Futuro ou alterar tecnologias j utilizadas a m de adaptar melhor os SGIs ao novo contexto de redes.
175
Arquitetura de gerncia de identidade do projeto PRIME A arquitetura de SGI proposta pelo PRIME foi desenvolvida para suportar uma ampla gerncia do ciclo de vida dos dados relacionados identidade. O foco principal apoiar usurios na administrao dos dados de suas identidades [Sommer et al. 2008]. O desenvolvimento da arquitetura segue a necessidade de mant-la aberta para futuras ampliaes. Tal caracterstica segue a abordagem modular para a arquitetura com uma boa separao funcional entre os componentes principais. Outro princpio a simplicidade. O projeto geral feito de tal forma que as interaes entre as entidades tenham o mximo de privacidade e os dados sejam revelados apenas quando necessrio. A Figura 4.7 mostra um resumo dos componentes na arquitetura PRIME. No conjunto repositrio de dados cada repositrio armazena dados e metadados mantidos pela entidade qual os dados pertencem ou a qualquer outra entidade. Um sistema centrado no usurio ter um repositrio nico, para armazenar seus prprios dados em formato criptografado, e uma empresa ter mltiplos repositrios de dados, devido s suas necessidades de gerenciamento. Os repositrios de dados podem ser acessados por outros componentes internos ao sistema PRIME, assim como por outras entidades solicitantes, como um usurio ou um servio.
Sistema de Interface da Aplicao
Controle de Identidade Gerente de Obrigao
Unidade de Federao Negociao Gerente de Garantia Controle de Garantia Controle de Acesso e Execuo de Identidade Controle de Acesso e Deciso de Identidade Gerenciamento de Confiana Reputao
Repositrio de Dados
Repositrio de Polticas
Figura 4.7. Arquitetura PRIME
Um dos componentes chave na arquitetura PRIME o componente de Controle de Acesso e Deciso de Identidade (Access Control Decision ACD), desenvolvido para ser aproveitado na implementao de um protocolo de negociao entre duas entidades. O componente ACD um componente central que faz o acesso aos dados e toma decises relacionadas liberao de unidades individuais de dados. O componente de Controle
lanoicpO etnenopmoC
Ponto de Extenso de Privacidade
176
de Acesso e Execuo (Access Control Enforcement ACE) controla todos os acessos aos dados. Ele permite ao ACD acessar e ler dados a partir do repositrio, caso o acesso tenha sido concedido. O componente anlogo funo de execuo em arquiteturas de controle de acesso, com a diferena fundamental de que o ACD possui funes mais avanadas que as utilizadas atualmente para tomar tais decises. Todo o acesso aos repositrios feito atravs do componente ACE. O componente de aplicao recorre ao componente ACD para tomar uma deciso de acesso. As polticas so armazenadas em um dos possveis repositrios de poltica, que so acessados pelo ACD. O componente de negociao, do ingls negotiation, implementa a funcionalidade de negociao cujo principal objetivo impulsionar a troca de dados entre as entidades, especialmente para estabelecer a conana e a trocar os dados necessrios. O componente de negociao opera sobre os pedidos em respostas compostas, onde composto signica a possibilidade de incluir vrios atributos ou informaes sobre atributos. Ele consulta o componente ACD obtendo as polticas de decises para unidades de dados atmicas envolvidas na negociao. O componente agrega os resultados recebidos do componente ACD. O acesso aos dados feito atravs do componente ACE. As fontes de dados, especializadas no estabelecimento de conana, podem ser implementadas em um sistema SGI. A arquitetura PRIME dene um componente para gerncia de conana, que capaz de fornecer certicados de dados para outros componentes obtidos a partir de uma avaliao local. Uma funcionalidade principal do componente de gerncia de conana criar e vericar certicados sobre a conabilidade das plataformas. O componente controle de garantia (assurance control) responsvel por garantir a segurana, tanto durante o uso local quanto em interaes com outras entidades. Uma das caractersticas do AC agregar informaes obtidas a partir de componentes de gerncia de conabilidade de uma das mltiplas plataformas que compreendem os servios do sistema. O componente de controle de garantia cria controles e avaliaes de controle que auxiliam a entidade na tomada de decises. A unidade de federao responsvel pela certicao e troca de dados. Ela pode implementar diferentes protocolos. O protocolo proposto pelo projeto PRIME voltado a sistemas de certicao privada (sistemas de credenciais annimas) devido s inmeras vantagens em termos de privacidade. A unidade de federao um componente nico que implementa trocas de dados de acordo com as regras do componente de negociao e com as intervenes do usurios. Outros protocolos j existentes podem ser integrados a este componente a m de tornar a arquitetura PRIME compatvel com protocolos pertinentes. A interface de aplicao do sistema um componente importante desta arquitetura. Ela prov uma interface entre o PRIME e o usurio, permitindo ao sistema fornecer informaes sobre as interaes relacionadas identidade, alm de permitir a administrao de dados e polticas. Com relao arquitetura, a interface deve ter acesso a outros mdulos da arquitetura PRIME a m de impedir que processos externos controlem o sistema sem que o usurio perceba. O componente controle de identidade, do ingls identity control, controla o uxo de dados atravs da arquitetura e facilita o registro de componentes, tornando a arquitetura
177
extensvel e exvel. O componente controle de identidade de duas entidades se comunicam para trocar dados, de acordo com as polticas conguradas. Tanto o componente de controle de identidade, quanto o componente de negociao podem interagir com outros componentes da arquitetura devido ao seu papel de controlador geral e e controlador de negociao. A arquitetura PRIME constituda por mais alguns componentes que possuem funcionalidades convencionais e, por isto, so mencionadas brevemente. O componente de auditoria registra informaes de eventos de processamento e aes de uma entidade, os quais podem ser relevantes para o processamento de dados. O componente de gerenciamento de eventos fornece um framework para gerenciar o que usado por outros componentes.
DAIDALOS - Modelagem de interfaces de rede avanadas para entrega e administrao de servios personalizados, otimizados e independentes da localizao O projeto DAIDALOS [DAIDALOS 2006] foi um dos primeiros voltados a gerncia de identidade fortemente centrado nas infraestruturas de redes e servios. Um dos resultados desse projeto o conceito de Identidade Virtual (VID) e sua aplicao em tais infraestruturas, onde o VID denota a entidade em uma funo especca ou contexto de uso, e no a entidade em sua totalidade [Sarma and Giro 2009]. A identicao de informaes relacionadas a um prestador de servios ou entidade realizada localmente e gerenciada por diferentes entidades ou prestadores de servios. Um esquema VID assegura a divulgao coordenada de todos esses dados. Um VID um identicador pseudonmico que permite o acesso a um subconjunto de dados pessoais do usurio. O proprietrio do VID decide o mbito e detalha exatamente o que pode ser divulgado. A gerncia de identidade age em nome de usurios, monitorando e controlando estados de VIDs e seu ciclo de vida. Ele avalia e verica a existncia de ameaas associadas divulgao de informaes no mbito de uma VID, em pontos especcos, e controla as mudanas de estados dos ciclos de vida do VID. Isto signica que, se o usurio revogar uma VID, o gerenciamento de identidade deve parar todas as operaes que a envolvem. O acesso ubquo a servios e contedos de terceiros est se tornando uma norma na Internet e em computao pervasiva, como descrito na Seo 4.2. O projeto DAIDALOS pretende utilizar a computao pervasiva para organizar tecnologias de comunicao a m de melhorar a experincia do usurio. DAIDALOS visa ajudar os usurios a acessar servios, no importando onde eles estejam. Na Internet do Futuro, sero disponibilizados diversos servios eletrnicos aos usurios. Os acessos a servios em qualquer lugar e a qualquer hora, facilitados pelo aumento da cobertura atravs de vrias tecnologias de rede, permitir que os usurios estejam constantemente conectados aos servios atravs de diferentes canais de rede. Neste contexto, os provedores de servios se preocuparo em atrair a ateno dos usurios, e os provedores de rede se preocuparo com aumento do uso das redes. A computao pervasiva no DAIDALOS visa apoiar os usurios comuns na gerncia de identidades [Taylor et al. 2011] .
178
Arquitetura de gerncia de identidade do projeto DAIDALOS Tendo em vista a necessidade de criar uma nova gerao de infraestrutura de comunicao centrada no usurio que fornea o suporte adequado Internet do Futuro, o projeto DAIDALOS busca integrar tecnologias de redes heterogneas permitindo aos operadores de rede e provedores de servios oferecer novos servios. O objetivo da arquitetura de gerncia de identidade desse projeto possibilita aos usurios acessar a uma vasta gama de servios multimdia personalizados. A Figura 4.8 ilustra a funcionalidade principal dos componentes no Daidalos Pervasive Service Platform (PSP). A camada de gerncia de servios e identidade permite acesso ubquo a servios. Essa funcionalidade inclui servio de descoberta e recomposio para servios de valor agregado para usurios. O componente de descoberta de servio necessrio para apoiar servios criados posteriormente ao desenvolvimento da arquitetura. Os provedores de servios podem anunciar servios e os usurios podem encontrar os servios que necessitam. Uma vez que cada provedor ir oferecer apenas um determinado nmero de servios, ser includo um componente composio de servios a m de permitir a oferta de novos servios compostos a partir dos servios existentes. O componente gerncia de identidade garante que uma infraestrutura de segurana e privacidade possa ser aplicada aos servios de descoberta e composio.
Figura 4.8. Arquitetura Daidalos Pervasive Service Platform (PSP)
O componente gerncia de servios de ontologia dene a interoperabilidade atravs de servios e mecanismos como um glossrio de provedores de servios e consumidores. Este tambm um aspecto chave do componente de composio de servio, validando as vrias semnticas de servios. Os componentes sesso e gerncia de recur-
179
sos apiam um ambiente de gerncia em tempo de execuo para servios compostos, em que os provedores de servios e operadores podem aplicar polticas combinadas a personalizaes do usurio. A camada gerncia de experincia do usurio responsvel por monitorar e controlar as experincias do usrio. O componente gerncia de contexto coleta dados brutos sobre o contexto usando vrios sensores, rena-os e oferece esta informao em um formato mais apropriado para a plataforma ou para aplicaes e servios que os solicitem. O componente gerncia de aprendizagem controla o aprendizado com base no comportamento histrico dos usurios, tais como interao com os servios, e usa esse conhecimento para manter atualizadas as preferncias dos usurios para vrios servios. Atravs do componente de gerncia de preferncia, as preferncias podem ser aplicadas s plataformas de servios, como a alterao de parmetros de qualidade de servio (QoS), ou fornecidas aos aplicativos e servios de terceiros. O componente negociao de privacidade aprimora os mecanismos de negociao entre os usurios e os servios. O componente gerncia de identidade do DAIDALOS fundamental para a aceitao dos usurios predominantes aos servios, pois fornece os meios para acesso a servios seguros, enquanto locadores de servios podem cobrar pelos servios prestados. O modelo de identidade est envolvido em todos os estgios do ciclo de vida de uma conta, desde sua criao, at o login em dispositivos, a seleo de servios e uso. A gerncia de identidade DAIDALOS usa identidades virtuais para assegurar que as identidades dos usurios no sero reveladas aos vrios provedores de servios envolvidos na prestao de servios compostos. SWIFT - Difuso segura de identidades para telecomunicaes federadas O projeto Europeu SWIFT [FIDIS 2010] nanciado pelo programa FP7, do ingls 7th Framework Programme. O projeto aproveita a tecnologia de gerncia de identidade para integrar o servio e a infraestrutura de transporte a m de beneciar usurios e prestadores de servios. O objetivo estender as funes de gerncia de identidade e a federao para redes sem negligenciar a usabilidade e privacidade. A arquitetura proposta por SWIFT atua como um backbone para o sistema inteiro. Ela depende da noo de identidade digital que fornecida por atributos de ligao, autenticao e outras informaes sobre o usurio. Uma vez que a informao nunca armazenada em um nico lugar, a arquitetura age como um ponto de contato para servios externos obterem informaes sobre o usurio ou sobre uma de suas identidades digitais. Arquitetura de gerncia de identidade do projeto SWIFT Com base no projeto DAIDALOS, o projeto SWIFT aprimorou as solues de gerncia de identidade, dando foco s operadoras de telecomunicaes. O resultado uma arquitetura estendida, desenvolvida para prover segurana e privacidade capazes de abranger as necessidades de futuras solues de gerncia de identidade. Essa arquitetura uma soluo de privacidade inter-camadas que aprimora as solues existentes e atua em uma nova infraestrutura de controle de acesso. A arquitetura utiliza cartes eletrnicos de identicao, fornecendo uma viso integrada dos dispositivos dos usurios, buscando solucionar
180
problemas de compatibilidades com solues inteligentes [Barisch et al. 2010]. A Figura 4.9 ilustra a arquitetura proposta pelo projeto SWIFT. A arquitetura contm cinco habilitadores de segurana no dispositivo do usurio, interligados pelo gerenciador de VID (VIDM) e pelo gerenciador de credenciais (CM). O VIDM utilizado pelo usurio para interagir com o componente central do sistema, a m de realizar tarefas relacionadas gerncia de identidade. A arquitetura fornece uma interface grca para o usurio a m de selecionar, criar ou destruir identidades virtuais, estabelecer sesses com os PSs e com os agregadores de identidade. A arquitetura utiliza os habilitadores de segurana conectados. Permite a congurao de atributos de polticas de liberao. Se necessrio, ele permite a criao de credenciais atravs do gerenciador de credenticiais. O CM reponsvel pela criao de credenciais necessrias para autenticao e autorizao em oposio ao PS e ao agregador de identidades. Dentro do contexto SWIFT, essas credenciais tambm so conhecidas como instrues da arquitetura.
Figura 4.9. Arquitetura SWIFT
O gerenciador de credenciais responsvel pela criao de credenciais utilizadas para autenticao e autorizao entre o PS e o agregador de identidades. O CM prov uma interface abstrata para o carto eletrnico de identicao, para o habilitador de inicializao de credenciais (CBS) e para o habilitador de credenciais annimas (ACE). Uma das funes do carto eletrnico de identicao oferecer um armazenamento seguro de credenciais e atributos do usurio. Essa funcionalidade aumenta a segurana do dispositivo do usurio, alm de possibilitar a utilizao de servios independentes da conexo com o agregador de identidade ou com o provedor de atributos. O ACE tambm pode oferecer uma credencial annima. Se necessrio, o CM pode especicar credenciais para interagir com outros sistemas de gerncia de identidade por intermdio do CBS. Uma vez que o usurio pode possuir dispositivos com diferentes
181
recursos e capacidades de segurana, os quais podem ser utilizados em diferentes contextos, o habilitador de transferncia de identidade (ITE) permite utilizar a identidade atravs desses dispositivos. Alm disso, o VIDM pode controlar a representao da identidade do usurio na rede e na camada de servio por meio do gerenciador de pseudnimos inter-camadas. 4.5.2. Alianas Uma vez que sistemas de gerncia de identidade necessitam de uma boa padronizao para garantir o uso abrangente das arquiteturas desenvolvidas, diversas alianas entre companhias vm sendo criadas para auxiliar no uso das novas arquiteturas de gerncia de identidade. Esta subseo apresenta as pricipais alianas existentes desde s que focam apenas na gerncia de identidade para a Internet convencional at as alianas que focam em padres para a Internet do Futuro. Liberty Alliance A Liberty Alliance [Liberty 2001] tem por objetivo estabelecer padres abertos, diretrizes e melhores prticas para gerncia de identidade, focalizando, principalmente, identidades para servios Web. O projeto desenvolvido por esta aliana promove uma abordagem de gerncia de identidade federada, voltada para a construo de relacionamentos de conana entre as empresas e para a capacidade de confederar contas de usurios isolados entre crculos de conana bem denidos [Glsser and Vajihollahi 2008]. A funo da aliana Liberty fornecer suporte ao desenvolvimento, implantao e evoluo de um padro aberto e interopervel para redes de identidades federadas. O objetivo da aliana Liberty permitir um mundo conectado, em que os usurios e as empresas possam realizar transaes mais facilmente, ao mesmo tempo que protegem sua privacidade e a segurana de informaes vitais dessa identidade. Um usurio pode federar suas diferentes identidades em uma identidade nica fornecida por um IdP, a m de acessar servios fornecidos por PSs que participam de um mesmo crculo de conana, autenticando-se apenas uma vez no IdP. Isso baseia-se em um relacionamento de conana pr-estabelecido entre o IdP e todos os PSs do crculo de conana. O modelo oferece um nvel de pseudoanonimato atravs do uso de pseudnimos ao invs de identicadores reais na comunicao entre o IdP e o PS, aumentando assim a privacidade do usurio. FIDIS A FIDIS (Future of Identity in Information Society) [FIDIS 2010] uma Rede de Excelncia (do ingls, Network of Excellence ou NoE) suportada pela Unio Europia. Esta aliana integra esforos de pesquisa das diferentes naes europias buscando solucionar problemas desaadores, tais como suporte a identidade e identicao, interoperabilidade de identidades, conceitos de identicao, roubo de identicadores, privacidade, segurana e pers de usurios, alm de buscar solues para problemas forenses. Uma das principais atividades de pesquisa da aliana est focada na melhor denio de identidade
182
e identicao. A FIDIS dene sete linhas de pesquisa, cada uma com o foco em um aspecto importante de identidade, como privacidade, interoperabilidade, mobilidade e outros. O ramo chamado Identidade da Identidade visa desenvolver um inventrio de denies no domnio de identidade e seus respectivos casos de uso. Ele cataloga ainda os modelos existentes de gerncia de identidade, assim como desenvolve uma viso geral das perspectivas futuras de tais modelos [Glsser and Vajihollahi 2008]. 4.5.3. Especicaes consolidadas Atualmente, existem vrias especicaes de sistemas de gerncia de identidade consolidadas, tais como Security Assertion Mark-up Language (SAML), OpenID, Shibboleth e outras. Apesar dessas especicaes no serem exclusivas para as redes da prxima gerao, ressalta-se que futuramente essas especicaes devem ser compatveis entre si, a m de fornecer um framework de gerncia de identidade coeso. Considerando o contexto de Internet do Futuro, esses padres devero evoluir cada vez mais a m de atender, no apenas s necessidades de determinados segmentos da indstria, mas tambm assumir arquiteturas e infraestruturas de redes especcas, o que pode culminar no desenvolvimento de diferentes padres.
SAML O SAML resulta dos trabalhos do OASIS [OASIS 2011] Security Services Technical Committee, mas a verso atual do SAML conta com uma grande contribuio da Liberty Alliance. O SAML um padro XML para troca de dados de autenticao e autorizao entre servios. Esse padro XML resolve dois problemas, autenticao nica e identidades federadas, e geralmente destinado a parceiros comerciais que buscam um padro para troca segura de informaes. O SAML foi criado por especialistas em segurana, da indstria e da academia, especicamente para prover a interoperabilidade entre servios de autenticao web. O princpio utizado pelo projeto SAML a identidade federada. O modelo de identidade federada permite que organizaes usem mtodos diferentes de autenticao e autorizao que sejam capazes de interoperar, estendendo a capacidade de cada servio existente na organizao, ao invs de forar sua troca. A identidade federada tambm permite ajudar usurios a obterem vantagens dos sistemas de autenticao existentes reduzindo, assim, o nmero de senhas que eles tm que lembrar [Morgan et al. 2004].
OpenID OpenID [OpenID 2006] um framework aberto, descentralizado e gratuito voltado para a identidade digital do usurio. OpenID permite aos usurios de Internet acessar diferentes sites, baseados em uma nica identidade digital, o que elimina a necessidade de diferentes nomes de usurio e senha para cada stio web [Miloucheva et al. 2008]. Seu desenvolvimento iniciou em 2005 e obteve expressiva ateno, tanto da comunidade de
183
desenvolvimento web quanto de grandes corporaes. Hoje, Google, IBM, Microsoft, VeriSign e Yahoo! so membros da Fundao OpenID.
Shibboleth O Shibboleth [Shibboleth 2011] uma iniciativa originada no ambiente acadmico, cujo objetivo facilitar o compartilhamento de recursos de pesquisa entre instituies acadmicas. Ele um padro que tem como base pacotes de software de cdigo aberto com acesso nico para web entre ou dentro dos limites organizacionais. Esse padro permite que sites tomem decises de autorizao para acesso individual a m de proteger recursos online, de forma a preservar a privacidade. O software Shibboleth implementa abordagens de identidade federada para fornecer um acesso nico federado e um framework de troca de atributos. Ele fornece a funcionalidade de privacidade estendida permitindo ao browser do usurio e ao seu local de origem controlar os atributos liberados para cada aplicao. Isso tambm simplica a gerncia de identidade e permisses para organizaes, suportanto usurios e aplicaes.
RAPID No RAPID (Roadmap for Advanced Research in Privacy and Identity Management), a gerncia de identidade obedece as denies e o ciclo de vida de identidades digitais e pers, assim como as denies de ambientes para troca e validao de informaes e o conceito de identidades parciais. Trs requisitos bsicos de um SGI so destacados: (1) a conabilidade e a delidade, (2) a divulgao controlada de informaes e (3) o apoio suporte. O projeto estuda os obstculos e problemas no desenvolvimento de um sistema que suporta Identidades Digitais Mltiplas e Conveis a m de direcionar futuras pesquisas na rea [Glsser and Vajihollahi 2008].
HIGGINS Higgins [Higgins 2011] um framework de identidade para Internet, com cdigo aberto, desenvolvido para integrar identidade, perl e informaes de relacionamentos sociais atravs de mltiplos sites, aplicaes e dispositivos. Higgins no um protocolo, mas uma infraestrutura desenvolvida para suportar uma experincia consistente do usurio. Ele trabalha como todos os protocolos de identidade digital, incluindo WS-Trust, OpenID, SAML, XDI, LDAP, entre outros. Higgins permite construir aplicaes e servios que iro trabalhar com diversos sistemas de gerncia de identidade, permitindo ao desenvolvedor incorporar padres de identidade aos softwares. Do ponto de vista do usurio, Higgins oferece s pessoas maior controle sobre suas identidades digitais, como as identidades online, informaes pessoais e relacionamentos sociais. A arquitetura do framework permite adaptar as tecnolocias existentes conforme necessrio. Higgins tambm compatvel com diversos protocolos e servios relacionados segurana e gerncia de identidade.
184
Concordia O projeto Concordia uma iniciativa global projetada para desenvolver a interoperabilidade entre dos protocolos de gerncia de identidade utilizados atualmente. Ele dene casos de uso e requisitos do mundo real que podem ser utilizados em mltiplos protocolos de gerncia de identidade simultaneamente, em vrios cenrios de implatano, encorajando e facilitando a criao de solues de protocolos apropriados para diferentes tecnologias. Para a gerncia de identidade, ele busca por solues voltadas ao usurio e gerncia de identidade federada. Na perspectiva da comunidade de cdigo aberto, os projetos Higgins e Concordia esto criando um framework de identidade multiprotocolo e promovendo a interoperabilidade entre protocolos de autenticao diferentes. Alm de implementar uma estrutura de identidade de cdigo aberto que suporte abordagens tanto trandicionais quanto voltadas ao usurio. O framework do Higgins est criando um modelo de dados de identidade atrativo e um servio de atributo de identidade que oferece acesso uniforme a atributos de identidade independente do objetivo nal. Paralelamente, Concordia oferece dicas teis relacionadas a um modelo de referncia de identidade e tem desenvolvido e experimentado solues para suportar a interoperabilidade entre diferentes solues de gerncia de identidade. Os projetos Higgins e Concordia so relevantes e devem ser tomados como ponto de partida para reforar e tratar adequadamente solues para a Internet do Futuro [Rotondi 2008].
4.6. Ferramentas e tecnologias para gerncia de identidade

Ao longo da histria das civilizaes, diversos mtodos para evitar que uma informao fosse obtida por pessoas no autorizadas foram criados. Os primeiros mtodos utilizados para comprovar a identidade baseavam-se no uso de senhas ou palavras-chave. Segundo esses mtodos, uma informao s poderia ser obtida pela entidade que possuisse a palavra-chave. No entanto, o roubo ou a simples presuno da senha permitia que entidades no autorizadas obtivessem a informao original. Dessa forma, a m de aumentar o nvel de segurana, foram criados os chamados tokens de autenticao. Os tokens so dispositivos que tm a nalidade de fornecer acesso uma determinada informao somente ao portador do dispositivo e mediante sua senha de acesso. Quando comparado ao uso de senhas, os tokens passaram a ser utilizados massivamente por oferecer um nvel de segurana maior. Com o crescente uso dessa tecnologia, surgiu a necessidade de prover ao token a capacidade de ser inviolvel garantindo, assim, que somente o verdadeiro dono da informao obtivesse acesso a ela. Assim, foram desenvolvidos diversos modelos de dispositivos para a identicao. Cronologicamente, os modelos de maior importncia para uma identicao digital so: Cartes de ta magntica Cartes inteligentes (smart cards) e cartes inteligentes sem contato (contactless smart cards) RFID cards (Radio-Frequency IDentication)
185
Cartes inteligentes multiaplicao Os modelos citados foram criados para aumentar a segurana assim como a capacidade de armazenamento e a facilidade de uso. Os cartes de ta magntica, usados amplamente no incio dos anos 80, comearam a ter sua segurana comprometida pelo alto ndice de falsicaes (como clonagens) e tm perdido espao para os cartes inteligentes. Estes possuem caractersticas que os tornam inviolveis e possuem maior espao de armazenamento. com base na tecnologia dos cartes inteligentes, foram desenvolvidos os cartes sem contato, que utilizam radiofrequncia para acesso e so providos de mtodos extras de segurana. Seguindo a mesma linha, foram desenvolvidos os cartes RFID, cuja principal caracterstica a identicao do usurio a uma distncia maior, funcionando como um dispositivo de controle e rastreamento. A popularizao dos tokens permitiu o aumento no uso de cartes inteligentes por diversos servios. Uma pessoa que necessitasse acessar diversos servios utilizando este dispositivo de segurana, deveria possuir diversos tokens, um para cada servio. Para diminuir a quantidade de tokens, os cartes multiaplicao foram criados com o objetivo de englobar diversos tokens em um s, facilitando o acesso aos diversos servios oferecidos e que antes deveriam ser acessados utilizando cartes diferentes. Atualmente, duas tcnicas principais so utilizadas para provar a identidade de uma entidade, algo que o usurio sabe ou algo que ele possui (senhas, cartes, documentos). Entretanto, estas tcnicas podem ser burladas pela presuno da senha e pelo emprstimo do carto. Para aumentar a segurana no processo de identicao, foi adicionado mais uma dimenso para conrmao da identidade: algo que o usuro . Neste ponto entra a Biometria, capaz de identicar um usurio utilizando alguns de seus fatores fsicos e biolgicos. Dessa forma, os principais mtodos de identicao utilizados atualmente so a identicao por senha, a identicao por token e a identicao por caractersticas fsicas e biolgicas. Atravs desse conjunto, possvel garantir uma complexidade maior, dicultando a quebra de privacidade e oferecendo mais segurana para a gerncia de identidade. Dentre as diversas tecnologias usadas para a gerncia de identidade, algumas se destacam pelo seu alto ndice de uso, de segurana e de praticidade. Neste escopo, podemos citar os cartes inteligentes, a aiometria e os cartes multiaplicao. As prximas subsees descrevem essas trs principais tecnologias de gerncia de identidade dando enfoque aos seus usos na Internet do Futuro. 4.6.1. Cartes Inteligentes (Smart Cards) Os cartes inteligentes, tambm conhecidos como Smart Cards, so cartes que se parecem, em forma e tamanho, a um carto de crdito convencional de plstico com tarja magntica. A diferena entre os dois dispositivos que o carto inteligente possui capacidade de processamento, pois possui um microprocessador e memria embutidos, ambos com sosticados mecanismos de segurana. Mais especicamente, o carto inteligente possui um mdulo de memria ROM, um mdulo de memria RAM e um mdulo de memria EEPROM. O primeiro mdulo armazena as instrues que sero enviadas ao
186
processador. O segundo mdulo armazena os dados que so processados. E o terceiro mdulo armazena os dados propriamente ditos. Um carto inteligente conta ainda com uma CPU e mdulos tanto para a entrada e sada de dados, quanto para a criptograa dos dados armazenados no carto.
Tipos de Carto Os cartes inteligentes usados atualmente diferem em dois fatores principais, o tamanho e a forma de acesso ao meio. As principais formas de comunicao dos cartes atuais so por contato ou por radiofrequencia. Os cartes com comunicao por contato devem ser inseridos em um leitor, enquanto os cares sem contato se utilizam de comunicao por radiofrequncia para troca de informaes entre o carto e o leitor de informaes. Os cartes inteligentes com contato foram usados inicialmente em bancos na Frana. Sua capacidade de guardar chaves privadas e executar modernos algoritmos de criptograa tornou possvel prover um alto nvel de segurana s informaes. A drstica reduo do preo desses dispositivos tornou seu uso cada vez mais frequente, gerando a criao de novas aplicaes que utilizam este recurso de segurana, especialmente aplicaes que implementam a identicao, controle de acesso, armazenamento seguro de dados e assinaturas eletrnicas. Os cartes inteligentes sem contato se diferem dos clssicos cartes inteligentes pela forma de comunicao. Ambos, a memria e o microprocessador utilizam a interface sem contato para fazer a transmisso de dados. Esses cartes tm a sua energia transferida sem qualquer contato fsico, permitindo acesso a vrias aplicaes sem que o usurio necessite segurar o carto na mo, sendo possvel mant-lo dentro de uma bolsa ou carteira. Muitas aplicaes foram desenvolvidas para utilizar esse tipo de carto, tais como controle de acesso em transporte pblico, cartes corporativos e passes para entrada em estabelecimentos. Este tipo de carto tambm elimina um possvel erro de fabricao dos contatos eltricos. Os smart cards tm um ciclo de vida bem denido. O processo de produo composto por cinco fases. O ciclo de vida comea no produtor do hardware do carto, que responsvel pela fabricao do chip a ser adicionado ao carto. O produtor de hardware tambm deve fornecer todo suporte ao hardware do equipamento fornecido. Uma vez criado o chip, iniciado o processo de confeco do carto. A confeco do carto depende do objetivo para o qual ele ser utilizado, podendo ser do tamanho de um carto de crdito ou do tamanho de um carto SIM. Para o processo de instalao de um sistema para o funcionamento do carto inteligente, necessrio mais um intermedirio, o emissor do carto. Este tem a funo de fornecer um carto pronto para ter aplicaes instaladas, garantindo um sistema operacional seguro para a execuo das aplicaes. Uma vez que o carto esteja pronto, basta fazer as instalaes da aplicao requerida. Este processo feito pelo provedor de servios. O provedor de servios oferece um carto com sua aplicao, a qual dever estar congurada para o funcionar no sistema operacional fornecido pelo emissor do carto. No nal do processo est o usurio, que utilizar o carto para a sua identicao.
187
Evoluo e Adaptaes Desde seu surgimento, os cartes inteligentes passaram por profundas mudanas no processo de fabricao. De acordo com as principais mudanas, a evoluo destes cartes dividida em quatro geraes. A Figura 4.10 ilustra as principais caractersticas de cada gerao. Na primeira gerao, o produtor de hardware o principal responsvel pela fabricao do carto. O produtor de hardware tinha um contato direto com o provedor de servios, pois toda a escrita no carto era feita durante o primeiro processo. Com isso, o produtor de hardware era contratado apenas para inserir a aplicao do provedor de servios dentro do chip do carto.
Figura 4.10. Caractersticas das quatro geraes dos cartes inteligentes
Na segunda gerao houve a diviso da camada da aplicao em trs diferentes processos. A primeira camada constituda por um conjunto de instrues de hardware, a segunda por um conjunto de classes e a terceira pela aplicao em si. Isso permitiu segmentar melhor as camadas, tornando possvel aproveitar as classes de aplicaes e a camada de hardware para outras aplicaes. Na terceira gerao, houve a incluso do fabricante e do emissor do carto ao processo. Estes tm como funo a insero de informaes adicionais, como o PIN, que dever ser usado pelo emissor e pelo provedor de servios como um mtodo segurana no carto inteligente. Finalmente, na ltima gerao de cartes inteligentes, houve uma grande mudana na separao das atividades de cada envolvido na produo do carto. Agora, o produtor de hardware responsvel por produzir toda a Camada de hardware e as classes de aplicaes, facilitando e minimizando a necessidade de mudanas nas camadas superiores. O fabricante e o emissor se unem em uma nica etapa que tem como objetivo criar um framework de classes. Este servir de base para qualquer aplicao que o provedor de servios escolha para colocar dentro do carto. Nesta gerao foi considerado um novo agente, o que ir utilizar e modicar os dados, o usurio. De posse do carto, o usurio pode atualiz-lo a m de manter suas informaes em dia.
188
Sistemas operacionais para cartes inteligentes Atualmente so dois os principais sistemas operacionais utilizados em cartes inteligentes, o MULTOS e o sistema operacional criado para o Java Card. O Java Card um carto inteligente que prov suporte a todos os padres de carto inteligentes. No entanto, o Java Card tem uma diferena bsica com relao aos cartes inteligentes. Uma mquina virtual, a Java Virtual Machine (JVM) implementada em sua memria ROM. Esta mquina virtual controla o acesso a todos os recursos do carto, como memria e entrada e sada de dados, e suporta a funcionalidade de operaes caractersticas de sistemas operacionais para cartes inteligentes. O funcionamento da dessa mquina virtual inicia com a execuo de um subconjunto de cdigo chamado Java byte code para que as funes sejam acessadas pelo leitor do carto garantindo a conabilidade do carto. O Java Card composto por classes padro e um conjunto de rotinas que permitem que as aplicaes Java sejam executadas diretamente. O sistema operacional do Java Card permite que os aplicativos do carto inteligente sejam escritos em linguagem Java, o que de fato traz independncia para desenvolvimento de software. Alm disso, ele fornece uma boa base para cartes de mltiplas aplicaes, suportando mais de um aplicativo por vez. A compilao de cdigo no Java Card traz consigo, includo na compilao, um conversor que verica cada classe e otimiza o cdigo para os recursos limitados de um carto inteligente. O MULTOS (Multiple Operating System) foi desenvolvido originalmente pela Mondex International. um sistema multiaplicao de alta segurana, desenvolvido especialmente para cartes inteligentes, possibilitando que diversas aplicaes sejam instaladas, ao mesmo tempo, no carto. O MULTOS tem sua prpria linguagem de programao, a MEL (MULTOS Executable Language), que otimizada para os sistemas de cartes inteligentes. Entretanto, o sistema fornece compiladores para vrias linguagens, como Assembly, C, Java e Visual Basic. Com isso, a caracterstica mais importante do MULTOS a independncia de linguagem. O MULTOS a nica plataforma com suporte programao em linguagem Assembly. Para programao em C, o MULTOS possui um compilador que oferece fcil portabilidade para aplicativos j existentes para o sistema operacional MULTOS. Diferente do Java Card, o MULTOS prov suporte um pouco diferente linguagem de programao Java. Ambos, Java Card e MULTOS, suportam a linguagem Java e ambos possuem um compilador Java que traduz as classes Java. A diferena que no Java Card, as classes so convertidas em cdigo Java byte code, j no MULTOS, o compilador traduz as classes Java para a linguagem codicada MEL, que j otimizada para trabalhar em Cartes Inteligentes. Tanto o MULTOS quanto o Java Card so muito utilizados. Entretanto, devido linguagem para otimizao de cdigo do MULTOS, este oferece um pequeno ganho de desempenho para o cartes inteligentes. 4.6.2. Biometria Biometria o estudo estatstico das caractersticas fsicas ou comportamentais dos seres vivos. Utiliza caractersticas fsicas ou comportamentais das pessoas como forma de identic-las unicamente. Os sistemas chamados biomtricos baseiam o seu funciona-
189
mento em caractersticas de diversas partes do corpo humano. Os olhos, a palma da mo, as digitais, a retina ou ris dos olhos so as mais utilizadas para identicao. A ideia fundamental a de que cada indivduo nico e possui caractersticas fsicas e comportamentais diferentes. A autenticao biomtrica tem a vantagem de checar as caractersticas pessoais do usurio, o que torna a identicao do usurio mais el, diminuindo a possibilidade de fraude. As impresses digitais tm o seu reconhecimento baseado em imagens. A estrutura dessas impresses composta por vales e mincias, que tm as suas localizaes mapeadas para que seja feita a comparao com outras imagens. Esta tcnica de identicao a mais antiga e a mais aceita para identicao de pessoas. O reconhecimento de face tem como base a imagem da face. A estrutura da face salva como uma imagem para uma futura comparao. No passado, os algoritmos de reconhecimento de face usavam somente modelos geomtricos, mas atualmente eles baseiamse em modelos matemticos e de identicao de padres para proceder a comparao das imagens. Os grandes avanos obtidos na ltima dcada zeram com que esta tecnologia obtivesse maior aceitao. Esta uma tecnologia intuitiva, pois este o modo como pessoas reconhecem seus amigos e como feita pela vericao de documentos. Esses dois mtodos so os mais aceitos atualmente para uma possvel implementao como padro para gerncia de identidade. Devido fcil captura dos dados, as digitais e a face tm preferncia, sendo necessrio apenas um sensor de digitais e uma webcam para capturar os dados. Cartes RFID Por engano, algum pode se referir a cartes inteligentes sem contato como cartes RFID, mas so tecnologias diferentes. Os cartes RFID tm como caracterstica a identicao por rdiofreqncia. Sua identicao feita de forma automtica atravs da captura de dados em uma rede sem o. Essa tecnologia inclui antenas e bobinas eletrnicas programadas com uma informao nica. O processo de identicao simples e rpido, onde s necessria a captura da freqncia. A maioria desses cartes no inviolvel, pois no contam com um hardware robusto. Os cartes RFID so mais utilizados para o controle de acesso e rastreamento, principalmente em ambientes em que no necessrio o reconhecimento, mas apenas a vericao do indivduo, garantindo uma rapidez ao processo. Cartes multiaplicao Olhando pela perspectiva de um desenvolvedor, um carto multiplicao um carto com vrias aplicaes carregadas na memria do carto. A maioria das aplicaes de um carto inteligente tm seus prprios dados e raramente compartilham-as, tornando-as independentes. Para garantir essa independncia o sistema operacional deve garantir o acesso apropriado para cada aplicao.
4.7. Concluses
Vrios esforos vm sendo observados na literatura em direo ao desenvolvimento da Internet do Futuro. Essa nova Internet pretende sanar problemas e limitaes encontradas
190
na Internet atual, sobretudo aqueles relacionados ao provimento de servios de forma segura, convel e robusta. A Internet do Futuro visionada em organizao em quatro dimenses, apoiadas por uma infraestrutura de rede denominada rede da prxima gerao. A rede da prxima gerao ou NGN um conceito de redes que tem como base a transferncia de pacotes para prover servios e se beneciar de mltiplas tecnologias e infraestruturas de comunicao existentes. Uma NGN composta por uma rede de servios, uma rede de base e uma rede de acesso. A rede de servios responsvel pelos servios oferecidos s entidades. A rede de base consiste do backbone da NGN. A rede de acesso comporta redes que se utilizam das diferentes tecnologias de comunicao sejam elas com o ou sem o. A Internet do Futuro, em especial, a NGN requer cada vez mais um gerenciamento da identidade das entidades. A NGN pretende prover diversos tipos de servios, muitos deles personalizados, e depende de informaes relacionadas ao perl dos usurios e servios para atingir um funcionamento eciente que garanta QoS, privacidade, segurana, disponibilidade e conabilidade dos servios. Nos diferentes nveis da NGN, a gerncia de identidade uma funcionalidade cada vez mais necessria e importante. Entretanto, sistemas de gerncia de identidade ainda possuem atualmente desaos. Dentre esses desaos, encontram-se questes relacionadas segurana, privacidade dos dados dos usurios e usabilidade que devem ser tratados a m de se tornarem mais adequados sua aplicao na Internet do Futuro. Alm dessas questes, os sistemas de gerncia de identidade desenvolvidos para a Internet do Futuro necessitam ser interoperveis, uma vez que tecnologias heterogneas so esperadas a trabalharem em conjunto. Alm das arquiteturas de gerncia de identidade, o captulo apresenta uma viso geral sobre as alianas existentes, as especicaes consolidadas e as ferramentas de gerncia de identidade utilizadas atualmente. As alianas e as especicaes consolidadas so descritas com o objetivo de mostrar o estado da arte em relao aos esforos que vm sendo realizados em direo a padronizaes de sistemas de gerncia de identidade. As ferramentas mais comuns utilizadas para auxiliar sistemas de gerncia de identidade como os cartes inteligentes, a biometria e os cartes RFID so descritos a m de prover uma descrio sobre o que vm sendo utilizado nos sistemas, assim como uma viso relacionada a seus avanos e perspectivas futuras. Com base nesse levantamento do estado da arte sobre sistemas de gerncia de identidade para Internet do Futuro, observamos que as propostas existentes ainda so bastante incipientes. As arquiteturas apesar de se dizerem voltadas Internet do Futuro, ainda no possuem ou tratam caractersticas realmente relacionadas ao novo paradigma de rede. Alm disso, as arquiteturas existentes so bastante conceituais, requerendo uma especicao mais detalhada e formal sobre os conceitos e usos desses conceitos na prtica. Elas necessitam ainda denir de forma mais clara como os mdulos e componentes conceituais sero na realidade implementados e como sero suas aplicaes no contexto heterogneo das redes da prxima gerao. Especicaes e anlises formais so requeridas a m de mostrar os custos referentes ao uso de cada uma dessas arquiteturas na rede. Em relao aos padres existentes, estes no consideram de fato as caractersticas e os possveis usos dos sistemas de gerncia de identidade nas redes da prxima gerao.
191
Um grande campo de oportunidades e de desenvolvimento observado em relao aos sistemas de gerncia de identidade e suas aplicaes nas redes da prxima gerao. O que se observa que a existncia de padres realmente voltados a Internet do Futuro ainda so inexistentes e muito trabalho ainda necessrio em direo especicao desses padres. Sobre as ferramentas existentes para gerncia de identidade, observa-se a evoluo que elas vm passando. Atualmente, a biometria e os cartes multiaplicao parecem ser as ferramentas mais promissoras por se adequarem aos requisitos e caractersticas das redes da prxima gerao. A capacidade dos cartes multiaplicao servirem para uso considerando diferentes servios vai de encontro caracterstica da Internet do Futuro de prover diferentes servios requerendo mecanismos que facilitem a gerncia de identidade pelos usurios sem sobrecarrega-los com a necessidade de memorizar diferentes senhas e identicadores. Entretanto, questes de segurana ainda precisam ser tratadas nesse tipo de ferramenta.
Referncias
[Akyildiz et al. 2006] Akyildiz, I. F., Lee, W.-Y., Vuran, M. C., and Mohanty, S. (2006). Next generation/dynamic spectrum access/cognitive radio wireless networks: a survey. Computer Networks, 50(13):21272159. [Aldun et al. 2011] Aldun, M., Snchez, F., Alvarez, F., Jimnez, D., Menndez, J., and Cebrecos, C. (2011). System architecture for enriched semantic personalized media search and retrieval in the future media internet. IEEE Communications Magazine, 49(3):144 151. [Alpr et al. 2011] Alpr, G., Hoepman, J., and Siljee, J. (2011). The Identity Crisis Security, Privacy and Usability Issues in Identity Management. Identity Management on Mobile Devices. [Androulaki et al. 2009] Androulaki, E., Johnson, M., Vo, B., and Bellovin, S. (2009). Cybersecurity through an Identity Management System. In Engaging Data Forum, MIT. [Barisch et al. 2010] Barisch, M., Torroglosa, E., Lischka, M., Marques, R., Marx, R., Matos, A., Perez, A., and Scheuermann, D. (2010). Security and Privacy Enablers for Future Identity Management Systems. In Future Network and Mobile Summit, Florence, Italy. MS10. [Benevenuto et al. 2009] Benevenuto, F., Rodrigues, T., Cha, M., and Almeida, V. (2009). Characterizing user behavior in online social networks. In Proceedings of the 9th ACM SIGCOMM conference on Internet measurement conference, IMC 09, pages 4962, New York, NY, USA. ACM. [Benslimane et al. 2008] Benslimane, D., Dustdar, S., and Sheth, A. (2008). Services mashups: The new generation of web applications. IEEE Internet Computing, 12(5):1315.
192
[Boccaletti et al. 2006] Boccaletti, S., Latora, V., Moreno, Y., Chavez, M., and Hwang, D.-U. (2006). Complex networks: Structure and dynamics. Physics Reports, 424(45):175 308. [Boldrini et al. 2010] Boldrini, C., Conti, M., and Passarella, A. (2010). Modelling social-aware forwarding in opportunistic networks. In IFIP Performance Evaluation of Computer and Communication Systems (PERFORM 2010), Vienna, Austria. [Chai et al. 2011] Chai, W. K., Wang, N., Psaras, I., Pavlou, G., Wang, C., de Blas, G., Ramon-Salguero, F., Liang, L., Spirou, S., Beben, A., and Hadjioannou, E. (2011). Curling: Content-ubiquitous resolution and delivery infrastructure for next-generation services. EEE Communications Magazine, 49(3):112 120. [Chim et al. 2011] Chim, T., Yiu, S., Hui, L., and Li, V. (2011). SPECS: Secure and Privacy Enhancing Communications Schemes for VANETs. Ad Hoc Network, 9:189 203. [Choi et al. 2011] Choi, J., Han, J., Cho, E., Kwon, T., and Yanghee, C. (2011). A survey on content-oriented networking for efcient content delivery. IEEE Communications Magazine, 49(3):121 127. [Choi and Hong 2007] Choi, M.-J. and Hong, J. W.-K. (2007). Towards management of next generation networks. IEICE Transactions, 90-B(11):30043014. [DAIDALOS 2006] DAIDALOS (2006). The Daidalos Project. daidalos.org, ltimo acesso 28 de Maro de 2011. hhtp://www.ist-
[Dhamija and Dusseault 2008] Dhamija, R. and Dusseault, L. (2008). The Seven Flaws of Identity Management: Usability and Security Challenges. IEEE Security and Privacy, 6:2429. [FIDIS 2010] FIDIS (2010). Future of Identity in the Information Society. www.dis.net, ltimo acesso 10 de Novembro de 2010. [FOKUS 2009] FOKUS (2009). NGN Evolution Towards the Future Internet. Technical report, Fraunhofer Institute for Open Communication Systems. [Glsser and Vajihollahi 2008] Glsser, U. and Vajihollahi, M. (2008). Identity Management Architecture. In ISI, pages 137144. [Gomez-Skarmeta et al. 2010] Gomez-Skarmeta, A. F., Martinez-Julia, P., Girao, J., and Sarma, A. (2010). Identity based Architecture for Secure Communication in Future Internet. In The 6th ACM Workshop on Digital Identity Management, DIM10, pages 4548, New York, NY, USA. ACM. [Hansen et al. 2008] Hansen, M., Schwartz, A., and Cooper, A. (2008). Privacy and Identity Management. IEEE Security and Privacy, 6:3845. [Heegaard and Trivedi 2009] Heegaard, P. E. and Trivedi, K. S. (2009). Network survivability modeling. Computer Networks, 53(8):12151234.
193
[Higgins 2011] Higgins (2011). Higgins - Open Source Identity Framework. http://www.eclipse.org/higgins, ltimo acesso 28 de Maro de 2011. [Hui et al. 2011] Hui, P., Crowcroft, J., and Yoneki, E. (2011). Bubble rap: Social-based forwarding in delay tolerant networks. IEEE Transactions on Mobile Computing, ((to appear)). [ICPP 2003] ICPP (2003). Identity management systems (ims): Identication and comparison study. Technical report, Independent Centre for Privacy Protection (ICPP) and Studio Notarile Genghini (SNG). [ITU-T 2004] ITU-T (2004). General overview of NGN. Recommendation Y.2001. Dezembro. [Josang et al. 2005] Josang, A., Fabre, J., Hay, B., Dalziel, J., and Pope, S. (2005). Trust Requirements in Identity Management. In Australasian Information Security Workshop 2005 (AISW 2005). [Kim and Shin 2008] Kim, H. and Shin, K. G. (2008). In-band spectrum sensing in cognitive radio networks: energy detection or feature detection? In ACM MobiCom, pages 1425, New York, NY, USA. ACM. [Levin et al. 2009] Levin, A., Sutherland, E., and Choe, Y. (2009). The Future Internet. Technical report, International Communication Union. [Li et al. 2009] Li, G., Sun, H., Gao, H., Yu, H., and Cai, Y. (2009). A survey on wireless grids and clouds. In International Conference on Grid and Cooperative Computing, pages 261 267. [Li and Sandrasegaran 2005] Li, M. and Sandrasegaran, K. (2005). Network management challenges for next generation networks. In IEEE Conference on Local Computer Networks, pages 593598, Los Alamitos, CA, USA. IEEE Computer Society. [Liberty 2001] Liberty (2001). The Liberty Alliance http://www.projectliberty.org, ltimo acesso: 28 de Maro de 2011. Project.
[Maghiros et al. 2006] Maghiros, L., Punie, Y., Delaitre, S., Hert, P., Gutwirth, S., Schreurs, W., Moscibroda, A., Friedewald, M., Linden, R., Wright, D., Vildjiounaite, E., and Alahuhta, P. (2006). Safeguards in a world of ambient intelligence. In International Conference on Intelligent Environments, volume 2, pages 245 249. [Maliki and Seigneur 2007] Maliki, T. E. and Seigneur, J.-M. (2007). A survey of usercentric identity management technologies. The International Conference on Emerging Security Information, Systems, and Technologies, 0:1217. [Miloucheva et al. 2008] Miloucheva, I., D.Wagner, Niephaus, C., and Hetzer, D. (2008). User-centric Identity enabled QoS Policy Management for Next Generation Internet. In ICT-Mobile Summit Stockholm.
194
[Morgan et al. 2004] Morgan, R., Cantor, S., Carmody, S., Hoehn, W., and Klingenstein, K. (2004). Federated Security : The Shibboleth Approach. EDUCAUSE Quarterly, 27(4). [OASIS 2011] OASIS (2011). OASIS Advanced Open Standards for the Information Society. http://www.oasis-open.org, ltimo acesso 28 de Maro de 2011. [OpenID 2006] OpenID (2006). The OpenID Project. http://openid.net, ltimo acesso 28 de Maro de 2011. [Park and Rappaport 2007] Park, C. and Rappaport, T. (2007). Short-range wireless communications for next-generation networks: Uwb, 60 ghz millimeter-wave wpan, and zigbee. IEEE Wireless Communications, 14(4):7078. [Paul et al. 2011] Paul, S., Pan, J., and Jain, R. (2011). Architectures for the Future Networks and the Next Generation Internet: A Survey. Computer Communications, 34:242. [Prasad et al. 2008] Prasad, R., Pawelczak, P., Hoffmeyer, J., and Berger, H. (2008). Cognitive functionality in next generation wireless networks: standardization efforts. IEEE Communications Magazine, 46(4):7278. [PRIME 2010] PRIME (2010). Privacy and Identity Management for Europe. www.prime-project.eu, ltimo acesso 10 de Novembro de 2010. [Rotondi 2008] Rotondi, D. (2008). Extending user-centred identity management approaches to address Future Internet issues. Technical report, GEMOM - Genetic Message Oriented Secure Middleware. [Sabena et al. 2010] Sabena, F., Dehghantanha, A., and Seddon, A. P. (2010). A Review of Vulnerabilities in Identity Management Using Biometrics. In International Conference on Future Networks, volume 0, pages 4249, Los Alamitos, CA, USA. IEEE Computer Society. [Sakellari p053] Sakellari, G. (2009, doi: 10.1093/comjnl/bxp053). The Cognitive Packet Network: A Survey. The Computer Journal: Special Issue on Random Neural Networks, 53(3):268279. [Salsano et al. 2008] Salsano, S., Polidoro, A., Mingardi, C., Niccolini, S., and Veltri, L. (2008). Sip-based mobility management in next generation networks. IEEE Wireless Communications, 15(2):92 99. [Sarma and Giro 2009] Sarma, A. and Giro, J. (2009). Identities in the Future Internet of Things. Wireless Personal Communication, 49:353363. [Shibboleth 2011] Shibboleth (2011). The Shibboleth http://shibboleth.internet2.edu, ltimo acesso 28 de Maro de 2011. Project.
[Sommer et al. 2008] Sommer, D., Mont, M. C., and Pearson, S. (2008). PRIME Architecture V3. Technical report, PRIME Consortium.
195
[Song and Jamalipour 2005] Song, Q. and Jamalipour, A. (2005). A network selection mechanism for next generation networks. In IEEE International Conference on Communications, volume 2, pages 14181422. [Taylor et al. 2011] Taylor, N. K., Robertson, P., Farshchian, B. A., Doolin, K., Roussaki, I. G., Marshall, L., Mullins, R., Druesedow, S., and Dolinar, K. (2011). Pervasive Computing in Daidalos. IEEE Pervasive Computing, 10:7481. [Weber et al. 2010] Weber, S., Martucci, L., Ries, S., and Mhlhuser, M. (2010). Towards Trustworthy Identity and Access Management for the Future Internet. In Trustworthy IoPTS: The 4th International Workshop on Trustworthy Internet of People Things and Services. [Zhou et al. 2010] Zhou, M., Zhang, R., Zeng, D., and Qian, W. (2010). Services in the cloud computing era: a survey. In International Universal Communication Symposium (IUCS), pages 40 46.
196
Captulo
5
Resource Allocation in Clouds: Concepts, Tools and Research Challenges
Glauco Estcio Gonalves, Patrcia Takako Endo, Thiago Damasceno Cordeiro, Andr Vitor de Almeida Palhares, Djamel Sadok, Judith Kelner, Bob Melander, Jan-Erik Mngs
Abstract Cloud computing is an attractive computing model since it allows for the provision of resources on-demand. Such a process of allocation and reallocation of resources is the key to accommodating unpredictable demands and improving the return on investment from the infrastructure supporting the Cloud. However, despite the recent growth of the Cloud Computing market, several problems with the process of resource allocation remain unaddressed. This short course introduces essential concepts and technologies regarding Cloud Computing and presents some research questions on the topic, focusing on the challenges and the state-of-the-art solutions in resource allocation. Resumo Computao na Nuvem um modelo de computao atrativo, uma vez que permite que recursos sejam provisionados sob demanda. Tal processo de alocao e realocao de recursos a chave para acomodar demandas imprevistas e para melhorar o retorno de investimento na infraestrutura que suporta a Nuvem. Entretanto, a despeito da recente expanso do mercado de Computao na Nuvem, diversos problemas relativos alocao de recursos permanecem abertos. Este minicurso introduz os conceitos e tecnologias essenciais da Computao em Nuvem e apresenta algumas questes de pesquisa na rea, focando nos desafios e solues para alocao de recursos.
198
5.1. Introduction
Cloud Computing offers an interesting solution for software development and access of content with transparency of the underlying infrastructure locality. The Cloud infrastructure is usually composed of several datacenters and consumers have access to only a slice of the computational power over a scalable network. The provision of these computational resources is controlled by a provider, and resources are allocated in an elastic way, according to consumers needs. The use of Clouds as a type of infrastructure for running software is quite different than traditional practices, where software runs over infrastructures often dimensioned according to the worst case use and peak scenarios. To accommodate unforeseen demands on the infrastructure in a scalable and elastic way, the process of allocation and reallocation in Cloud Computing must be dynamic. Furthermore, another essential feature of the resource allocation mechanisms in Cloud Computing is to guarantee that the requirements of all applications are suitably met. According to [Khan, 2009], a resource allocation is defined to be robust against perturbations in specified system parameters if degradation in the performance feature is limited when the perturbations occur within a certain range. To achieve this requirement, any allocation mechanism in Cloud Computing should be aware of the status of each element/resource in the infrastructure. Then, the mechanism should apply algorithms to better allocate physical or virtual resources to consumers applications, according to the requirements pre-established with the cloud provider. Beyond the benefit of elastic services, Cloud Computing allows consumers to reduce or eliminate costs associated with internal infrastructure for the provision of their services. This opportunity of cost reduction makes Cloud Computing a very attractive alternative for consumers, especially for business initiatives. Enterprises can effectively offload operational risks to cloud providers. From the perspective of cloud providers, the model offers a way for better utilization of their own infrastructure. Authors in [Armbrust et al 2009] suggest that this model benefits from a form of statistical multiplexing, since it allocates resources for several users concurrently. This statistical multiplexing of datacenters is guaranteed through several decades of research in areas such as: distributed computing, grid computing, web technologies, service computing, and virtualization. However, despite the recent and notable growth of the Cloud Computing market, there are several key issues open with the process of resource allocation. This short course introduces essential concepts and technologies for Cloud Computing. It also presents some research questions on the area, focusing on the challenges and state-ofthe-art solutions for resource allocation. 5.1.1. The Emergence of Cloud Computing Nowadays, there are several definitions for Cloud Computing in literature, covering common terms like IaaS (Infrastructure as a Service), PaaS (Platform as a Service) and SaaS (Software as a Service). However, there is still confusion about the definition due to the lack of standardization. According to [Zhang et al 2010], the main reason for the existence of different perceptions of Cloud Computing is that it is not a new technology, but rather a new model that brings together a set of existing technologies to develop and
199
run applications in a different way. In fact, technologies such as virtualization and service oriented provisioning are not new, however Cloud Computing uses them to offer a new service to its consumers and, at the same time, to meet new business requirements. Such discussion about the definition of Cloud Computing will be reexamined in more detail on Section 5.2.1. Since the popularization of the Cloud Computing term in 2007, with IBM Blue Cloud [Vouk 2008], several enterprises have become Cloud Computing providers: Amazon with Elastic Compute Cloud (EC2)1, Google with Google App Engine2, Microsoft with Windows Azure Platform3, and Salesforce with Force.com4 . Despite offering services with different purposes, all of these solutions are called Clouds. Each solution has their own programmability level and therefore can be put in their specific class. More about the different proposals for the classification of Cloud initiatives will be presented in Section 5.2.3. As well as contributions from commercial interests, the Open Source Community has been very active in the development of Cloud Computing. They have supplied numerous contributions in related areas such as tools for interaction with existent Clouds, software for automated use of available Clouds, alternatives for standardization, and virtualization. Moreover, the Open Source Community is actively developing solutions for management clouds, especially those employed in academic research around the world. Some of these tools are presented in Section 5.5. 5.1.2. The value of Cloud for Business Many organizations have invested in Cloud Computing, and to date more than 150 enterprises have entered the industry as Cloud providers5. On the side of Cloud consumers, a recent study of more than 600 companies by InformationWeek reported that the number of companies using Cloud Computing increased from 18% in February 2009 to 30% in October 2010, a 67% increase. Moreover, an interesting worldwide survey by Gartner6 identified Cloud Computing as the top technology priority for CIOs in 2011. The cited business research on Cloud Computing demonstrates financial interest and reveals the increasing credibility of Cloud Computing. Such growth is motivated by its ongoing consolidation as well as by the revenues that customers and operators are observing with Cloud Computing. It is interesting to notice the different viewpoints of both parties: from the side of enterprises that are using Cloud Computing, it is very attractive since it provides opportunity for cost reductions with internal infrastructure, as well as other advantages. Alternately, from the providers viewpoint, Cloud Computing makes it possible to increase revenues using their own IT infrastructure. However, such investment should be carefully dimensioned, since consumers have high expectations
1 2 3 4 5 6
http://aws.amazon.com/ec2/ http://code.google.com/intl/appengine/appengine/ http://www.microsoft.com/windowsazure/ http://www.salesforce.com/platform/ http://cloudcomputing.sys-con.com/node/770174 http://www.gartner.com/it/page.jsp?id=1526414
200
about the elasticity of their applications. Metaphorically, one can say that consumers expect that providers resources be infinite. Questions like How many physical machines are necessary to accommodate my unpredictable demand? and How many consumers are necessary to obtain financial returns in a reasonable time? should be taken into consideration by providers. In this way, considering the providers viewpoint, resource management in this business scenario should be treated very cautiously. Authors in [Buyya et al 2008] believes that market-oriented resource management is necessary to regulate supply and demand of resources to achieve market equilibrium. They suggest that this would provide feedback in terms of economic incentives for both consumers and providers. Furthermore, they promote the use of QoS-based resource allocation mechanisms that differentiate service requests based on their utility. 5.1.3. The value of Cloud for Academy In parallel to the commercial growth of Cloud Computing, it is prevalent in academic circles and is the theme of many research projects around the world. Many important proposals of open architectures were developed by academic institutes, such as the Cumulus Project [Wang et al 2008], and Eucalyptus [Nurmi et al 2009],. The Cumulus Project is based on OpenNebula [OpenNebula Project 2011a], and it intends on providing virtual machines, virtual applications and virtual computing platforms for scientific applications. Visualizing the integration of already existing technologies, the Cumulus project uses HP and IBM blade servers running Linux and the open-source Xen hypervisor7. Eucalyptus is another open source Cloud Computing framework that provides resources for experimental instrumentation and academic study. Eucalyptus users are able to start, control, access, and terminate entire virtual machines. In its current version, Eucalyptus supports VMs that run atop the Xen supervisor [Barham et al 2003]. Beyond open architectures and tools, resource allocation is another topic that has been attracting attention in the academic community. Some work had been done to address this problem, but with different focuses. At the same time, one can note that the resource allocation issue is not a new problem. There are many solutions focused in the datacenter area ([Urgaonkar et al 2010], [Chen et al 2010], [Kong et al 2010]) and Grid Computing ([Murphy et al 2010], [Xhafa and Abraham 2010]). In this way, some of the new strategies for resource allocation employ these existing solutions by adapting them to be used in Cloud Computing environments ([Lee et al 2010], [Beloglazov and Buyya 2010], [Buyya et al 2010]). There is also a different way to handle resources in Clouds that is based on the allocation problems in Virtual Network Environments [Chowdhury 2009]. General concepts from the area of networks virtualization can be applied to the field of Cloud Computing. This can be done by considering that virtual networks can be associated with developers applications, which are composed of several servers and databases as well as the network elements (routers, switches, and links) between them. Section 5.4.3
http://xen.org/
201
describes the resource allocation problems on network virtualization technology in more detail. There are many academic papers relating to challenging research in Cloud Computing, such as automated service provisioning, server consolidation, and energy management. Some of these challenges are discussed in Section 5.3. Indeed, this is the major motivation for Cloud Computing in academia: there are many questions to be answered. 5.1.4. Structure of the short course This paper presents and discusses the state-of-the-art and the challenges of resource allocation for Cloud Computing. To better understand these challenges, the remainder of this paper is organized as follows. Section 5.2 introduces the basic principles of Cloud Computing by presenting the definitions, agents, and a classification of Cloud operators. This section is important because it demonstrates the authors view about Cloud Computing and presents definitions used throughout of this paper. Section 5.3 focuses on the description of research opportunities in Cloud Computing. For didactical reasons, these research questions were classified in three areas: negotiation, resource management, and resource control. Challenges in the negotiation area are related to the creation of innovative interfaces between developers and the Cloud. Challenges in the resource management and resource control areas are related to automated provisioning of resources, including energy-efficient, VM migration and cloning, development of communication protocols, and security and privacy. Resource management and resource control layers are faced with the problem of selecting the best suitable physical/virtual resources to accommodate applications under previously negotiated requirements. In this short course, we address these issues by describing concepts and solutions of resource allocation problem in Section 5.4. Section 5.5 is focused on describing some of the existing open source solutions by highlighting their main characteristics and architectures. Finally, a conclusion of this paper and future trends are presented in Section 5.6.
5.2. What is Cloud Computing?

In this section the main concepts of Cloud Computing will be presented. It will begin with a discussion on the definition of Cloud Computing (Section 5.2.1) and the main agents involved in Cloud Computing (Section 5.2.2). After that, classifications of Cloud initiatives are offered in Section 5.2.3. Finally, some of the main technologies acting behind the scenes of Cloud Computing initiatives are presented in Section 5.2.4. 5.2.1. Definitions Considering the differences between the several Cloud Computing initiatives, one can understand Cloud Computing as a broad area encompassing such different research areas as Grid Computing and Content Delivery Networks (CDNs). Regardless of their coverage, Cloud Computing may be seen as a commonplace for all these areas, since it is able to offer solutions to the problems of each area and it can be applied according to
202
respective singularities. Thus, far from intruding into those research areas, Cloud Computing establishes relationships with them. Basically there are two relationships: on one hand, Cloud Computing inherits techniques and algorithms from each area; on the other hand, Cloud Computing offers an infrastructure for applications of these areas. This occurs with Grid Computing, for example, since traditional task allocation techniques used in grids can be used on Clouds and, at the same time, uncertainties in availability and performance present in grids can be solved with Clouds infrastructure [Lee and Zomaya 2010]. With CDNs a similar relationship occurs; Cloud Computing can adapt servers placement algorithms to its own necessities [Presti et al. 2007] and CDNs can use Cloud Computing environments to improve their operations ([Ramaswamy et al. 2005], [Broberg et al. 2009]). Despite this relationship with other areas and the increasingly widespread use of the Cloud Computing term, the concept lacks a formal definition. Authors in [Vaquero et al. 2008] reviewed the literature for a minimum set of characteristics that Clouds must exhibit. However, they were not able to find a single common feature between current definitions. On the other hand, they noted that the set of characteristics that is most similar to a minimum common definition is: elasticity, pay-per use model, and virtualization. The first two characteristics are essential for Cloud Computing and are complementary, since users want to rent and release resources on-demand and pay for what they use. However, there is no consensus about virtualization. Some other definitions ([Buyya et al. 2009], [Armbrust et al. 2009]) highlight virtualization as an essential technology for Cloud Computing, but leading enterprises in this area, like Google [Sheth 2009], affirm that such technology is dispensable for their solutions. The concept here is that virtualization is an old solution in computer science, frequently identified with some form of abstraction, which can be used with different purposes [Padala 2010]. Several solutions, like Amazon EC2, use server virtualization technologies to break a powerful physical computational resource into smaller, virtual entities to be sold. Alternately, other initiatives, like Google App Engine, use distributed processing technologies that join several computational resources into only one virtual computational resource offering an environment like a supercomputer. From the minimum set of characteristics encountered by [Vaquero et al. 2008] (elasticity, pay-per use model, and virtualization), they also formulated their own definition of Clouds: Clouds are a large pool of easily usable and accessible virtualized resources. These resources can be dynamically recongured to adjust to a variable load, allowing also for an optimum resource utilization. This pool of resources is typically exploited by a pay-per-use model in which guarantees are offered by the Infrastructure Provider by means of customized SLA. Other authors give a similar definition [Buyya et al. 2009]: A Cloud is a type of parallel and distributed system consisting of a collection of inter-connected and virtualized computers that are dynamically provisioned and presented as one or more unified computing resource(s) based on service-level agreements established through negotiation between the service provider and consumers. Please note that both definitions cite the use of service-level agreements as a necessary aspect in Cloud Computing. An interesting definition of Cloud Computing is given by the National Institute of Standards and Technology (NIST) of the United States: Cloud computing is a model for enabling convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that
203
can be rapidly provisioned and released with minimal management effort or service provider interaction [Mell and Grace 2009]. The definition confirms that on-demand dynamic reconfiguration (previously called elasticity) is a key characteristic. Additionally, the NIST definition highlights another Cloud Computing characteristic: it assumes that there are minimal management efforts required to reconfigure resources. In other words, the Cloud must offer self-service solutions that must attend to requests ondemand. This is important because it excludes from the scope of Cloud Computing those initiatives that operate through the rental of computing resources in a weekly or monthly basis. Hence, it restricts Cloud Computing to systems that provide automatic mechanisms for resource rental in real-time with minimal human intervention. The NIST definition gives a satisfactory explanation of Cloud Computing as a computing model. But, contrary to the two previously cited definitions, NIST does not cover the main object of Cloud Computing: the Cloud. Thus, in this short course, Cloud Computing is defined as the computing model that operates based on Clouds. In turn, the Cloud is defined as a conceptual layer that operates above an infrastructure to provide services in a timely manner. This definition encompasses three main characteristics of Clouds. Firstly, it notes that a Cloud is primarily a concept, i.e., a Cloud is an abstraction layer over an infrastructure. Thus, since Clouds are simply a concept, they are independent of the technologies in the infrastructure and therefore one can accept different setups, like Amazon EC2 or Google App Engine, to be named Clouds. Moreover, the infrastructure is defined in a broad sense once it can be composed by software, physical devices, and/or other Clouds, as occurs with Dropbox8 that is hosted by the Amazon Simple Storage Service (S3)9. Secondly, all Clouds have the same purpose: to provide services. This means that a Cloud hides the complexity of the underlying infrastructure while exploring the potential of overlying services, acting similarly to a middleware. Also, providing a service involves, implicitly, the use of some type of agreement that should be guaranteed by the Cloud. Such agreements can vary from pre-defined contracts to malleable agreements defining functional and non-functional requirements. Thirdly, the Cloud must provide services as quickly as possible such that the infrastructure resources are allocated and reallocated to attend the users needs. 5.2.2. Agents involved in Cloud Computing Several authors ([Vaquero et al. 2008], [Buyya et al. 2009], [Zhang et al 2010], and [Vouk 2008]) have presented the agents involved in Cloud Computing. However, there is some discordance between the explanations of each one. Therefore, this short course will focus only on three distinct agents in Cloud Computing as shown in Figure 5.1: clients, developers, and provider. The first notable point is that the provider will deal with two types of users that, in this short course, are called developers and clients. Such differentiation is important because, in Cloud Computing, users (developers) can create new services that will be accessed by another type of users (clients). Thus, clients are the customer of a service produced by a developer. They lease services from developers and use these services, but such use generates demand to the provider that hosts the
8 9
http://www.dropbox.com/ https://s3.amazonaws.com/
204
service, and therefore the client can also be considered a user of the Cloud. It is important to highlight that in some scenarios (like scientific computation or batch processing) a developer may behave as a client to the Cloud because it is the end-user of its applications. Please note that the text will use users when referring to both classes without distinctions.
Client
Client
Client
Client
Developer
Developer
Figure 5.1. Agents in a typical Cloud Computing scenario
Developers can be service providers, independent programmers, scientific institutions, and so on, all who build applications into the Cloud. Please note that, a priori, developers do not need to know about the architectures and technologies that compound the Cloud infrastructure, nor about the specific location of each item in the infrastructure. This concept can be called as transparency of locality. Basically, developers want to create and run their applications while keeping decisions related to maintenance and management of the infrastructure to the provider. Lastly, it must be clarified that the term application is used to mean all types of software that can be developed on the Cloud. These applications may be requisitioned from clients or from developers, depending on the applications purpose as determined by its developer. In addition, it is important to notice that the type of applications supported by a Cloud depends exclusively on the purposes of the Cloud determined by the provider. Such variety of purposes generates many different types of Cloud Operators that are discussed in Section 5.2.3. Please note that the aforementioned agents are a simplification of the entire ecosystem that can emerge from Cloud Computing. The figure of the Cloud Brokers, for example, arises naturally. [Buyya et al. 2009] defines that such brokers have the mission of acting on behalf of developers to select suitable providers and negotiate application requirements with them. Also, brokers operating in the Cloud Computing market will force standardization in the industry, since they will need to compare information from each operator on a solid and clear basis. 5.2.3. Classification of Cloud Operators Currently, there are several operational initiatives of Cloud Computing; however despite all being called Clouds, they provide different types of services. For that reason, the academic community ([Vaquero et al. 2008], [Buyya et al. 2009], [Mell and Grace 2009], [Zhang et al. 2010], [Youseff et al. 2008]) precisely classified these solutions in order to understand their relationships. The three complementary proposals for classification are as follows.
205
Classification according to the intended audience This first simple taxonomy is suggested by NIST [Mell and Grace 2009] and tries to organize providers according to the deployment model of the Cloud, i.e., according to the audience at which the cloud is aimed. There are four classes in this classification: Private Clouds, Community Clouds, Public Clouds, and Hybrid Clouds. The first three classes accommodate providers in a gradual opening of the intended audience coverage. The Private Cloud class encompasses such types of Clouds destined to be used solely by an organization operating over their own datacenter or one leased from a third party for exclusive use. When the Cloud infrastructure is shared by a group of organizations with similar interests it is classified as a Community Cloud. Furthermore, the Public Cloud class encompasses all initiatives intended to be used by the general public. It is important to highlight that this latter class is the main focus of the literature on Cloud Computing since it offers the main challenges. Finally, Hybrid Clouds are simply the composition of two or more Clouds pertaining to different classes (Private, Community, or Public). Classification according to the service type In [Youseff et al. 2008], authors offer a classification as represented in Figure 5.2. Such taxonomy divides Clouds in five categories: Cloud Application, Cloud Software Environment, Cloud Software Infrastructure, Software Kernel, and Firmware/Hardware. By employing the concept of service composition from the realm of Service-Oriented Architecture (SOA), authors arrange the different types of Clouds in a stack, showing that Clouds of higher levels are created using services in lower levels. This idea pertains to the definitions of Cloud Computing discussed previously in Sections 5.2.1 and 5.2.2. Essentially, the Cloud operator does not needs to be the owner of the infrastructure. However, this classification allows each layer to use services of all layers below, permitting a Cloud on the Cloud Application layer to operate over their own physical infrastructure.
Figure 5.2. Classification of Cloud types (from [Youseff et al. 2008])
The class in the top of the stack, also called Software-as-a-Service (SaaS), involves applications accessed through the Internet, including social networks, webmail, and office tools. Such services provide software to be used by the general public, whose main interest is to avoid tasks related to software management like installation and updating. Moreover, for the same reasons, these services can target businesses as in the case of Customer Relationship Manager (CRM) software provided by Salesforce.com. From the point of view of the cloud operator, SaaS can decrease costs with software implementation when compared with traditional processes. Similarly, the Cloud Software Environment, also called Platform-as-a-Service (PaaS), encloses Clouds that
206
offer programming environments for developers. Through well-defined APIs, developers can use software modules for access control, authentication, distributed processing, and so on, in order to produce their own applications in the Cloud. Also, developers can contract services for automatic scalability of their software, databases, and storage services. In the middle of the stack is the Cloud Software Infrastructure class of initiatives. This class encompasses solutions that provide virtual versions of infrastructure devices found on datacenters like machines, databases, links, and so on. Clouds in this class can be divided into three subclasses according to the type of resource that is offered by the Cloud. Computational resources are grouped in the Infrastructure-as-a-service (IaaS) subclass that provides generic virtual machines that can be used in many different ways by the contracting developer. Services for massive data storage are grouped in the Data-as-a-Service (DaaS) class, whose main mission is to save users data on remote disks, which allows access to these users from anywhere and at anytime. Finally, the third subclass, called Communications-as-a-Service (CaaS), is composed of solutions that offer virtual private links and routers through telecommunication infrastructures. The last two classes do not offer Cloud services specifically, but they are included in the classification to show that providers offering Clouds in higher layers can have their own software and hardware infrastructure. The Software Kernel class includes all of the software necessary to provide services to the other categories like operating systems, hypervisors, cloud management middleware, programming APIs, libraries, and so on. The class of Firmware/Hardware covers all sale and rental services of physical servers and communication hardware. Classification according to programmability The five-class scheme presented above can classify and organize the current spectrum of Cloud Computing solutions, but such a model is limited because the number of classes and their relationships will need to be rearranged as new Cloud services emerge. Therefore, in this short course, a different classification model will be used based on the programmability concept, which was previously introduced in [Endo et al. 2010]. Borrowed from the realm of network virtualization [Chowdhury and Boutaba 2010], programmability is a concept related to the programming features a network element offers to developers, measuring how much freedom the developer has to manipulate resources and/or devices. This concept can be easily applied to the comparison of Cloud Computing solutions. More programmable Clouds offer environments where developers are free to choose programming paradigms, languages, and platforms, thus having more control over their leased resources. Less programmable clouds restrict developers in some way: perhaps by forcing a set of programming languages on the developer or by providing support for only one application paradigm. On the other hand, programmability directly affects the way developers manage their leased resources. From this point-of-view, providers of less programmable Clouds are responsible to manage their infrastructure while being transparent to developers. In turn, a more programmable Cloud leaves more of these tasks to developers, thus introducing management difficulties due to the more heterogeneous programming environment. Thus, Cloud Programmability can be defined as the level of sovereignty developers have to manipulate services leased from an operator. Programmability is a
207
relative concept, i.e., it was designed to compare one Cloud with others. Also, programmability is directly proportional to heterogeneity in the infrastructure of the provider and inversely proportional to the amount of effort that developers must spend to manage leased resources. To illustrate how the concept can be used, one can classify two current Clouds: Amazon EC2 and Google App Engine. One can note that Amazon EC2 is more programmable, since in this Cloud developers can choose between different virtual machine classes, operating systems, and so on. After they lease one of these virtual machines, developers can configure it to work as they see fit: as a web server, as a content server, as a unit for batch processing, and so on. On the other hand, Google App Engine can be classified as a less programmable solution, because it allows developers to create web applications that will be hosted by Google. This restricts developers to the Web paradigm and to some programming languages. 5.2.4. Mediation System Figure 5.3 introduces an Archetypal Cloud Mediation System that can be used as a reference to the main targets of a Cloud Mediation System. The Archetypal Mediation System was developed while focusing on one principle: resource management as the main service of any Cloud Computing provider. Thus, this reduced mediation system relegates other important services like authentication, accounting, and security, for example, to the group of auxiliary services that is out of the scope of this short course. Clients also do not factor into this view of the system, since resource management is mainly related to the allocation of developers applications and meeting their requirements.
Developer Developer
Mediation System
Negotiation Resource Management Resource Control
Resources
Figure 5.3. Components of a Archetypal Cloud Mediation System
The mediation system is responsible for the entire process of resource allocation in the Cloud. Such a process covers tasks that range from the automatic negotiation of developers requirements to the execution of their applications. It has three main layers: negotiation, resource management, and resource control. The negotiation layer deals with the interface between the Cloud and developers. In the case of Clouds serving infrastructure services, the interface can be a set of operations based on Web Services for access and control of the leased virtual machines. Alternately, in the case of PaaS services, this interface can assume the form of an API with programming primitives for software development in the Cloud. Moreover, the negotiation layer handles the process of contract establishment between the enterprises and the Cloud. Currently, this process is simple and the contracts tend to be restrictive.
208
One can expect that in the future, Clouds will offer more sophisticated avenues for user interaction through high level abstractions and service level policies. The resource management layer is responsible for the optimal allocation of applications for obtaining the maximum usage of resources. This function requires advanced strategies and heuristics to allocate resources that meet the contractual requirements as established with the application developer. These may include service quality restrictions, jurisdiction restrictions, elastic adaptation, and so on. Metaphorically, one can say that while the resource management layer acts as the brain of the Cloud, the resource control layer plays the role of its limbs. The resource control encompasses all of the functions needed to enforce decisions generated by the upper layer. Beyond the tools used to configure the Cloud resources effectively, all communication protocols used by the Cloud are included in this layer. 5.2.5. Groundwork Technologies In the following section, some of the technologies that compose the groundwork in current mediation systems on Cloud Computing (namely Service-oriented Computing, Virtualization, MapReduce Framework, and Datacenters) will be discussed. Service-Oriented Computing Service-Oriented Computing (SOC) defines a set of principles, architectural models, technologies, and frameworks for the design and development of distributed applications based on the Service-Orientation paradigm. In turn, Service-Orientation is a design paradigm intended for the creation of solution logic units (services) that are individually shaped so that they can be collectively and repeatedly utilized [Erl 2009]. The development of software focused on services gave rise to SOA (ServiceOriented Architecture), which can be defined as an architectural model that supports the discovery, message exchange, and integration between loosely coupled services using industry standards [Khoshafian 2007]. In other words, SOA defines a set of standards for the design and development of systems, and can be easily reused and combined to adapt to changes in business requirements. The common technology for the implementation of SOA principles is the Web Service that defines a set of standards to implement services over the World Wide Web. In Cloud Computing, SOA is the main paradigm for the development of functions on the negotiation layer. Operators publish APIs for their services on the web, allowing developers to use the Cloud and to automate several tasks related to the management of their applications. Such APIs can assume the form of WSDL documents10, REST-based documentation11, or libraries for popular programming languages12. Also, operators can make available SDKs and other toolkits for the manipulation of applications running on the Cloud.
10 11 12
http://s3.amazonaws.com/ec2-downloads/ec2.wsdl http://kenai.com/projects/suncloudapis/pages/Home http://code.google.com/intl/pt-BR/appengine/docs/
209
Server Virtualization Server (or platform) virtualization is a technique that allows a computer system to be partitioned on multiple isolated execution environments similar to a single physical computer, which are called Virtual Machines (VM). Each VM can be configured in an independent way having its own operating system, applications, and network parameters. Commonly, such VMs are hosted on a physical server running a hypervisor, which is a piece of software that effectively virtualizes the server and manages the VMs [Padala 2010]. There are several hypervisor options that can be used for server virtualization. From the open-source community, one can cite Citrixs Xen13 and the Kernel-based Virtual Machine (KVM)14. From the realm of proprietary solutions, some examples are VMWare ESX15 and Microsofts HyperV16. The main factor that boosted up the adoption of server virtualization within Cloud Computing is that such technology offers good flexibility regarding reallocation of workloads across the physical resources. Such flexibility allows, for example, for operators to execute maintenance without stopping developers applications (that are running on VMs) or to implement strategies for better resource usage through the migration of VMs. Also, server virtualization is adapted for the fast provisioning of new VMs through the use of templates, which enables providers to offer elasticity services for applications developers [Marshall et al. 2010]. MapReduce Framework MapReduce [Dean and Ghemawat 2004] is a programming framework developed by Google for distributed processing of large data sets across computing infrastructures. Inspired on the map and reduce primitives present in functional languages, authors of MapReduce developed an entire framework for the automatic distribution of computations. In this framework, developers are responsible for writing map and reduce operations and for using them according to their needs, which is similar to the functional paradigm. These map and reduce operations will be executed by the MapReduce system that transparently distributes computations across the computing infrastructure and treats all issues related to node communication, load balance, and fault tolerance. Also, for the distribution and synchronization of the data required by the application, the MapReduce system also requires the use of a distributed file system called Google File System (GFS) [Ghemawat et al. 2003]. Despite being introduced by Google, there are some open source implementations of the MapReduce system, like Hadoop17 and TPlatform18. The former is popular open-source software for running applications on large clusters built of commodity hardware. This software is used by companies like Amazon, AOL, and
13 14 15 16 17 18
http://www.xen.org/products/cloudxen.html http://www.linux-kvm.org/page/Main_Page http://www.vmware.com/ http://www.microsoft.com/hyper-v-server/en/us/default.aspx http://hadoop.apache.org/ http://net.pku.edu.cn/~webg/tplatform/
210
IBM, as well as in different web applications such as Facebook, Twitter, Last.fm etc19. Basically, Hadoop is composed of two modules: a MapReduce environment for distributed computing, and a distributed file system called Hadoop Distributed File System (HDFS). The latter is an academic initiative that provides a development platform for web mining applications. Similarly to Hadoop and Googles MapReduce, the TPlatform has a MapReduce module and a distributed file system called Tianwang File System (TFS) [Peng et al. 2009]. The use of MapReduce solutions is common groundwork technology in PaaS Clouds because it offers a versatile sandbox for developers. Differently from IaaS Clouds, PaaS developers using a general-purpose language with MapReduce support do not need to be concerned about software configuration, software updating, network configurations, and so on. All these tasks are the responsibility of the Cloud provider, which, in turn, benefits from the fact that configurations will be standardized across the overall infrastructure. Datacenters Developers who are hosting their applications on a Cloud wish to scale their leased resources, effectively increasing and decreasing their virtual infrastructure according to the demand of their clients. This is also true for developers making use of their own private clouds. Thus, independently of the class of Cloud in question, a robust and safe infrastructure is needed. Whereas virtualization and MapReduce respond for the software solution to attend this demand, the physical infrastructure of Clouds relies on one or more datacenters. These datacenters are infrastructures composed of TI components providing processing capacity, storage, and network services for one or more organizations [Veras 2009]. Currently, the size of a datacenter (in number of components) can vary from tens of components to tens of thousands of components depending on the datacenters mission. Also, there are several different TI components for datacenters including switches and routers, load balancers, storage devices, dedicated storage networks, and, the main component of any datacenter, servers [Greenberg et al. 2008]. In terms of servers, the blade variety arises as a good solution for Cloud Computing, since they possess modular design optimized to minimize expenditures of power consumption, cooling capacity, and the use of physical space [Veras 2009]. Once a blade server chassis has been installed, additional servers can be added into bays while the system is up and running, which promotes scalability. However, the initial configuration can be labor-intensive and expensive. This disadvantage comes with the fact that the blade servers are specialized computing equipment and their configuration and administration often requires training provided by the vendor, which may not be inexpensive. For Cloud Computing, the use of datacenters provides the required power to attend developers demands on processing, storage, and networking capacities. Also, a large datacenter, running a virtualization solution, allows for better usage of the hardwares power through the statistical multiplexing of developers applications.
19
http://wiki.apache.org/hadoop/PoweredBy
211
5.3. Open Research Problems

Despite the large number of current Cloud solutions, several research challenges remain open. For didactical reasons, the research questions were grouped into three areas following the three layers presented in Section 5.2.4: negotiation, resource management, and resource control. Upcoming sections will discuss the main challenges to address in each one of these areas: Section 5.3.1 will discuss challenges in the negotiation layer and Section 5.3.2 will discuss challenges in the resource management and resource control layers jointly. 5.3.1. Challenges in the negotiation layer Challenges in the negotiation area are related to the creation of innovative interfaces between developers and the Cloud. Currently, these interfaces assume the form of an API that, according to the programmability level, can range from a web-service toolkit for VM manipulation (e.g. Amazon EC2) to a set of programming primitives used to develop applications (e.g. Google App Engine). In addition, such APIs allow developers to request and control additional functionalities like service quality assessment, load balance, elastic application growth, backup strategies, and so on. However, the next generation of Clouds which are associated with the Internet of Services20 must offer sophisticated interaction mechanisms for human users, which can be based on service-level specifications. This type of interface will demand formal approaches to specifying the operators offerings and the developers requirements. Also, it is important to highlight that these requirements and offerings will overcome current requirements while considering issues like geographical restrictions or juridical/political aspects. Beyond the internal challenges faced by Clouds, the new service-aware markets, as emphasized by [Llorente 2010], will bring both new opportunities and new challenges to the interaction between operators. These operators will provide specific interfaces on which their services/resources can be aggregated by developers (or brokers) to compose new services to be offered. Thus, an upcoming issue in the future that must be overcome is the need for standardization. Currently, the main market providers offer proprietary interfaces to access their services, which can hinder users within their infrastructure as the migration of applications cannot be easily made between cloud providers [Buyya et al 2009]. It is hoped that cloud providers identify this problem and work together to offer a standardized API based on open standards like SOAP and REST. An important effort in the search for standardization comes from the Open Cloud Manifesto21, which is an initiative supported by hundreds of companies that aims to discuss a way to produce open standards for Cloud Computing. Their major doctrines are collaboration and coordination of efforts on the standardization, adoption of open standards wherever appropriate, and the development of standards based on customer requirements. Participants of the Open Cloud Manifesto, through the Cloud Computing Use Case group, produced an interesting white paper [OpenCloud 2011] highlighting
20 21
http://cordis.europa.eu/fp7/ict/ssai/home_en.html http://www.opencloudmanifesto.org/
212
the requirements that need to be standardized in a cloud environment to ensure interoperability in the most typical scenarios of interaction Use Cases in Cloud Computing. Another group involved with Cloud standards is the Open Grid Forum22, which is intended to develop the specification of the Open Cloud Computing Interface (OCCI)23. The goal of OCCI is to provide an easily extendable RESTful interface for the management of Clouds. Originally, the OCCI was designed for IaaS setups, but their current specification [Metsch 2010] was extended to offer a generic scheme for the management of different Cloud services. Despite being currently adopted by Opensource projects only, considerable growth [Edmonds 2010] can be noted in the number of groups adopting OCCI as an alternative interface (OpenNebula, Eucalyptus, and Libvirt, for example) turning it into an interesting candidate for standard interfacing. According to [Sheth and Ranabahu 2010], Cloud interoperability faces two types of heterogeneities: vertical heterogeneity and horizontal heterogeneity. The first type is concerned with interoperability within a single Cloud and may be addressed by a common middleware throughout the entire infrastructure. Authors highlight the Open Virtualization Format24 (OVF), standard software used to manage VMs across a Cloud with heterogeneous infrastructure, which is already accepted by some hypervisors like VMWare ESX and VirtualBox25. Another solution for the vertical heterogeneity is Libvirt26, which is a free software API that provides a common generic and stable layer to manage VMs. Libvirt offers an abstraction to programmers since it supports execution on different hypervisors like: Xen, KVM, VirtualBox, and VMWare ESX. The second challenge, the horizontal heterogeneity, is more difficult to address because it is related to Clouds from different providers, and each provider has its own programmability level. Therefore, the key challenge is dealing with these differences. In this case, a high level of granularity in the modeling may help to address the problem. In [Sheth and Ranabahu 2010], the same authors describe three interoperability aspects where semantic models would benefit Clouds. The first aspect is about functional portability, since semantic models may be used to define and share functional aspects of applications in a platform-agnostic way. The second point is the lack of support for data migration between Clouds. Regarding this concept, the authors see an opportunity for using data models such as a Resource Description Framework (RDF). Finally, the last aspect is that of service description portability. The growing number of different Cloud APIs makes the composition of cloud services difficult to achieve. Thus, the authors suggest using some scheme of annotation to enrich service descriptions and to permit easy combinations of cloud services.
22 23
24
http://www.gridforum.org/ http://occi-wg.org/about/specification/ http://www.dmtf.org/vman http://www.virtualbox.org/ http://www.libvirt.org/
25 26
213
5.3.2. Challenges in the resource management and resource control layers Although being two distinct layers, Resource Management and Resource Control face related challenges, which are treated jointly in this section. According to the discussion in [Zhang et al. 2010], the first challenge regarding these layers is to meet their main objective: the automated provisioning of resources. Certainly, this problem is not a new one, and several computing areas have faced such type of problem since early operating systems. However, due to the heterogeneous and time-variant environment in a Cloud, the resource provisioning becomes a complex task, forcing the mediation system to respond with minimal turnaround time in order to maintain the developers quality requirements. More details about this challenge will be treated in Section 5.4 under the discussion about resource allocation problems/solutions. The project of energy-efficient Clouds is another research challenge in Cloud Computing. Energy management is a current worldwide design concept, since there is considerable concern about the reduction of carbon footprints and the need for climate balance. Regarding Clouds, this point is especially relevant as a result of the high demand for electricity to power and to cool the servers hosted on them [Buyya et al. 2010]. According to [Zhang et al. 2010], this challenge involves remodeling technologies employed at datacenters for energy reduction, which can be approached from different perspectives including new datacenter architecture, energy-aware VM management, and the use of energy-efficient network protocols and network devices. As discussed in Section 5.2.4, operators implement Clouds using huge datacenters that are expensive to construct and require significant energy consumption. Also, their hierarchical architectures suffer from limitations like scalability, stiffness of address spaces, and node congestion in upper levels of the hierarchy. Such waste of resources has motivated research on the remodeling of datacenter architectures. Authors in [Verdi et al. 2010] surveyed this theme, highlighted the main problems on network topologies of state-of-the-art datacenters, and discussed literature solutions for these problems. Such solutions involve the development of new strategies for routing and forwarding, the creation of smart/programmable network devices, cross-layer interactions in the network protocols stack, and so forth. [Zhang et al. 2010] also suggest research on the creation of small datacenters, since they can offer a cheaper and more energy efficient consumer alternative to constructing a geographically distributed cloud, which is very adapted for time-critical services and interactive applications. Regarding energy-aware VM management, savings may be achieved through many different strategies, one of which is the consolidation of VMs in servers according to current resource utilization. This makes use of VM migration and cloning, a typical technology available on virtualized datacenters. The strategy and the feature both have their own open research points. VM migration and cloning provides an interesting technology to balance load over servers within a Cloud, provide fault tolerance to unpredictable errors, or reallocate applications before a programmed service interruption. But, although major industry hypervisors (like VMWare or Xen) have implemented VM migration techniques including live options, there remains some open problems to be investigated. These include cloning a VM into multiple replicas on different hosts [Lagar-Cavilla et al. 2009] and developing VM migration across wide-area networks [Cully et al. 2008]. Also, the use of migration introduces a network problem, since, after migration, VMs
214
require adaptation of the link layer forwarding. Some of the strategies for new datacenter architectures explained in [Verdi et al. 2010] offer solutions to this problem. Server consolidation is a useful strategy for minimizing energy consumption while trying to maintain high usage of the servers resources. The basic mechanism of this strategy saves the energy consolidating VMs (through migration) onto some servers and puts the idle servers into a standby state. The first open research point on this topic is the development of algorithms and heuristics for this type of problem, which can be mapped to bin-packing problems known to be NP-hard. [Zhang et al. 2010] also cites other related challenges to server consolidation: allocate VMs while maintaining their communication relationships and the prediction of VMs resource usage for the anticipation of migrations. Development of communication protocols in Clouds is another open field of research. Such protocols can act as a standard plane for resource management and control in the Cloud, allowing interoperability between devices. It is expected that such type of protocols can control and reserve resources of the different elements including processing servers, switches, routers, load balancers, and storage components present in the datacenter. One possible method of coping with this challenge is to use smart communication nodes with an open programming interface to create new services within the node. One example of this type of open nodes can be seen in the emerging Openflow-enabled switches [McKeown et al 2008]. Security and privacy issues are the main hurdles considered by potential users of Clouds. Developers and clients expect that providers will ensure confidentiality in the data access and expect a complete auditing system for confirming that there are no security breaches. Despite being present in prior discussions on distributed systems, security remains as an open research field in Cloud Computing since it requires new solutions (or adaptations of older ones) to cope with specific aspects of the cloud-based computing model. Such type of solution must cover the multiple sub-systems operating on Clouds and must be integrated into all devices and software pieces to allow complete auditing of the Cloud. Also, as indicated by [Chen, Paxson, and Katz 2010], research on this topic must be made from the base, and be initiated by categorizing all the threats to which Clouds are subject.
5.4. Resource Allocation

This short course is focused on the resource management and resource control layers. These layers are related to each other and the main objective is to implement resource allocation mechanisms that provide an automated provisioning of resources. In this way, one of the main purposes of any cloud operator is to schedule developers applications while aiming for the best utilization of available resources. A developers application covers, aside from the software, some additional information about the applications needs and services as negotiated previously. Thus, the Cloud Computing operator faces the problem of selecting the most suitable physical and virtual resources to accommodate these applications under the previously negotiated requirements. This section presents the main general concepts and also some already available solutions for this problem. First, general definitions on resource allocation are given and some terms that will be used throughout this section are clarified. Next, the main challenges related to
215
resource allocation are presented. More specifically, the fundamental aspects that are present while facing the resource allocation problem will be exhibited. Then some of the existing solutions will be presented, highlighting how its components fit under each one of the fundamental aspects. 5.4.1. Definitions for Resource Allocation Resource allocation is a subject that has been addressed in many computing areas, such as operating systems, grid computing, and datacenter management. A Resource Allocation System (RAS) in Cloud Computing can be seen as any mechanism that aims to guarantee that the applications requirements are attended to correctly by the providers infrastructure. Along with this guarantee to the developer, resource allocation mechanisms should also consider the current status of each resource in the Cloud environment, in order to apply algorithms to better allocate physical and/or virtual resources to developers applications, thus minimizing the operational cost of the cloud environment. An important point when allocating resources for incoming requests is how the resources are modeled. There are many levels of abstraction of the services that a cloud can provide for developers, and many parameters that can be optimized during allocation. The modeling and description of the resources should consider at least these requirements in order for the RAS works properly. Cloud resources can be seen as any resource (physical or virtual) that developers may request from the Cloud. For example, developers can have network requirements, such as bandwidth and delay, and computational requirements, such as CPU, memory and storage. Additionally, as explained in Section 5.3, other requirements are also feasible of Clouds, such as maximum delay between nodes, topology of the network of all nodes, jurisdiction issues, and interaction between different applications. Generally, resources are located in a datacenter that is shared by multiple clients, and should be dynamically assigned and adjusted according to demand. It is important to note that the clients and developers may see those finite resources as unlimited and the tool that will make this possible is the RAS. The RAS should deal with these unpredictable requests in an elastic and transparent way. This elasticity should allow the dynamic use of physical resources, thus avoiding both the under-provisioning and overprovisioning of resources. In this way, one may consider that the Cloud resources, resource modeling, and developer requirements are the inputs of a resource allocation system, as shown in Figure 5.4. Each one of these aspects will be described in more detail in the next section, since they are each closely related to the challenges on resource allocation.
216
Resource Modeling Cloud Resources Developer Requirements
Resource Allocation
Figure 5.4. Resource Allocation System Inputs
5.4.2. Research Challenges in Resource Allocation This section presents the main challenges faced while dealing with resource allocation under a Cloud. The challenges that a RAS should face are divided into four categories: resource modeling and description, resource offering and treatment, resource discovery and monitoring, and resource selection. When developing a resource allocation system, one should think about how to describe the resources present in the Cloud. The development of a suitable resource model and description is the first challenge that an RAS must address. An RAS also faces the challenge of representing the applications requirements, called resource offering and treatment. Also, an automatic and dynamic RAS must be aware of the current status of the Cloud resources in real time. Thus, mechanisms for resource discovery and monitoring are an essential part of this system. These two mechanisms are also the inputs for optimization algorithms, since it is necessary to know the resources and their status in order to elect those that fulfill all the requirements. Figure 5.5 shows how these challenges are related. First, the provider faces the problems grouped in the Conception Phase, where resources must be modeled according to the variety of services the Cloud will provide and the type of resources that it will offer. The next two challenges are faced in the scope of the Operational Phase. When requests for resources arrive, the RAS should initiate resource discovery to determine if there are indeed resources available in the Cloud to attend the request. Finally, if resources are available, the RAS may select and allocate them to serve the request. These challenges are described with more details next.
Conception Phase Operational Phase Resource Discovery and Monitoring
Resource Modeling
Resource Offering and Treatment
Resource Selection and Optimization
Figure 5.5. Relationship between resource allocation challenges
217
Resource Modeling and Description Resource modeling and description defines how the Cloud functions and how it deals with infrastructural resources. This modeling is essential to all operations in the Cloud. Management, control, and optimization algorithms are all dependent on the resource model chosen by the operator. Also, the services that a Cloud will provide to developers depend on this concept. Network and computing resources may be described by several existing specifications, such as Resource Description Framework (RDF)27 and Network Description Language (NDL)28. However, with Clouds it is very important that resource modeling takes into account schemas for representing virtual resources, virtual networks, and virtual applications. According to [Houidi et al. 2009], virtual resources need to be described in terms of properties and functionalities much like as in the way services and devices/nodes are described in existing service architectures. It is important to note that if a particular model is very detailed (description at a very low level) it means that its details are relevant and should not be disregarded, which in turn makes the optimization problem much more difficult to handle and solve. For example, if we consider that a request is composed of all the physical specifications of each machine, we will have to deal with the little details that in another situation could be disregarded or considered irrelevant. In this way, matching the request with available resources is rendered more difficult due to the peculiarities of each request, and achieving a generic solution is considerably more complicated. On the other hand, more details can give more flexibility and allow for a better usage of resources. This concept is called the granularity of the resources description. Solutions for Resource Modeling and Description There are many solutions that are focused on solving the challenges of resource description. Next, some of these solutions are surveyed and analyzed, with the objective being to exemplify the approaches that are being used to accomplish these challenges. Note that resource modeling and description is associated with a greater challenge in Cloud Computing: interoperability. The author in [Nelson 2009] describes the hazy scenario, in which large Cloud providers use proprietary systems, thus hampering the potential for integration between different Clouds. In this way, the main goal of interoperability in Clouds is to enable the seamless flow of data across Clouds from different providers and also between applications inside the same Cloud [Dillon and Chang 2010]. As explained in Section 5.3.1, solutions such as intermediary layers, standardization, and open APIs, are interesting options for interoperability. In the search for standardization, the Elastra29 has an interesting initiative. They have published their Elastic Modeling Languages that are a set of three languages defined using the Web Ontology Language (OWL): the Elastic Deployment Modeling Language (EDML), the Elastic Computing Modeling Language (ECML), and the Elastic Management Modeling Language (EMML). This set of languages expresses the
27 28 29
http://www.w3.org/RDF/ https://noc.sara.nl/nrg/ndl/ www.elastra.com/technology/languages
218
application requirements, state of cloud resources, and configurations required to enable automated application deployment and management [Charlton 2009]. The EDML provides a language to enable the description of common servers in datacenters such as web servers, application servers, databases, load balancers, etc. The language allows detailed descriptions of these servers ranging from the CPU architecture and storage technology, to the server configuration and software packages installed. The ECML is used to create a structural description for applications. It uses EDML descriptions to instantiate components and also introduces abstract units called connectors which are used to mediate communication between components. Furthermore, ECML can describe high-level requirements such as scalability, security, backup and others. Finally, the EMML permits information retrieval on ECML and EDML elements, since it maintains information regarding the current state and history of these items in the Cloud. A different solution is provided by the Application Descriptor Language (ADL), which is used to describe web applications in a specific grid operating system, called AppLogic30. The ADL modeling considers that resources may be real physical resources, or virtual ones sharing the same hardware. Basically, there are three types of descriptors: component, assembly, and package, as will be addressed below. The component descriptor describes specific network applications (such as an HTTP server or database server) located on a single host. The attributes of the component descriptor are all optional and are used to describe valid properties of the component. .migrateable is an example of a component attribute that indicates that the component can be migrated to another host. Beyond attributes, entities may also have sub-entities that define component characteristics. For example, resource defines components requirements such as CPU, memory, and network bandwidth. The assembly descriptor is used to describe a new component composed of several interconnected components, which can in turn be used to describe the structure of an application. Finally, the package descriptor is similar to a table of contents, in which re-usable components may be shared amongst all applications. In the same way as the other descriptors, the package descriptor also has their own attributes and sub-entities. Service Modeling Language (SML)31 and Service Modeling Language Interchange Format (SML-IF)32 are a pair of XML-based specifications created by leading information technology companies that have defined a set of XML and XML Schema documents, as well as several rules for the treatment of these documents. The SML specification defines the main concepts of the model, and is a set of interrelated XML documents that contain information about the different aspects of an IT service as well as the constraints that each aspect must satisfy to function properly. Constraints are captured in two ways. The first constraint is established through XML Schema documents, and the second is through the use of rule documents. SML uses common query languages such as XPath for rule construction. Once a model is defined,
30 31 32
http://doc.3tera.com/AppLogic24/AppLogic.html http://www.w3.org/TR/2007/WD-sml-20070806/ http://www.w3.org/TR/sml-if/
219
one can then establish its validity. This involves checking whether all documents satisfy the XML Schema constraints and the rule-based constraints. The SML-IF specification describes a packaging format for exchanging SMLbased models. It defines how all SML documents can be packaged into a single document without any loss of fidelity. The SML-IF specification enables interoperability between different implementations of SML. This is a result of the fact that all conforming implementations must be able to produce and consume SML-IF documents. Note that, in contrast to an SML document, the SML-IF document is not required to be complete. It is possible to have a scenario in which a provider sends an incomplete model to another provider so that they can be integrated together to produce a complete model. CML (Common Model Library) is a set of rules that uses SML to encode models and SML-IF to communicate between them. CML defines syntax and semantic for expressions for the purpose of managing entities in the IT environment. In summary, CML is a set of XML schemas that describes IT entities. This collection includes infrastructure (e.g. application servers), logical entities (e.g. software license, and IT roles), and relationships [Houidi et al. 2009]. Another XML-based solution is presented in [Houidi et al. 2009], where virtual resources are now considered. In this work, authors consider a network virtualization environment scenario where infrastructure providers should describe their virtual resources and services in order to be able to offer them. In this solution, properties and functionalities of the virtual resources are modeled in a UML class diagram. Authors suggest that their diagram can be represented in a XML-based document, but does not show an example document or a XML-Schema for such type of documents. Resource Offering and Treatment Once the resources are modeled, the Cloud provider may offer and handle them through an interface. At a lower level, the RAS should handle the Cloud resources and, at a higher level, address applications requirements. The resource offering interface should provide some way for developers to clearly describe the requirements of their application. These requirements may be represented by some form of a Service Level Agreement (SLA) that must be ensured by the provider through continuous monitoring of QoS, due to the dynamic nature of the Cloud [Patel et al. 2009][Yfoulis and Gounaris 2009]. Handling resources requires the implementation of solutions to control all resources available in the Cloud. Such control and management solutions would offer a complete set of signaling protocols to set up hypervisors, routers, and switches. Currently, to delegate these control tasks, each Cloud provider implements their own solution that descends, in general, from datacenter control solutions. They also employ virtual datacenter solutions developed by vendors like VMWare or Citrix33. However, in the future, new signaling protocols can be developed for integrated reservation of resources in the Cloud environment.
33
http://www.citrix.com/
220
It is important to highlight that resource modeling is not necessarily dependent on the way in which resources are offered to developers. For example, the Cloud provider could model each resource individually, like independent items in a finegrained scale (such as GHz of CPU or GB of memory), but can offer them like a coupled collection of items or a bundle, such as classes of VM (high memory and high processor types). As previously noted, in addition to traditional network requirements and computational requirements, new requirements for developers may be present in Clouds. An example of such a requirement is the topology of the network, which may be defined by developers. Developers are able to configure nodes relationships and communication restrictions (down and uplinks, for example). Jurisdiction is another example. It is related to where (physically) applications and their data must be stored and handled. Due to some restrictions such as copyright laws developers may solicit to store information in chosen places, such as specific countries or continents. The node proximity may be another restriction indicating that there should be a maximum (or minimum) physical distance (or delay value) between nodes or locations. Please note that it may directly impact other requirements, such as topology. Resource Discovery and Monitoring Resource discovery may be described basically as the task in which the provider should find appropriate resources (suitable candidates) in order to comply with incoming developers requests. Also, more specific questions, like How should one discover resources with (physical) proximity in a Cloud?, or How does one cause minimal impact upon network traffic responsibility? can be seen as a resource discovery responsibility and are not trivial to be answered, given the dynamic nature of the Cloud environment. Considering that one of the key features of Cloud Computing is the capability of acquiring and releasing resources on-demand [Zhang et al. 2010], resource monitoring should be continuous. This is because, in addition to serving as an information provider to handle new requests, it should also be informed of resources current status to make an informed decision of a possible reallocation, i.e., it must assist resource usage optimization. The timing and the quantity of messages is a relevant issue to be emphasized, because the network bandwidth should be used rationally. In this way, a careful analysis should be done to find a suitable trade-off between the amount of messages and the frequency of information refreshing. The monitoring may be passive or active. It is considered passive when there is an entity (or a set of entities) that collects information from nodes continuously, i.e., the nodes are passive in relation to this entity. The entity may send messages to nodes asking for information or simply may retrieve information when necessary. When the monitoring is active, nodes are autonomous and may decide when to send state information to some central entity. Clouds also make use of both alternatives simultaneously to improve the monitoring solution. A simple implementation of a resource discovery service is the discovery framework used in an advertisement process as described in [Houidi et al. 2009]. Such a framework is proposed for a scenario based on a network virtualization environment, but it can be easily adapted for other scenarios. Such a framework can be used by brokers to discover and match available resources, and typically is composed of
221
distributed repositories, which are responsible for storing information about and descriptions of physical and virtual resources. Resource Selection and Optimization After acquiring information about available resources in the Cloud (during the discovery phase), a set of appropriate candidates is highlighted. The resource selection mechanism elects the candidate solution that fulfills all requirements and optimizes the usage of the infrastructure. In virtual networks, for example, the essence of resource selection mechanisms is to find the best mapping between the virtual graph and the substrate graph. This should achieve the best load balancing in the substrate network resources, with respect to the capacity constrains [Houidi et al. 2008]. By this example, it is clear that selecting solutions from a set of available ones is not a trivial task due to the dynamicity of the scenario and all the different requirements that must be contemplated by the provider. The resource selection may be done using an optimization algorithm. Many optimization strategies may be used, from simple and well-known techniques such as simple heuristics with thresholds or linear programming, to newer ones, such as Lyapunov Optimization [Urgaonkar et al. 2010]. Moreover, traditional artificial intelligence algorithms ant colony and game theory [Teng and Magouls 2010], for example are also viable for Clouds. One way to classify resource selection strategies is related to the moment when optimization techniques are applied: a priori and a posteriori. In the case of a priori techniques, the first allocation solution is already an optimal solution. To achieve this goal, the optimization strategy should consider all variables that influence the allocation process. For example, consider that VM instances should be allocated in the Cloud; the optimization strategy should determine the problem, present a solution (or a set of possibilities) that satisfy all constraints, and attempt the goals (such as the minimization of resource reallocations) in an optimal manner. In the case of a posteriori techniques, once an initial resource allocation is made, which can be a suboptimal solution, the RAS should manage its resources in a continuous way. If necessary, decisions, such as to add more memory or storage capacity to a VM, reallocate an already allocated application, or reallocate resources for other applications, should be taken in order to optimize the system utilization or to comply with a developers requirements. Since the resource utilization and provisioning are dynamic (i.e., in addition to the resources being requested and then allocated, they can also be de-allocated), it is more interesting that the a posteriori optimization strategies reach an optimal allocation first, and are able to optimize the old requests and readjust them according to new demand. In this case, the optimization strategy may also fit with the definition of a priori and dynamic classification. Furthermore, optimization strategies may also be applied to improve specific aspects in the Cloud such as energy saving or to cope with polices for security and faulttolerance.
222
5.4.3. Solutions This section presents existing solutions that address the resource allocation problem and its challenges. These solutions come from several sources including state-of-art papers, existing techniques coming from other technologies (such as grid computing), and others. The reader should notice that the treatment given here is not extensive and can be seen only as a survey of information about these solutions. Also, one must keep in mind that the solutions presented here accomplish many of the described challenges. The resource allocation problem is not new. There are many solutions focusing on datacenters ([Urgaonkar et al. 2010], [Chen et al. 2010], [Kong et al. 2010]) and grid computing ([Murphy and Goasguen 2010], [Xhafa and Abraham, 2010]). Some of the new strategies for resource allocation employ these legacy solutions adapting them to be used in Cloud Computing environments ([Lee and Zomaya 2010], [Beloglazov and Buyya 2010], [Buyya et al. 2010]). Also, as will be described here, an approach is to treat the resource allocation on Cloud Computing based on a network virtualization viewpoint. As many of the solutions found try to optimize energy consumption, we will discuss it here as a major section. As an example, an RAS can achieve optimal energy consumption by observing the energy consumption in real time and by making decisions about reallocation, such as VM migration to liberate underused servers. The second major subsection is related to the time-response management of applications in the Cloud. In this section, the selected papers focus on optimizing the time that tasks take to be executed. This is important in order to fulfill the developers requirements and the overall performance of Clouds. Resource allocation based on virtual network environments is also reviewed. General concepts from this area can be applied to the field of Cloud Computing by considering that a virtual network can be associated with a developer application that is composed of several servers and databases as well as the network that interconnects them. More details on virtual networks can be found in [Chowdhury 2009]. Energy management As mentioned previously in Section 5.3, energy management is an important current worldwide design criterion especially in Cloud Computing. According to [Buyya et al. 2010], lowering the energy usage is a challenging and complex issue because computing applications and data are growing so quickly that increasingly larger servers and disks are needed to process them fast enough within smaller time periods. However, energy saving can be achieved through many strategies, such as consolidating VMs according to current resource utilization, turning off or setting CPU hibernation when servers become idle, moving workloads or VMs, and so on. Authors in [Urgaonkar et al. 2010] use queuing information to implement a resource allocation and energy management mechanism in virtualized datacenters. It assumes that to attend each application there is a certain number of VMs hosted by the same number of servers. The servers queuing information is used to make online control decisions, according to changes in the applications workload. The energy saving is done by switching idle servers into inactive mode when their workload is low, and turning them on again when workload increases. To achieve this goal, the authors
223
present the Datacenter Control Algorithm (DCA), which addresses clients requests according to the following three steps: Admission Control, Routing, and Resource Allocation. Each application has its own Admission Control module, which receives new requests and is responsible for verifying if new requests can be admitted using a threshold-based solution. After that, admitted requests can be routed between available servers, prioritizing active servers with the smallest requests queue. Finally, in a fully distributed way, servers allocate resources for each VM in order to minimize time to attend to their requests. Another energy management system for virtualized datacenters is proposed in [Beloglazov and Buyya 2010] and [Buyya et al. 2010]. The papers consider an environment where developers request VMs in the Cloud. In this scenario, providers have to deal with the tradeoff between energy and performance. Specifically, they must obtain minimum energy consumption while meeting developer requirements. Reduction of energy consumption is performed by switching off idle servers. The proposed system architecture is composed of the Dispatcher, the Global Manager, and the Local Manager. Clients requesting VMs send their requests to the Dispatcher that distributes requests between VMs. The Local Manager monitors the resources, specifically the usage of VMs and the state of servers. This information is sent to the Global Manager that is responsible for processing information from Local Managers and for resource selection. These decisions are divided into two parts: the admission of new requests and the optimization of current allocation. The admission control is made using some type of rank algorithm that allocates VMs to a server that will provide the smallest increase in power consumption. The optimization of VM allocation can be implemented using threshold-based heuristics. [Chen et al. 2010] proposes an integrated solution that couples the management of IT resources and cooling infrastructure to reduce the energy consumption of both systems. While continually monitoring the performance and the temperature of groups of servers, the system reallocates VMs in order to shutdown servers with low usage to save power. The system also manages air conditioners in the room according to IT resources needs. One interesting related problem is the application instance placement, defined in [Karve et al. 2006] as the problem of placing application instances on a given set of server machines to adjust the amount of resources available to applications in response to their resource demands. In [Steinder et al. 2008], authors developed an application placement controller that consolidates servers to achieve power savings without an unacceptable loss of application performance. To achieve this goal, two controllers work together: one controller monitors application performance information that will be used by the other one to place application instances, according to constraints such as CPU or memory capacity. The placement is managed by the starting and stopping of individual instances of applications. Response Time Management Response time management is an important concept related to how the resource allocation mechanism will treat the response time of the tasks to achieve good system performance. Ordinarily, this concept is used in Grid Computing. Makespan is a term
224
used to describe the amount of time taken from the initiation of the first task to the time the last task completes its execution [Lee and Zomaya 2010]. However, due to the dynamicity of grid resources usage, it is hard to guarantee that the makespan of a given schedule is reached. In this way, to ensure that tasks will finish their execution within the estimated completion times (in the presence of resource performance fluctuation) is seen as a major performance issue in Grid Computing [Lee and Zomaya 2010]. Since Grid applications may also be supported in Cloud, we also need to treat this challenge, because at first the Cloud is not concerned with execution time of applications, or in grid language, the response time of tasks. At same time, we can use the advantages of Cloud Computing to improve solutions. In [Lee and Zomaya 2010], the authors make use of Cloud resources to increase the reliability of task completion. Cloud resources are resorted to because authors have considered that they are often tightly coupled, homogeneous and reliable. Min-min, Max-min and XSufferage are static scheduling mechanisms, in which the rescheduling process is activated when a task completes its execution later than its estimated time. Authors propose the RC algorithm, in which the scheduling mechanism is initiated together with the subsequent tasks that caused the delay in task completion. The RC algorithm initially uses one of the static scheduling mechanisms mentioned previously to allocate tasks only on grid resources; and whether there is a significant amount of delay in tasks completion, waiting tasks would possibly be rescheduled onto Cloud resources. Authors in [Kong et al 2010] focus on online and dynamic task scheduling in a virtualized datacenter scenario with the main goal being to achieve a trade-off between availability and performance. The proposed scheme makes use of the two Fuzzy predictors: one to calculate the availability level of the resources, and the other one to treat the load-balance requirement. The intersection set between availability and loadbalance terms is then calculated. If the intersection is null, the algorithm gives priority to satisfying the availability requirement. Otherwise, the task with the minimum expected response time is selected. In [Karve et al 2006], authors developed an application placement mechanism that dynamically configures the number and the location of application instances. Such a mechanism is based on three steps: the first step sorts nodes and applications according to the density and assigns them according to satisfaction constraints. The second step derives a new placement from the previous one in an attempt to minimize the number of placement changes. Ultimately, the third step is invoked to achieve a better load balance, considering the solution proposed by the second step. Network Virtualization The network virtualization area is a relatively new field in network research that is related to the research of Cloud Computing. Authors in [Chowdhury et al. 2009] describe the main problem of this area as the allocation of virtual networks over a substrate network. Resource allocation in Cloud Computing can also be seen with this point of view: the main goal is to allocate developers virtual network requests on a substrate network according to some constraints and while aiming to obtain a clever configuration of the virtual network and underlying resources. The resource modeling approach described next is based on [Chowdhury et al. 2009]. The Cloud operator infrastructure can be seen as a graph, called the substrate
225
graph. Virtual networks requests are also modeled as graphs. Bandwidth, storage, CPU or memory requirements and restrictions can be modeled as values that each link or node has associated with them. Among other constraints that can be considered, there is the physical location of the virtual node, as modeled by [Chowdhury et al. 2009]. This can be used to model access delay requirements of the arriving virtual network nodes. Different versions of this model can also be created, for example, the model can neglect storage requirements when the storage is over-provisioned. With a virtual network description, an allocation system can assign virtual networks. Such a virtual network assignment can be seen as a simple mapping from the nodes of the virtual network request to the substrate nodes, and from the links of the virtual network request to the substrate paths. Virtual network assignments consume the underlying resources onto which they are mapped. Given this model, an algorithm that allocates virtual networks, which selects and optimizes resources, should consider the constraints of the problem (CPU, memory, location or bandwidth limits) and should have an objective function to optimize based on the algorithm objectives. In [Haider et al. 2009], authors describe possible objective functions to be optimized related to maximizing the revenue of the service provider while minimizing link and nodes stress, etc. It also provides a survey with some heuristic techniques used when allocating virtual networks. The authors also describe some basic strategies based on allocating the virtual nodes on substrate nodes first and then allocating the virtual links to substrate paths as not satisfactory. In [Chowdhury et al. 2009], the objective function of the virtual network allocation algorithm is closely related to the cost and revenue of the provider. Authors reduce their problem to a mixed integer programming problem and then relax integer constraints to solve the problem with a polynomial time algorithm. Then an approximate solution to the initial problem is obtained based on this relaxed polynomial algorithm. There are two different algorithms for the approximation of this solution; one is the D-ViNE, a deterministic algorithm, and the other one is the R-ViNE, or randomized algorithm. Another approach, taken by [Zhu and Ammar 2006] is based on an objective function that attempts to homogenize the distribution of hosts over the substrate network as much as possible by minimizing the maximum number of virtual nodes per substrate nodes and virtual links per substrate links. Thus, all resources from the substrate network are used in a balanced way. In order to achieve that, static and dynamic algorithms are presented. [Haider et al. 2009] describes how some virtual network applications, mainly virtual network test-beds, implement their resource management and allocation. PlanetLab34 allocation is generally chosen by the user, but some automatic mechanisms have been proposed in [Ricci et al. 2006]. Also, SWORD [Albrecht et al 2008], a service running in PlanetLab, can act on resource discovery and find a virtual network mapping with the lowest penalty function. Alternately, Emulab35 uses a facility which is based on simulated annealing in order to optimize the allocation. Other techniques are
34 35
PlanetLab, http://www.planet-lab.org/ Emulab - Network Emulation Testbed, http://www.emulab.net/
226
also implemented to provide better performance to the user, such as selecting nodes that are in close proximity to already allocated neighbors with higher probability. Furthermore, there are still several research challenges in the virtual network allocation area. Authors in [Haider et al. 2009] highlighted the development of dynamic allocation algorithms based on the dynamic behavior of the bandwidth consumption of the virtual networks. This could be implemented using game theory or adaptive feedback control theory. Also, the development of other heuristic approaches to overcome this NP-hard problem is essential. They suggest an investigation into the tradeoffs of the many characteristics of the already existing algorithms, as well as some studies on how static algorithms could deal with dynamic scenarios.
5.5. Open-source Mediation Systems

Building a Cloud often involves employing a Mediation System for the management of resources. The decision about which solution to use is very difficult since the range of solutions for Cloud management is broad and each solution has specific characteristics adapted towards specific scenarios. Such an ecosystem of solutions is also populated by proprietary and open-source solutions; however the scope of this section is restricted to the latter type. Previous papers including ([Rimal et al. 2009], [Endo et al. 2010], [Cordeiro et al. 2010]) have surveyed open source Mediation Systems for Clouds and have compared features like architecture, virtualization platforms, and service type. Table 5.1 summarizes some of these solutions. Firstly, one can note the predominance of IaaS Mediation Systems and, secondly, that the open-source mediation systems support both proprietary and open-source hypervisors.
Table 5.1. Comparative between open-source Mediation Systems (adapted from [Endo et al. 2010]). Solutions XCP Nimbus OpenNebula Eucalyptus TPlatform Apache VCL Enomaly Service IaaS IaaS IaaS IaaS PaaS SaaS IaaS Main Characteristics Automatic management Turns legacy clusters into Clouds Policy-driven resource allocation Hierarchical Architecture Focus on web mining Applications on the Internet Focus on small clouds Infrastructure Xen Xen and KVM Xen, KVM, and VMWare Xen and KVM TFS and MapReduce VMware Xen, KVM, and VirtualBox
Particularly, this section follows the analysis made by [Cordeiro et al. 2010], which surveyed and compared in detail three open-source Mediation Systems. However, the paper showed that the Xen Cloud Platform (XCP) is intended to manage a virtualized infrastructure and do not offers a solution for resources negotiation, i.e., the XCP does not implement a Cloud Mediation System with all layers defined in the archetypal as shown in Figure 5.3. Therefore, this section will highlight the main characteristics and architectures of two solutions previously presented in this paper: Eucalyptus and OpenNebula, and will also discuss another solution: Nimbus. As well, this section follows the analysis made by [Sempolinski and Thain 2010]. 5.5.1. Eucalyptus Since its conception, Eucalyptus was designed to provide services compatible with Amazon EC2, i.e., it was designed for the rental of virtual machines in the Cloud. It is
227
interesting to note that all communications in Eucalyptus are made through Web Services standards. Also, Eucalyptus is intended to bridge the gap between open-source software for Clouds and enterprise solutions. This is clearly shown through the design of their external interface, which is fully compatible with the Amazon EC2 interface. Architecture The Eucalyptus architecture foresees two different user classes: administrators and developers. This once again reflects a business-oriented model view. The former are the users responsible for managing the entire Cloud who have access to all features of Eucalyptus. The latter are the developers that can request and make use of VM instances directly from Eucalyptus, without the need for administrators intervention. In this scenario, developers can also be clients when using their VMs for own use, or can configure their VMs and provide a service to other clients. As presented in [Nurmi et al. 2008], Eucalyptus has four components, as shown in Figure 5.6. VMs hosted on a given server are directly managed by a Node Controller (NC) running on the same server. This option is interesting because the NC offers a common layer that abstracts the hypervisor solution employed on each server. NCs are grouped in clusters managed by the Cluster Controller (CC). This CC gathers state information from each NC, schedules developers requests to individual NCs, and manages the configuration of public and private networks. At the top of the architecture is the Cloud Controller (CLC), which processes requests and makes VM placement decisions. The Walrus is a data storage service compatible with Amazons S3, which is responsible for manipulating VM templates and delivering them to NCs when a developer wishes to instantiate a VM. A clear advantage of the Eucalyptus architecture is it is a natural fit for existing enterprise processing environments, as a result of its hierarchical design.
CLC and Walrus Public Network
CC
CC
Private Network
Private Network
NC
NC
NC
NC
NC
NC
NC
Cluster A
Cluster B
Figure 5.6. Components of the Eucalyptus Architecture [Nurmi et al. 2009]
Negotiation issues Eucalyptus was developed entirely inside a Service-Oriented paradigm. Therefore, messages exchanged between Eucalyptus components as well as messages sent by developers requiring a resource are described through WSDL interfaces. In other words, Eucalyptus employs Web Services for communication on all layers of the Mediation System. The interfaces associated with the control of the internal components will be discussed later.
NC
228
One must note that the negotiation or external interface is offered by the CLC and is responsible by translating developers requests into operations for the internal components. Currently, for the sake of compatibility with Amazons EC2, Eucalyptus supports both SOAP-based and HTTP Query-based interfaces [Nurmi et al. 2009]. The main operations are runInstances and terminateInstances, where an instance is a VM. Also for maintaining compatibility with Amazon EC2, developers on Eucalyptus may only instantiate VMs from classes previously configured. Such classes specify the main aspects of the target VMs including number of cores, memory size, disk size, operating system etc. Resource Management and Control For internal communication and control, Eucalyptus also uses Web Service interfaces. The NC implements a number of operations to manage VMs hosted on the server. Important operations supported are: runInstance, terminateInstance, and describeResource. The first two are used to send commands to start and to stop a specific VM, respectively. The last one reports current characteristics like memory and disk usage of the server (the physical node). The CCs also provide a WSDL interface; however, unlike the interface provided by the NC, each operation can be used to manage groups of VM instances as indicated by the operations names: runInstances, terminateInstances, and describeResources.
Figure 5.7. Sequence Diagram of messages to run a VM
Resource management in Eucalyptus is related to the allocation and deallocation of VMs on the servers. Such a process follows a peculiar algorithm whose message passing is shown in Figure 5.7. The resource allocation process is triggered by a developer request and finalized when the VM is actually running on a node [Nurmi et al. 2008]. When the negotiation interface on Eucalyptus receives a runInstances request from one developer, the CLC determines which CC can support the VM by querying CCs through the describeResources operation and then by choosing the first CC that responds with enough free resources. In the same way, when a CC receives a runInstances request from the CLC it queries each NC through the describeResource message and chooses the first NC that has enough free resources. 5.5.2. OpenNebula OpenNebula is a flexible tool that orchestrates storage, network and virtualization technologies to enable the dynamic placement of services on distributed infrastructures. It has been designed to be modular to permit its integration into as many different
229
hypervisors and environments as possible. Such flexibility attracted a growing number of organizations including the European Space Astronomy Centre36, the European Organization for Nuclear Research (CERN)37, and Telefnica38. The entire list of organizations using OpenNebula or contributing in its development can be found on [OpenNebula Project 2011a].
Architecture
The physical infrastructure assumed for OpenNebula adopts a classical cluster-like (master and slave nodes) architecture with a front-end server and a set of servers for hosting VMs. Also, it requires at least one physical network joining all the cluster nodes with the front-end. The front-end server executes the main OpenNebula processes while the other servers on the cluster are hypervisor-enabled hosts providing resources to allocated VMs. One distinct aspect of OpenNebula is that the software was developed following a layered architecture adequate extension, which is depicted in Figure 5.8. The OpenNebula architecture has three layers: Tools, Core and Drivers. The upper layer of the architecture is called Tools and contains all the modules for the manipulation of OpenNebula. This layer encompasses, for example, the interfaces modules that are used by administrators and developers to interact with OpenNebula. Moreover, beyond negotiation layer issues, the Tools layer implements the Scheduler module, which makes runtime decisions about where VMs must be allocated. Other tools to provide extra functionalities for the OpenNebula can be implemented on this layer using the OpenNebula Cloud API which is based on an XML-RPC interface.
Figure 5.8. OpenNebula Architecture (adapted from [OpenNebula Project 2011b])
The Core layer has the components responsible for handling VM requests and controlling resources. The main component of this layer is the Request Manager, which handles developers requests through an XML-RPC interface that calls the internal managers according to the invoked method. Physical servers and VMs are managed and monitored by the Host Manager and the VM Manager, respectively. The Virtual Network Manager (VN Manager) manages virtual networks by keeping track of IP and
36 37 38
http://www.esa.int/esaMI/ESAC/index.html http://public.web.cern.ch/public/ http://www.tid.es/en/Pages/default.aspx
230
MAC addresses and their association with VMs, acting like a DHCP for the virtual networks. Finally, the SQL Database stores internal data structures. The third layer has modules called Drivers, which supports different underlying platforms. These Drivers run on separated processes, generally in the servers responsible for host VMs, and they communicate with the Core module through a simple text messaging protocol. There are drivers to deal with file transfers implemented by network protocols including NFS and SSH. Also, there are hypervisordependent drivers for managing VMs running on each server. Finally, there are drivers to request services from external Clouds like Amazon EC2 or ElasticHosts. Negotiation issues Similarly to Eucalyptus, OpenNebula works with administrative and client accounts, the latter being for Cloud developers. Administrators access OpenNebula as a private Cloud through the Command Line Interface (CLI) that allows for the manipulation of the overall infrastructure through intuitive commands. Developers launch and control their leased virtual infrastructure (computing, network, and storage) using Web Servicebased interfaces. OpenNebula implements three different interfaces: one compatible with the EC2 Query API from Amazon, another compatible with the OCCI from the Open Grid Forum, and a third compatible with a subset of calls of the VMWares vCloud API. Resource Management and Control The Scheduler is the OpenNebula module responsible for making VM placement decisions. By having access to all VM allocation requests received by OpenNebula, the Scheduler can keep track of VM allocations, make decisions about the allocation of incoming VM requests, and send appropriate deployment or enforcement commands to the Core. The default scheduler on OpenNebula provides a scheduling policy that places VMs according to a ranking algorithm, which relies on performance data from both the running VMs and physical servers. Moreover, following their modular principle, OpenNebula allows extension of their architecture with a new different scheduler. Algorithm 1: Scheduling algortithm.
Inputs: requirements, rank, hostsList; Outputs: selectedHost; 1 Begin 2 for each host in hostsList do 3 if (host meets requirements) then 4 candidates.new(host); 5 end 6 end 7 sorted = sortByRank(candidates, rank); 8 selectedHost = sorted(1); 9 end
Figure 5.9. Default scheduling algorithm (from [Cordeiro et al. 2010])
The basic operation of the default scheduling algorithm used in OpenNebula is shown in Figure 5.9. The algorithm requires two inputs that are sent in the VM request: requirements and rank. The former consists of a set of simple rules indicating minimum resource requirements (such as CPU or Memory) and the latter consists of a policy for resource allocation. The main objective of this policy is to provide an index for the ranking of candidate servers. It can be made in the form of an arithmetic expression encompassing server aspects including quantity of free CPU, number of VMs hosted,
231
temperature, etc. Thus, when a VM request arrives, the Scheduler, based on the requirements, filters those servers from hostsList that do not meet the minimum requirements requested and creates a new list of candidate servers (candidates). After that, the remaining hosts are sorted using the rank policy. Finally, the first host in the list sorted is chosen as the selectedHost which will be used to allocate the VM. Despite being a simple algorithm for resource management, a careful adjustment of the inputs (Requirements and Rank) can permit different placement schemes. For example, using FREECPU as the rank indicates that servers with lesser loads must be prioritized. Such ranking will cause a spread of VMs among the servers of the cluster, which can be interesting when allocating VMs that demand high processing capacity. Other example is to rank candidates using RUNNING_VMS. Such a method can be used to allocate VMs in as few servers as possible, enforcing a server consolidation strategy. 5.5.3. Nimbus Nimbus is an extensible open-source mediation system whose main purpose is to turn a grid of infrastructure resources into an IaaS Cloud for scientific computing. Nimbus enables providers to build private or community Clouds and enables developers to lease remote resources by deploying VMs, including the simple and automatic lease of large infrastructures. Nimbus is highly configurable and extensible, allowing providers to customize its solutions. In the next section we describe the software components of Nimbus architecture in more detail. Then we illustrate how the negotiation with developers works. Last there is some information about Nimbus resource management. Architecture Similarly to OpenNebula, Nimbus runs over a cluster-like infrastructure with one server acting as a front-end for developers to access the Cloud and the other servers acting as VM hosts. Each hosting server must have one of either Xen or KVM hypervisors in order for the Nimbus Virtual Machine Manager (VMM software, or workspacecontrol) to work. The front-end server must also have Cumulus installed, which is the Nimbus storage solution for VM image repository. It comprises an open source implementation of the Amazons S3 REST API39. Through Cumulus, developers are able to access and manage their storage quotas. Cumulus is designed for scalability and allows providers to configure multiple storage implementations. Figure 5.10 shows the Nimbus software architecture. The most important component in this architecture is the workspace service, whose main role is to manage the virtual machines on the pool. Also, the workspace service is responsible for receiving developers requests through different interfaces. Currently, Nimbus implements two interfaces: the WSRF-based (Web Services Resource Framework40) interface and the Amazon EC2-compatible interface. Thus, according to the interface,
39 40
http://docs.amazonwebservices.com/AmazonS3/latest/dev/ http://www.globus.org/wsrf/
232
developers must use proper client software for deploying, interacting with, querying, saving and terminating sessions with virtual machines.
Context Client Cloud Client WSRF EC2 Client EC2 WSDL Context Broker Workspace Service Workspace Pilot Workspace Resource Manager Workspace Control
Figure 5.10. Nimbus software components [adapted from Keahey 2009]
The context broker allows developers to coordinate large virtual clusters to launch automatically and repeatedly. It allows for the creation of virtual networks, as opposed to launching a set of unconnected virtual machines like most VM-on-demand services. The workspace control (or VMM) is the component of Nimbus that must be installed on each server in order to perform basic management and control operations of the VMs. Finally, the Workspace Resource Manager and Workspace Pilot components provide automatic management of VMs including deciding which servers are appropriate to run each VM. Negotiation issues To deploy their applications, developers can use a command line application provided by Nimbus which will communicate with the Cloud through WSRF (a specification that provides stateful operations to Web Services). Based on the client application, developers communicate with WSRF services which allows for data associated with resources to be stored and retrieved. Another possible method of accessing the cloud infrastructure is using the Amazon EC2 interface. Such an interface will allow developers to use EC2 clients when dealing with Nimbus-based Clouds. Nimbus has a partial implementation of EC2s WSDL, and the EC2 Query API. Many EC2 operations are already supported [Nimbus Project 2011]. The developer also has the option of launching any number of VMs simultaneously (called a cluster of VMs). The type of VMs, their images, how many of each type should be launched, and the layout of the VMs can be specified through an XML file. The cluster deployment is implemented by the context broker and using information coming from the context agent that should boot on each VM node. Resource Management and Control The resource management in Nimbus is implemented on two components: the Workspace Resource Manager and the Workspace Pilot. The former implements a strategy where the developer has direct control of a pool of VMM nodes. The latter allows developers to submit regular jobs on the infrastructure and makes use of already configured batch schedulers like TORQUE41. One interesting feature for the scientific
41
http://www.clusterresources.com/pages/products/torque-resource-manager.php
233
community offered by Nimbus is that, due to their grid-based nature, users must inform the amount of time for which the VM is running. The Nimbus resource control is implemented mainly using the Workspace Control. It should be installed on each server and permits operations such as starting VMs, pausing VMs, stopping VMs, connecting VMs securely to the network, etc. The workspace control uses Libvirt over a Xen/KVM hypervisor. The front-end server uses SSH to access the hosting servers. 5.5.4. Comparisons In this section, we compare the open source systems for Cloud management as presented earlier using various criteria. The main aspects and features studied here were chosen because of their believed fundamental importance on the decision of which solution an operator should use. At the end of this section, some useful scenarios for each mediation system are discussed based on the differences identified herein. Through the analysis of OpenNebula, Nimbus and Eucalyptus, we can see that these mediation systems are focused on implementing an actual Cloud by offering virtualized elements over a pool of physical resources. They implement, in fact, an IaaS that can be used for private or public purposes. Although Eucalyptus can already handle two different virtualization platforms, OpenNebula distinguishes itself by having a native ability provided by its modular architecture to deal with different underlying virtualization platforms supported by the use of its Drivers, which makes it much more flexible. Alternately, Nimbus employs the Libvirt as a common layer for communication with different hypervisors. Architecture The architecture of a mediation system for Cloud management indicates how that platform works and how it was built. It is also an important decision parameter when choosing an environment in which to implement a Cloud. Though a completely centered system is, of course, easier to implement and manage, it can suffer from performance and availability problems. Conversely, hierarchical approaches are more reliable when considering control and management. Eucalyptus has a truly hierarchical approach. The Cloud is divided into different clusters, each with its own cluster controller that is responsible for all nodes under that cluster. On the upper level of the hierarchy, the Cloud controller is responsible for all the cluster controllers. OpenNebula and Nimbus work with a front-end server and several hypervisorenabled servers, creating a hierarchy of two levels only. In terms of software architecture, OpenNebula offers a completely modular and layered architecture making it easily integrated with different technologies. It has three main layers: Tools, Core and Drivers. Among the Tools, there is the Scheduler, responsible for assigning new VMs to hosts. Nimbus also has clear modular software architecture to provide support of both VMs allocation and regular job scheduling. Negotiation issues This aspect concerns the problem of how Cloud clients are going to access their leased resources. Public Cloud systems should provide this interface insomuch that the clients
234
can operate their resources transparently. Note that this is a concept that hopefully will be standardized in the future. On OpenNebula, Nimbus and Eucalyptus, an external user is able to use their resources through a Web Service interface provided by the mediation system. It is interesting to note that all these are also compatible with Amazon interfaces, primarily Amazons EC2. A further advantage of OpenNebula is that it can easily be extended to implement other interfaces, as well as Nimbus. Resource Management and Control The placement algorithm of the platform is important to guarantee a clever and perhaps optimal use of the resources. Poorly used resources always result in inefficiency. The publically available Eucalyptus version has a simple algorithm that seems to pay little attention to VM placement on the Cloud. Nimbus offers the Workspace Resource Manager and the Workspace Pilot that are responsible for deploying nodes and jobs on the Cloud, respectively. The main advantage of these components is that their underlying implementations are based on well-accepted solutions for scheduling in grids. OpenNebula brings an interesting approach for VM placement based on its defined Rank value, which can be used to implement useful policies. As such, it may be more attractive to developers who see resource usage and optimization as a critical requirement. Scenarios With the main differences now identified, we are able to discuss where and when each Cloud mediation system should be used. In the first scenario, suppose we want to offer a public Cloud service to a community (more specifically, a simple IaaS). In this case, Eucalyptus will fit very well, however it is not able to provide some important services like VM migration. Moreover, its allocation algorithms are simple and may not be efficient in some cases. Now, consider that we have a pool of resources, possibly with heterogeneous virtualization platforms, and we want to create a private/hybrid Cloud over it. OpenNebula or Nimbus can easily support this. Choosing one or the other will depend on the intended audience of the Cloud. OpenNebula is more adapted to VM-oriented scenarios, i.e., scenarios where developers want VMs to try and test new software in a sandbox environment. On the other hand, Nimbus is more driven towards scientific computing developers and the sharing of excess time between them [Sempolinski and Thain 2010].
5.6. Final Considerations

As was highlighted in this short course, Cloud Computing is a good solution for users interested in using or developing services provided on demand. We differentiated two types of users that providers interact with: clients and developers. Beyond this separation, we divided open research challenges into three areas: negotiation, resource management, and resource control. This grouping was implemented with the goal of separating challenges according to the individualities of
235
each layer defined in the Archetypal Cloud Mediation System (presented in Section 5.2.4). It is interesting because this Archetypal system was conceived considering that resource management is the main service of any Cloud Computing provider. In this way, we directed the entire paper towards resource allocation aspects. In this section we will finalize the short course, review the challenges addressed previously and make some considerations about the future prospects of Cloud Computing. 5.6.1. Review of the matter Section 5.2 described important definitions regarding Cloud Computing, including references that answered the question: What is Cloud Computing?. Several authors made their contributions, however we emphasize that there is no consensus about a unique definition, but rather a collection of functionalities that characterize the Cloud. Beyond the questions about the definition of Cloud, there are many open research problems that were addressed in Section 5.3. Divided into three layers (negotiation, resource management, and resource control), these problems describe aspects related to interface and resource allocation. Since the negotiation layer is responsible for the interface between the Cloud and the developers, here we find problems associated with interaction mechanisms with human users, as well issues surrounding interoperability. The two other layers are strongly associated with achieving their main goal: the automated provisioning of resources. In this way, problems of these layers are also associated. Energy management is an important aspect in Cloud Computing due to the high need for electricity to power and to cool the computing infrastructure. VM consolidation was described as one strategy that makes use of VM migration and cloning to save energy. Other aspect related to VM consolidation is the development of protocols which should be used to manage and control all types of Cloud resources, which would allow for interoperability between them. Considering these concepts, we defined a Resource Allocation System (RAS) as a resource allocation mechanism responsible for controlling Cloud resources and for attending to applications requirements. To do this in an optimized way, RAS needs to know the current status of each resource. In this short course, we described challenges related to this issue as divided into four categories (resource modeling and description, resource offering and treatment, resource discovery and monitoring, and resource selection), and grouped into two phases (conception and operational). Essentially, we may say that the challenge is all about to how properly describe resources for the purpose of offering them to users when posed with a request. Then, the challenge is to discover the resources on the Cloud and identify the optimal resource that satisfies all the requirements of the request. 5.6.2. Future Trends As we could notice in this short course, Cloud Computing is still in its maturation phase and there are many challenges to be solved or improved. In this Section, we present some considerations about future perspectives of Cloud Computing.
236
We think that resource modeling and description, and resource offering and treatment areas will be concerned with answers of questions like How is the ideal level of resource modeling abstraction? or How different Cloud providers can consent about service offering, considering scenarios with heterogeneous physical infrastructure?. Here, we believe that standardization efforts will keep as a trend with the main goal of creating compatible and integrated Cloud providers. About resource discovery and monitoring, we see the need of automating discovery and allocation processes, and make the monitoring process more active, being able to re-allocate resources according to demand or to the current status of the Cloud (in order to optimize resource usage). In this way, we could think in an adaptative Cloud that is able to self-manage its resources and self-adapt its configurations according to different circumstances. Other important aspect treated in resource selection and optimization challenges is the question about energy management. We guess that the effort in this area will become increasingly concrete due to importance of current questions about energy efficiency. Together with this, still with the goal of improving resource usage, we can also think about Clouds in which underused and non-dedicated resources can be clustered and availed in an opportunistic way.
References
Albrecht, J., Oppenheimer, D., Vahdat, A., and Patterson, D. A. (2008) Design and Implementation Trade-offs for Wide-area Resource Discovery. In ACM Transactions on Internet Technology, Vol. 8 , Issue 4, Article 18, September. Armbrust, M., Fox, A., Grifth, R., Joseph, A.D., Katz, R.H., Konwinski, A., Lee, G., Patterson, D.A., Rabkin, A., Stoica, I., Zaharia, M. (2009) Above the Clouds: A Berkeley View of Cloud Computing, Tech. Rep. UCB/EECS-2009-28, EECS Department, University of California, Berkeley. Barham, P., Dragovic, B., Fraser, K., Hand, S., Harris, T., Ho, A., Neugebauer, R., Pratt, I. and Warfield, A. (2003) Xen and the art of virtualization. In: 19th ACM symposium on Operating systems principles, New York, NY, USA. Beloglazov, A. and Buyya, R. (2010) Energy Efficient Resource Management in Virtualized Cloud Data Centers. In IEEE/ACM International Conference on Cluster, Cloud and Grid Computing. Broberg, J. and Buyya, R. and Tari, Z. (2009) MetaCDN: Harnessing Storage Clouds for high performance content delivery. In Journal of Network and Computer Applications, pp. 1012-1022, Elsevier. Buyya R., Beloglazov, A., Abawajy, J. (2010) Energy-Efficient Management of Data Center Resources for Cloud Computing: A Vision, Architectural Elements, and Open Challenges. In International Conference on Parallel and Distributed Processing Techniques and Applications. Buyya, R. et al. (2008) Market-Oriented Cloud Computing: Vision, Hype, and Reality for Delivering IT Services as Computing Utilities. In 10th IEEE international conference on high performance computing and communications.
237
Buyya, R., Yeo, C.S., Venugopal, S., Broberg, J., Brandic, I. (2009) Cloud computing and emerging IT platforms: Vision, hype, and reality for delivering computing as the 5th utility. In: Future Generation Computer Systems, Elsevier B. V. Charlton, S. (2009) Model-Driven Design and Operations for the Cloud. In Workshop on Best Practices in Cloud Computing: Designing for the Cloud. Chen, Y., Gmach, D., Hyser, C., Wang, Z., Bash, C., Hoover, C., Singhal, S. (2010) Integrated Management of Application Performance, Power and Cooling in Data Centers, In IEEE Network Operations and Management Symposium (NOMS), 2010, pp. 615-622, Osaka, Japan, April. Chen, Y., Paxson, V., Katz, R. H. (2010) Whats New About Cloud Computing Security?, Tech. Rep. UCB/EECS-2010-5, EECS Department, University of California, Berkeley. Chowdhury, N. M. M. K., Rahman, M. R., and Boutaba, R. (2009) "Virtual Network Embedding with Coordinated Node and Link Mapping," IEEE INFOCOM. Chowdhury, N.M. M. K. and Boutaba, R. (2010) A survey of network virtualization. In Computer Networks, Vol. 54, issue 5, pp. 862-876. Elsevier. Cordeiro, T., Damalio, D., Pereira, N., Endo, P., Palhares, A., Gonalves, G., Sadok, D., Kelner, J., Melander, B., Souza, V., Mngs, J. (2010) Open Source Cloud Computing Platforms. In: 9th International Conference on Grid and Cloud Computing, Nanjang, China, pp.366-371. Cully, B., Lefebvre, G., Meyer, D., Feeley, M., Hutchinson, N. e Wareld, A. (2008) Remus: High availability via asyncronous virtual machine replication. In: 5th USENIX Symposium on Networked Systems Design and Implementation, April. Dean, J. and Ghemawat, S. (2004). Mapreduce: simplied data processing on large clusters. In OSDI04: Proceedings of the 6th conference on Symposium on Opearting Systems Design & Implementation, pages 1010, Berkeley, CA, USA. USENIX Association. Dillon, T., Wu, C., and Chang, E. (2010) Cloud Computing: Issues and Challenges, In IEEE International Conference on Advanced Information Networking and Applications, pp. 27-33. Edmonds, A. (2010) OCCI Implementations. Open Cloud Computing Interface Blog. Available at: http://occi-wg.org/2010/11/17/occi-implementations/. Endo, P. T., Gonalves, G. E., Kelner, J., Sadok, D. (2010) A Survey on Open-source Cloud Computing Solutions. Workshop em Clouds, Grids e Aplicaes, Simpsio Brasileiro de Redes de Computadores e Sistemas Distribudos. Erl, T. (2009) SOA design patterns, Prentice Hall, Boston. Ghemawat, S., Gobioff, H., and Leung, S. (2003) The Google le system. In 19th Symposium on Operating Systems Principles, pages 2943, Lake George, New York. Greenberg, A., Hamilton, J., Maltz, D. A., and Patel, P. (2008). The cost of a cloud: research problems in data center networks. SIGCOMM Comput. Commun. Rev. 39, n. 1, pp. 68-73.
238
Haider A., Potter, R., Nakao, A. (2009) Challenges in Resource Allocation in Network Virtualization. In 20th ITC Specialist Seminar, Hoi An, Vietnam, May. Houidi, I., Louati, W., and Zeghlache, D. (2008) A distributed virtual network mapping algorithm. In Proceedings of IEEE International Conference on Communications, pp. 56345640. Houidi, I., Louati, W., Zeghlache, D., and Baucke, S. (2009) Virtual Resource Description and Clustering for Virtual Network Discovery In Proceedings of IEEE ICC Workshop on the Network of the Future. Karve, A., Kimbrel, T., Pacifici, G., Spreitzer, M., Steinder, M., Sviridenko, M., and Tantawi, A. (2006) Dynamic Placement for Clustered Web Application. In International World Wide Web Conference Committee. Keahey, K. (2009) Nimbus: Open Source Infrastructure-as-a-Service Cloud Computing Software. In Workshop on adapting applications and computing services to multicore and virtualization, CERN, Switzerland. Khan, S., Maciejewsk, A., and Siegel, H. (2009) Robust CDN Replica Placement Techniques, In IEEE International Symposium on Parallel&Distributed Processing. Khoshafian, S. (2007) Service Oriented Enterprises. Auerbach Publications. Kong, X., Lin, C., Jiang, Y., Yan, W and Chu, X. (2010) Efficient dynamic task scheduling in virtualized data centers with fuzzy prediction. In Journal of Network and Computer Applications, Elsevier. Kong, X., Lin, C., Jiang, Y., Yan, W and Chu, X. (2010) Efficient dynamic task scheduling in virtualized data centers with fuzzy prediction. In Journal of Network and Computer Applications, Elsevier. Lagar-Cavilla, H. A.; Whitney, J. A.; Scannell, A. M.; Patchin, P.; Rumble, S. M.; Lara, E.; Brudno, M.; Satyanarayanan, M. (2009) SnowFlock: rapid virtual machine cloning for cloud computing. In Fourth ACM European Conference on Computer Systems. Lee, Y. and Zomaya, A. (2010) Rescheduling for reliable job completion with the support of clouds. In Future Generation Computer Systems, vol. 26, pp. 1192-1199, Elsevier. Llorente, I. M. (2010) Key Research Challenges in Cloud Computing. Presented at 3rd EU-Japan Symposium on Future Internet and New Generation Networks. Lo Presti, F et atl. (2007) Distributed Dynamic Replica Placement and Request Redirection in Content Delivery Networks. In 15th International Symposium on Modeling, Analysis, and Simulation of Computer and Telecommunication Systems. Marshall, P., Keahey, K., and Freeman, T. (2010) Elastic Site: Using Clouds to Elastically Extend Site Resources, 10th IEEE/ACM International Conference on Cluster, Cloud and Grid Computing, pp. 43-52, Australia, June. McKeown, N., Anderson, T., Balakrishnan, H., Parulkar, G., Peterson, L., Rexford, J., Shenker, S. and Turner, J. (2008) OpenFlow: enabling innovation in campus networks, ACM SIGCOMM Computer Communication Review.
239
Mell, P. and Grance, T. (2009). The NIST Denition of Cloud Computing. National Institute of Standards and Technology, Information Technology Laboratory. Metsch, T., Edmonds, A., Nyrn, R. (2010) Open Cloud Computing Interface Core. Open Grid Forum, OCCI-WG, Specification Document. Available at: http://forge.gridforum.org/sf/go/doc16161?nav=1. Murphy, M, and Goasguen, S. (2010) Virtual Organization Clusters: Self-provisioned clouds on the grid. In Future Generation Computer Systems. Nelson, M. (2009) Building a Open Cloud, Science, pp. 1656-1657, vol, 324, American Association for the Advancement of Science. Nimbus Project. (2011) Nimbus 2.7 Admin Guide, Available at: http://www.nimbusproject.org/docs/2.7/admin/index.html. Visited on March, 2011. Nurmi, D., Wolski, R., Grzegorczyk, C., Obertelli, G., Soman, S., Youseff, L. and Zagorodnov, D. (2009) The Eucalyptus Open-Source Cloud Computing System. In: 9th IEEE/ACM International Symposium on Cluster Computing and the Grid. Nurmi, D., Wolski, R., Grzegorczyk, C., Obertelli, G., Soman, S., Youseff, L., and Zagorodnov, D. (2008) Eucalyptus: A Technical Report on an Elastic Utility Computing Architecture Linking Your Programs to Useful Systems. University of California, Santa Barbara, October. OpenCloud. (2011) Cloud Computing Use Cases Whitepaper - Version 4.0. http://opencloudmanifesto.org/Cloud_Computing_Use_Cases_Whitepaper-4_0.pdf. OpenNebula Project. (2011a) OpenNebula 2.0 Documentation. Available at: http:// www.opennebula.org/documentation:documentation. Visited on February, 2011. OpenNebula Project. (2011b) OpenNebula.org The Open Source Toolkit for Cloud Computing, Available at: http://www.opennebula.org/. Visited on February, 2011. Padala, P. (2010) Automated management of virtualized data centers. Ph.D. Thesis, Univ. Michigan. Patel, P., Ranabahu, A. and Sheth, A. (2009) Service Level Agreement in Cloud Computing. In Cloud Workshop at OOPSLA. Ramaswamy, L., Liu, L., and Iyengar, A. (2005) Cache Clouds: Cooperative Caching of Dynamic Documents in Edge Networks. In Proceedings of the 25th IEEE International Conference on Distributed Computing System. Ricci, R., Oppenheimer, D., Lepreau, J. and Vahdat, A. (2006) Lessons from Resource Allocators for Large-Scale Multiuser Testbeds. In ACM SIGOPS Operating Systems Review, Vol. 40 , Issue 1, pp. 25-32, January. Rimal, B., Choi, E., and Lumbi, I. (2009) A Taxonomy and Survey of Cloud Computing Systems. In International Joint Conference on INC, IMS and IDC. Sempolinski, P., and Thain, D. (2010) A Comparison and Critique of Eucalyptus, OpenNebula and Nimbus. In IEEE International Conference on Cloud Computing Technology and Science, pp. 417-426. Sheth, A and Ranabahu, A. (2010) Semantic Modeling for Cloud Computing, Part I. In IEEE Computer Society - Semantics & Services.
240
Sheth, R. (2009) What we talk about when we talk about cloud computing. Available at: http://googleenterprise.blogspot.com/2009/04/what-we-talk-about-when-we-talkabout.html. Steinder, M., Whalley, I., Hanson, J.E., Kephart, J.O., Coordinated Management of Power Usage and Runtime Performance. 2008. Teng, F. and Magouls, F. A New Game Theoretical Resource Allocation Algorithm for Cloud Computing, pp. 321-330, Advances in Grid and Pervasive Computing, 2010. Urgaonkar, R., Kozat, U., Igarashi, K, and Neely, M. (2010) Dynamic Resource Allocation and Power Management in Virtualized Data Centers, In IEEE Network Operations and Management Symposium (NOMS). Vaquero, L., Merino, L., Caceres, J., and Lindner, M. (2008) A Break in the Clouds: Towards a Cloud Definition, vol. 39, pp. 5055, January. Veras, M. (2009) Datacenter: Componente Central da Infraestrutura de TI. Brasport Livros e Multimdia, Rio de Janeiro. Verdi, F. L., Rothenberg, C. E., Pasquini, R., and Magalhes, M. (2010). Novas arquiteturas de data center para cloud computing. In SBRC 2010 - Minicursos. Vouk, M.A. (2008) Cloud Computing Issues, Research and Implementations. Journal of Computing and Information Technology, pages 235246. University of Zagreb, Croatia. Wang, L., Tao, J., Kunze, M., Rattu, D. and Castellanos, A. (2008) The Cumulus Project: Build a Scientific Cloud for a Data Center. In: Workshop on Cloud Computing and Its Applications, Chicago, USA Xhafa, F and Abraham, A. (2010) Computational models and heuristics methods for Grid scheduling problems. In Future Generation Computer Systems. Yfoulis, C.A. and Gounaris, A. (2009) Honoring SLAs on cloud computing services: A control perspective. In Proceedings of EUCA/IEEE European Control Conference. Youseff, L., Butrico, M., and Silva, D. (2008) Toward a unied ontology of cloud computing. In Grid Computing Environments Workshop (GCE08). Zhang, Q., Cheng, L., and Boutaba, R. (2010) Cloud computing: state-of-the-art and research challenges. Journal of Internet Service Applications, Springer, pp. 7-18. Zhu, Y. and Ammar, M. (2006) Algorithms for assigning substrate network resources to virtual network components. In Proceedings of IEEE INFOCOM.
ISSN 2177-4978
ISSN 2177-4978
9 772177 497006
Patrocnios:

SBRC MC

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

SBRC MC

Enviado por

Direitos autorais:

Formatos disponíveis

XXIX Simpsio Brasileiro de Redes de Computadores e Sistemas Distribudos 30 de maio a 3 de junho de 2011 Campo Grande, MS

Minicursos Livro Texto

Minicurso Livro Texto

Copyright 2011 da Sociedade Brasileira de Computao Todos os direitos reservados

XXIX Simpsio Brasileiro de Redes de Computadores e Sistemas Distribudos - SBRC 2011

Minicursos Livro Texto

Laboratrio Nacional de Redes de Computadores (LARC)

XXIX Simpsio Brasileiro de Redes de Computadores e Sistemas Distribudos - SBRC 2011

Minicursos Livro Texto

XXIX Simpsio Brasileiro de Redes de Computadores e Sistemas Distribudos - SBRC 2011

Mensagem do Coordenador Geral

Minicursos Livro Texto

Mensagem da Coordenadora de Minicursos

XXIX Simpsio Brasileiro de Redes de Computadores e Sistemas Distribudos - SBRC 2011

XXIX Simpsio Brasileiro de Redes de Computadores e Sistemas Distribudos - SBRC 2011

Comit de Avaliao de Minicursos

XXIX Simpsio Brasileiro de Redes de Computadores e Sistemas Distribudos - SBRC 2011

Minicursos Livro Texto

XXIX Simpsio Brasileiro de Redes de Computadores e Sistemas Distribudos - SBRC 2011

Minicursos Livro Texto

Captulo 4 Gerncia de Identidade na Internet do Futuro ............... 151

XXIX Simpsio Brasileiro de Redes de Computadores e Sistemas Distribudos - SBRC 2011

Minicursos Livro Texto

XXIX Simpsio Brasileiro de Redes de Computadores e Sistemas Distribudos - SBRC 2011

Minicursos Livro Texto

Figura 1.1. A evoluo do conceito da Internet [Banniza et al. 2009]

XXIX Simpsio Brasileiro de Redes de Computadores e Sistemas Distribudos - SBRC 2011

Minicursos Livro Texto

1.2. Pesquisa Experimental em Internet do Futuro no Brasil e no Mundo

XXIX Simpsio Brasileiro de Redes de Computadores e Sistemas Distribudos - SBRC 2011

Minicursos Livro Texto

XXIX Simpsio Brasileiro de Redes de Computadores e Sistemas Distribudos - SBRC 2011

Minicursos Livro Texto

XXIX Simpsio Brasileiro de Redes de Computadores e Sistemas Distribudos - SBRC 2011

Minicursos Livro Texto

XXIX Simpsio Brasileiro de Redes de Computadores e Sistemas Distribudos - SBRC 2011

Figura 1.2. A criao de um fatia sobre a infraestrutura do GENI [GENI-Sys 2008]

Minicursos Livro Texto

Figura 1.3. ORBIT Testbed Indoor

XXIX Simpsio Brasileiro de Redes de Computadores e Sistemas Distribudos - SBRC 2011

Figura 1.4. Cluster EmuLab

Minicursos Livro Texto

XXIX Simpsio Brasileiro de Redes de Computadores e Sistemas Distribudos - SBRC 2011

Figura 1.5. Ambiente federado CREW [FIRE 2010]

Minicursos Livro Texto

XXIX Simpsio Brasileiro de Redes de Computadores e Sistemas Distribudos - SBRC 2011

1.3. OpenFlow e Virtualizao

Minicursos Livro Texto

XXIX Simpsio Brasileiro de Redes de Computadores e Sistemas Distribudos - SBRC 2011

Minicursos Livro Texto

Figura 1.7. Comutador OpenFlow Dedicado

(b) Figura 1.8. Cabealhos que denem um uxo em comutadores dotipo 0.

XXIX Simpsio Brasileiro de Redes de Computadores e Sistemas Distribudos - SBRC 2011

Minicursos Livro Texto

Figura 1.9. Componentes de uma rede baseada no NOX

XXIX Simpsio Brasileiro de Redes de Computadores e Sistemas Distribudos - SBRC 2011

Minicursos Livro Texto

Figura 1.10. Virtualizao Completa

XXIX Simpsio Brasileiro de Redes de Computadores e Sistemas Distribudos - SBRC 2011

Figura 1.11. Virtualizao utilizando Container

Minicursos Livro Texto

Figura 1.12. Viso Geral do Arquitetura XEN

XXIX Simpsio Brasileiro de Redes de Computadores e Sistemas Distribudos - SBRC 2011