Capa livro texto minicursos A4 - SBRC 2011

Transcrição

XXIX Simpósio Brasileiro de Redes de Computadores e
Sistemas Distribuídos
30 de maio a 3 de junho de 2011
Campo Grande, MS
Minicursos
Livro Texto
Editora
Sociedade Brasileira de Computação (SBC)
Organizadores
Fabíola Gonçalves Pereira Greve (UFBA)
Ronaldo Alves Ferreira (UFMS)
Realização
Faculdade de Computação
Universidade Federal de Mato Grosso do Sul (UFMS)
Promoção
Laboratório Nacional de Redes de Computadores (LARC)
ii
Minicurso Livro Texto
Copyright © 2011 da Sociedade Brasileira de Computação
Todos os direitos reservados
Capa: Venise Melo
Produção Editorial: Fabíola Greve, Lucilene Vilela Gonçalves, Ronaldo Alves Ferreira
Cópias Adicionais:
Av. Bento Gonçalves, 9500 – Setor 4 – Prédio 43.412 – Sala 219
Bairro Agronomia – CEP 91.509-900 – Porto Alegre – RS
Fone: (51) 3308-6835
E-mail: [email protected]
Dados Internacionais de Catalogação na Publicação (CIP)
Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos (29.: 2011 :
Campo Grande, MS).
Minicursos / XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas
Distribuídos ; organizadores Fabíola Gonçalves Pereira Greve, Ronaldo Alves Ferreira. – Porto
Alegre : SBC, c2011.
240 p.
ISSN 2177-4978
1. Redes de computadores. 2. Sistemas distribuídos. I. Greve, Fabíola Gonçalves
Pereira. II. Ferreira, Ronaldo Alves. III. Título.
XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos - SBRC 2011
Promoção
Diretoria
Presidente
José Carlos Maldonado (USP)
Vice-Presidente
Marcelo Walter (UFRGS)
Diretor Administrativo
Luciano Paschoal Gaspary (UFRGS)
Diretor de Finanças
Paulo Cesar Masiero (USP)
Diretor de Eventos e Comissões Especiais
Lisandro Zambenedetti Granville (UFRGS)
Diretora de Educação
Mirella Moura Moro (UFMG)
Diretora de Publicações
Karin Breitman (PUC-Rio)
Diretora de Planejamento e Programas Especiais
Ana Carolina Salgado (UFPE)
Diretora de Secretarias Regionais
Thais Vasconcelos Batista (UFRN)
Diretor de Divulgação e Marketing
Altigran Soares da Silva (UFAM)
Diretor de Regulamentação da Profissão
Ricardo de Oliveira Anido (UNICAMP)
Diretor de Eventos Especiais
Carlos Eduardo Ferreira (USP)
Diretor de Cooperação com Sociedades Científicas
Marcelo Walter (UFRGS)
iii
iv
Minicursos Livro Texto
Promoção
Conselho
Mandato 2009-2013
Virgílio Almeida (UFMG)
Flávio Rech Wagner (UFRGS)
Silvio Romero de Lemos Meira (UFPE)
Itana Maria de Souza Gimenes (UEM)
Jacques Wainer (UNICAMP)
Mandato 2007-2011
Cláudia Maria Bauzer Medeiros (UNICAMP)
Roberto da Silva Bigonha (UFMG)
Cláudio 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)
Laboratório Nacional de Redes de Computadores (LARC)
Diretoria
Diretor do Conselho Técnico-Científico
Artur Ziviani (LNCC)
Diretor Executivo
Célio Vinicius Neves de Albuquerque (UFF)
Vice-Diretora do Conselho Técnico-Científico
Flávia Coimbra Delicato (UFRN)
Vice-Diretor Executivo
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
Realização
Comitê de Organização
Coordenação Geral
Ronaldo Alves Ferreira (UFMS)
Coordenação do Comitê de Programa
Artur Ziviani (LNCC)
Bruno Schulze (LNCC)
Coordenação de Palestras e Tutoriais
Nelson Luis Saldanha da Fonseca (UNICAMP)
Coordenação de Painéis e Debates
José Augusto Suruagy Monteiro (UNIFACS)
Coordenação de Minicursos
Coordenação de Workshops
Fábio Moreira Costa (UFG)
Coordenação do Salão de Ferramentas
Luis Carlos Erpen De Bona (UFPR)
Comitê Consultivo
Antônio Jorge Gomes Abelém (UFPA)
Carlos André Guimarães Ferraz (UFPE)
Francisco Vilar Brasileiro (UFCG)
Lisandro Zambenedetti Granville (UFRGS)
Luci Pirmez (UFRJ)
Marinho Pilla Barcellos (UFRGS)
Paulo André da Silva Gonçalves (UFPE)
v
vi
Realização
Organização Local
Brivaldo Alves da Silva Jr. (UFMS)
Edson Norberto Cáceres (UFMS)
Eduardo Carlos Souza Martins (UFMS/POP-MS)
Hana Karina Sales Rubinstejn (UFMS)
Irineu Sotoma (UFMS)
Kátia Mara França (UFMS)
Luciano Gonda (UFMS)
Lucilene Vilela Gonçalves (POP-MS)
Márcio Aparecido Inácio da Silva (UFMS)
Marcos Paulo Moro (UFGD)
Massashi Emilson Oshiro (POP-MS)
Nalvo Franco de Almeida Jr. (UFMS)
Péricles Christian Moraes Lopes (UFMS)
Renato Porfírio Ishii (UFMS)
vii
Mensagem do Coordenador Geral
Sejam bem-vindos ao XXIX Simpósio Brasileiro de Redes de Computadores e Sistemas
Distribuídos (SBRC 2011) em Campo Grande, MS. É um prazer e uma distinção
organizar um simpósio de tamanha relevância para a computação no Brasil, mais ainda
por ser a primeira vez que a Região Centro-Oeste tem o privilégio de sediá-lo. O SBRC
é um evento anual promovido pela Sociedade Brasileira de Computação (SBC) e pelo
Laboratório Nacional de Redes de Computadores (LARC). Ao longo dos seus quase
trinta anos, o SBRC tornou-se o mais importante evento científico nacional em Redes de
Computadores e Sistemas Distribuídos e um dos maiores da área de Informática no país.
O SBRC 2011 está com uma programação bastante rica, de qualidade diferenciada e que
consiste em: 18 sessões técnicas de artigos completos que abordam o que há de mais
novo nas áreas de redes de computadores e sistemas distribuídos; três sessões técnicas
para apresentação de ferramentas selecionadas para o Salão de Ferramentas; cinco
minicursos, com quatro horas de duração, sobre temas atuais; três palestras e t rês
tutoriais com pesquisadores de alto prestígio internacional; e três painéis sobre assuntos
de interesse da comunidade. Além dessas já tradicionais atividades do simpósio,
ocorrerão em paralelo oito workshops: XVI Workshop de Gerência e Operação de
Redes e Serviços (WGRS), XII Workshop da Rede Nacional de Ensino e Pesquisa
(WRNP), XII Workshop de Testes e Tolerância a F alhas (WTF), IX Workshop em
Clouds, Grids e Aplicações (WCGA), VII Workshop de Redes Dinâmicas 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 laboração de inúmeras
pessoas ao longo desta jornada. Meus sinceros agradecimentos aos membros dos
Comitês de Organização Geral e Local por realizarem um trabalho de excelente
qualidade e com muita eficiência, a qualidade da programação deste simpósio é fruto do
trabalho dedicado dessas pessoas. Sou grato a Faculdade de Computação da UFMS por
ter sido uma facilitadora ao longo de todo o pr ocesso de organização, desde a nossa
proposta inicial até o f echamento da programação. Gostaria de agradecer, também, ao
Comitê Gestor da Internet no Brasil (CGI.br), às agências governamentais de fomento e
aos patrocinadores por reconhecerem a importância do S BRC e investirem recursos
financeiros fundamentais para a realização do evento. Com o apoio financeiro recebido,
foi possível manter os custos de inscrição baixos e oferecer um programa social de alta
qualidade.
Em nome do Comitê Organizador, agradeço a todos os participantes pela presença em
mais esta edição do SBRC e d esejo uma semana produtiva, agradável 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 serão apresentados nessa 29a. edição
do Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos. Ao longo
dos anos, os minicursos vêm se configurando como uma excelente fonte de divulgação
de resultados de pesquisa em temas atuais, de grande relevância e n ão cobertos pelas
grades curriculares. Cada minicurso compõe um capítulo deste livro e está estruturado
para ser apresentado durante o evento em cerca de quatro horas. Para esta edição, foram
escolhidas 5 e xcelentes propostas, dentre 31 s ubmetidas, configurando uma taxa de
aceitação de cerca de 16%. Cada proposta obteve entre 3 e 4 avaliações feitas por um
Comitê de Avaliação criterioso composto por 26 pe squisadores especialistas nas
diversas áreas de redes e sistemas distribuídos.
Os minicursos selecionados para essa 29a. edição têm temática bastante atual e em sua
maioria abordam questões relativas à próxima geração de infraestrutura e serviços para
a Internet do futuro. Sabe-se que num futuro próximo, a Internet estará conectando os
mais variados tipos de dispositivos e objetos e em quantidades inimagináveis. Ela será
omnipresente e universal. As redes deverão se auto configurar de forma a at ender de
maneira eficaz, permanente, segura e co nfiável as demandas de serviços dos mais
variados graus por comunidades que se auto organizam no tempo e no espaço. Mais do
nunca os aspectos de confiança no f uncionamento dos sistemas precisarão ser
assegurados. Novos mecanismos de identicação de objetos, distribuição de conteúdo e
buscas, inclusive semânticas, além da oferta de recursos sob demanda, serão
necessários. Esses requisitos, dentre outros, formam o objeto de estudo dos capítulos a
seguir.
O Capítulo 1 a borda técnicas de virtualização de redes, considerando o padrão de
comunicação OpenFlow. Seu foco são as redes experimentais como laboratório para as
soluções e desafios enfrentados na implementação dos novos protocolos, arquiteturas e
serviços da Internet do futuro. O capítulo apresenta recentes experiências na área tanto
no Brasil como Exterior, uma descrição do arcabouço OpenFlow e aspectos de
virtualização, além de requisitos, mecanismos de configuração e t estes para as redes
experimentais.
O Capítulo 2 introduz as redes sociais on-line. As redes sociais são um extraordinário
testemunho e acelerador de movimentos sociais e sobretudo um formidável vetor de
democracia. Para tanto, permitem com que usuários criem e manipulem conteúdo de
maneira ad-hoc e quase irrestrita. Tudo isso suscita o emprego de novas técnicas para a
manipulação de grande volume de dados e para o de senvolvimento de sistemas de
distribuição de conteúdo confiáveis e seguros, além de novas formas de organização,
uso e busca de conteúdo, particularmente de mineração de dados. Elas introduzem
novos padrões de tráfego na Internet e várias alternativas de interação humanocomputador. O capítulo faz uma breve apresentação das redes existentes, discute suas
principais características, as diferentes abordagens de coleta e extração de dados, além
de importantes métricas e tipos de análises utilizadas no estudo dos grafos que modelam
essas redes.
ix
Web das coisas é o t ema do C apítulo 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) propõe a interligação dos
diversos objetos via padrões Web, de maneira a facilitar o seu uso e a sua integração às
inúmeras aplicações existentes na Web. O capítulo introduz os conceitos e tecnologias
da WoT, uma arquitetura de software com descrição do pr ojeto de implementação de
seus componentes, bem como exemplos práticos de construção de aplicações baseadas
no paradigma da WoT.
O Capítulo 4 tem como preocupação a gerência de identidades de usuários na Internet
do futuro. A segurança é uma preocupação 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
vulneráveis e sujeitos a variados ataques de agentes maliciosos. A gestão de identidades
possibilita o c ontrole do pe rfil dos usuários e das suas relações de confiança, define
políticas de acesso e f az uso de mecanismos de autenticação para a o ferta segura de
serviços na rede. O capítulo apresenta os principais desafios, descreve técnicas
adequadas, bem como os dispositivos específicos e arquiteturas existentes para a
implementação da gerência de identidades no novo modelo computacional introduzido
pela Internet do futuro.
O Capítulo 5 discute a questão de alocação de recursos na Computação em Nuvem. Este
novo paradigma permite com que um grande volume de recursos disponíveis na Internet
tenha utilização imediata e s ob demanda, viabilizando assim a o ferta de serviços,
processos, dispositivos e infra-estrutura de maneira universal e ilimitada. O processo de
alocação de recursos é nesse contexto fundamental para o provimento dos mesmos. Ele
deve ser dinâmico e permitir com que os requisitos do conjunto de aplicações possam
ser atendidos. O capítulo define e apresenta as tecnologias essenciais da computação em
nuvem, com foco nos desafios e soluções para a alocação de recursos.
Gostaria de expressar os meus sinceros agradecimentos ao Ronaldo Alves Ferreira da
UFMS, coordenador do SBRC 2011, pela confiança, presteza e apoio recebido ao longo
das nossas interações. Um grande agradecimento a todos os membros do Comitê de
Avaliação pelas ótimas intervenções, reatividade e boas discussões que contribuíram
para termos uma seleção 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.
Fabíola Gonçalves Pereira Greve
Coordenadora de Minicursos do SBRC 2011
Comitê de Avaliação de Minicursos
Alfredo Goldman vel Lejbman (USP)
Alysson Bessani (Universidade de Lisboa)
Antônio Jorge Gomes Abelém (UFPA)
Carlos Alberto Kamienski (UFABC)
Carlos Montez (UFSC)
Daniel Mossé (University of Pittsburg)
Eduardo Nakamura (UFAM)
Elias Procópio Duarte Jr. (UFRP)
Francisco Brasileiro (UFCG)
Genaro Costa (UFBA)
Hana Karina Salles Rubinsztejn (UFMS)
José Marcos Nogueira (UFMG)
Jussara Almeida (UFMG)
Luci Pirmez (UFRJ)
Lucia Drummond (UFF)
Luis Carlos De Bona (UFPR)
Luiz Eduardo Buzato (UNICAMP)
Marcelo Dias de Amorim (LIP6/CNRS)
Marinho Barcellos (UFRGS)
Nabor Mendonça (UNIFOR)
Noemi Rodriguez (PUC-Rio)
Paulo André da Silva Gonçalves (UFPE)
Regina Araújo (UFSCar)
x
xi
Sumário
Capítulo 1 – Pesquisa Experimental para a Internet do Futuro: Uma
Proposta Utilizando Virtualização e o Framework OpenFlow ............... 1
1.1 Introdução .......................................................................................................... 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 Investigação 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 Virtualização ............................................................................... 19
1.3.1 O OpenFlow .......................................................................................... 19
1.3.1.1 Aplicações ............................................................................... 20
1.3.1.2 Modos de Funcionamento dos Switch ..................................... 21
1.3.1.3 Controle Usando NOX ............................................................ 23
1.3.2 Virtualização ......................................................................................... 25
1.3.2.1 Virtualização de Sistemas........................................................ 26
1.3.2.2 Virtualização de Redes ............................................................ 29
1.3.2.3 Redes de Sobreposição (Overlay)............................................ 31
1.3.2.4 Virtualização de Rede com OpenFlow .................................... 32
1.4 Requisitos para Construção de um Ambiente para Experimento e
Virtualização de Redes ........................................................................................... 34
1.4.1 Tipos de Hardwares .............................................................................. 35
1.4.2 Arcabouços de Controle ........................................................................ 36
1.4.3 Monitoração e Medição ........................................................................ 37
1.4.4 Ferramentas para Gerência de Virtualização ........................................ 39
1.5 Estudo de Caso ................................................................................................ 42
1.5.1 Definição do Ambiente ......................................................................... 42
1.5.1.1 Dados de Implementação do Ambiente ................................... 42
1.5.1.2 Plano de Dados ........................................................................ 44
1.5.1.3 Plano de Controle .................................................................... 45
1.5.2 Aplicação Prática .................................................................................. 46
1.5.3 Conclusão .............................................................................................. 53
1.6 Considerações Finais e o Futuro em Pesquisa Experimental em Internet do
Futuro ..................................................................................................................... 53
1.6.1 Considerações Finais............................................................................. 53
1.6.2 Tendências Futuras ............................................................................... 54
Referências ............................................................................................................. 55
xii
Capítulo 2 – Explorando Redes Sociais Online: Da Coleta e Análise de
Grandes Bases de Dados às Aplicações .................................................... 63
2.1 Introdução ........................................................................................................ 64
2.2 Definições e Características de Redes Sociais Online..................................... 66
2.2.1 Definição ............................................................................................... 66
2.2.2 Elementos das Redes Sociais Online ..................................................... 67
2.3 Teoria de Redes Complexas ............................................................................ 69
2.3.1 Métricas para o Estudo de Redes Complexas ....................................... 69
2.3.1.1 Grau dos Vértices .................................................................... 69
2.3.1.2 Coeficiente de Agrupamento ................................................... 70
2.3.1.3 Componentes ........................................................................... 71
2.3.1.4 Distância Média e Diâmetro .................................................... 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 Técnicas de Coleta de Dados ........................................................................... 75
2.4.1 Dados dos Usuários ............................................................................... 75
2.4.2 Dados de Pontos Intermediários ........................................................... 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 Inspeção 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 Aplicações ............................................................................. 87
2.5 Extração de Informação ................................................................................... 88
2.5.1 Visão Geral ........................................................................................... 88
2.5.2 Identificação de Entidades .................................................................... 91
2.5.3 Resolução de Entidades ........................................................................ 91
2.6 Bases de Dados Disponíveis na Web .............................................................. 93
2.7 Conclusões ....................................................................................................... 93
Referências ............................................................................................................. 94
xiii
Capítulo 3 – Web das Coisas: Conectando Dispositivos Físicos ao
Mundo Digital ........................................................................................... 103
3.1 Introdução ...................................................................................................... 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 Princípios REST .................................................................... 110
3.3.2 ROA .................................................................................................... 113
3.3.2.1 URIs ....................................................................................... 113
3.3.2.2 Endereçabilidade ................................................................... 114
3.3.2.3 Sem Estado ............................................................................ 114
3.3.2.4 Representação ........................................................................ 115
3.3.2.5 Links e Conectividade ........................................................... 115
3.3.2.6 Interface Uniforme ................................................................ 115
3.3.3 Desenvolvimento de Serviços RESTful .............................................. 116
3.3.3.1 Requisitos do Serviço Web de Exemplo ............................... 117
3.3.3.2 Identificação de Recursos ...................................................... 118
3.3.3.3 Representação de Recursos ................................................... 118
3.3.3.4 Definição 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 Comunicação Orientada a Eventos ..................................................... 128
3.5 Web das Coisas: Desenvolvendo Aplicações na Plataforma Sun SPOT....... 129
3.5.1 Introdução a Plataforma Sun SPOT .................................................... 129
3.5.2 Integração de Dispositivos na Web ..................................................... 131
3.5.2.1 Técnica de Implementação de Servidores Web em Dispositivos
Embarcados ........................................................................................ 132
3.5.2.2 Implementação de Gateways ................................................. 138
3.5.2.3 Exposição de Dispositivos como Recursos REST ................ 142
3.5.2.4 Representação de Estado ....................................................... 142
3.5.3 Técnicas de Implementação de Mashups Físicos ............................... 143
3.6 Conclusão ...................................................................................................... 145
Referências ........................................................................................................... 146
xiv
Capítulo 4 – Gerência de Identidade na Internet do Futuro ............... 151
4.1 Introdução ...................................................................................................... 152
4.2 Internet do Futuro .......................................................................................... 155
4.2.1 Exemplos de Serviços da Internet do Futuro ...................................... 157
4.2.2 Redes da Próxima Geração ................................................................. 159
4.3 Gerência 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 Usuários, Provedores de Identidade e Provedores de Serviços .......... 167
4.4 Requisitos de um Sistema de Gestão de Identidade na Internet do Futuro ... 169
4.5 Iniciativas de Gerência de Identidade para as Redes da Próxima Geração ... 174
4.5.1 Projetos e Arquiteturas ........................................................................ 174
4.5.2 Alianças ............................................................................................... 181
4.5.3 Especificações Consolidadas .............................................................. 182
4.6 Ferramentas e Tecnologias para Gerência de Identidade .............................. 184
4.6.1 Cartões Inteligentes (Smart Cards) ..................................................... 185
4.6.2 Biometria ............................................................................................. 188
4.7 Conclusões ..................................................................................................... 189
Referências ........................................................................................................... 191
Capítulo 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
Referências ........................................................................................................... 236
Capítulo
1
Pesquisa Experimental para a Internet do Futuro:
Uma Proposta Utilizando Virtualização e o Framework Openflow
Fernando N. N. Farias, José M. Dias Júnior, João J. Salvatti, Sérgio Silva,
Antônio J. G. Abelém, 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 flexibility 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 first, 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 efficiently them without sacrificing the current infrastructure, since there will be
the need for routers and switches to be reconfigured, and resources to be allocated and
monitored. Thus, the network must be as flexible 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
2
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 configure 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 flexibilidade da
tecnologia IP. Apesar de todo o sucesso da Internet, a tecnologia básica IP é a causa
das suas próprias limitações que se tornam cada vez mais evidentes. Um dos principais
objetivos da atividade conhecida como Internet do Futuro (IF) é a formulação e avaliação de arquiteturas alternativas para substituir o protocolo IP. Nesse contexto, duas
abordagens estão sendo discutidas e investigadas: a primeira denominada limpa (Clean
Slate), que visa substituir a arquitetura atual por uma nova totalmente reconstruída, e a
outra chamada evolucionária (Evolutionary) que pretende evoluir a arquitetura atual sem
perder a compatibilidade com a anterior. No entanto, o maior desafio agora é onde habilitar e testar as propostas das respectivas abordagens de modo a validá-las eficientemente,
sem prejudicar a infraestrutura atual, já que haverá a necessidade de que roteadores e
switches sejam reconfigurados, e recursos sejam alocados e monitorados. Em suma, a
rede deve ser a mais flexível possível, para que essa infraestrutura permita a coexistência de múltiplos modelos paralelos. Nesse sentido, a virtualização (de rede, dispositivos,
enlace e etc.) e a solução OpenFlow vem se tornando uma interessante alternativa para
habilitar múltiplos experimentos com novas arquiteturas em um ambiente de produção.
Uma rede OpenFlow admite a programação do comportamento da rede, além da criação de ambientes de rede virtuais chamados fatias (redes virtuais com nós, enlaces e
recursos) para testar novos modelos de protocolo. Este minicurso tem como principal
objetivo apresentar os desafios e soluções para se criar um ambiente de testes para a
Internet do Futuro utilizando técnicas de virtualização de redes e o framework OpenFlow. O minicurso será essencialmente teórico e apresentará os fatores motivacionais
que vêm levando os profissionais da área e a comunidade acadêmica a investirem na realização de pesquisa experimental para investigar os desafios da Internet do Futuro. Em
seguida, serão expostas as recentes experiências realizadas para IF, tanto no Brasil como
em backbones da Europa, da América do Norte e da Ásia. Após isso, será detalhado o
arcabouço OpenFlow, incluindo os principais aspectos sobre virtualização. Logo depois,
serão descritos os requisitos para construção de uma rede para experimentação, com
a demonstração e o detalhamento dos mecanismos necessários para configurar e testar
esse ambiente. Um estudo de caso de criação de várias fatias de redes para testes de
protocolos também será demonstrado. Por fim, serão apresentadas as tendências futuras
em relação à pesquisa experimental em Internet do Futuro.
3
1.1. Introdução
A Internet hoje está sendo usada para uma grande variedade de propósitos comerciais e
não comerciais. Para muitas pessoas é uma ferramenta de trabalho crucial, para outras, seu
local de trabalho. Porém, para a grande maioria, é um eficiente meio de comunicação, 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 flexibilidade da tecnologia IP (Internet Protocol), que provê um
mecanismo uniforme de transporte fim a fim, independente das tecnologias utilizadas nas
camadas de mais baixo nível.
Apesar de todo o sucesso da Internet, a tecnologia básica IP é a causa das suas
próprias limitações, que se tornam cada vez mais evidentes. A noção central de tamanho
único, que requer tratamento idêntico para todos os fluxos de informação na Internet ao
nível do pacote IP, não é desejável e nem necessariamente econômica, especialmente
quando certas classes de aplicação, tais como de mídia interativa ou de acesso remoto
a instrumentos científicos que, requerem garantias de qualidade de serviço (Quality of
Service - QoS) desnecessárias para a maioria de outras aplicações.
A atual arquitetura da Internet, inicialmente projetada há aproximadamente 30
anos, sofreu muitas extensões nos anos recentes para incluir novas funcionalidades, as
quais não foram previstas no projeto inicial. Muitos especialistas de rede agora consideram que é necessário conduzir um estudo de arquiteturas alternativas para Internet do
Futuro (IF), como uma maneira realmente eficiente de resolver muitos dos problemas
prementes que atualmente afligem a Internet. Algumas das desvantagens da continuada
persistência no uso da atual arquitetura incluem:
• Exaustão já anunciada do espaço atualmente disponível de identificadores de rede
IP versão 4 (IPv4), causando uma “balcanização” da Internet, sem verdadeira conectividade global;
• Custos elevados dos roteadores IP, restringindo o crescimento da rede, motivado
principalmente pela natureza não escalonável das tabelas de roteamento, e dos requisitos de desempenho necessários para poder processar essas gigantescas tabelas
na mesma velocidade que seus enlaces;
• Investimentos imensos em medidas paliativas para conter problemas de segurança
atualmente causados por spam, negação de serviço (DoS - denial of service) e
crimes de roubo de informação;
• Dificuldades de combinar transparência de acesso e desempenho de aplicação para
usuários móveis.
Devido a isso, nos últimos anos, vêm sendo aplicadas à arquitetura da Internet
uma série de modificações pontuais ou “remendos”, para atender às limitações encontradas. Entre os “remendos” mais conhecidos, podem ser mencionados Classless Internet Domain Routing (CIDR), Network Address Translation (NAT), Serviços Integrados
(Intserv), Serviços Diferenciados (Diffserv), IP Seguro, IP Móvel, firewalls e filtros de
spam; estes são os mais conhecidos.
4
Por conta disso, há um entendimento crescente entre os pesquisadores em redes
de computadores que soluções para a maioria destes problemas, dependerão de um redesenho fundamental da atual arquitetura da Internet, baseada em IP. E como aliada na
busca dessas soluções, surge a atividade conhecida como Internet do Futuro, que inclui
entre seus principais objetivos a formulação e avaliação 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 evolução do conceito da Internet [Banniza et al. 2009]
Nesse contexto, duas abordagens estão sendo discutidas e investigadas. A primeira
denominada limpa (Clean Slate), que visa substituir a arquitetura atual por uma nova
totalmente reconstruída. A outra, chamada evolucionária (Evolutionary), que pretende
evoluir a arquitetura atual sem perder a compatibilidade com a anterior.
A proposta Clean Slate, que atualmente é um dos esforços 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, é possível destacar como os principais
desafios: robustez e disponibilidade, suporte a nós móveis economicamente viável e rentável, gerenciabilidade com segurança e ser evolutiva.
As pesquisas baseadas em Clean Slate permitem explorar radicalmente uma nova
arquitetura para Internet, mas isso não quer dizer que serão imediatamente aplicadas.
Desse modo, algumas dessas soluções podem ter ou não um caminho viável de implantação na Internet atual [Feldmann 2007].
Por outro lado, tem-se a abordagem Evolutionary ou Incremental, que tem a missão, como pesquisadores da Internet, de primeiro medir e entender o estado corrente
5
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 mutação” [Rexford and Dovrolis 2010], ou seja, inovações que
podem, primeiro, afastar ou resolver estes desafios e, segundo, adaptar-se para a corrente
infraestrutura da Internet, de uma forma que seja compatível com as versões anteriores e
possa ser incrementalmente expansível.
A adoção de qualquer uma das arquiteturas alternativas pode alterar a situação em
que a Internet atual se encontra. Entretanto, um sério obstáculo para adoção efetiva de
tais inovações tem sido a inabilidade de validá-las de maneira convincente. A redução no
impacto do mundo real de qualquer inovação se deve à enorme base instalada de equipamentos e protocolos e à relutância em experimentar com tráfego de produção, 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 não é testada, levando
à crença comumente mantida de que a infraestrutura da Internet “ossificou” ou enrijeceu [Paul et al. 2011].
Tendo reconhecido o problema, a comunidade de pesquisa de rede está desenvolvendo soluções alternativas para pesquisa experimental em IF. Suas atividades inicias,
usando redes para experimentação (testbeds), começaram nos EUA com os programas
Global Environment for Network Innovations (GENI) [GENI 2011] e Future Internet Design (FIND) [FIND 2011], onde suas principais propostas são testar e amadurecer um
grande conjunto de pesquisas em comunicação de dados e sistemas distribuídos.
Além disso, ainda há o programa Future Internet Research and Experimentation (FIRE) na UE (União Europeia) [FIRE 2011] que é uma iniciativa de ambiente de
pesquisa para experimentação e validação de ideias inovadoras e revolucionárias para
novos paradigmas de redes e serviços. Nesta mesma linha, temos o projeto AKARI no
Japão [AKARI 2009], um programa de pesquisa que tem como objetivo implementar a
nova geração de redes para 2015, baseada na proposta Clean Slate. E por fim, iniciativas
semelhantes também foram lançadas mais recentemente na Coreia [Liu et al. 2009] e na
China [Bi 2011].
Neste sentido, redes de experimentação programáveis e virtualizadas vêm sendo
utilizadas por esses projetos para diminuir a barreira de custo à entrada de novas ideias,
aumentando a taxa de inovação da infraestrutura de rede. Com isso, são oferecidas infraestruturas capazes de habilitar, controlar e testar as respectivas abordagens, de modo a
validá-las eficientemente, sem prejudicar a infraestrutura atual.
No contexto de redes programáveis, o arcabouço OpenFlow é uma solução que
vem oferecendo aos pesquisadores a possibilidade de testar seus protocolos experimentais
em redes de produção como: redes de um campus, redes metropolitanas ou em um backbone de rede de ensino e pesquisa [McKeown et al. 2008]. O OpenFlow, além de oferecer o protocolo de controle, chamado de OpenFlow protocol para manipular a tabela de
encaminhamento dos roteadores e switches, também oferece uma API (Application Programming Interface) simples e extensível para programar o comportamento dos fluxos de
pacotes. Desta forma que, através desta API, pesquisadores podem rapidamente construir
novos protocolos e aplicá-los em um ambiente de produção sem prejudicá-lo.
6
A virtualização de computadores tem sido usada há muito tempo e hoje está amplamente disponível em plataformas comuns. É realizada por meio do compartilhamento
de processadores e dispositivos de E/S, utilizando técnicas de fatiamento de tempo e
memória virtual. A virtualização de redes, a mais recente, é conseguida pelo uso de
switches, roteadores virtuais e a multiplexação de enlaces [Chowdhury and Boutaba 2010].
Observando isso, o uso das técnicas de virtualização de redes (dispositivos, enlace,
etc.) em conjunto com a solução OpenFlow vem se tornando uma excelente alternativa
para habilitar múltiplos experimentos com novas arquiteturas em um ambiente de produção. Uma rede OpenFlow permite que se possa programar o comportamento da rede,
além de criar ambientes virtuais de rede chamados de “fatias” (redes virtuais com nós,
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 necessários e o uso de virtualização e OpenFlow
para se criar um ambiente de testes para experimentação e desenvolvimento de protocolos na abordagem de IF. Além desta seção introdutória, o artigo está dividido da seguinte
maneira:
• Seção 2 - são apresentadas as recentes experiências realizadas para Internet do Futuro, tanto no Brasil como em backbones da Europa e da América do Norte;
• Seção 3 - é detalhado o framework OpenFlow, incluindo os principais aspectos
sobre virtualização;
• Seção 4 - são descritos os requisitos para construção de um testbed experimental;
• Seção 5 - tem-se um estudo de caso de criação de vários slices de redes para testes
de protocolos;
• Seção 6 - são apresentadas as considerações finais e tendências futuras em relação
à pesquisa experimental e Internet do Futuro.
1.2. Pesquisa Experimental em Internet do Futuro no Brasil e no Mundo
Atualmente, na comunidade acadêmica, existe um amplo consenso de que a Internet atual
sofre várias limitações relacionadas com escalabilidade, suporte a redes móveis de vários
tipos (ad-hoc, multi-hop e mesh), mobilidade, ao consumo de energia, à transparência, à
segurança e outras [Jain 2006].
A partir disso, nesta seção, são levantados e comentados os principais desafios
que estão relacionados à Internet do Futuro. Como também, são observados os projetos
a respeito de investigação da IF como o caso do GENI (Global Environment for Network
Innovation), financiado pela NSF (National Science Foundation), FIRE (Future Internet
Research and Experimentation), pela União Europeia e por iniciativas brasileiras.
1.2.1. Desafios Relacionados à Internet do Futuro
O conceito básico da arquitetura da Internet foi desenvolvido há mais de trinta anos atrás.
Neste tempo, tem-se aprendido bastante sobre redes de computadores e encaminhamento
7
de pacotes. Também, durante este mesmo período, a Internet vem sofrendo contínuas
adaptações, causadas pelo seu rápido crescimento e pela quantidade de usuários e aplicações habilitadas sobre sua arquitetura. Essas adaptações ou “remendos” demonstram
que o projeto inicial já não se ajusta às necessidades atuais na rede. Além disso, a arquitetura atual da Internet já apresenta inúmeros problemas ainda não solucionados, impedindo
o atendimento dos requisitos destas novas aplicações e serviços.
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 eficiente de resolver muitos dos
problemas prementes que atualmente afligem a Internet. A seguir, são apresentados alguns dos principais desafios, 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
comunicação em rede. No entanto, hoje há vários desafios no horizonte, entre elas as
tecnologias sem fio e as novas soluções ópticas
As redes sem fio abrangem uma série de tecnologias que vão do Wi-Fi de hoje até
as ultra-widebands e redes de sensores sem fio de amanhã. Considera-se que as redes sem
fio são talvez umas das maiores tecnologias de rede e com granularidade maior ou igual
às redes locais (LAN). No entanto, uma consequência das redes sem fio é a mobilidade.
Atualmente, a mobilidade está na “borda” da rede, mas, os mecanismos para torná-la
mais eficiente não funcionam de maneira satisfatória. Principalmente, nas questões relacionadas à eficiência energética, mudança de ponto de acesso e aplicações. Portanto,
identificam-se os seguintes desafios para suporte às tecnologias sem fio:
• a Internet do Futuro deve suportar a mobilidade como o objetivo primordial em sua
construção. Os nós devem ser capazes de modificar seu ponto de acesso na Internet
e, mesmo assim, continuarem sendo alcançáveis
• a Internet do Futuro deve oferecer meios adequados para uma aplicação de descobrir
as características dos mais variados tipos de enlace de rede sem fio e se adaptar a
eles, de maneira a prover as eficiências energéticas destes nós.
• a Internet do Futuro deve facilitar o processo pelo qual os nós móveis, fisicamente
próximos, descubram-se uns aos outros.
Outra tecnologia revolucionária é 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 lógicos para encaminhar dados com
taxas de transmissão muito maiores que as redes puramente eletrônicas. Isso envolve
mudanças em vários níveis: de redes em anéis para redes em malha; de redes com comprimentos de ondas fixamente alocados para transmissores (e receptores) dinamicamente
sintonizados; de redes sem buffers ópticos para redes com planos de controles inteligentes
8
e com buffers ópticos suficientes; e de redes ópticas que utilizam larguras de bandas fixas
para as que permitem que a largura de banda seja dinamicamente alocada, acessada e utilizada. Logo se identificam os desafios para Internet do Futuro poder explorar a emergente
capacidade óptica:
• a Internet do Futuro deve ser projetada para permitir aos usuários utilizarem essas novas capacidades de transporte ópticos, incluindo uma melhor confiabilidade
através de diagnósticos entre camadas;
• a Internet do Futuro deve permitir que os nós que são dinamicamente configuráveis
habilitem a camada eletrônica para o acesso dinâmico de usuários;
• a Internet do Futuro deve incluir softwares de controle e gerenciamento que permitam à rede formada por nós dinamicamente reconfiguráveis ser configurada por
aplicações que necessitem de uma grande quantidade de recursos de rede, tal como
largura de banda
b. Segurança e Robustez
Talvez a razão que mais estimulou a comunidade acadêmica a pensar em um redesenho
da Internet foi a possibilidade de ter uma rede com grandes avanços na segurança e na
robustez. Na Internet atual, não há nenhuma abordagem, realmente abrangente para tratar
questões de segurança. Ela possui muitos mecanismos, mas não uma “arquitetura segura”
e muito menos um conjunto de regras determinando como esses mecanismos devem ser
combinados para se obter uma boa segurança de maneira geral. A segurança em redes e
principalmente a da Internet, atualmente se assemelha a um conjunto crescente de remendos, extremamente suscetível a falhas.
Para construção de uma rede mais robusta e segura, identificam-se os seguintes
desafios:
• qualquer conjunto de hosts deve ser capaz de se comunicar entre si com alta confiabilidade e previsibilidade e nós maliciosos ou defeituosos não podem ser capazes
de interromper esta comunicação. Além disso, os usuários devem esperar por um
nível de disponibilidade correspondente ou que exceda o sistema de telefonia de
hoje;
• a segurança e robustez devem ser estendidas através de suas camadas, pois a segurança e confiabilidade de um usuário final dependem da robustez, tanto nas camadas
de comunicação quanto nas aplicações distribuídas.
c. Eficiência Energética na Comunicação
Atualmente, há uma preocupação mundial [Joseph and Lewis 2008] pelo desenvolvimento
de tecnologias que diminuam o consumo de energia, principalmente em redes, como as de
sensores sem fio e as de dispositivos móveis Wi-Fi, onde recursos energéticos são fatores
9
relevantes em sua comunicação. Com as atuais tecnologias, comunicando um bit sobre
um meio sem fio, em intervalos curtos, consomem mais energia do que o seu processamento, e não possui tendência de mudanças em um futuro próximo [Chen, 2006]. No
entanto, a Internet atual não possui mecanismos que levem em consideração a comunicação com requisitos de eficiência de energia, de modo a adaptar o seu consumo mediante
a observação do meio. Ou ainda, que adapte o uso de energia para oferecer uma comunicação eficiente, na transmissão de dados e no gerenciamento de rede, a baixos níveis
energéticos.
Portanto, como desafio para o projeto da Internet do Futuro:
• deve-se prover meios para uma eficiência energética generalizada tanto para dispositivos sem fio quanto os com fio;
• desenvolver tecnologias com o foco no uso eficiente da energia elétrica;
• incluir em sua arquitetura mecanismos que ofereçam uma comunicação eficiente
tanto na transmissão de dados como no gerenciamento de rede;
• prover uma arquitetura para Internet do Futuro energeticamente otimizada.
d. Separação de Identidade e Endereço
Na Internet atual, um sistema é identificado pelo seu endereço IP. Como resultado, quando
o sistema mudar a localização do ponto da sua interligação, seu endereçamento também
pode mudar. Ou seja, o endereço IP, neste caso, ao mesmo tempo, tem o papel de identificador e localizador. Devido a isso, os nós móveis se tornaram um desafio na Internet
atual. Por essas características, torna-se difícil iniciar a comunicação com um sistema
móvel.
Este é um problema bem conhecido na Internet e há um número considerável 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 desafios:
• aplicar soluções que permitam a localização global de um determinado host, através
da utilização de um sistema de endereçamento global;
• definir novas formas de localização e identificação, além do desenvolvimento de
endereçamentos coesos às necessidades da rede.
e. Qualidade de Serviço e Qualidade de Experiência
A natureza do IP, não orientado a conexão, dificulta qualquer aplicação de garantia de
QoS (Quality of Service - qualidade de serviço). Além disso, a característica de encaminhamento de pacote baseado em melhor esforço faz com que qualquer abordagem
10
relacionada a questões de reservar de recursos ou prioridade interfira no funcionamento
estabelecido para Internet atual.
Desta maneira, embora a qualidade de serviço tenha sido extremamente pesquisada
na comunidade acadêmica ainda não há um modelo claro de como diferentes níveis de
qualidade devem ser aplicados e de que forma ele se integrar arquitetura de rede atual.
Desta fora, são desafios para arquitetura da Internet do Futuro:
• permitir uma variedade de garantias levando em consideração tanto a qualidade da
aplicação na rede como a qualidade de experiência do usuário;
• novos métodos de encaminhamentos de pacote baseados nas características das
aplicações, principalmente as de tempo real.
f. Separação entre os Planos de Controle, Gerenciamento e Dados
Na Internet atual, os planos de controle, gerenciamento e dados são unificados, ou seja,
mensagens de controle, por exemplo, mensagens de conexão TCP (Transmission Control
Protocol) ou mensagens de gerenciamento SNMP (Simple Network Management Protocol), seguem no mesmo canal em que trafegam os dados. Como consequência, ocorre
a possibilidade de um significante risco de segurança dos dados de controle, além do
desperdício de recursos da rede.
Uma vantagem desta separação de planos é a adoção de novas tecnologias de plano
de dados pela arquitetura de rede como: um comprimento de onda; quadro SDH; ou uma
linha de transmissão de energia (Power Line Comunication - PLC). Logo a separação
entre os planos deve ser parte integrante desta próxima geração da arquitetura da Internet.
g. Isolamento
Para algumas aplicações críticas, o usuário demanda isolamento em um ambiente compartilhado como na Internet atual. Isolamento significa garantir que o desempenho desta aplicação crítica não seja afetado por outras aplicações que queiram compartilhar o mesmo
recurso.
Com o uso da virtualização, o isolamento se tornou um fator ainda mais importante, principalmente para virtualização de redes, onde um roteador ou uma infraestrutura
de rede é totalmente virtualizada, de forma que o encaminhamento de pacotes não pode,
de maneira alguma, sofrer interferências de, ou causá-las em outras infraestruturas.
Assim, a próxima geração da Internet deve prover em sua arquitetura um modo
eficiente de prover uma combinação programável de isolamento e compartilhamento às
suas aplicações e serviços.
11
h. Mobilidade
Com a crescente e diversificada quantidade de serviços na Internet, impulsionada principalmente pelo aumento do acesso de dispositivos sem fio. Amplia-se a necessidade de
mobilidade pelos usuários.
Com isso, a forma de comunicação estabelecida originalmente pela arquitetura da
Internet atual como conexão ponto-a-ponto e entrega imediata, faz com que esses tipos
de usuários não sejam atendidos satisfatoriamente. Principalmente, por causa de uma
questão comum relacionada à mobilidade, que são os handovers, criados com o objetivo
de evitar que os nós móveis tenham a perda das suas conexões ativas. Os protocolos da
Internet atual não prevêem o tratamento desse comportamento. E ainda, protocolos como
TCP também são prejudicados por não prever esse tipo de usuário.
Com isso, a Internet do Futuro enfrenta o grande desafio de como permitir a movimentação do nó entre diferentes pontos de acesso sem que as conexões ativas sejam perdidas.
i. Escalabilidade
Com o aumento exponencial do número de estações ou sistemas conectados à Internet,
alguns componentes da arquitetura atual têm sofrido com problemas de escalabilidade.
Esse é o caso do sistema de roteamento, que sofre com o aumento e as atualizações frequentes de suas tabelas. Ainda há a questão dos endereçamentos que não são capazes de
suportar todos os elementos conectados à rede, como é o caso do IPv4.
Portanto, a Internet do Futuro terá o desafio de manter o sistema global de roteamento escalável, além de novos protocolos que mantenham essa escalabilidade, mesmo
com o aumento do espaço de endereçamento. E também novas formas de endereçamento
para evitar a escassez do recurso.
1.2.2. Iniciativas para Investigação 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 desafios da Internet do Futuro e,
com isso, modelar a arquitetura que conduzirá a um nova geração da Internet.
No entanto, estas novas propostas e especulações teóricas na direção destas soluções
deveriam ser suportadas por uma infraestrutura real de rede experimental e testadas em
ambientes de larga escala. Estas instalações experimentais desempenhariam o papel de
rede para experimentação ou ambiente de tese (testbed), possibilitando experimentos para
a prova de conceitos de novas arquiteturas, protocolos, tecnologias e serviços.
Uma coexistência com a rede de tráfego de produção é essencial para observação
e captura de certos aspectos e fenômenos perceptíveis apenas em instalações 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 começaram a surgir, em fiferentes 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 investigação e experimentação em Internet do Futuro. O GENI é um conjunto de
infraestruturas de redes para experimentação, dos mais variados modelos tais como: sem
fio, óptico e elétrico. Patrocinado pela National Science Fundation (NSF) desde 2005,
atualmente está em fase de desenvolvimento e prototipagem.
O objetivo do GENI é montar um grande laboratório em larga escala para experimentações em redes de computadores, onde a maior importância é validar novas possibilidades para Internet do Futuro.
Para o GENI, os conceitos principais relacionados à experimentação em Internet
do Futuro e que fazem parte do projeto de sua arquitetura são [GENI-Sys 2008]:
Programabilidade: Os pesquisadores poderão carregar software nos nós do GENI para
modificar o seu comportamento;
Virtualização e outras formas de compartilhamento de recursos: Qualquer que seja a
implementação de máquina virtual sobre um nó GENI, será permitido que múltiplos
pesquisadores simultaneamente compartilhem a mesma infraestrutura. Cada experimento terá à sua disposição uma fatia isolada, com recursos fim-a-fim alocados
dentro do infraestrutura do GENI;
Federação: O GENI será composto por infraestruturas próprias e por outras de apoio,
operadas por organizações parceiras ao projeto, criando o conceito de uma federação de recursos e nós, que, na visão 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
localizações, chamada de uma fatia de recursos. Dentro dessa fatia o pesquisador
poderá remotamente descobrir, reservar, configurar, “depurar”, operar e gerenciar
seus experimentos e recursos disponíveis.
Para se ter uma ideia de como o GENI irá funcionar após a sua concepção, a
Figura 1.2 ilustra o fluxo 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 experimentação de seus modelos ou protocolos no ambiente
GENI. Esse processo é formado por três estágios intermediários: descoberta de recurso,
criação da fatia e experimentação.
Na descoberta de recursos (DR), Figura 1.2(a), o pesquisador terá uma visão
global dos recursos disponíveis para o seu experimento. A partir disso, poderá definir,
de maneira simples, quais os recursos do GENI serão utilizados em seus experimentos.
Na criação da fatia, Figura 1.2(b), o pesquisado recebe uma fatia ou contêiner
vazio onde serão instanciados os recursos e o software que foram definidos pela DR.
13
Figura 1.2. A criação de um fatia sobre a infraestrutura do GENI [GENI-Sys 2008]
Neste caso, uma fatia é uma integração de dois agregados: um cluster de computadores e
uma rede ou um conjunto de redes.
Por fim, na experimentação, 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 confluência de vários grandes ambientes de teste,
oferecendo alternativas para experimentação 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 laboratório para testes e desenvolvimento de aplicações distribuídas, criado a partir de 2002 por um consórcio de instituições
acadêmicas, governamentais e industriais, que montou uma grande malha de computadores espalhados pelo mundo em diversas redes. Hoje, possui mais de 1050 máquinas 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 virtualização dos nós e
de criação de fatias de recursos virtuais e dedicados nos nós usados num experimento. No
Brasil há participação do consórcio desde 2004.
14
No projeto GENI, o PlanetLab GENI [Spiral2 2010], será uma alternativa de rede
para experimentação para seus pesquisadores. O grupo de Princeton dirige esta atividade e tem como escopo integrar logicamente os componentes GENI aos serviços PlanetLab como: PLC (PlanetLab Central Sofware), responsável por criar a rede sobreposta
definindo a topologia virtual que será usada para experimento; e o SFA (Slice-Based Facility Architecture), responsável por localizar e alocar os recursos para os experimentos [Peterson et al. 2009].
ORBIT
O projeto ORBIT provê um rede sem fio flexível aberto à comunidade acadêmica para
experimentação. Ele foi desenvolvido para que pesquisadores entendessem as limitações
do mundo real das redes sem fio, que muitas vezes não são percebidas em simulações
por causa das simplificações aplicadas ao modelo ou por terem sido aplicadas em uma
quantidade pequenas de nós.
O ORBIT possui dois ambientes de teste no campus da Universidade Rutgers: o
primeiro é dentro de um laboratório, constituído por 400 nós dispostos em uma grade
20x20 (ilustrado na Figura 1.3), separados por um metro de distância entre os nós adjacentes, onde cada nó é composto por uma plataforma PC com múltiplas interfaces sem fio
e com fio. O segundo está localizado ao ar livre , numa área de 1,5 hectares. Entre eles
existem nós fixos, e também nós móveis para prover mobilidade entre os roteadores (v.
http://www.orbit-lab.org/wiki/WikiStart).
Figura 1.3. ORBIT Testbed Indoor
No GENI, sua integração permitirá que pesquisadores gerenciem esse ambiente
de redes sem fio dentro do GENI, além estender a capilaridade de nós do ORBIT para
outros ambientes sem fio. 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 interação do usuário com ele.
O projeto é gerenciado pela Universidade de Utah, onde foram desenvolvidos os
primeiros nós do EmuLab. Atualmente, há mais de doze países utilizando o EmuLab,
totalizando uma rede para experimentação com mais de cem nós. 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 disponíveis no EmuLab são: Emulação (Emulation), neste ambiente, o pesquisador
define uma topologia arbitrária com switches ou roteadores e nós 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 fio; e o ambiente Software-Defined Radio o qual permite experimentações
em camada 1 para análise de processamento de sinal.
Figura 1.4. Cluster EmuLab
No GENI, a integração 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, além de controlar novos não oferecidos atualmente, por exemplo,
à infraestrutura de altíssima 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 financiamento de projetos que produzam infraestruturas para
experimentação em Internet do Futuro. A meta é que as pesquisas em tecnologias para
Internet do Futuro sejam direcionadas à rede ou a serviço e tenham a possibilidade de
comparar as soluções correntes com as propostas futuras. Desta forma, afirma-se que o
FIRE possui duas dimensões relacionadas que direcionam suas pesquisas e seus investimentos [FIRE 2008]:
Pesquisa Experimental: o objetivo é integrar a pesquisa multidisciplinar e a experimentação em larga escala. A partir daí, definir uma metodologia que direcionará
pesquisa experimental na infraestrutura FIRE, baseada em um ciclo interativo que
vai da pesquisa, passando pelo projeto e chegando à experimentação;
Facilidades para Testes: o objetivo é oferecer múltiplos ambientes de teste, suportando
várias tecnologias e interligados e federados entre si para permitir a realização
de experimentos envolvendo dois ou mais dos ambientes distintos. Deste modo
pretende-se que FIRE seja sustentável, renovável, dinâmico e integrado em larga
escala. Deverá ainda facilitar a pesquisa experimental na comunidade acadêmica,
nos centros de pesquisa e na indústria.
Para o FIRE, as experiências práticas são essenciais para dar credibilidade e levantar o nível de confiança na conclusão da pesquisa. Além disso, a experimentação deve
ser executada em larga escala para que seja representativa, convincente e, para provar a
escalabilidade da solução, testada. Os projetos de ambiente de teste em destaque aqui,
financiados 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 múltiplos locais para o suporte à pesquisa de aplicações,
serviços e sistemas, visando a “Internet de Serviços” dentro da Internet do Futuro. O BonFIRE objetiva oferecer aos pesquisadores acesso a um ambiente experimental em larga
escala para experimentação de seus sistemas e aplicações, avaliações do efeito “crosscutting” da convergência dos serviços, infraestrutura de rede e a análise do impacto socioeconômico.
O BonFIRE irá operar uma nuvem baseada em IaaS (Infrastructure as a Service)
com políticas e melhores práticas de experimentações. Ele irá se adaptar a uma abordagem multiplataforma federada provendo interconexão e interoperação entre os serviços
e a rede no ambiente de teste. A plataforma irá oferecer serviços avançados e ferramentas para pesquisa de novos serviços, incluindo nuvens de federações, gerenciamento de
máquinas virtuais, modelagem, gerenciamento do ciclo de vida a experimentação, monitoramento da qualidade de serviço e análise 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 avanço em pesquisa
em sensoriamento de espectros, rádios cognitivos e estratégias de redes cognitivas em
visões horizontais e verticais do espectro compartilhado em bandas licenciadas e não
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 fio utilizando um leque de tecnologias sem fio como: heterogêneos ISM, Celular e Sensores
sem fio, com o estado da arte de plataforma de sensoriamento cognitivo.
O CREW irá fisicamente e virtualmente federar componentes interligando entidades de software e hardware de diferentes padrões usando APIs padronizadas. Além
disso, o CREW estabelecerá um “benchmark framework” (arcabouço de controle padrão),
habilitará experimentos controlados, metodologias para análise automática de performance e reproduzirá condições para teste.
OFELIA
O projeto OFELIA [OFELIA 2011] visa criar um ambiente para experimentação que também permita a seus pesquisadores o controle a redes da sua maneira de forma precisa e
dinâmica. Para alcançar isso, o ambiente OFELIA é baseado em OpenFlow, atualmente
uma tecnologia de rede emergente que permite virtualizar e controlar ambientes de rede
através de interfaces seguras e padronizadas (v. seção 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 Bélgica, Alemanha, Espanha, Suíça e Reino Unido. Essas ilhas reúnem uma
diversidade de infraestruturas baseadas em OpenFlow que permitirá experimentações em
18
redes multicamadas e multitecnologicas. Na Figura 1.6 é apresentada como a estrutura
dessas ilhas serão instaladas em cada um desses países.
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. Além disso, novas aplicações poderão ser colocadas no
controlador OpenFlow a qualquer momento na infraestrutura. Também permitirá serem
investigadas novas estruturas e formatos de endereçamento e modelos de encaminhamentos.
1.2.2.3. Iniciativas Brasileiras
Os parceiros brasileiros contribuem no projeto com a experiência na implantação de instalações de experimentações locais e na participação em diferentes projetos de pesquisa
experimental em Internet do Futuro, embora com pouca ou nenhuma coalizão estratégica
entre elas. O primeiro desses projetos a destacar-se é o de pesquisa e desenvolvimento
GIGA e suas instalações 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 definidas por software. Deverá ser atualizado em breve com comutadores OpenFlow de 10G (o primeiro
na América do Sul) e uma solução aberta (“open-source”) de roteamento de pacotes (o
primeiro do mundo e neste momento disponível 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 laboratórios de 23 instituições da Região Sudeste do Brasil e está conectada com a rede nacional da RNP (Rede Ipê). Através desta,
interliga-se com redes de pesquisa e ensino em todo o mundo. A rede GIGA mantém 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 Ciência e Tecnologia
(INCT). O projeto Web Science começou 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 experiência em redes ópticas e sem fio, estudos de simulação e emulação e monitoramento de rede. Um dos primeiros objetivos do projeto é
estabelecer ilhas experimentais nos laboratórios de cada parceiro e interligá-las em camada 2 através das redes de Ipê e GIGA.
1.3. OpenFlow e Virtualização
1.3.1. O OpenFlow
A pesquisa na área de arquiteturas de redes de computadores possui diversos desafios
em relação à implementação e experimentação de novas propostas em ambientes reais.
Isso ocorre devido à dificuldade para o pesquisador possuir uma rede de testes próxima
de uma rede real. Para isso foi desenvolvido o OpenFlow [McKeown et al. 2008], que
propõe um mecanismo para permitir que redes reais sejam utilizadas como um ambiente
de experimentos.
O OpenFlow é uma proposta tecnológica que, baseada na separação 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 tráfego de produção.
A proposta é fundamentado em comutadores Ethernet comerciais e define um protocolo
padrão para controlar o estado destes comutadores (tabela de fuxos, estatísticas e etc.). O
conceito de fluxo é o bloco fundamental que habilita aos pesquisadores definir o plano
de encaminhamento na rede, conforme os objetivos definidos pelas novas propostas de
arquiteturas e protocolos de rede. O OpenFlow também define 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. Seção 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 tráfegos, o experimental e o de produção. Assim, o OpenFlow possibilita que os pesquisadores reprogramem os comutadores, sem provocar interferência na configurações da rede de produção. Outro objetivo dessa proposta é permitir que os fabricantes possam incluir as
funcionalidades do OpenFlow nos seus comutadores sem necessitarem expor o projeto
desses equipamentos.
Além disso, tais equipamentos devem possuir um custo baixo e desempenho semelhante aos já utilizados nas redes de produção, tanto nas universidades como nas redes de
pesquisa, de forma que os administradores destas redes aceitem a substituição dos equipamentos já existentes. Com base no exposto, o projeto do OpenFlow tem como objetivo
ser flexível para atender aos seguintes requisitos:
• possibilidade de uso em implementação de baixo custo e de alto desempenho;
• capacidade de suportar uma ampla gama de pesquisas científicas;
• garantia de isolamento entre o tráfego experimental e o tráfego de produção;
20
• consistência com a necessidade dos fabricantes não exporem o projeto de suas
plataformas.
O OpenFlow explora a tabela de fluxo que já existe nos comutadores atuais, e
normalmente são utilizadas para implementar serviços como NAT, firewall e VLANs. O
comutador OpenFlow é constituído de uma tabela de fluxos e um evento associado a cada
entrada na tabela. Basicamente, a arquitetura do OpenFlow é composto por três partes:
Tabela de Fluxos: Cada entrada na tabela de fluxos contém uma ação associada, e consiste em Campos do cabeçalho (utilizado para definir um fluxo), ações (define como
os pacotes devem ser processados e para onde devem ser encaminhados) e contadores (utilizados para estatísticas ou remoção de fluxos inativos).
Canal Seguro: Para que a rede não sofra ataques de elementos mal intencionados, o
Secure Channel assegura confiabilidade na troca de informações entre o comutador
e o controlador. A interface utilizada para acesso ao tráfego é o protocolo Secure
Socket Layer (SSL). O NOX também suporta outras interfaces (passivas ou ativas),
TCP e PCAP. Essas são bem úteis em ambientes virtuais, pela simplicidade de
utilização, pois não necessitam de chaves criptográficas.
Protocolo OpenFlow: Disponibiliza um protocolo aberto para estabelecer a comunicação
entre o comutador e o controlador. Ao fornecer uma interface externa que atue sobre os fluxos de um comutador, o Protocolo OpenFlow (OFP - OpenFlow Protocol)
evita a necessidade de um comutador programável.
1.3.1.1. Aplicações
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
possíveis 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 é responsável por escolher a melhor rota para o pacote seguir na
rede a partir dos mecanismos do protocolo de roteamento proposto. Após isso, o
controlador adiciona entradas na Tabela de Fluxos de cada comutador pertencente
à rota escolhida. Os próximos pacotes desse fluxo que forem encaminhados na rede
não necessitarão serem enviados para o controlador;
Mobilidade: Uma rede OpenFlow pode possuir pontos de acesso sem-fio, permitindo
que clientes móveis utilizem sua infraestrutura para se conectarem a Servidores ou
à Internet. Assim, mecanismos de handoff podem ser executados no Controlador
realizando alteração dinâmica das tabelas de fluxo dos comutadores de acordo com
a movimentação do cliente, permitindo a redefinição da rota utilizada;
21
Redes Não-IP: Como visto anteriormente, um comutador OpenFlow pode ser desenvolvido para analisar campos arbitrários de um pacote, permitindo flexibilidade na
definição do fluxo. Assim, podem ser testadas, por exemplo, novas formas de endereçamento e roteamento. Nos comutadores do “tipo 0”, os pacotes Não-IP podem
ser definidos pelo endereço 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 fluxo como, por exemplo, os protocolos de
Redes Ativas. Esse tipo de proposta pode ser implementado no OpenFlow forçando
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 programável, como é o caso de um roteador programável 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 não suporta encaminhamento comum de Nível 2 e Nível 3. O
segundo tipo consiste em um comutador ou roteador comercial com OpenFlow habilitado
que, além de suportar as funcionalidades do OpenFlow, realiza as funções comuns de um
comutador ou roteador. Esses dois tipos são detalhados abaixo.
Comutador OpenFlow Dedicado
Esse tipo de comutador, exemplificado na Figura 1.7, é um elemento que apenas encaminha o tráfego entre as portas do comutador de acordo com a Tabela de Fluxos configurada
remotamente via controlador. O fluxo pode ser definido de diferentes formas, por exemplo, um fluxo pode ser definido como todos os pacotes provenientes de certa porta TCP
ou os pacotes com um determinado endereço MAC de destino. Além disso, alguns comutadores OpenFlow podem tratar pacotes que não utilizam o IPv4, verificando campos
arbitrários de seu cabeçalho. Isso mostra a flexibilidade do OpenFlow para suportar diferentes tipos de experimentos.
Para cada entrada da tabela de fluxos é definida uma ação para ser tomada com os
pacotes oriundos de um determinado fluxo. As três ações básicas que todos Comutadores
OpenFlow devem suportar são as seguintes:
• encaminhar os pacotes do fluxo para uma ou várias portas específicas. Isso permite
que os pacotes sejam roteados pela rede;
• encapsular os pacotes e encaminhá-los para o Controlador utilizando o Canal Seguro de comunicação. Essa ação pode ser executada no momento do envio do
primeiro pacote de um fluxo, que ainda não tenha sido definido nas Tabelas de
Fluxo dos comutadores, com o objetivo do Controlador configurar os comutadores
22
Figura 1.7. Comutador OpenFlow Dedicado
com esse novo fluxo. Além disso, a ação pode ser realizada em um experimento no
qual é necessário processamento adicional nos pacotes de um fluxo;
• descartar o pacote. Essa ação pode ser utilizada em aplicações de segurança para
impedir, por exemplo, ataques de negação de serviço.
Uma entrada na Tabela de Fluxos possui três campos, como apresentado na Figura
1.8a. O primeiro identifica o cabeçalho que define o fluxo. Por exemplo, no cabeçalho
dos comutadores OpenFlow (comutadores “tipo 0”), um fluxo pode ser definido por 10
parâmetros. Esses parâmetros podem ser o MAC e IP de origem ou destino, as portas
TCP usadas, entre outros como mostra a Figura 1.8b. Em outras gerações de comutadores
OpenFlow, esses parâmetros podem ser definidos arbitrariamente, permitindo o experimento de protocolos que não utilizam o IP.
(a)
(b)
Figura 1.8. Cabeçalhos que definem um fluxo em comutadores do“tipo 0”.
23
O segundo campo identifica a ação a ser tomada e o terceiro armazena as estatísticas do fluxo. Essas estatísticas podem ser o número de pacotes ou bytes referentes ao
fluxo que passaram pelo comutador e o intervalo de tempo desde a última vez em que um
pacote do fluxo foi identificado pelo comutador. Esse último é importante, por exemplo,
para remoção de um fluxo da tabela caso esteja inativo.
Comutador com OpenFlow Habilitado
Esse tipo de comutador consiste nos equipamentos que já realizam encaminhamento normal de Nível 2 e Nível 3, mas adicionaram o OpenFlow com uma funcionalidade. Assim,
o tráfego de produção pode ser encaminhado utilizando o encaminhamento normal e permanece isolado do tráfego experimental, que utiliza o mecanismo do OpenFlow. Para
isso, esses comutadores podem adicionar outra ação além das três ações básicas citadas
anteriormente:
• encaminhar os pacotes do fluxo pelo pipeline normal do comutador. Nessa ação,
um fluxo identificado como não sendo referente ao OpenFlow será processado utilizando o encaminhamento normal.
Como alternativa ao uso da ação anterior, um comutador pode isolar o tráfego de
produção do tráfego OpenFlow através 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 básicas dos sistemas operacionais de computadores são oferecer uma interface de alto nível para as aplicações utilizarem os recursos de
hardware e também controlar a interação entre essas aplicações.
A interface de alto nível tornou os programas mais fáceis de serem desenvolvidos
e de executarem em diferentes plataformas de hardware. Isso ocorre porque os programadores não precisam mais se preocupar com interações de baixo nível da aplicação com
o hardware e podem escrever seus programas utilizando primitivas genéricas que funcionam em diversas arquiteturas.
Em redes de computadores, o gerenciamento é realizado por configurações de
baixo nível que depende do conhecimento da rede, análogo às aplicações desenvolvidas
sem os sistemas operacionais. Como exemplo, o controle de acesso aos usuários de uma
rede utilizando uma ACL (Access Control List - Lista de Controle de Acesso), necessita do
conhecimento do endereço IP do usuário, que é um parâmetro de baixo nível dependente
da rede.
24
Portanto, existe a necessidade de um sistema operacional de redes que forneça
interfaces para controlar e observar uma rede, semelhantes às interfaces de leitura e escrita em diversos recursos oferecidos através de um sistema operacional de computador
[Gude et al. 2008]. Assim, o sistema operacional de redes deverá fornecer uma interface
genérica de programação que permite o desenvolvimento de aplicações de gerenciamento
da rede. Esse sistema centraliza o gerenciamento da rede, necessitando haver uma grande
preocupação 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 também no gerenciamento de redes de produção.
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 aplicações executando a partir
do NOX. Todos os controladores compartilham uma única visão da rede, que é mantida
na base de dados de um dos servidores.
Figura 1.9. Componentes de uma rede baseada no NOX
A visão da rede é montada com base em informações da rede coletadas pelo NOX
e é usada na tomada de decisões pelas aplicações de gerenciamento. As informações
coletadas podem ser a topologia dos comutadores, a localização dos elementos da rede
(ex. usuários, clientes, middleboxes) e os serviços oferecidos (ex. HTTP ou NFS).
As aplicações irão manipular o tráfego da rede a partir da configuração remota
dos comutadores OpenFlow. Esse controle é realizado no nível de fluxo, ou seja, sempre
quando um determinado controle é realizado no primeiro pacote de um fluxo todos os
outros pacotes desse fluxo sofrerão a mesma ação.
O funcionamento da rede baseada no NOX ocorre da seguinte forma: ao receber
um pacote, o comutador verifica o cabeçalho do pacote para ver se ele está definido em sua
Tabela de Fluxos. Se estiver definido, o comutador executa a ação especificada na Tabela
25
de Fluxos e atualiza os contadores referentes à estatística do fluxo. Senão, encapsula o
pacote e o envia para o NOX.
O NOX então será responsável por adicionar uma entrada na Tabela de Fluxos do
comutador, identificando o fluxo referente aquele pacote. Dependendo da aplicação, o
NOX pode não adicionar essa entrada, forçando que os comutadores enviem sempre para
o NOX os pacotes que receberem.
Como exemplo de aplicação 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 Visão da Rede do NOX, na qual
é conhecida uma visão global da rede e as rotas em uso, pode-se adquirir conhecimento
necessário para realizar tais ações. Além disso, essas ações podem ser auxiliadas por aplicações desenvolvidas para o NOX, como redução de velocidade dos enlaces ou migração
dos fluxos de um comutador que será desligado para outro comutador em uso.
Além 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 distribuído.
1.3.2. Virtualização
A virtualização é uma técnica que permite que um sistema execute processos oferecendo a
cada um deles a ilusão de executar sobre recursos dedicados. Inicialmente um mecanismo
de isolamento, ela representa um fator de uso eficiente da crescente capacidade computacional disponível [Egi et al. 2010] e a integra arquiteturas onde elementos comuns a um
conjunto de processos virtualizados possuem apenas uma cópia em execução, acessada
de forma compartilhada [Bhatia et al. 2008].
O conceito foi estendido do âmbito de nós para os demais elementos de uma rede
de computadores, dando origem à virtualização de redes [Chowdhury and Boutaba 2010].
Em um processo paralelo àquele descrito para a virtualização tradicional, a aplicação da
virtualização de redes passou a permitir que os componentes de uma rede física particionassem sua capacidade de maneira a realizar simultaneamente múltiplas funções, estabelecendo infraestruturas lógicas distintas e mutuamente isoladas.
Assim como no caso da virtualização de sistemas, a virtualização de redes também permitiu que as arquiteturas de redes se tornassem mais eficientes. Funções que
tradicionalmente eram gerenciadas de forma distribuída passaram a ser projetadas para
uma execução e administração centralizadas. É o caso do encaminhamento do tráfego IP:
podem ser encontradas arquiteturas do estado-da-arte [Nascimento et al. 2010] em que
decisões de roteamento, originalmente tomadas de forma local por nós especializados,
são encaminhados por comutadores a um sistema controlador, que executa em memória
uma versão virtualizada da rede e dos respectivos elementos roteadores. Deriva decisões
da base de informações de roteamento construída pela execução desta rede virtual e as
transmite aos comutadores, que reagem de acordo.
26
1.3.2.1. Virtualização de Sistemas
Uma solução de virtualização fornece aos sistemas, executando sob sua supervisão, a
abstração de um ambiente computacional exclusivo sobre o qual eles estão operando (nó
“convidado”), quando de fato tem-se um computador (“anfitrião”) cujos recursos foram
partilhados entre esses mesmos sistemas.
Pode-se realizar a virtualização de sistemas de duas formas: a virtualização completa, em que cada convidado executa seu sistema operacional, e a virtualização baseada
em containers, em que o sistema operacional do anfitrião distribui e isola os recursos
disponíveis entre os sistemas convidados [Bhatia et al. 2008].
Ainda segundo Bhatia [Bhatia et al. 2008], na virtualização completa, ilustrada
na Figura 1.10, o anfitrião executa um Monitor de Máquinas Virtuais - MMV, também
chamado hypervisor. É responsabilidade do MMV prover abstração de hardware (chamada
de máquina virtual) para que seja possível executar o sistema operacional convidado, bem
como mapear cada requisição dos convidados a seus respectivos dispositivos virtuais, para
o elemento físico correspondente.
Figura 1.10. Virtualização Completa
Também existe uma variação desta técnica chamada paravirtualização, que consiste em otimizar a emulação de hardware provida pelo MMV com vistas a um ganho
de desempenho. Nesta abordagem, porém, os sistemas operacionais convidados devem
ser modificados para que possam ser executados, o que não acontece na virtualização
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 eficiente em cenários em que se deseja apenas executar de forma
isolada diversas cópias do mesmo software. Ainda assim, os nós virtuais podem ser individualmente gerenciados, tal como na virtualização completa.
27
Figura 1.11. Virtualização utilizando Container
A virtualização é empregada através de ferramentas que apresentam diferenças
entre si e possuem suas vantagens e desvantagens. Atualmente, há uma gama enorme de
softwares livres e empresas que fornecem soluções com esse conceito. Neste minicurso,
são comentados apenas as ferramentas Xen e o OpenVz, por serem as mais relevantes no
contexto atual.
XEN
O Xen é um monitor de máquina virtual (VMM ou hypervisor), em software livre, para
arquiteturas x86. Originário de um projeto de pesquisa da Universidade de Cambridge,
sua primeira versão foi criada em 2003, quatro anos antes de ser comprada pela Citrix
System, em 2007. Ele apresenta uma solução para virtualização um pouco diferente das
conhecidas.
Seu conceito consiste em criar um hypervisor, responsável por controlar os recursos das máquinas virtuais, mas que não possui drivers de dispositivos. Dessa forma,
não é possível rodar um sistema operacional diretamente no hypervisor. Assim, faz-se
necessário que um sistema seja invocado para fazer a comunicação entre o hypervisor e
os sistemas hóspedes.
A Figura 1.12 apresenta uma visão geral do Xen. Esse sistema inicial chama-se
domínio 0. Ele consiste em uma máquina virtual que executa um núcleo Linux modificado e possui privilégios para acessar dispositivos de entrada e saída às outras máquinas
virtuais, onde podem rodar outros sistemas operacionais, chamados domínio U. Elas são
criadas, inicializadas e desligadas através do domínio 0. Possuem um driver virtual para
acesso aos recursos de hardware.
O domínio 0 possui os drivers dos dispositivos da máquina física, além de dois
drivers especiais que tratam as requisições de acesso à rede e ao disco enviadas pelas
28
Figura 1.12. Visão Geral do Arquitetura XEN
máquinas virtuais. Assim, toda requisição de uso da máquina real feita por uma máquina
do domínio U deve ser tratada pelo domínio 0 antes de ser enviada ao hypervisor.
Originalmente, o Xen foi desenvolvido com o objetivo de implementar a técnica
de para-virtualização, e, para isso, era necessário modificar os sistemas hóspedes para darlhes a consciência de rodarem sobre um hypervisor. Essa estratégia foi tomada visando
ganhos em desempenho, mas limitou a difusão do Xen aos sistemas Unix, de código
aberto.
OPENVZ
O OpenVZ é uma solução de virtualização em nível de sistema operacional. Cria ambientes virtuais isolados, que funcionam como servidores convencionais, porém, utilizando
um único hardware em comum. Estes ambientes virtuais seguros são conhecidos como
VE (Virtual Environment) ou como VPS (Virtual Private Server).
VPS’s podem ser reinicializados independentes uns dos outros. Todos possuem
hostname, “root access” e endereço IP próprio, ou seja, o que um servidor real normalmente possui, sendo assim uma solução extremamente confiável e funcional de virtualização.
As capacidades básicas dos VPS’s são:
Dynamic Real-time Partitioning: artição de um único servidor físico em dezenas de VPSs,
cada um com funcionalidade total;
Resource Management: atribuição e controle dos recursos dos VPSs. Realocação de
recursos em tempo real;
Mass Management: gerenciamento unificado de uma grande quantidade de servidores
físicos e virtuais (VPSs).
Como pode ser visto na Figura 4.13, um servidor físico pode conter diversos VPS’s
29
Figura 1.13. Arquitetura de virtualização utilizada pelo openVZ
(Virtual Private Servers). Cada VPS possui isolamento total uns dos outros, inclusive com
uma visão única de seus Ambientes Virtuais (VE’s).
O OpenVZ provê uma solução para Provedor de Serviços de Hospedagem possibilitando que:
• Centenas de usuários possuam seus próprios servidores privados (Virtual Private
Servers) compartilhando um único servidor físico;
• Provê para cada usuário uma garantia de qualidade de serviço;
• Transferência transparente dos ambientes virtuais dos usuários para outros servidores físicos, sem nenhum tipo de reconfiguração manual.
O Virtual Private Server se comporta como um único servidor, onde:
• Cada VPS possui seus próprios processos, usuários e provê acesso completo de root
via shell
• Cada VPS possui seu próprio endereço IP, número de portas, firewall e roteamento;
• Cada VPS possui seus próprios arquivos de configuração para o sistema e aplicações, como também suas próprias bibliotecas de sistema.
1.3.2.2. Virtualização de Redes
Assim como a virtualização provê o compartilhamento de recursos de um nó computacional por múltiplos sistemas, a virtualização de redes (VR) é um método para que múltiplas arquiteturas de rede heterogêneas compartilhem o mesmo substrato físico - neste
caso, componentes de uma rede como roteadores, comutadores, etc.
30
Segundo Chowdhury [Chowdhury and Boutaba 2010], existem quatro abordagens
para a implementação de VR: as Redes Locais Virtuais (VLANs), as Redes Privadas
Virtuais (VPNs) e as redes de sobreposição (Overlay). Em [Sherwood et al. 2010a] ,
apresenta-se uma quarta, a partir do conceito de redes programáveis.
Redes Locais Virtuais (VLANs)
Uma VLAN é um agrupamento lógico de dispositivos ou usuários que podem ser unidos
por função, departamento ou aplicativo, independentemente da localização de seus segmentos físicos. A configuração de VLANs é feita no comutador, e possivelmente no
roteador, através de software proprietário do fabricante.
Com efeito, numa rede local a comunicação entre as diferentes máquinas é governada pela arquitetura física. Graças às redes virtuais (VLANs), é possível livrar-se das
limitações da arquitetura física (constrangimentos geográficos, restrições de endereçamento, etc), definindo uma segmentação lógica (software), baseada num agrupamento de
máquinas com critérios como endereços MAC, números de porta ou protocolo.
Foram definidos vários tipos de VLAN, de acordo com o critério de comutação e
o nível em que se efetua:
• VLAN de nível 1 (Port-Based VLAN) - define uma rede virtual em função das portas
de conexão no comutador;
• VLAN de nível 2 (MAC Address-Based VLAN) - consiste em definir uma rede virtual em função dos endereços MAC das estações;
• VLAN de nível 3 - distinguem-se vários tipos de VLAN de nível 3: VLAN por
sub-rede (Network Address-Based VLAN), que associa sub-rede de acordo com
o endereço IP fonte dos datagramas e VLAN por protocolo (em inglês ProtocolBased VLAN) que permite criar uma rede virtual por tipo de protocolo, por exemplo: TCP/IP, IPX e AppleTalk, agrupando assim todas as máquinas que utilizam o
mesmo protocolo numa mesma rede.
A VLAN permite definir uma nova rede acima da rede física e a esse respeito
oferece mais flexibilidade para a administração e modificações da rede porque qualquer
arquitetura pode ser alterada por simples parametrização dos comutadores. E ainda, um
ganho em segurança, porque as informações são encapsuladas em um nível suplementar
e são eventualmente analisadas. A VLAN oferece também redução da divulgação do
tráfego sobre a rede.
Redes Privadas Virtuais (VPNs)
A ideia de utilizar uma rede pública como a Internet em vez de linhas privativas para
implementar redes corporativas é denominada de VPN (Virtual Private Network) ou Rede
Privada Virtual. As VPNs são túneis seguros entre pontos autorizados, criados através da
31
Internet ou outras redes públicas e/ou privadas para transferência de informações, com
proteção criptográfica, entre redes corporativas ou usuários remotos.
A segurança é a primeira e mais importante função da VPN. Uma vez que dados
privados serão transmitidos pela Internet, que é um meio de transmissão inseguro, eles
devem ser protegidos de forma a não permitir que sejam modificados ou interceptados.
Outro serviço oferecido pelas VPNs é a conexão entre corporações, as Extranets,
através da Internet, além de possibilitar conexões discadas e cifradas que podem ser muito
úteis para usuários móveis ou remotos, bem como filiais distantes de uma empresa.
Uma das grandes vantagens decorrentes do uso das VPNs é a redução de custos
com comunicações corporativas, pois elimina a necessidade de enlaces dedicados de longa
distância que podem ser substituídos pela Internet.
As LANs podem, através de enlaces dedicados ou discados, conectarem-se a algum provedor de acesso local e interligarem-se a outras LANs, possibilitando o fluxo de
dados através da Internet. Esta solução pode ser bastante interessante sob o ponto de vista
econômico, sobretudo nos casos em que enlaces internacionais ou nacionais de longa distância estão envolvidos. Outro fator que simplifica a operacionalização da WAN é que a
conexão LAN-Internet-LAN fica parcialmente a cargo dos provedores de acesso.
1.3.2.3. Redes de Sobreposição (Overlay)
Uma rede de sobreposição é uma rede virtual que cria uma topologia virtual no topo da
topologia física de outras redes. Os nós em uma rede de sobreposição são unidos por meio
de ligações virtuais que correspondem a caminhos na rede subjacente. Na Figura 1.14
ilustra essa afirmação, na camada “IP” os nós correspondem aos roteadores e sistemas
terminais, enquanto na camada “Overlay”, que é uma rede de sobreposição, tem-se a
topologia virtual. As redes de sobreposição são tipicamente programadas na camada de
aplicação, embora várias implementações nas camadas inferiores da pilha de redes o faça
existir.
As redes de sobreposição não são restritas geograficamente e são bastante flexíveis
e adaptáveis a mudanças, se comparadas a qualquer outra rede. Como resultado, as redes
sobrepostas têm sido usadas para implantar novos recursos e extensões na Internet.
Figura 1.14. Modelo de Rede de Sobreposição
32
Muitos modelos de sobreposição têm 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 serviço [Subramanian et al. 2004], ataque de
negação de serviços [Andersen 2003], distribuição de conteúdo, compartilhamento de arquivos [Lua et al. 2005] e até sistemas de armazenamento [Dabek et al. 2001]. Redes de
sobreposição também estão sendo usada como ambientes de teste, por exemplo PlanetLab
[Peterson et al. 2009], Federica [Campanella 2011] e o GENI [GENI 2011], para desenvolvimento e avaliação de novas arquiteturas.
1.3.2.4. Virtualização de Rede com OpenFlow
Similar à virtualização de computadores, a virtualização de redes promete melhorar a
alocação de recursos além de permitir que seus operadores possam checar suas redes antes
de eventuais mudanças, e também que clientes compartilhem o mesmo equipamento de
forma controlada e isolada.
Portanto, analogamente, a rede em si deve ter uma camada de abstração de hardware, similar ao que acontece na virtualização de computadores. Esta camada deve ser
facilmente “fatiável”, para que múltiplas 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 abstração de hardware, têm-se novos protocolos e formatos de endereçamento rodando independentemente e sua própria “fatia”, uma
mesma rede física, e na parte de baixo da camada de virtualização, novos hardwares, podendo ser desenvolvidos para diferentes ambientes e diferentes velocidade, mídia (com
fio e sem fio) e energia.
De acordo com Sherwood [Sherwood et al. 2010a], a camada de abstração de
hardware é provida pelo OpenFlow e como camada de virtualização se tem FlowVisor.
Similar à virtualização de computadores, o FlowVisor é uma camada de abstração que
reside entre o hardware e o software dos componentes da arquitetura, conforme ilustrado
na Figura 1.15. Portanto, a integração FlowVisor e OpenFlow permite que em uma rede
OpenFlow possam ser criados várias 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 múltiplos controladores.
Todas as mensagens do protocolo OpenFlow tanto aquelas originárias dos comutadores
para os controladores quanto as dos controladores para os comutadores, são interceptadas através do FlowVisor. Desse modo, os controladores não necessitam de modificações e, devido à interceptação 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 à existência da interface entre os planos de dados e o de controle, a técnica
empregada permite a partição do plano de dados em fatias que estão sob a gerência do
FlowVisor [Sherwood et al. 2009].
33
Figura 1.15. Comparação entre o FlowVisor como camada de virtualização com
a virtualização computacional [Sherwood et al. 2009]
Cada fatia está vinculado a um controlador. O FlowVisor define uma fatia como
um conjunto de fluxos também chamado de “espaço de fluxo” (ou flowspace). Devido à versão atual do protocolo OpenFlow permitir a definição de um fluxo como uma
combinação de dez campos do cabeçalho de pacote incluindo informações das camadas
física, de enlace, de rede e de transporte, o FlowVisor possibilita que se implemente fatias
com um elevado nível de granularidade, no que diz respeito à caracterização do flowspace [Sherwood et al. 2010a] . Além disso, as fatias podem ser definidas por ações de
negação, união e intersecção.
A Figura 1.16 ilustra o particionamento da rede em fatias. Nesta figura, além
da fatia da rede de produção, têm-se mais duas fatias identificadas por “Alice” e “Bob”.
Os círculos enumerados em ordem crescente indicam a dinâmica de execução 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 política do espaço de fluxos definida para aquela
fatia (2), o FlowVisor reescreve a mensagem do controlador transparentemente para a fatia
da rede que compõe o plano de dados (3). As mensagens originárias dos comutadores
para o plano de controle (4), por sua vez, são novamente interceptadas pelo FlowVisor e
reescritas para o respectivo controlador de acordo com a política que define o espaço de
fluxos.
O particionamento da rede possibilita que as ações desenvolvidas em uma de suas
fatias não interfiram negativamente nos demais, mesmo que estes estejam compartilhando
a mesma infraestrutura física. Em arquiteturas mais tradicionais, a rede é fatiada através
da técnica de VLAN (Virtual Local Area Network), porém, com a diversidade dos modelos de redes, a estrutura de VLANs torna os experimentos, como IP Mobility ou Wireless
Handover, por exemplo, bastante difíceis de gerenciar.
34
Figura 1.16. Gerenciamento de slices por meio do FlowVisor [Sherwood et al. 2009]
As características inerentes ao FlowVisor, como a virtualização transparente, o
forte isolamento entre as fatias e a sua rica política de definição de flowspaces tornam
o mesmo uma ferramenta extremamente eficiente no que diz respeito à virtualização e
implementação de redes programáveis orientadas a software.
1.4. Requisitos para Construção de um Ambiente para Experimento e Virtualização de Redes
Iniciativas [FIRE 2011] [GENI 2011] [AKARI 2009] vêm construindo infraestruturas para
testar novos protocolos, serviços e aplicações em ambientes de larga escala, visando solucionar esses desafios da Internet atual e compor a arquitetura da chamada Internet do
Futuro.
Por essas razões, definir estratégias corretas para construção e operação destes
ambientes de teste para Internet do Futuro é considerado uma etapa vital. Além disso,
o ambiente deve combinar flexibilidade a um conjunto mínimo de restrições e um completo controle do ambiente para seus pesquisadores [Kim et al. 2009]. Deste modo, o
OpenFlow vem se destacando como arcabouço capaz de habilitar experimentos de novas
tecnologias utilizando redes reais de produção. Nesta mesma linha, a virtualização vem
como uma ferramenta essencial, para permitir o acesso compartilhado de recursos, seja
de rede ou computacional.
Portanto nesta seção, observam-se as informações importantes para construção
de uma rede para experimentação, levando em consideração a utilização de OpenFlow
e virtualização. Verificam-se o modo que se descrevem, os hardwares utilizados dentro
desta infraestrutura, tipos de enlaces, software de virtualização e ferramentas para análise
de tráfegos e geração de tráfego
35
1.4.1. Tipos de Hardwares
Para construção do ambiente de teste, é necessário principalmente hardware que suporte
virtualização e OpenFlow. Para isso, são necessários dispositivos especiais para que o
desempenho da rede virtual não tenha uma influência nos experimentos realizados, e que
seja possível sua otimização de forma programável. Entre esses dispositivos estão interfaces de redes programáveis e comutadores programáveis com OpenFlow habilitado.
Interface de Rede Programável
O NetFPGA [Lockwood et al. 2007] é uma plataforma aberta que permite estudantes
e pesquisadores desenvolverem protótipos de sistemas de redes em alta velocidade e
sistemas de aceleração de redes via hardware, além de protótipos de comutadores ou
roteadores IP para Internet do Futuro.
O NetFPGA consiste em um placa de desenvolvimento reconfigurável, interface
de ligação ao PC, utilizando PCI e PCI-e, dois processadores PowerPC, e software que
possibilita o desenvolvimento de novas funcionalidades. Há duas versões da placa: a
mais antiga possui quatro interfaces de 1 Gbps Ethernet RJ-45 e um vazão que de 8Gbps;
a mais nova tem quatro interfaces 10 Gbps Ethernet SFP+, e vazão até 80 Gbps. Além
disso, é totalmente compatível com Linux e OpenFlow.
Switches Programáveis
O OpenFlow é um arcabouço que permite o gerenciamento da tabela de encaminhamento
de comutadores Ethernet, desacoplando a lógica de controle do equipamento do hardware de encaminhamento de pacotes, permitindo assim o conceito chamado de SoftwareDefined Networking (SDN) [Greene 2009]. Esta separação não só permite um modelo
de inovação aberta tanto no plano de controle quanto no plano de encaminhamento, mas
também permite a virtualização do plano de encaminhamento em fatias ou redes lógicas.
Deste modo, são necessários equipamentos que possuam o OpenFlow habilitado.
No entanto, o protocolo Openflow ainda está em fase de padronização nos comutadores e algum fabricantes já disponibilizam versões de comutadores com OpenFlow
habilitado, como é o caso dos modelos Pronto 3290 para soluções até 1 Gbps Ethernet e o
Pronto 3790 para 10 Gbps Ethernet e SFP+. Também há o projeto Indigo [INDIGO 2011]
que é uma implementação aberta do OpenFlow que permite rodar sobre comutadores físicos baseados em chipsets da Broadcom. A cada comutador suportado é desenvolvido
um firmware para essa linha de produto. Este firmware sobrescreve o original do comutador, instalando a nova imagem com OpenFlow habilitado. Dentre os comutadores
compatíveis, temos, além 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 também são uma parte importante dentro do substrato, pois deles são virtualizados recursos como: processador, armazenamento e E/S. Para isso, são necessários
servidores de alto capacidade computacional para que não haja perda de desempenho no
nível virtualizado e suporte à quantidade de usuários locais e também os federados. Observando esses requisitos, as linhas de servidores do tipo blade surgem como uma excelente
36
solução 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
comunicação integradas em um mesmo chassis.
A vantagem do uso de servidores blade é a possibilidade do crescimento incremental mediante a demanda de usuários, devido a sua característica modular, baseada
em containers de servidores, comutadores e armazenamento. O seu capacidade computacional pode ser incrementado com introdução de novas lâminas blade, que são servidores
que são inseridos no chassis e incluem recursos de processamento e memória. Além disso,
outra vantagem é a sua otimização para uso de virtualização com barramento em altíssimas taxas de transferência, e implementação de grupos de recursos dentro de conjunto
virtualizado. O uso de blades está ligado principalmente à virtualização de servidores e à
computação em nuvem.
1.4.2. Arcabouços de Controle
O arcabouço de controle é o coração de qualquer infraestrutura de experimentação baseada
em virtualização. Porém, muitos arcabouços são limitados a certos tipos de recurso e a
um tipo de comunidade de pesquisa. Com base nisso, são apresentados alguns arcabouços
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
arcabouço que pretende controlar a integração em larga escala de infraestruturas existentes e em construção no GENI. Esses ambientes de teste são compostos principalmente
por elementos embarcados e programáveis nas redes backbone, PCs com hardwares programáveis e uma variedade de redes sem fio, redes de acesso e clusters programáveis. Atualmente, o ProtoGENI está usando RSpec para descrever seus nós, enlaces e interfaces.
Esses recursos são mapeados para o Emulab que aplica os mapas virtuais de recursos em
nós locais e vlans.
ORCA(GENI)
O ORCA [ORCA 2011] [BEN 2011] é framework de código 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 protótipo arcabouço GENI.
No ORCA, há uma coleção dinâmica de controladores de interação que trabalham
juntas para o aprovisionamento e configuração de recursos para as fatias requisitadas pelos
seus usuários, de acordo com as políticas dos participantes.
Atualmente, o ORCA foi estendido para gerenciar um ambiente de teste em uma
rede óptica metropolitana. Também está em processo de integração a seleção para utilização de protótipos para redes de sensores e sem fio, de modo que o ORCA ofereça a maior
variedade possível de ambientes de teste.
37
FEDERICA (FIRE)
O FEDERICA [Szegedi et al. 2009] é uma iniciativa composta de roteadores, comutadores e computadores para experimentações em Internet do Futuro. Ele é baseado nas
redes acadêmicas de alguns países europeus e na rede pan-europeia GEANT.
O arcabouço FEDERICA é capaz de alocar recursos para múltiplas 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 instrumentação que vão desde a gerência e controle de máquinas virtuais à alocação de circuitos
fim-a-fim camada 2, camada 1 ou MPLS.
PII (FIRE)
O objetivo do projeto PII [Paul et al. 2011] é criar uma federação de instalações experimentais entre diferentes pólos de inovação regional na Europa. Isso permite que as empresas participantes possam testar novos serviços de comunicação e aplicações na Europa
como um todo.
O arcabouço também terá como objetivo federar redes para experimentação distribuídas por laboratórios espalhados pela Europa, assim provendo um ambiente de teste
realístico para novos conceitos de serviços, tecnologias de rede e modelos de negócios.
Os mecanismos de seu arcabouço incluem regras e procedimentos para alcançar níveis de
teste e colaboração dentro dessas federações de infraestruturas dentro da Europa.
1.4.3. Monitoração e Medição
Medição e monitoramento são atividades que observam o estado operacional do ambiente
de teste que está sendo usado, de modo que se possa obter informações sobre o desempenho dos recursos disponíveis no ambiente, e verificar a disponibilidade do recurso ou
componente. O objetivo disso é oferecer a outros sistemas uma visão dos recursos da
infraestrutura, para auxiliar decisões como a possibilidade de alocação de recurso, bem
como sua escolha e disponibilização.
Portando, dentro dos requisitos para construção dessas ambientes de teste, esses
elementos são essenciais. A seguir, são apresentados alguns softwares relacionados a
características de medição e monitoramento.
PerfSONAR
O perfSONAR (PERFormance Service-Oriented Network monitoring ARchitecture) é uma
arquitetura orientada a serviços (SOA) que foi projetada para o monitoramento de redes em ambientes interdomínios. No perfSONAR, existe um conjunto de serviços bem
definidos que realizam ou disponibilizam resultados de medições de desempenho em um
ambiente federado. Esses serviços atuam como uma camada intermediária entre as ferramentas de medições e as ferramentas de visualização [Tierney et al. 2009].
Além disso, o perfSONAR também definiu um protocolo comum entre os serviços
para permitir que sejam criados novos serviços seguindo a padronização deste protocolo,
dando flexibilidade à arquitetura. Também, criou-se uma representação unificada para
definir, armazenar e arquivar os dados relativos às medidas do experimento que é mais
38
um componente chave, de modo que certo nível de concordância é necessário para fazer
convergir esforços e melhorar a experiência, fidelidade e usabilidade das infraestruturas
de experimentação em escala global.
O pS-Performance Toolkit [Ps-Performace 2011] é uma coleção de ferramentas de
medida de desempenho de redes desenvolvida dentro do projeto perfSONAR.
BWCTL
O BWCTL [Hu et al. 2010] é uma aplicação cliente/servidor que permite o agendamento
de testes com políticas de medidas utilizando IPERF, THRULAY [Shalunov 2011] e
NUTTCP [Fink and R. 2011]. Estes testes podem medir, por exemplo, a máxima largura
de banda para TCP ou testes UDP para medir o atraso, a variação do atraso ou nível 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, verifica se
foi criado ou não, e caso seja criado, ele verifica se os desempenhos solicitados estão
realmente disponíveis.
Real-Time Unified Measurement Framework
O UMF (Unifed Measurament Framework) é um arcabouço desenvolvido para oferecer
capacidade de medições em tempo real a avaliações de desempenho sobre vários cenários
de infraestrutura, interfaces de integração dos recursos de medição com os substratos
e os framewoks de controle dos protótipos de GENI e outros sistemas que necessitem
de suas medidas e a monitoração das condições dos recursos de um slice durante um
experimento [UMF 2011].
Inicialmente, o UMF está sendo desenvolvido para alimentar informações dos demais arcabouços de controle do GENI e de visualização dos usuários pesquisadores. Na
Figura 1.17, mostra o esquema de interação dos arcabouços com o UMF.
Figura 1.17. Esquema de interação do UMF com outros frameworks do GENI
UMF é um arcabouço genérico para gerenciamento de ambiente de teste e coleta
de métricas de experimentos. Quando o experimento está sendo executado, os dados
são medidos e coletados de acordo com a descrição do usuário. Pontos de medição são
39
definidos dentro de uma aplicação C/C++ ou automaticamente, baseados em arquivos de
configuração XML.
Os dados medidos são transmitidos usando codificação XDR e salvos em um
banco de dados para análise posterior. Um novo banco de dados de medição é criado
para cada experimento. O SQLite pode ser usado para manipular os dados ou estes podem ser exportados para geração de gráficos ou tabelas.
No UMF, há medidores de desempenho (Performance Monitors) para os mais
variados tipos de substratos físicos, 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 fio, e protocolos padrões
para medição como TL1, SNMP e NetConf.
1.4.4. Ferramentas para Gerência de Virtualização
As ferramentas de gerência são essenciais no desenvolvimento dos ambientes de experimentação, pois elas têm o papel de manipular, criar, configurar e remover recursos nestes
ambientes. Portanto, abaixo, são apresentadas as principais ferramentas para gerenciamento de virtualização, computação em nuvem e manipulação 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 específico de
hypervisors, a LIBVIRT comunica-se com um hypervisor disponível para executar as solicitações da API. Deste modo, a LIBVIRT provê uma comum genérica e estável camada
para gerenciamento. A API pode acessar esse hypervisor permitindo o aprovisionamento,
criação, modificação, controle, monitoramento, migração, inicialização e finalização da
VM (virtual machine). No entanto, o suporte a todas essas operações irá depender da
tecnologia de virtualização utilizada.
Com a LIBVIRT, têm-se dois meios de controle distintos. O primeiro é demonstrado na Figura 1.18, no lado esquerdo, em que o aplicativo de gerenciamento e os
domínios existem no mesmo nó. Nesse caso, o aplicativo de gerenciamento trabalha
por meio da biblioteca libvirt para controlar os domínios locais. Outros meios de controle existentes são quando o aplicativo de gerenciamento e os domínios estão em nós
separados, o que é ilustrado na Figura 4.19, lado direito. Este modo usa um daemon
especial chamado libvirtd que é executado em nós remotos. Tal daemon é iniciado automaticamente quando a libvirt é instalada em um novo nó e pode determinar, de forma
automática, os hypervisors locais e configurar drivers para eles. O aplicativo de gerenciamento se comunica por meio da libvirt local com o libvirt remoto através de um protocolo
customizado [Bolte et al. 2010].
A API LIBVIRT foi construída para trabalhar através de múltiplos ambientes de
virtualização. Dentre as tecnologias de virtualização temos: QEMU, LXC, OpenVZ, User
Mode Linux, KVM, VirtualBox e VMWare. Além disso, também 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 arcabouço aberto para montagem e gerência de ambientes de computação em nuvem utilizando virtualização, sendo o seu foco a pesquisa
acadêmica. Ele provê uma implementação baseada em IaaS (Infraestructure as a Service),
ou seja, infraestrutura como recurso nuvem. Os usuários do Eucalyptus são capazes de
iniciar, controlar, acessar e finalizar máquinas virtuais (VMs). A atual versão do Eucalyptus suporta VMs, rodando sobre uma hypervisor XEN, mas há planos de utilizar
KVM/QEMU e VMWare.
O projeto Eucalyptus apresenta quatro características que o diferenciam de outras
soluções de computação em nuvem e virtualização: o Eucalyptus foi projetada para ser
simples, de modo que não há a obrigatoriedade da dedicação de recursos; o arcabouço
foi projetado para encorajar extensões 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 tráfego de rede de diferentes usuários, permitindo que clusters remotos
pareçam partes da mesma rede local.
A gerência do Eucalyptus é baseada em serviços Web, o que oferece alguns benefícios à arquitetura, como a exposição da API em forma bem conhecida e funcional como
o WSDL (Web Service Description Language), definindo tanto as operações que seus
serviços podem desempenhar, quanto as estruturas de dados de entrada e saída utilizadas.
A arquitetura define três níveis de gerenciamento da infraestrutura de nuvem:
Instace Manager (IM): Controla a execução, inspecção e finalização das instâncias de
VMs nos hospedeiros nos quais estão rodando;
Group Manager (GM): Suas funcionalidades são as seguintes: escalonamento e gerenciamento de execução de operações sobre os IM, controle de operações sobre a rede
virtual sobreposta e reportagem de informações sobre um conjunto de IMs;
Cloud Manager (CM): Interage com os usuários e gerenciadores reportando informações
a respeito dos estados dos recursos da nuvem.
41
O Eucalyptus é flexível e pode ser instalado em uma infraestrutura mínima (no
mínimo duas máquinas), como também em milhares de núcleos e terabytes de armazenamento, Com total integração sobre uma rede sobreposta de interligação das infraestruturas
de nuvem.
E-GENI
O Enterprise-GENI [E-GENI 2011] é uma arquitetura/arcabouço utilizada para gerenciar
o uso de fatia em uma infraestrutura baseada em OpenFlow e FlowVisor. O objetivo do
arcabouço é criar uma interface para visualização e gerências de múltiplos experimentos
em rede OpenFlow. A Figura 1.19 mostra como está definida a arquitetura do E-GENI.
Figura 1.19. Arquitetura do E-GENI [E-GENI 2011]
A arquitetura do E-GENI é dividida em três partes:
OpenFlow-Based Substrate: Composto de switches que se comunicam utilizando o protocolo OpenFlow para uma aplicação do controlador;
FlowVisor: Customizado para controlar slice de rede pelo isolamento e controle de tráfego
de experimentos individuais;
Aggregate Manager: Uma aplicação integra o Clearinghouse, responsável pela manipulação 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 arcabouço GENI como mais uma alternativa dentro da infraestrutura de experimentação
para Internet do Futuro do GENI.
42
1.5. Estudo de Caso
Com o propósito de criação de ambientes experimentais em Internet do Futuro, a comunidade acadêmica vem orientando esforços consideráveis na criação de ambientes de
teste baseados em redes programáveis. Baseada em tráfegos reais de usuários, a criação
de ambientes programáveis permite uma abordagem mais realística com relação à 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 é possível implementar uma rápida prototipagem de protocolos de rede que seja facilmente aplicável a redes reais. Ou seja, por
meio de um ambiente local, é possível implementar uma funcionalidade que possa ser
imediatamente aplicada para testes num ambiente global possibilitando uma maior inovação em redes programáveis.
Como importante proposta no contexto de redes programáveis, neste estudo de
caso utiliza-se do arcabouço OpenFlow devido à possibilidade de criação de uma infraestrutura de experimentação sobre uma rede de produção. Além disso, por meio da
utilização do OpenFlow associado à virtualização, demonstra-se como é possível criar,
utilizar e gerenciar várias fatias sobre uma infraestrutura de rede compartilhada, possibilitando que vários experimentos de protocolos possam ser executados de maneira simultânea.
Por meio deste estudo de caso demonstra-se que é possível implementar uma nova
funcionalidade, ou mesmo uma nova arquitetura de rede em ambientes locais baseados em
software. Estas funcionalidades podem então ser testadas por seus usuários por meio de
largas topologias e com tráfegos específicos. Posteriormente, os mesmos códigos que
implementam estas funcionalidades podem ser empregados em ambientes de teste reais.
1.5.1. Definição do Ambiente
Para exemplificar a utilização do OpenFlow associado à virtualização, esse estudo de caso
tem como principal objetivo apresentar como se pode desenvolver um ambiente capaz de
suportar simultaneamente vários experimentos de protocolos compartilhando a mesma
infraestrutura física.
1.5.1.1. Dados de Implementação do Ambiente
O estudo de caso é formado por um ambiente virtualizado, ou seja, os nós de equipamentos OpenFlow e hosts clientes da redes são elementos de virtualização. Para implementar
esse ambiente com suporte ao arcabouço OpenFlow, utiliza-se dois servidores: um com
Xen Server para armazenar os servidores que contêm os controladores que são utilizados
em cada fatia do experimento e outro servidor utilizando apenas o sistema operacional
Linux e o software Mininet [MiniNet 2011].
O Mininet utiliza virtualização baseada em contêineres para criar instâncias virtuais de cada comutador (ou host cliente) que seja utilizado no experimento. Além 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 realização do
43
estudo de caso.
Figura 1.20. Ambiente de teste do estudo de caso
A Tabela 1.1 apresenta, de forma resumida, as informações e configurações dos
servidores utilizados no estudo de caso.
Tabela 1.1. Dados dos Servidores
Dados
Sistema Operacional
Memória
Interface de Rede 1GbE
Armazenamento
Virtualização
Servidor MiniNet
Debian Lenny 5.0
4096 MB
2
320 GB SAS
Contêiner
Servidor de Controladores NOX
Citrix XenServer 5.6
2048 MB
2
500 GB SATA
XEN
No servidor de controladores têm-se três maquinas virtuais (VM) rodando três
aplicações diferentes no controlador. Cada controlador se comunica com o FlowVisor usando 3-tuplas de informações: VLAN, IP e porta TCP do processo servidor do FlowVisor.
Com o objetivo de isolar o tráfego de cada controlador para eventuais análises do
comportamento das informações de controle entre o controlador e o FlowVisor são divididas por VLANs, VM1 VLAN 100, VM2 VLAN 200 e VM3 VLAN 300. A Tabela 1.2
contém um resumo dos dados de configuração de cada VM de controlador.
44
Tabela 1.2. Configurações das VMs com os Controladores NOX
Dados
Sistema Operacional
Memória
Endereçamento IP
VLAN
Software Controlador
Porta de Conexão com FlowvVisor
Armazenamento
Aplicação
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
contém o aplicativo Mininet virtualizando a infraestrutura física de comutadores e clientes.
E um segundo com o FlowVisor que realiza a criação, remoção e gerência das fatias no
plano de dados do Mininet. A Tabela 1.3 resume as configurações do servidor Mininet.
Tabela 1.3. Dados do Servidor MiniNet
Dados
Sistema Operacional
Memória
Armazenamento
Virtualização de Rede
Virtualização
Porta FlowVisor
Servidor MiniNet
Debian Lenny 5.0
4096 MB
2
320 GB SAS
FlowVisor 0.6
Contêiner Virtuais LXC
6633
Mesmo utilizando a infraestrutura virtualizada de comutadores Openflow, os testes
aqui executados são totalmente compatíveis 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 solução 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 contém a descrição 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 configurado no ambiente Mininet.
Para este trabalho optou-se pelo emprego de uma topologia em malha 3x3. O
objetivo é ter um cenário com uma quantidade de nós consideráveis e que também pos1O
scripts para o Mininet, assim como as aplicações NOX podem ser encontrados em
http://www.gercom.ufpa.br/minicurso_sbrc
45
Figura 1.21. Topologia e do plano de dados
sibilite nós 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 três 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 três aplicações NOX, tais como,
Switch, Spanning_Tree e Routing. Nas extremidades têm-se os hosts utilizados para geração de tráfego no plano de dados, seja por meio de requisições ICMP ou utilizando fluxos
TCP ou UDP com uso da aplicação Iperf.
Figura 1.22. Slice dos Experimentos
46
Representando o controle lógico dos pesquisadores, tem-se três 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 aplicação 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: iniciação do processo núcleo do NOX (nox_core),
onde a opção -v indica o modo de depuração, a opção -i informa o protocolo de transporte
e a porta ao qual o NOX estará escutando conexões dos comutadores do plano de dados,
e, por fim, a aplicação NOX utilizada.
Cada um destas fatias deve conectar-se ao seu respectivo controlador NOX inicializado pelos comandos anteriores. As instruções a seguir, utilizando o comando fvctl,
efetivam a criação das fatias:
# fvctl createSlice switch tcp:192.168.100.1:1515 [email protected]
# fvctl createSlice switch_stp tcp:192.168.200.1:1516 [email protected]
# fvctl createSlice switch_router tcp:192.168.300.1:1517 [email protected]
O comando fvctl permite a gerência das fatias, portanto os parâmetros dos comandos acima indicam: createSlice o tipo de ação que é aplicado à fatia; switch descreve o
nome da fatia a ser criado; tcp:192.168.100.1:1515 apresenta o endereço do controlador
vinculado à fatia; e no final define-se o correio eletrônico do responsável.
Ao final de cada entrada é solicitada a criação de uma senha para fatia específica,
provendo um controle de acesso a cada operação na fatia. O comando a seguir lista as
fatias criadas atualmente:
# fvctl listSlices
Enter root’s password:
Slice 0: root
Slice 1: switch
Slice 2: switch_stp
Slice 3: switch_router
1.5.2. Aplicação Prática
A primeira aplicação apenas efetua o encaminhamento de pacote na camada 2, com um
comportamento de comutador; a segunda, além de efetuar o encaminhamento na camada
2 via comutador, também trata o aparecimento de ciclos na rede através 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, têm-se dois hosts clientes, um em cada extremidade da topologia da fatia, gerando
fluxo de pacotes entre eles.
47
Figura 1.23. Slice Switch
Os comandos abaixo alocam os recursos para o slice Switch. A definição inclui
a especificação dos nós que compõem o plano de dados e a característica do fluxo que
percorre o plano de dados.
# fvctl addFlowSpace 00:00:00:00:00:01 10 dl_vlan=100 “Slice:switch=4”
Neste comando os parâmetros são as flags, addFlowSpace, que adiciona o recurso
identificado pelo Datapath, a prioridade de execução (10) , onde quanto maior o valor da
prioridade mais rápido a informação da fatia é processada, e, por fim, “Slice:switch=4”
que indica a qual fatia o recurso é alocado.
Nos comandos acima se tem a adição dos nós SW01, SW02 e SW03 formando a
topologia da fatia Switch, neste caso os nós são identificados pelos endereços Datapath
00:00:00:00:00:01, 00:00:00:00:00:02 e 00:00:00:00:00:03, respectivamente. Para identificar os fluxos 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 identificar o fluxo que faz parte
daquela fatia.
Nesta aplicação o comportamento do comutador consiste em analisar cada pacote
e “aprender” sobre sua porta de origem, associando o endereço 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 contrário, o comutador realizará a ação de
“flood”, ou seja, encaminha para todas as portas.
Após a inclusão dos nós na fatia Switch, os nós OpenFlow passam a ser reconhecidos pelo NOX correspondente à fatia, e a executar as ações da aplicação instanciada
na mesma. Para ilustrar o funcionamento da aplicação Switch, aplica-se um fluxo ICMP
do tipo ECHO_REQUEST e ECHO_REPLY entre os hosts da fatia. Na primeira tentativa
de comunicação são trocadas informações de controle entre os comutadores da fatia e o
controlador. Como o pacote é desconhecido é aplicada a todos os nós a ação 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 ação de FLOOD para a porta correspondente, de modo a alcançar o nó de
destino. Como mostrado na Figura 1.25.
Figura 1.25. Tabela de fluxo após o conhecimento do nó de destino
Fatia STP
O protocolo STP possibilita a inclusão de ligações redundantes entre os comutadores,
provendo caminhos alternativos no caso de falha de uma dessas ligações. Nesse contexto,
seu objetivo é evitar a formação de ciclos entre os comutadores e permitir a ativação e
desativação automática 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 cenário no qual há presença de
ciclos no caminho entre os hosts finais. O objetivo, neste caso, é tratar este problema por
meio da implementação do algoritmo SpanningTree no ambiente do controlador.
Figura 1.26. Slice STP
A alocação de recursos à fatia switch_stp é feita de maneira similar ao que foi
implementado para a fatia switch. Para este fim, deve-se executar a seguinte sequência de
comandos:
# fvctl addFlowSpace 00:00:00:00:00:04 10 dl_vlan=200 “Slice:switch_stp=4”
Os comandos definem os recursos da fatia switch_stp, que neste caso são os
fluxos de pacotes com vlan_id igual a 200. E também os nós 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 módulo STP, quando um novo comutador conecta-se ao controlador NOX, o
módulo registra o nó e neste momento desabilita a operação de FLOOD em todas as suas
portas. Periodicamente o módulo realiza consultas com todos os enlaces para montar a
lista de elementos da topologia. Esta lista é utilizada para a construção da árvore geradora
(Spanning Tree). De modo que, todos os comutadores candidatos são alocados em uma
lista e ordenados (de maneira crescentemente) por meio de seu Datapath; O primeiro
elemento é removido da lista e definido como "comutador raiz"da árvore geradora.
Este procedimento é então executado para todos os comutadores candidatos que
compõem a lista. O módulo Spanning Tree, também utiliza o módulo de descoberta do
NOX, chamado Discovery, para localizar as ligações dos comutadores com os seus nós
50
vizinhos.
Como realizado no experimento anterior, foi gerado um fluxo ICMP entre os hosts
clientes que utilizam a fatia switch_stp. Uma vez encontrada a topologia, através do
módulo Discovery, o algoritmo calcula a melhor forma de desfazer o ciclo, desabilitando
umas das portas do comutador que foi escolhida no cálculo.
Na Figura 1.27, os itens numerados de 1 a 5 mostram o processo de reconhecimento de características dos comutadores que compõem a fatia, além da convergência da
aplicação na habilitação (e não-habilitação) de portas.
Figura 1.27. Log do controlador sobre as decisões do STP
O item “1” corresponde à descoberta dos comutadores, neste momento o comando
de non-flood é enviado em todas as portas dos comutadores OpenFlow descobertos, representados por valores numéricos. No item “2”, o primeiro comutador é selecionado, tem
suas portas 1, 3 e 4 habilitadas para flood e a porta 2 desabilitada. Deste modo o algoritmo
segue para os próximos comutadores candidatos conforme itens “3”, “4” e “5” até que a
árvore esteja formada e o protocolo convirja completamente, habilitando assim o tráfego
entre os dois hosts. A partir desse momento o encaminhamento dos dados é igual ao do
módulo comutador.
Fatia Roteamento
Na fatia switch_router utiliza-se a aplicação de routing. Esta aplicação possui a capacidade de aplicar aos nós o comportamento de roteadores, efetuando encaminhamento na
camada 3. A Figura 1.28 exibe como os recursos de rede que são visualizados pelo controlador NOX que está habilitado com a aplicação routing.
Para aplicar os nós que fazem parte da fatia neste experimento, a seguinte configuração foi realizada:
51
Figura 1.28. Visão do controlador do fatia Roteamento
# fvctl addFlowSpace 00:00:00:00:00:01 10 dl_vlan=300 “Slice:switch_router=4”
Para esta fatia utilizou-se os comutadores SW01, SW02, SW03, SW06 e SW09.
Cada host está endereçado com sub-redes diferentes por meio das seguintes configurações
de endereçamento IP listados pela Tabela 5.
Tabela 1.4. Endereçamento IP dos hosts ligados ao slice
Host
Host02
Host04
Host05
Endereço 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 fluxos de
pacotes, sendo o primeiro UDP e o segundo TCP. Desta forma, entre os hosts 02 e 04
têm-se um fluxo TCP na porta 200 e entre os hosts 02 e 05 têm-se um fluxo UDP na porta
100.
O que se percebeu nesse experimento é que na primeira tentativa de estabelecimento de comunicação entre os hosts, tanto para fluxo TCP quanto UDP, são trocadas
informações de controle (comutador e controlador), para determinar o que fazer com
esse fluxo. Os primeiros pacotes são enviados para a fila, através da ação IN_QUEUE,
ilustrado na Figura 1.29, para evitar a perda de pacote, enquanto se determina a sua rota.
Quando a rota é determinada, são aplicadas as ações 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 ações 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 alterações
para uma porta conhecida. Caso um pacote seja destinado para um endereço IP no qual o
roteador conhece o próximo salto, o mesmo utiliza a rota previamente definida e aplica as
ações de encaminhamento para cada comutador na rota determinada.
Figura 1.29. Ações aplicadas a tabela de fluxo dos nós openflow durante o
primeiro pacote
Figura 1.30. Após a passagem dos primeiro pacote
Também se observou que esta aplicação de roteamento não é baseada em algoritmos específicos tais como de vetor de distâncias ou estado de enlaces. O que se percebe é
a necessidade de melhorias e novas idéias para a aplicação de roteamento. Nesse sentido,
53
existem exemplos de esforços vem sendo desenvolvido para aplicar essas características,
como é o caso da aplicação QuagFlow [Nascimento et al. 2010].
Por meio do QuagFlow é possível aplicar algoritmos de roteamento baseado no
conjunto de aplicações disponíveis 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. Conclusão
O estudo de caso mostrou que de uma maneira rápida e simplificada é possível construir infraestruturas prontas para experimento de protocolos baseadas em redes OpenFlow. Além disso, é uma excelente ferramenta para experimentação em Internet do Futuro (IF). Observou-se que com pequenos recursos é possível iniciar estes estudos para IF
virtualizando todo plano de dados alinhado às necessidades de um ambiente real.
Um ponto fraco da solução seria a não disponibilidade de interfaces de mais alto
nível, como por exemplo interfaces web que facilitem a interação com FlowVisor. O que
deixa a sua manipulação fortemente dependente do administrador da rede para criação da
fatia do experimento com alta probabilidade de falha durante a inserção de comandos.
1.6. Considerações finais e o futuro em Pesquisa Experimental em Internet do
Futuro
1.6.1. Considerações Finais
A virtualização tornou-se a principal ferramenta para pesquisa de desenvolvimento e habilitação da Internet do Futuro em todas as comunicações ou camadas computacionais
dessas grandes infraestruturas. Com o uso da virtualização na construção desses ambientes de teste foi possível desacoplar a complexidade dos recursos físicos dos serviços
oferecidos e apresentar simples interfaces com usuário, em localizações geográficas distintas e independentes de dispositivo de acesso.
Além disso, a virtualização terá um papel importante, pois ela permitirá a comparação das novas tecnologias que estão sendo desenvolvidas para Internet do Futuro,
com as tecnologias atuais. Também garantirá que tecnologias desenvolvidas no passado
possam ser disponíveis nessa moderna infraestrutura.
Com isso, a construção dos arcabouços para esses ambientes de teste está sendo
desenvolvida com base na virtualização, seja ela baseada na virtualização do substrato,
seja na infraestrutura física que contém todos os hardware e software para inicializar os
recursos virtuais, bem como para a criação da infraestrutura virtual contendo os recursos
virtuais e a topologia lógica, interligando-as.
O arcabouço OpenFlow é uma dessas soluções, pois provê um protocolo aberto
para programação do comportamento de fluxos de pacote em diferentes comutadores e
roteadores. A rede contendo OpenFlow pode ter o tráfego particionado entre tráfego de
produção e tráfego de experimentação, de maneira que pesquisadores possam controlar
seus próprios fluxos. A rede de produção 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 física possa ser
compartilhada entre várias topologias lógicas, onde cada uma possui sua própria lógica
de encaminhamento e tratamento de fluxos de pacotes distintos.
Por fim, o OpenFlow possibilita de maneira rápida e simples a criação de uma infraestrutura para concepção de novos protocolos, como apresentada na seção de estudos
de casos onde em um único servidor, conseguimos simular uma infraestrutura de comutadores e roteadores OpenFlow. Também conseguimos aplicar os conceitos de virtualização
baseada em fatias de recursos e redes programáveis.
Este capítulo apresentou o andamento da pesquisa experimental em Internet do
Futuro no mundo e observou duas grandes tecnologias que estarão presentes nessas infraestruturas montadas em escala mundial. São elas: a virtualização e o arcabouço OpenFlow.
1.6.2. Tendências Futuras
Nossa observação é que esta busca pela Internet do Futura ainda está em sua fase inicial,
porém se expandindo com rapidez em algumas regiões do mundo. Liderando esta busca
estão os EUA, a UE e o Japão, seguida por Coreia, China e Brasil.
Nos EUA o programa GENI está iniciando a sua terceira fase, a chamada espiral 3,
e as tendências, nesta terceira fase, será iniciar o suporte de pesquisadores nas infraestruturas de experimentação e a incrementação de recursos disponíveis para uso entre seus
usuários, através de integração à chamada meso-scale, envolvendo a participação de maior
número de universidades interligadas pelas grandes redes de pesquisa, Internet2 e NLR.
Além disso, a ênfase será em ambientes de redes móveis 4G na periferia, integradas por
redes ópticas e Ethernet nas redes fixas, e a ênfase no uso de tecnologia OpenFlow, para
possibilitar experimentação com redes definidas por software. O GENI está sendo complementado pelo novo programa Future Internet Architectures (FIA), lançado 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 início no final 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, através
do estudo de casos de uso dos ambientes montados. No Japão, representado pelo projeto
AKARI, que está na em seu segundo período desenvolvimento, à tendência futura é para
início das construções de seus ambientes de teste e as primeiras demonstrações experimentais. O objetivo é que para o final de 2016 oferecer um protótipo da nova geração de
rede para disponibilidade aos pesquisadores. OpenFlow também é importante no Japão
e a empresa NEC está apostando na importância desta tecnologia para seu portfólio de
produtos das categorias comutador e controlador.
Por fim, no Brasil, a pesquisa em Internet do Futuro iniciou através de projetos isolados, como o projeto Horizon [Horizon 2011] e o projeto Webscience [WebScience 2010]
que prevê a construção de uma rede para experimentação em arquiteturas de Internet do
55
Futuro. Este último projeto servia como uma das bases para a proposta de cooperação com
um consórcio europeu, através do projeto FIBRE submetido às Chamadas Coordenadas
em TIC entre Brasil e a UE.
O projeto FIBRE, se confirmado, tornará possível a construção de uma instalação
experimental compartilhada de larga escala, que permita a experimentação em infraestrutura de rede e aplicações distribuídas. 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.
Além disso, possibilitará a federação 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 instalações ao mostrar aplicações
baseadas em OpenFlow, estabelecidas sobre os recursos das instalações federadas. Portanto, aumentará a colaboração e a troca de conhecimentos entre pesquisadores europeus
e brasileiros no campo de Internet do Futuro.
Agradecimentos
Este trabalho esta sendo apoiado por recursos financiados pelas seguintes instituições:
FAPESPA, CAPES, CNpQ e RNP.
Referências
[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:131–145.
[Andersen 2003] Andersen, D. G. (2003). Mayday: distributed filtering for internet services. In Proceedings of the 4th conference on USENIX Symposium on Internet Technologies and Systems - Volume 4, USITS’03, pages 3–3, Berkeley, CA, USA. USENIX
Association.
[Balakrishnan et al. 2004] Balakrishnan, H., Lakshminarayanan, K., Ratnasamy, S.,
Shenker, S., Stoica, I., and Walfish, M. (2004). A layered naming architecture for
the internet. SIGCOMM Comput. Commun. Rev., 34:343–352.
[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:5–22.
[BEACON 2011] BEACON (2011). Java-based openflow controller. Disponível em:
http://www.openflowhub.org/display/Beacon/Beacon+Home.Acessado em: 20/02/11.
[BEN 2011] BEN (2011). Breakable experimental network. Disponível 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 flexible, fast virtual networks on commodity hardware. In Proceedings of
the 2008 ACM CoNEXT Conference, CoNEXT ’08, pages 72:1–72:6, New York, NY,
USA. ACM.
[Bi 2011] Bi, J. (2011). Future internet related research activities in china. Disponível
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. Disponível em: http://www.bonfire-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
123–132. 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:862–876.
[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:55–67.
[Clack 2011] Clack, D. C. (2011).
Toward the design of a future internet. technical report:
National science fundation.
Disponível 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. Disponível 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.
Disponível
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 flexible virtual
routers on commodity hardware. SIGCOMM Comput. Commun. Rev., 40:127–128.
[Eide et al. 2006] Eide, E., Stoller, L., Stack, T., Freire, J., and Lepreau, J. (2006). Integrated scientific workflow management for the emulab network testbed. In Proceedings of the annual conference on USENIX ’06 Annual Technical Conference, pages
33–33, Berkeley, CA, USA. USENIX Association.
[Feldmann 2007] Feldmann, A. (2007). Internet clean-slate design: what and why? SIGCOMM Comput. Commun. Rev., 37:59–64.
[FIND 2011] FIND (2011). Future internet design. http://www.nets-find.net.
[Fink and R. 2011] Fink, B. and R., S. (2011).
Nuttcp.
Disponível 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.
Disponível
em:
http://www.futureInternet.eu/fileadmin/documents/bled_documents/experiemental_facilities/FIREIssues-paper-2.2.pdf.
[FIRE 2010] FIRE (2010). Future internet research and experimentation: An overview
of european fire initiative and its projects. Technical report, Disponível em:
http://cordis.europa.eu/fp7/ict/fire/docs/fire-brochure-201_en.pdf.
[FIRE 2011] FIRE (2011).
Future internet research and experimentation.
http://cordis.europa.eu/fp7/ict/fire/. 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.
Disponível em:
http://groups.geni.net/geni/attachment/wiki/GeniSysOvrvw/GENISysOvrvw092908.pdf.
[Greene 2009] Greene, K. (2009).
Tr10:
Software-defined 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:105–110.
[Horizon 2011] Horizon (2011). Horizon project: A new horizon to the internet.
Disponível 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).
Disponível
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, MILCOM’06, pages 153–161, Piscataway, NJ, USA. IEEE
Press.
[Jannotti et al. 2000] Jannotti, J., Gifford, D. K., Johnson, K. L., Kaashoek, M. F., and
O’Toole, 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, OSDI’00, pages 14–14, 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:12–16.
[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:1–8.
[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 169–182, 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 traffic 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:1–42: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). Netfpga–an open platform for
gigabit-rate network switching and routing. In Proceedings of the 2007 IEEE International Conference on Microelectronic Systems Education, MSE ’07, pages 160–161,
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). Openflow: enabling innovation in campus networks. SIGCOMM Comput. Commun. Rev., 38:69–74.
59
[MiniNet 2011] MiniNet (2011). Rapid prototyping for software-defined networks.
Disponível 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
Magalhães, M. F. (2010). Quagflow: partnering quagga with openflow. 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 124–131, Washington, DC, USA.
IEEE Computer Society.
[OFELIA 2011] OFELIA (2011). Openflow in europe - linking infrastructure and applications. Disponível 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.
Disponível:
[ORCA 2011] ORCA (2011). Open resource control architecture. Disponível 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:2–42.
[Peterson et al. 2006] Peterson, L., Muir, S., Roscoe, T., and Klingaman, A.
(2006). Planetlab architecture: An overview. Disponível em: http://www.planetlab.org/files/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. Disponiível em: http://svn.planetlab.org/attachment/wiki/GeniWrapper/sfa.pdf.
[ProtoGENI 2011] ProtoGENI
(2011).
Disponível
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.
Disponível em:
60
[Rexford and Dovrolis 2010] Rexford, J. and Dovrolis, C. (2010). Future internet architecture: clean-slate versus evolutionary research. Commun. ACM, 53:36–40.
[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:242–251.
[Shalunov 2011] Shalunov, S. (2011). Thrulay - network capacity tester. Disponível 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 openflow. SIGCOMM Comput. Commun. Rev., 40:129–130.
[Sherwood et al. 2009] Sherwood, R., Gibb, G., Yap, K., Appenzeller, G., McKeown, N., and Parulkar, G. (2009). Flowvisor: A network virtualization layer.
Disponível em: http://OpenFlowswitch.org/downloads/technicalreports/OpenFlow-tr2009-1flowvisor.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, OSDI’10, pages 1–6, Berkeley, CA, USA. USENIX Association.
[Spiral2 2010] Spiral2 (2010).
Geni spiral 2 overview.
Disponível 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:205–218.
[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 6–6, 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. Disponível em:
http://acs.lbl.gov/ tierney/papers/perfsonar-LBNL-report.pdf.
[UMF 2011] UMF (2011). Embedding real-time substrate measurements for crosslayer communications. Disponível em: http://groups.geni.net/geni/wiki/Embeddedem:
20/02/2011.
[WebScience 2010] WebScience (2010).
Brazilian institute for web science research.
Disponível em: http://webscience.org.br/files/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
flow-based networking with difane. SIGCOMM Comput. Commun. Rev., 40:351–362.
62
Capítulo
2
Explorando Redes Sociais Online: Da Coleta e
Análise de Grandes Bases de Dados às Aplicações
Fabrício Benevenuto, Jussara M. Almeida e Altigran S. Silva
Resumo
Redes sociais online têm se tornado extremamente populares, levando ao surgimento e à
crescente popularização de uma nova onda de aplicações na Web. Associado a esse crescimento, redes sociais estão se tornando um tema central de pesquisas em diversas áreas
da Ciência da Computação. Este mini-curso oferece uma introdução ao pesquisador
que pretende explorar esse tema. Inicialmente, apresentamos as principais características das redes sociais mais populares atualmente. Em seguida, discutimos as principais
métricas e análises 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
técnicas.
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. Introdução
Desde seu início, a Internet tem sido palco de uma série de novas aplicações, incluindo email, aplicações par-a-par, aplicações de comércio eletrônico assim como vários
serviços Web. Atualmente, a Web vem experimentando uma nova onda de aplicações
associada à proliferação das redes sociais online e ao crescimento da popularidade da
mídia digital. Várias redes sociais online (OSNs - Online Social Networks) surgiram, incluindo redes de profissionais (ex., LinkedIn), redes de amigos (ex., MySpace, Facebook,
Orkut), e redes para o compartilhamento de conteúdos específicos tais como mensagens
curtas (ex., Twitter), diários e blogs (ex., LiveJournal), fotos (ex., Flickr), e vídeos (ex.,
YouTube).
Redes sociais online têm atraído milhões de usuários. De acordo com a Nielsen
Online [99], mídia social, termo usado em referência a conteúdo criado e disseminado
via interações sociais, passou na frente de email como a atividade online mais popular.
Mais de dois terços da população online global visita ou participa de redes sociais e blogs.
Como comparação, se o Facebook fosse um país, este seria o terceiro país mais populoso
do mundo, graças aos seus 500 milhões de usuários registrados [5]. Tanta popularidade
está associada a uma funcionalidade comum de todas as redes sociais online que é permitir
que usuários criem e compartilhem conteúdo nesses ambientes. Este conteúdo pode variar
de simples mensagens de texto comunicando eventos do dia-a-dia até mesmo a conteúdo
multimídia, como fotos e vídeos. Como conseqüência, as estatísticas sobre conteúdo gerado pelos usuários nesses sítios Web são impressionantes. Por exemplo, o Facebook
compartilha mais de 60 bilhões de fotos, que ocupam mais de 1.5 PB de espaço [10]. A
quantidade de conteúdo que o YouTube armazena em 60 dias seria equivalente ao conteúdo televisionado em 60 anos, sem interrupção, pelas emissoras norte-americanas NBC,
CBS e ABC juntas [12]. De fato, o YouTube foi acessado por mais de 100 milhões de
usuários apenas em Janeiro de 2009 [1], com uma taxa de upload de 10 horas de vídeo
por minuto [14].
Apesar de tanta popularidade e da enorme quantidade de conteúdo disponível, o
estudo de redes sociais ainda está em sua infância, já que esses ambientes estão experimentando novas tendências e enfrentando diversos novos problemas e desafios. A seguir
sumarizamos alguns elementos motivadores para o estudo de redes sociais online.
• Comercial: Com usuários passando muito tempo navegando em redes sociais online, esses sítios Web têm se tornado um grande alvo para propagandas. De fato,
em 2007, 1,2 bilhões de dólares foram gastos em propagandas em redes sociais online no mundo todo, e é esperado que este número triplique até 2011 [21]. Além
disso, usuários de redes sociais online compartilham e recebem uma grande quantidade de informação, influenciando e sendo influenciados por seus amigos [40].
Conseqüentemente, redes sociais online estão se tornando cada vez mais um alvo
de campanhas políticas [59] e de diversas outras formas de marketing viral, onde
usuários são encorajados a compartilhar anúncios sobre marcas e produtos com seus
amigos [78].
• Sociológica: No passado o estudo de redes sociais era um domínio de sociólogos e antropólogos, que utilizavam, como ferramentas típicas para se obter dados,
65
entrevistas e pesquisas com usuários voluntários [113]. Como conseqüência, muitos desses estudos foram realizados com base em amostras de dados pequenas e
possivelmente pouco representativas. Com a popularização de aplicações de redes
sociais online, surgiu a oportunidade de estudos nesse tema com o uso de grandes
bases de dados, coletadas de tais aplicações. Sistemas como Facebook, Twitter,
Orkut, MySpace e YouTube possuem milhões de usuários registrados e bilhões de
elos que os conectam. Redes sociais online permitem o registro em larga escala
de diversos aspectos da natureza humana relacionados à comunicação, à interação
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 audiência local ou até mesmo global. De fato, redes sociais online vêm funcionando como um novo meio de comunicação, modificando
aspectos de nossas vidas.
• Melhorias dos sistemas atuais: Assim como qualquer sistema Web, redes sociais
online são vulneráveis a novas tendências e estão sujeitas a experimentarem uma
rápida transferência de seus usuários para outros sistema, sem aviso prévio. Por
exemplo, inicialmente o MySpace experimentou um crescimento exponencial
no número de usuários. Entretanto, este crescimento foi seguido por uma forte
queda depois de abril de 2008 devido a um aumento no número de usuários 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 países. Dentre esses países, o Brasil é o com maior número de
usuários registrados [11]. Várias razões podem explicar este tipo de fenômeno,
incluindo a interface e novas utilidades do sistema, problemas de desempenho e
características dos usuários, etc. Finalmente, o grande volume de dados disponíveis
em diferentes redes sociais online abre um novo leque de opções para pesquisas
relacionadas à recuperação de conteúdo, onde estratégias de busca e recomendação
de usuários e conteúdo são cada vez mais importantes.
Outro aspecto importante está relacionado ao tráfego gerado pelas redes sociais
online. Intuitivamente, existe uma diferença crucial entre publicar conteúdo na
Web tradicional e compartilhar conteúdo através de redes sociais online. Quando
as pessoas publicam algum conteúdo na Web, elas tipicamente fazem isso para
que todos os usuários da Internet, em qualquer lugar, possam acessar. Por outro
lado, quando usuários publicam conteúdo em redes sociais online, eles geralmente
possuem uma audiência em mente, geralmente, seus amigos. Algumas vezes, a
audiência é explicitamente definida por um usuário ou pela política do sistema.
Conseqüentemente, redes sociais online constituem uma classe única de aplicações
com potencial para remodelar os padrões de tráfego na Internet. Estudar aspectos de
sistemas relacionados a redes sociais pode ser de grande importância para a próxima
geração da infra-estrutura da Internet e para o projeto de sistemas de distribuição
de conteúdo mais eficientes, eficazes e robustos [71, 102].
• Segurança e conteúdo indesejável: Redes sociais online estão cada vez mais se
tornando alvo de usuários maliciosos ou oportunistas que enviam propagandas não
66
solicitadas, spam, e até mesmo phishing. O problema se manifesta de diversas maneiras, tais como a inclusão de vídeos contendo spams em listas de vídeos mais
populares [29, 26], o envio de spam no Twitter [24], a inclusão de metadados (particularmente tags) que não descrevem adequadamente o conteúdo associado (p.ex:
tag spamming) [27], etc. Conteúdo não solicitado consome a atenção humana, talvez o recurso mais importante na era da informação. Em última instância, o ruído
e o distúrbio causados por alguns usuários reduzem a efetividade da comunicação
online.
Redes sociais online são ambientes perfeitos para o estudo de vários temas da
computação, incluindo sistemas distribuídos, padrões de tráfego na Internet, mineração
de dados, sistemas multimídia e interação humano-computador. Além disso, por permitir que usuários criem conteúdo, redes sociais vêm se tornando um tema chave em
pesquisas relacionadas à organização e tratamento de grandes quantidades de dados, além
de constituírem um ambiente ideal para extração de conhecimento e aplicação de técnicas de mineração de dados. Neste mini-curso apresentamos uma visão geral sobre redes
sociais, oferecendo uma base necessária ao pesquisador que pretende explorar o tema.
Inicialmente, apresentamos as principais características das redes sociais mais populares
atualmente. Em seguida, discutimos as principais métricas e análises 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 técnicas.
2.2. Definições e Características de Redes Sociais Online
Esta seção apresenta uma visão geral sobre as redes sociais online, suas principais
características e mecanismos de interação entre os usuários.
2.2.1. Definição
O termo rede social online é geralmente utilizado para descrever um grupo de
pessoas que interagem primariamente através de qualquer mídia de comunicação. Conseqüentemente, baseado nessa definição, redes sociais online existem desde a criação da
Internet. Entretanto, neste trabalho, nós utilizaremos uma definição um pouco mais restrita, adotada em trabalhos anteriores [35, 85]. Nós definimos uma rede social online
como um serviço Web que permite a um indivíduo (1) construir perfis públicos ou semipúblicos dentro de um sistema, (2) articular uma lista de outros usuários com os quais
ele(a) compartilha conexões e (3) visualizar e percorrer suas listas de conexões assim
como outras listas criadas por outros usuários do sistema.
Com base nessa definição, existem várias redes sociais online disponíveis na Web,
que variam de acordo com seus objetivos primários. A Tabela 2.1 apresenta uma lista
com várias redes sociais online populares atualmente, juntamente com seus principais
propósitos. Uma lista atualizada e exaustiva de redes sociais online, com mais de 150
sítios Web, pode ser encontrada em [8].
Nome
Orkut
Facebook
MySpace
Hi5
LinkedIn
YouTube
Flickr
LiveJournal
Digg
Twitter
LastFM
Propósito
Amizades
Amizades
Amizades
Amizades
Professionais
Compartilhamento de vídeos
Compartilhamento de fotos
Blogs e diários
Compartilhamento de (bookmarks)
Troca de mensagens curtas
Compartilhamento de rádio/músicas
67
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.flickr.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 seção, discutimos várias funcionalidades oferecidas pelas principais aplicações de redes sociais online atuais. O objetivo desta seção não é prover uma lista completa
e exaustiva de funcionalidades, mas apenas descrever as mais relevantes.
• Perfis dos usuários: Redes sociais online possuem muitas funcionalidades organizadas ao redor do perfil do usuário, na forma de uma página individual, que oferece
a descrição de um membro. Perfis podem ser utilizados não só para identificar o
indivíduo no sistema, mas também para identificar pessoas com interesses em comum e articular novas relações. Tipicamente, perfis contêm detalhes demográficos
(idade, sexo, localização, etc.), interesses (passatempos, bandas favoritas, etc.), e
uma foto. Além da adição de texto, imagens e outros objetos criados pelo usuário,
o perfil de um usuário na rede social também contém mensagens de outros membros
e listas de pessoas identificadas como seus amigos na rede. Perfis são geralmente
acessíveis por qualquer um que tenha uma conta na rede social online ou podem ser
privados, de acordo com as políticas de privacidades definidas pelo usuário.
Recentemente, Boyd e colaboradores [34] mostraram que, para a maior parte dos
usuários de redes sociais online, existe uma forte relação entre a identidade do
indivíduo real e seu perfil na rede social.
• Atualizações: Atualizações são formas efetivas de ajudar usuários a descobrir conteúdo. Para encorajar usuários a compartilhar conteúdo e navegar por conteúdo
compartilhado por amigos, redes sociais online geralmente fazem as atualizações
imediatamente visíveis aos amigos na rede social. Burke e colaboradores [39] conduziram um estudo utilizando dados de 140,000 novos usuários do Facebook para
determinar que atividades como atualizações são vitais para que novos usuários
contribuam para o sistema. Como atualizações podem receber comentários de outros usuários, elas também são formas especiais de comunicação em redes sociais
online.
68
• Comentários: A maior parte das aplicações de redes sociais online permite que
usuários comentem o conteúdo compartilhado por outros. Alguns sistemas também
permitem que usuários adicionem comentários nos perfis de outros usuários. Comentários são um meio primordial de comunicação em redes sociais online, e também podem ser interpretados como expressão de relações sociais [19, 47]. Como
exemplo, usuários do YouTube podem comentar os vídeos armazenados por outros
no sistema, enquanto que tanto no Facebook quanto no Orkut, usuários podem adicionar comentários às fotos de outros. Da mesma forma, usuários do LiveJournal
podem postar comentários em blogs, etc.
• Avaliações: Em muitas redes sociais online, o conteúdo compartilhado por um
usuário pode ser avaliado por outros usuários. Avaliações podem aparecer em diferentes níveis de granularidade e formas. No Facebook, por exemplo, usuários
podem apenas gostar de uma postagem, clicando no botão “I like this”. De fato,
estatísticas recentes indicam que cada usuário do Facebook avalia, em média, 9 objetos por mês [5]. Ja no YouTube, vídeos podem ser avaliados com até 5 estrelas, de
forma similar à avaliação empregada na categorização de hotéis. O YouTube ainda
provê uma avaliação binária (positiva ou negativa) para os comentários recebidos
por vídeos, na tentativa de filtrar comentários ofensivos ou contendo alguma forma
de spam.
Avaliações de conteúdo são úteis de várias formas. Como exemplo, elas ajudam
usuários de sistemas como o YouTube a encontrar e identificar conteúdo relevante.
Avaliações podem ainda ajudar administradores a identificar conteúdo de baixa qualidade ou mesmo conteúdo inapropriado. Além disso, avaliações podem ser utilizadas para identificar conteúdo em destaque, para suportar sistemas de recomendação,
etc. Uma rede social online que coloca as avaliações dos usuários no centro do sistema é o Digg. O Digg permite que usuários avaliem URLs, notícias ou estórias e
utiliza aquelas mais votadas para expor o conteúdo mais popular [77].
• Listas de Favoritos: Várias aplicações sociais utilizam listas de favoritos para permitir que usuários selecionem e organizem seu conteúdo. Listas de favoritos ajudam
usuários a gerenciar seu próprio conteúdo e podem ser úteis para recomendações sociais. Como exemplo, usuários podem manter listas de vídeos favoritos no YouTube
e de fotos favoritas no Flickr. Nesses sistemas, usuários podem navegar na lista de
favoritos de outros usuários para buscar novos conteúdos [42]. Conseqüentemente,
listas de favoritos também facilitam a descoberta de conteúdo e a propagação de informação. Sistemas como o Orkut e o Twitter também provêem listas de favoritos
(fãs).
• Listas de Mais Populares (Top Lists): Tipicamente, redes sociais online que têm
o compartilhamento de conteúdo como elemento central do sistema, como o YouTube que é centrado no compartilhamento de vídeos, provêem listas de conteúdo
mais popular ou usuários mais populares. Geralmente, essas listas são baseadas em
avaliações ou outras estatísticas do sistema relativas ao conteúdo (ex: número de
visualizações, avaliações, ou comentários) ou relativas aos usuários (ex: número de
assinantes).
69
• Metadados: Em várias aplicações de redes sociais online, tais como o YouTube e o
Flickr, usuários tipicamente associam metadados, como título, descrição e tags, ao
conteúdo compartilhado. Metadados são essenciais para recuperação de conteúdo
em redes sociais online, uma vez que grande parte dos serviços de informação (p.ex:
busca, organização de conteúdo, recomendação, 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 são inerentemente redes complexas. Consequentemente, vários estudos recentes analisaram as características 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 número de áreas e sua teoria tem sido utilizada como ferramenta para entender
vários fenômenos, incluindo o espalhamento de epidemias [88], propagação de informação [115], busca na Web [38], e consequências de ataques a redes de computadores [17].
A seguir, várias propriedades estatísticas e métricas comumente utilizadas para analizar
e classificar rede complexas são apresentadas na seção 2.3.1. As seções 2.3.2 e 2.3.3
discutem propriedades específicas comumente associadas a várias redes complexas, a saber, redes small-world e redes power-law, respectivamente. Uma revisão detalhada sobre
métricas e teoria de redes complexas pode ser encontrada na referência [93].
2.3.1. Métricas para o Estudo de Redes Complexas
Uma rede é um conjunto de elementos, que chamamos de vértices ou nodos, com
conexões entre eles, chamadas de arestas. A estrutura topológica de uma rede pode ser
então modelada por um grafo, que, por sua vez, pode ser caracterizado a partir de diversas
métricas, 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 Vértices
Uma característica importante da estrutura de uma rede é a distribuição dos graus
de seus vértices. Tal distribuição já foi caraterizada em várias redes (ex: redes de
emails[64], a topologia da Internet [56], a Web [22], e redes neurais [36]) como seguindo
uma lei de potência. Em outras palavras, a probabilidade de um nodo ter grau k é proporcional a k−α , Consequentemente, uma métrica comumente utilizada para comparar
diferentes redes é o expoente α, obtido através de uma regressão linear. Valores típicos
para o expoente α ficam entre 1.0 e 3.5 [54]. Para redes direcionadas, é comum analisar
as distribuições doso grau dos nodos em ambas as direções, isto é, a distribuição do grau
de entrada e a distribuição do grau de saída.
Como exemplo, a Figura 2.1 mostra as distribuições dos graus de entrada (esquerda) e de saída (direita) para um grafo formado a partir das interações entre usuários
de vídeos do YouTube [23, 28]. Note que a curva da regressão linear, utilizada para se calcular o expoente α, também é exibida nesses gráficos. Ferramentas como o Gnuplot [6] e
o Matlab [9] podem ser utilizados para realizar a regressão e calcular o valor de α. Para
70
105
106
α = 2.096 fit, R2 = 0.987
5
# de nodos
10
# de nodos
α = 2.759 fit, R2 = 0.987
10
4
103
2
10
101
104
103
102
101
100 0
10
1
2
10
10
10
Grau de entrada
3
4
10
100 0
10
101
102
Grau de saida
103
Figura 2.1. Distribuições dos Grau sde Entrada e de Saída em um Grafo de Interações entre Usuários através de Vídeos do YouTube
verificar a acurácia da regressão, é comum medir o coeficiente de determinação R2 [109].
Quanto mais próximo o valor de R2 for de 1 (regressão perfeita), menor será a diferença
entre o modelo de regressão e os dados reais.
2.3.1.2. Coeficiente de Agrupamento
O coeficiente de agrupamento (clustering coefficient) de um nodo i, cc(i), é a
razão entre o número de arestas existentes entre os vizinhos de i e o número máximo
de arestas possíveis entre estes vizinhos. Como exemplo, a Figura 2.2 mostra o valor do
coeficiente de agrupamento para o nodo escuro em três cenários diferentes1 . No primeiro,
todos os vizinhos do nodo estão conectados entre si e, conseqüentemente, o cc do nodo
é 1. No segundo cenário, existe apenas 1 aresta entre os vizinhos do nodo dentre as 3
possíveis, deixando o nodo com cc = 1/3. No último cenário, não há nenhuma aresta
entre os vizinhos do nodo escuro e, portanto, o cc do nodo é 0.
Figura 2.2. Cálculo do Coeficiente de Agrupamento de um Nodo em Três Cenários Diferentes
Podemos notar que o coeficiente de agrupamento representa uma medida da densidade de arestas estabelecidas entre os vizinhos de um nodo. O coeficiente de agrupamento
1 Arestas
escuro.
tracejadas não existem e apenas ilustram as possíveis conexões entre os vizinhos do nodo
71
de uma rede, CC, é calculado como a média dos coeficiente 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 é
não direcionado.
Um trabalho que se tornou referência no estudo de componentes em redes complexas aborda a estrutura da Web representada por um grafo em que nodos são páginas
Web e arestas são elos existentes entre as páginas [38]. Os autores propõem 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 também de core, e outros grupos de componentes que podem alcançar o SCC
ou serem alcançados por ele. O modelo ficou conhecido como bow tie [38], pois a figura
que ilustrada o modelo lembra uma gravata borboleta.
(a) Web
(b) Fórum de Java
(c) Interações com vídeo
Figura 2.3. Estrutura dos Componentes da Web [38], do Fórum de Java [118] e
do Grafo de Interações de Usuários do YouTube [28]
Este modelo tem sido utilizado por outros estudos como forma de comparar a organização 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 três
72
redes diferentes, a saber, a rede Web, uma rede formada pelas conexões estabelecidas em
um Fórum de Java e a rede estabelecidas entre usuários do YouTube. O componente central, core, das figuras corresponde à fração dos nodos do grafo que fazem parte do SCC.
O componente in contém os nodos que apontam para algum nodo do core, mas não são
apontados por nodos desse componente. Finalmente, o componente out corresponde aos
nodos que são apontados por nodos do core. Note que há diferenças estruturais significativas 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 contém um percentual
muito maior dos nodos.
2.3.1.4. Distância Média e Diâmetro
A distância média de um grafo é o número médio de arestas em todos todos os
caminhos mínimos existentes entre todos os pares de nodos do grafo. Normalmente, a
distância média é computada apenas no SCC para grafos direcionados ou no WCC para
grafos não direcionados, já que não existe caminho entre nodos localizados em componentes diferentes. Outra métrica relacionada é o diâmetro do grafo. O diâmetro é definido
como a distância do maior caminho mínimo existente no grafo e, em geral, é também
computado somente para nodos do WCC ou do SCC.
2.3.1.5. Assortatividade
De acordo com Newman [92], assortatividade é uma medida típica de redes sociais. Uma rede exibe propriedades assortativas quando nodos com muitas conexões tendem
a se conectar a outros nodos com muitas conexões. Para caracterizar a assortatividade de
uma rede, medimos o grau médio 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 função de k. Valores crescentes indicam assortatividade,
isto é, nodos com graus maiores tendem a se conectar a nodos com um número maior de
conexões. Valores decrescentes de knn(k) em função 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 é definido como o número de caminhos mínimos
entre todos os pares de nodos em um grafo que passam por e [95]. Se existem múltiplos
caminhos mínimos entre um par de nodos, cada caminho recebe um peso de forma que a
soma dos pesos de todos os caminhos seja 1. Conseqüentemente, o betweenness de uma
aresta e pode ser expressado como:
B(e) =
∑
u∈V,v∈V
σe (u, v)
σ (u, v)
(1)
73
onde σ (u, v) representa o número de caminhos mínimos entre u e v, e σe (u, v) representa
o número de caminhos mínimos entre u e v que incluem e. O betweenness de uma aresta
indica a importância dessa aresta no grafo em termos de sua localização. Arestas com
maior betweenness fazem parte de um número maior de caminhos mínimos e, portanto,
são mais importantes para a estrutura do grafo.
De forma similar, o betweenness pode ser computado para um nodo ao invés de
uma aresta. Neste caso, a medida do betweenness mede o número de caminhos mínimos
que passam pelo dado nodo. Nodos que possuem muitos caminhos mínimos que passam
por eles possuem maior betweenness, indicando uma maior importância 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 métrica interessante de ser observada é o coeficiente de reciprocidade ρ,
uma métrica que captura a reciprocidade das interações em toda a rede [60]. O coeficiente
de reciprocidade ρ é definido pelo coeficiente de correlação entre entidades da matriz
de adjacência representativa do grafo direcionado. Em outras palavras, seja a matriz a
definida como ai j = 1 se há uma aresta de i para j no grafo, e ai j = 0, caso contrário.
Definimos a reciprocidade da rede ρ como :
ρ=
∑i6= j (ai j − ā)(a ji − ā)
,
∑i6= j (ai j − ā)2
(3)
onde o valor médio ā = ∑i6= j ai j /N(N − 1) e N é o número de usuários no grafo. O
coeficiente de reciprocidade indica se o número de arestas recíprocas na rede é maior ou
menor do que o de uma rede aleatória. Se o valor ρ é maior do que 0, a rede é recíproca;
caso contrário, ela é anti-recíproca.
2.3.1.8. PageRank
O PageRank é um algoritmo interativo que assinala um peso numérico para cada
nodo com o propósito de estimar sua importância relativa no grafo. O algoritmo foi inicialmente proposto por Brin and Page [37] para ordenar resultados de busca do protótipo
de máquina de busca da Google. A intuição por trás do PageRank é que uma página Web
74
é importante se existem muitas páginas apontando para ela ou se existem páginas importantes apontando para ela. A equação que calcula o PageRank (PR) de um nodo i, PR(i),
é definida da seguinte forma:
PR(i) = (1 − d) + d
PR(v)
Nv
v∈S(i)
∑
(4)
onde S(i) é o conjunto de páginas que apontam para i, Nv denomina o número de arestas
que saem do nodo v, e o parâmetro 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 usuários experientes em fóruns especializados [118] e usuários influentes no Twitter [116, 73]. Além disso, existem outras modificações do PageRank com
propósitos específicos, como por exemplo, a detecção de spam na Web [66].
2.3.2. Redes Small-World
O conceito de redes small-world ficou bastante conhecido com o famoso experimento de Milgram [84]. Este experimento consistiu de um grupo de voluntários tentando
enviar uma carta para uma pessoa alvo através de outras pessoas que eles conheciam.
Milgram enviou cartas a várias pessoas. As cartas explicavam que ele estava tentando
atingir uma pessoa específica em uma cidade dos EUA e que o destinatário deveria repassar a carta para alguém que ele achasse que poderia levar a carta o mais próximo do
seu destino final, ou entregá-la diretamente, caso o destinatário final fosse uma pessoa
conhecida. Antes de enviar a carta, entretanto, o remetente adicionava seu nome ao fim
da carta, para que Milgram pudesse registrar o caminho percorrido pela carta. Das cartas
que chegaram com sucesso ao destino final, o número médio de passos requerido para o
alvo foi 6, resultado que ficou conhecido como o princípio dos seis graus de separação.
Em termos das propriedades das redes sociais que discutimos, uma rede pode ser
considerada small-world se ela tiver duas propriedades básicas: coeficiente de agrupamento alto e diâmetro pequeno [114]. Estas propriedades foram verificadas em várias
redes como a Web [18, 38], redes de colaboração científica [91, 94] em que pesquisadores são nodos e arestas ligam co-autores de artigos, redes de atores de filmes [20] em que
atores são nodos e arestas ligam atores que participaram do mesmo filme, e redes sociais
online [15, 87, 50, 79, 23, 28]. Em particular, Mislove e colaboradores [87] verificaram
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 distribuições dos graus dos nodos seguem uma lei de potência (Seção
2.3.1.1) são ditas redes power-law. Redes livres de escala (scale free) são uma classe
de redes que seguem leis de potência caracterizadas pela seguinte propriedade: nodos de
grau alto tendem a se conectar a outros nodos de grau alto. Barabási e colaboradores [22]
propuseram um modelo para gerar redes livre de escala, introduzindo o conceito de conexão 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 circunstâncias, este modelo produz redes que seguem leis de
potência. Mais recentemente, Li e colaboradores [80] criaram uma métrica para medir se
uma rede é livre de escala ou não, além de prover uma longa discussão sobre o tema.
2.4. Técnicas de Coleta de Dados
Em um passado recente, redes sociais eram um domínio de sociólogos e antropólogos, que utilizavam pesquisas e entrevistas com pequenos grupos de usuários como
ferramentas de coleta de dados [113]. Com o surgimento das redes sociais online, a obtenção de dados reais em larga escala se tornou possível, e pesquisadores de diversas áreas
da computação começaram a realizar coletas de dados.
Diferentes áreas de pesquisa demandam diferentes tipos de dados e, por isso, existem várias formas de se obter dados de redes sociais online. A Figura 2.4 apresenta
possíveis pontos de coleta de dados, que variam desde entrevistas com os usuários até
à instalação de coletores localizados em servidores proxy ou em aplicações. A seguir
discutimos essas diferentes abordagens, bem como trabalhos que ilustram o uso dessas
estratégias.
2.4.1. Dados dos Usuários
Figura 2.4. Possíveis Pontos de Coleta de Dados
Um método comum de se analisar o uso de redes sociais online consiste em conduzir entrevistas com usuários desses sistemas. Em particular, esta estratégia tem sido
bastante empregada pela comunidade da área de interface homem-máquina [107, 69, 43,
32, 97], para a qual entrevistas estruturadas são as formas mais populares de obtenção de
dados.
Como exemplo, através de entrevistas com usuários do Facebook, Joinson e seus
colaboradores [69] identificaram várias razões pelas quais usuários utilizam o sistema, tais
como conexão social, compartilhamento de interesses, compartilhamento e recuperação
de conteúdo, navegação na rede social e atualização do seu estado atual. Chapman e
Lahav [43] conduziram entrevistas e analisaram os padrões de navegação de 36 usuários
de quatro nacionalidades diferentes para examinar diferenças etnográficas no uso de redes
sociais online.
76
2.4.2. Dados de Pontos Intermediários
Existem duas técnicas comuns utilizadas para coletar dados de pontos de agregação de tráfego na rede. A primeira consiste em coletar os dados que passam por um
provedor de serviços Internet (ISP) e filtrar as requisições 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 fizeram o uso dessas estratégias.
2.4.2.1. Servidores Proxy
Figura 2.5. Exemplo de um Servidor Proxy Intermediando o Tráfego entre Clientes e Servidores
Coletar dados de um servidor proxy tem sido uma estratégia utilizada em vários
estudos sobre o tráfego da Internet [52, 65, 82, 117]. A Figura 2.5 ilustra como um
servidor proxy funciona como um agregador de tráfego de seus clientes, podendo ser
utilizados para delimitar uma porção da rede, composta por computadores em uma mesma
localização geográficas.
Dado o crescente interesse por vídeos na Web, alguns trabalhos recentes utilizaram
servidores proxy para obter dados do tráfego gerado por sistemas de compartilhamento de
vídeos, como o YouTube. Gill e colaboradores [61] caracterizaram o tráfego do YouTube
coletando dados de um servidor proxy localizado na universidade de Calgary, no Canadá.
Eles mostraram que requisições de HTTP GET, utilizadas para fazer o download de conteúdo do YouTube, correspondem a 99.87% do total das requisições que passam pelo
servidor proxy. Eles ainda caracterizaram diversas métricas relacionadas a estas requisições tais como a duração, a idade e a categoria dos vídeos. Mais recentemente, os mesmos
autores caracterizam sessões de usuários no YouTube [62]. Eles mostraram que uma sessão típica dura cerca de 40 minutos, caracterizando também o tempo entre sessões e os
tipos de conteúdo transferidos em cada sessão. Finalmente, Zink e colaboradores [119]
também estudaram o tráfego de vídeos do YouTube coletado no servidor proxy de uma
universidade. Eles também analisaram, via simulação, os benefícios da adoção de abordagens de caches locais e globais para vídeos bem como do uso de arquiteturas P2P para
77
distribuição de vídeos. De maneira geral, eles mostraram que essas abordagens poderiam
reduzir significativamente o volume de tráfego, permitindo acesso aos vídeos de forma
mais rápida.
Em um trabalho recente, Schneider e colaboradores [105] extraíram dados de redes sociais online de um provedor de acesso a Internet e reconstruíram ações realizadas
pelos usuários em suas navegações 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 navegação dos usuários do ISP. Eles discutiram amplamente a
metodologia de reconstrução dos acessos dos usuários e, com base nesses dados, analisaram as seqüências de requisições realizadas pelos usuários vários sistemas, incluindo o
Facebook.
2.4.2.2. Agregadores de Redes Sociais
Agregadores de redes sociais são sistemas que permitem acesso a várias redes
sociais simultaneamente, através de um portal único. Esses sistemas ajudam usuários que
utilizam várias redes sociais online a gerenciar seus perfis de uma forma mais simples e
unificada [70, 106]. Ao se conectarem a um agregador de redes sociais online, usuários
podem acessar suas contas através de uma interface única, sem precisar se conectar em
cada rede social separadamente. Isto é feito através de uma conexão HTTP em tempo real
realizada em duas etapas: a primeira etapa ocorre entre o usuário 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 através de APIs, como o
OpenSocial [7], e todo o conteúdo é exibido através da interface do sistema agregador.
A Figura 2.6 descreve o esquema de interação entre os usuários, um sistema agregador
e algumas redes sociais online. Através dessa interface, um usuário pode utilizar várias
funcionalidades de cada rede social que ele está conectado, tais como checar atualizações
de amigos, enviar mensagens e compartilhar fotos.
Figura 2.6. Ilustração de um Usuário se Conectando a Múltiplas Redes Sociais
Online Simultaneamente Através de um Portal Agregador
Recentemente, a partir de uma colaboração com um agregador de redes sociais
online, nós coletamos dados da navegação dos usuários (i.e., clickstream) em 4 redes
sociais online: Orkut, Hi5, MySpace e LinkedIn [30]. A Tabela 2.2 mostra o número
de usuários, sessões e requisições HTTP para cada uma dessas redes. Baseados nesses
dados e em dados coletados do Orkut, nós examinamos o comportamento dos usuários
78
nas redes sociais online, caracterizando as interações estabelecidas entre eles através das
várias atividades realizadas.
# usuários # sessões
Orkut
36.309
57.927
515
723
Hi5
MySpace
115
119
85
91
LinkedIn
Total
37.024
58.860
# requisições
787.276
14.532
542
224
802.574
Tabela 2.2. Sumário dos Dados Obtidos de um Agregador de Redes Sociais Online
2.4.3. Dados de Servidores de Redes Sociais Online
Idealmente, servidores de aplicações de redes sociais online são os locais mais
adequados para a coleta de dados, uma vez que eles têm uma visão completa de todas
as ações e atividades realizadas por todos os usuários do sistema um dado período de
tempo. Entretanto, o acesso a dados armazenados por estes servidores, ainda que anonimizados, é tipicamente muito difícil. 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 interações textuais entre os usuários do Cyworld, uma
rede social bastante popular na Coréia do Sul. Eles compararam as propriedades estruturais da rede de amizades explícita criada naquela aplicação com as propriedades da rede
implícita estabelecida a partir de trocas de mensagens no livro de visitas do Cyworld,
discutindo diversas similaridades e diferenças. Citamos também o trabalho de Baluja e
colaboradores, que utilizaram dados do histórico de navegação de usuários do YouTube
para criar um grafo onde cada vídeo é um nodo e arestas ligam vídeos freqüentemente
vistos em seqüência. Baseados nesse grafo, eles criaram um mecanismo capaz de prover sugestões de vídeos personalizadas para os usuários do YouTube. Finalmente, Duarte
e seus colaboradores [53] caracterizaram o tráfego em um servidor de blogs do UOL
(www.uol.com.br), enquanto nós estudamos a navegação dos usuários em um servidor de
vídeos do UOL, chamado UOL Mais [25].
Dada a dificuldade em se obter dados diretamente de servidores de redes sociais
online, uma estratégia comum consiste em visitar páginas de redes sociais com o uso de
uma ferramenta automática, que chamamos de crawler ou robô, e coletar sistematicamente informações públicas de usuários e objetos. Tipicamente, os elos entre usuários de
uma rede social online podem ser coletados automaticamente, permitindo que os grafos
de conexões entre os usuários sejam reconstruídos. Essa estratégia tem sido amplamente
utilizada em uma grande variedade de trabalhos, incluindo estudos sobre a topologia das
redes sociais online [87, 16], padrões de acesso no YouTube [41] e interações reconstruídas através de mensagens trocadas pelos usuários [112]. A seguir discutimos vários
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 usuários da rede. Entretanto, na maior parte das vezes, não há uma forma sistemática de se coletar todos os
usuários de uma rede social online. Para esses casos é necessário 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 são descobertos e então coletados no segundo passo,
que só termina quando todos os nodos descobertos no primeiro passo são coletados. No
passo seguinte todos os nodos descobertos no passo anterior são coletados, e assim sucessivamente. Recomenda-se o uso de um grande número de nodos sementes para evitar que
a coleta não fique restrita a um pequeno componente do grafo.
Um ponto crucial sobre a coleta por snowball é a interrupção da coleta em um
passo intermediário, antes que todos os nodos alcançávels pela busca em largura sejam
atingidos. Esta interrupção pode ter que ser forçada para tornar a coleta viável. 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 distribuições de graus dos nodos com
uma tendência maior para valores grandes, o que pode, em última instância, afetar as
análises e conclusões observadas. Em outras palavras, os dados obtidos via coleta por
snowball com interrupção precisam ser tratados e analisados com cautela. Em outras palavras, o tipo de análise a ser feita precisa ser considerado. Por exemplo, se realizarmos
3 passos da coleta, podemos calcular, com precisão, o coeficiente de agrupamento dos
nodos semente. Entretanto, se quisermos computar o coeficiente de agrupamento médio
de toda a rede ou outras métricas globais como distribuição de graus, distância média,
etc., a coleta por snowball pode resultar em números tendenciosos caso ela não 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 usuários. Além disso, eles
mostram que usuários não incluídos 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 estratégia baseada em um
esquema de busca em largura ou busca em profundidade. Quanto maior o número de
sementes utilizadas maior a chance de se coletar o maior componente do grafo. Em trabalhos recentes, nós realizamos uma busca por palavras aleatórias no YouTube para verificar
se o componente coletado era o maior componente [28, 23]. Como a maior parte dos usuários 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 usuários. Além disso, eles mostram que usuários não incluídos 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 usuário u pode seguir um outro usuário v, sem necessariamente ser seguido por ele. Em casos como estes, ou seja, em grafos direcionados,
é necessário percorrer as arestas do grafo em ambas as direções a fim de coletar o WCC
completamente. Caso contrário, se coletarmos o grafo seguindo as arestas em apenas uma
direção, não é 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 direções é maior do que quando seguimos apenas uma das direções. Em algumas redes não
é possível percorrer o grafo em ambas as direções e, portanto, não é possível coletar o
maior WCC. Essa limitação é típica de estudos que envolvem a coleta da Web [38]. Ti-
81
picamente, a Web é freqüentemente coletada seguindo apenas uma direção dos elos entre
páginas, já que não é possível determinar o conjunto de páginas que apontam para uma
página.
Uma outra estratégia de coleta por amostragem em redes é baseada em caminhadas aleatórias (random walks) [100]. A idéia básica consiste em, a partir de um nodo
semente v, prosseguir selecionando aleatoriamente um dos vizinhos de v, e assim sucessivamente até que um número pre-definido B de nodos tenham sido selecionados. Um
mesmo nodo pode ser selecionado múltiplas vezes. Esta é a estratégia de caminhada aleatória mais comum disponível na literatura embora existam outras abordagens que diferem
em termos de como os vizinhos são selecionados [81, 101] Assim como a coleta por snowball, a coleta através de caminhadas aleatórias também tem suas limitações: a precisão
das estimativas depende não somente da estrutura do grafo mas também da característica
sendo estimada. Em particular, dependendo da estrutura do grafo, a coleta pode ficar
“presa"dentro de um subgrafo. Neste caso, as estimativas podem ser imprecisas se as
características do subgrafo não forem representativas da rede como um todo. Para mitigar este problema, Ribeiro e Towsley propuseram uma estratégia de coleta por caminhas
aleatórias chamado Frontier sampling, que começa com m nodos sementes[100]. Eles
ainda propuseram estimadores sem tendência para várias métricas de redes complexas,
incluindo o coeficiente de agrupamento global da rede, usando as arestas coletadas pelo
método 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 distribuídos em diversas máquinas. Isso acontece não só devido ao
processamento necessário para tratar e salvar os dados coletados, mas também para evitar
que servidores de redes sociais interpretem a coleta de dados públicos como um ataque a
seus servidores.
Uma forma de se realizar tal coleta, conforme descrito em [45], está representada
na Figura 2.9. A estratégia consiste em utilizar (1) uma máquina mestre que mantém uma
lista centralizada de usuários a serem visitados e (2) máquinas escravas, que coletam, armazenam e processam os dados coletados para identificar novos usuários. Novos usuários
identificados pelas máquinas escravas são repassados para a máquina mestre, que por sua
vez, distribui novos usuários a serem coletados para as máquinas escravas.
2.4.3.3. Coleta por Inspeção de Identificadores
Como discutido anteriormente, idealmente, a coleta de uma rede social online
deveria incluir a rede completa e não somente uma porção dela. Em alguns sistemas como
o MySpace e o Twitter é possível realizar uma coleta completa. Esses sistemas atribuem
um identificador (ID) numérico e seqüencial para cada usuário cadastrado. Como novos
usuários recebem um identificador seqüencial, podemos simplesmente percorrer todos os
IDs, sem ter que verificar a lista de amigos desses usuários em busca de novos IDs para
coletar.
82
Figura 2.9. Exemplo de Coleta Realizada de Forma Distribuída
Recentemente, nós realizamos uma coleta do Twitter seguindo essa estratégia.
Nós solicitamos aos administradores do Twitter a permissão para realizar uma coleta
em larga escala. Em resposta, eles adicionaram os endereços IPs de 58 máquinas sob
nosso controle em uma lista branca, com permissão para coletar dados. Cada uma das
58 máquinas, localizadas no Max Planck Institute for Software Systems (MPI-SWS), na
Alemanha2 , teve permissão para coletar dados a uma taxa máxima de 20 mil requisições
por hora. Utilizando a API do Twitter, nosso coletor investigou todos os 80 milhões de
IDs de forma seqüencial, coletando todas as informações públicas sobre esses usuários,
bem como seus elos de seguidores e seguidos e todos os seus tweets. Dos 80 milhões de
contas inspecionadas, nós encontramos cerca 55 milhões em uso. Isso acontece porque o
Twitter apaga contas inativas por um período maior do que 6 meses. No total, coletamos
cerca de 55 milhões de usuários, quase 2 bilhões de elos sociais e cerca de 1.8 bilhões de
tweets. Ao inspecionar as listas de seguidores e seguidos coletadas, nós não encontramos
nenhum identificador acima dos 80 milhões inspecionados, sugerindo que nós coletamos
todos os usuários do sistema na época. Esses dados foram utilizados recentemente em
dois trabalhos, um sobre detecção de spammers no Twitter [24] e o outro sobre medição
de influência no Twitter [40].
Torkjazi e colaboradores [108] também exploraram o uso de IDs sequenciais para
inspecionar o surgimento de novos usuários 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 usuários comuns expressem suas opiniões
sobre os mais diversos assuntos, e propaguem informações que consideram relevantes
em tempo real. É interessante notar como a interatividade e a avaliação do fluxo de
informações em tempo real passou a ser um fator importante para várias aplicações Web,
que monitoram fenômenos dinâmicos ocorridos na Web. Como exemplo, Google e Bing
já indexam tweets públicos como forma de prover busca por informação em tempo real.
Do ponto de vista científico, informações disponibilizadas em tempo real na Web
têm sido utilizadas de diferentes formas. O Google Insights3 , por exemplo, permite que o
usuário consulte informações geográficas e temporais relacionadas ao volume de uma determinada consulta, permitndo também que o usuário salve essas informações em formato
CSV. De fato, informações extraídas em tempo real do Google Insights foram utilizadas
para demonstrar que o volume de buscas na Web permite monitorar eventos tais como
o nível de desemprego e a ocorrência de doenças em tempo real [46, 63]. Em particular, Ginsberg e colaboradores [63] propuseram um método para monitorar ocorrências de
gripe baseado em buscas realizadas no Google. Eles mostraram que, em áreas com grande
população de usuários de máquinas de buscas, o volume de buscas relacionadas à gripe é
proporcional à ocorrência da doença.
Em um trabalho recente, Sakaki e colaboradores [103] mostraram o poder da informação disponibilizada em tempo real nas redes sociais online propondo um mecanismo para detecção de ocorrências de terremotos baseado em monitoramento do Twitter.
A abordagem, que consiste em simplesmente identificar tweets relacionados a terremotos
por região, foi capaz de enviar alertas sobre terremotos mais rapidamente do que agências
meteorológicas. Mais recentemente, Tumasjan e colaboradores [110] mostraram que opiniões identificadas em tweets relacionados à eleição federal alemã foi capaz de refletir o
sentimento político registrado fora das redes sociais.
Para o caso específico do Twitter, é bastante simples coletar informações em
tempo real, uma vez que o sistema oferece uma API com diversas opções relacionadas à
coleta de dados em tempo real. Como exemplo, para coletar em tempo real uma amostra
aleatória de tweets públicos basta executar o seguinte comando em algum terminal
UNIX, fornecendo o usuário e senha de um usuário 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 requisições HTTP juntamente com suas respectivas definições de resposta. Em
aplicações de redes sociais online é comum encontrarmos APIs que listam os amigos de
um usuário, seus objetos, suas comunidades, etc.
APIs são 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 informações de um usuário no Twitter. Além dessa
função, o Twitter ainda oferece várias outras funções em sua API. Com a API do Twitter
é possível coletar 5000 seguidores de um usuário através de uma única requisição. A
coleta dessa informação através do sítio Web convencional necessitaria de centenas de
requisições, visto que o Twitter só mostra alguns seguidores por página. Além disso, cada
página conteria uma quantidade muito grande de dados desnecessários, que deveriam ser
tratados e excluídos.
Vários sistemas possuem APIs, incluindo Twitter, Flickr, YouTube, Google Mapas, Yahoo Mapas, etc. Com tantas APIs existentes, é comum ver aplicações que utilizam
duas ou mais APIs para criar um novo serviço, que é o que chamamos de Mashup. Uma
interessante aplicação chamada Yahoo! Pipes [13], permite a combinação de diferentes
APIs de vários sistemas para a criação automatizada de Mashups.
2.4.3.6. Ferramentas e Bibliotecas
Desenvolver um coletor pode ser uma tarefa bastante complicada devido à diversidade de formatos de páginas. Entretanto, coletar redes sociais online é, e m geral,
diferente de coletar páginas da Web tradicional. As páginas de uma rede social online
são, em geral, bem estruturadas e possuem o mesmo formato, pois são geradas auto maticamente, enquanto que, na Web tradicional, as páginas podem ser criadas por qualquer
pessoa em qualquer formato. Além disso, como cada indivíduo ou objeto em uma rede
social, em geral, possui um identificador único, temos certeza sobre quais as informações
obtivemos quando coletamos uma página.
Existem várias 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 próprio coletor pode ser necessário. A Figura 2.11
mostra o uso da biblioteca LWP na linguagem Perl. Este código realiza a coleta dos
seguidores de um usuário no Twitter através de sua API. De maneira similar, o código
85
em Python da Figura 2.12 utiliza a biblioteca URLLIB para realizar a mesma tarefa. O
resultado da execução dos coletores é a lista de seguidores de um usuário 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 automáticas de coleta (coletores
ou robôs), se feito sem o devido cuidado, pode causar problemas de sobrecarga nos servidores alvos da coleta, o que, em última instância, pode afetar a qualidade de serviço
da aplicação alvo. Para evitar que isto aconteça, muitos servidores adotam um protocolo
conhecido como Robots.txt, no qual sítios Web regulamentam o que pode e o que não
pode ser coletado do sistema. Este método é bastante utilizado pelos administradores de
sistemas para informar aos robôs visitantes quais diretórios de um sítio Web não 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 máquina de busca como o
Google [37].
O Robots.txt nada mais é do que um arquivo que fica no diretório raiz dos sítios
e contém regras para coleta. Estas regras podem ser direcionadas a robôs específicos ou
podem ser de uso geral, tendo como alvo qualquer robô. Ao visitar um site, os robôs
devem primeiramente buscar pelo arquivo Robots.txt a fim de verificar suas permissões.
Exemplos desses arquivos são:
http://portal.acm.org/robots.txt
http://www.google.com/robots.txt
86
Figura 2.13. Resultado da Execução 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 conteúdo no sistema.
User-agent: *
Disallow: /
É possível ainda especificar restrições a alguns robôs específicos ou restringir o
acesso a alguns diretórios específicos. Como exemplo, o sítio Web www.globo.com oferece restrições para todos os robôs nos seguintes diretórios.
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
No caso de coleta de redes sociais online, é importante verificar não só o arquivo
dos sistemas, mas também os termos de uso do sistema.
R obots.txt
2.4.4. Dados de Aplicações
Em uma tentativa bem sucedida de enriquecer a experiência dos usuários de redes
sociais online, o Facebook realizou uma de suas maiores inovações: abriu sua plataforma
para desenvolvedores de aplicações [4]. Com esta inovação, desenvolvedores são capazes de criar diferentes tipos de aplicações. Com o sucesso no Facebook, outros sistemas
como Orkut e MySpace também adotoram essa estratégia. Como consequência, o número e a variedade de aplicações criadas nestes sistemas cresceram significativamente. O
Facebook sozinho possui atualmente mais de 81,000 aplicaçõess4 [2]. Empresas como a
Zynga, especializadas em desenvolver essas aplicações, contam com mais de 80 milhões
de usuários registrados em suas aplicações [2].
Figura 2.14. Funcionamento de Aplicações no Facebook e no Orkut
A Figura 2.14 mostra o funcionamento de uma aplicação terceirizada em execução
em redes sociais online como o Facebook ou o Orkut. Aplicações são caracterizadas pela
presença de um servidor da rede social intermediando toda a comunicação entre o cliente
e o servidor da aplicação. Tipicamente, o cliente envia a requisição ao servidor da rede
social online, que a repassa ao servidor da aplicação. Então, o servidor da aplicação
manda de volta a resposta ao servidor da rede social, que a repassa ao cliente [90].
Aplicações podem ser utilizadas para o estudo de interações entre os usuários que
utilizam as aplicações e também podem ser úteis para coletar outras informações dos
usuários, tais como lista de amigos e atividades executadas durante uma sessão. Alguns
trabalhos fizeram uso dessa estratégia para estudar os usuários de redes sociais online.
Nazir e colaboradores [89] analisaram características de aplicações no Facebook, desenvolvendo e lançando suas próprias aplicações. Em particular, eles estudaram a formação
4 Uma
grande lista de aplicações do Facebook pode ser encontrada na seguinte referência [3].
88
de comunidades online a partir de grafos de interação entre os usuários de suas aplicações.
Mais recentemente, os mesmos autores estudaram várias características relacionadas ao
desempenho de suas aplicações no Facebook [90].
2.5. Extração de Informação
A extração e o tratamento de informação a partir dos dados coletados são etapas
essenciais para permitir diferentes análises incluindo identificação de padrões de comportamento de usuários em diferentes sistemas, identificação de tópicos de interesse dos
usuários, etc. Nesta seção, discutimos brevemente os principais desafios relacionados a
essas etapas. Em particular, a identificação de entidades nomeadas, tais como pessoas,
organizações e produtos, encontradas em porções de texto, assim como a derivação de
relacionamentos entre estas entidades, representam importantes problemas, com diversas
aplicações interessantes. O nosso objetivo nesta seção não é detalhar todas as particularidades e soluções para estes problemas, que são tipicamente abordados por pesquisadores
de outras áreas tais como Bancos de Dados, Recuperação de Informação, Mineração de
Dados e Processamento de Linguagem Natural. Entretanto, reconhecendo a necessidade
de expertises complementares para o estudo de redes sociais online, achamos benéfico
para o leitor o contato, ainda que superficial, com estes tópicos.
2.5.1. Visão Geral
As redes sociais online são atualmente importantes plataformas para produção,
processamento e fluxo de informação. Tal informação pode se originar dentro das redes
ou fora delas e pode ser utilizada como fonte primária ou complementar para derivar conhecimento sobre a própria rede, seus membros, seus temas, suas comunidades, etc. No
entanto, esta informação quase sempre ocorre em um formato textual, não estruturado,
em linguagem natural e até mesmo em estilo telegráfico ou informalmente codificado.
Isso é um grande empecilho para que esta informação possa ser processada de maneira
automática 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 várias
formas, devido às variações introduzidas por diferentes formas de grafia, aspectos regionais ou culturais, uso de abreviaturas, erros tipográficos e outras razões associadas com o
uso convencional.
Em contextos já bastante explorados como sítios e páginas da Web, técnicas de
áreas como Recuperação de Informação, Mineração de Dados e Processamento de Linguagem Natural têm sido aplicadas com muito sucesso para extrair informação 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, comentários, feeds, tags,
cujo tratamento deve ser necessariamente diferente do que é normalmente aplicado a, por
exemplo, páginas Web. Além disto, dado o caráter informal de várias informações disponibilizadas em redes sociais online, técnicas de processamento de linguagem natural são
difíceis de serem aplicadas devido à ausência de padrões linguísticos. Além disso, nos
corpora textuais encontrados em redes sociais online existe muito lixo e ruído informacional (palavras escritas erradas, de baixa qualidade sintática ou semântica) dificultando
esta tarefa ainda mais.
89
Por exemplo, técnicas de extração aberta de informações na Web [55] que se baseiam em modelos linguísticos gerais de como relacionamentos são expressos em um
idioma, são o estado da arte em extração de entidades e relacionamentos de páginas Web.
No entanto, como os modelos utilizados nestas técnicas são construídos a partir de características linguísticas através da identificação de partes de discurso nos documentos-alvo,
elas dificilmente poderiam ser aplicadas em micro-documentos (por exemplo, tweets),
onde estas características podem não se apresentar.
Apesar das dificuldades mencionadas, a extração de informações contidas no corpus textual de redes sociais pode ajudar a responder de forma automática e efetiva questões como:
• Quem fala com quem sobre que assunto?
• Quem são os atores principais nas redes? Onde estão localizados?
• Que assuntos e tópicos emergem, se disseminam e desaparecem nos eco-sistemas
sociais digitais?
• Que indivíduos e grupos promovem e suprimem estes assuntos e tópicos?
• Qual a polaridade (positiva, negativa ou neutra) das opiniões emitidas na rede sobre
assuntos, pessoas, empresas, etc.?
Um Exemplo: Observatório da Web
Um exemplo de como a identificação de entidades é uma tarefa importante para
a análise de redes sociais online é o Observatório das Eleições 20105 , que é uma instância do Observatório da Web [104], projeto desenvolvido no âmbito do InWeb (Instituto
Nacional de Ciência e Tecnologia para a Web).
Este observatório foi desenvolvido para monitorar, em tempo real, o que estava
sendo veiculado sobre as eleições de 2010 nas várias mídias e pelos vários usuários da
Web. O seu objetivo era ajudar a traçar um panorama do cenário eleitoral do ponto de
vista das informações e das opiniões 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 inéditas de captura e análise de dados baseadas
em código livre ou aberto.
As entidades correlatas ao contexto das eleições foram o alvo principal do monitoramento. Isso incluía além dos candidatos à presidência, políticos com influência na
eleição, 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 conteúdo das fontes observadas.
A partir da identificação das entidades no textos coletados em tempo real, é possível gerar uma série de produtos de análise e visualização. 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 Visualização de Dados Gerados a Partir da Identificação
de Entidades no Observatório das Eleições.
No observatório, antes da extração propriamente dita, é realizado um préprocessamento dos textos coletados, incluindo a padronização da codificação dos caracteres, a eliminação de código HTML, cabeçalhos e anúncios de páginas coletadas através
de feeds, e o uso de métodos tradicionais de pré-processamento de textos [83] tais como a
remoção de stop words (palavras de pouco valor informacional como artigos, preposições
e conjunções) e o stemming, que consiste na extração dos radicais das palavras do texto.
A identificação de entidades nos textos é feita através da ferramenta Illinois Named Entity
Tagger [98], que utiliza técnicas de processamento de linguagem natural para identificar
referências a entidades (pessoas, organizações, locais, etc.) em texto livre. Apos a fase de
identificação, segue-se uma fase de desambiguação de entidades. Isso é necessário porque os métodos identificação de entidades têm dificuldade, em geral, de diferenciar “José
Serra” de “Serra da Piedade”, ou “Lula presidente” de “Lula Molusco”. Para isso, um
método de classificação foi utilizado para aprender a associar entidades a determinados
contextos.
A Figura 2.16 ilustra um RSS feed processado para identificação de entidades
pelo Observatório das Eleições. As tags são usadas como identificadores para distinguir
as duas entidades em todos os textos processados.
A pré-candidata do PT à Presidência da República <Person2> Dilma Rousseff </Person2> , quer juntar ao seu redor o maior número de legendas que
hoje estão na base aliada do presidente <Person1> Luiz Inácio Lula da Silva
</Person1>
Figura 2.16. Exemplo de RSS Feed com Entidades Identificadas no Observatório
das Eleições
91
2.5.2. Identificação de Entidades
O problema de identificação de entidades nomeadas (Named Entity Recognition –
NER) consiste em encontrar palavras que ocorrem em um documento ou trecho de texto
não estruturado e que façam referência a entidades do mundo real. Este problema tem
sido estudado em vários contexto como identificação de nomes de pessoas e companhias
em notícias, identificação de genes e proteínas e publicações biomédicas, etc. [48]. A
Figura 2.17(a) ilustra o resultado típico da aplicação de um método de extração de entidades.
<pessoa> Odorico Paraguaçu <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 inteligência. Dotado de
uma habilidade incrível com as palavras fruto de seu curso na <organização> Universidade de Sourbone </organização>), cativava as massas numa época em que os
comícios não tinham nem fanfarra, quanto mais bandas completas.6
(a)
Odorico
pessoa
Paraguaçu
foi
pessoa
outro
prefeito
cargo
(b)
eterno
de
outro outro
Sucupira
local
Figura 2.17. Exemplo de um trecho de texto com entidades identificadas (a) e
como uma sequência rotulada (b)
Uma abordagem comum para o problema de NER é a de rotulamento de sequências. Um documento é representado como uma sequência x de tokens x1 , . . . , xn e um
classificador associa x a uma sequência paralela de rótulos y = y1 , . . . , yN , onde cada yi
é um rótulo pertencente a um conjunto Y . Uma atribuição correta dos rótulos permite a
identificação direta das entidades. Por exemplo, na sequência ilustrada na Figura 2.17(b),
cada token recebe um rótulo, sendo que um rótulo especial outro é associado aos tokens
que não são partes de nomes de entidades.
A construção do classificador pode ser feita usando técnicas de aprendizagem de
máquina, ou seja, utilizando dados de treinamento que representam exemplos de mapeamento de sequências x para sequências y. Isso é feito, em geral, através de documentos
manualmente anotados de forma similar ao que está ilustrado na Figura 2.17(b). Estes classificadores são gerados pelo no aprendizado de modelos sequenciais tais como
Hidden Markov Models [58] ou Conditional Random Fields [74] ou suas variações (por
exemplo, [49]).
2.5.3. Resolução de Entidades
Uma vez que as referências a entidades são identificadas em um certo corpus,
algumas aplicações podem requerer ainda que sejam estabelecidas correspondências entre
referências distintas que se refiram a uma mesma entidade do mundo real. Este problema
é conhecido como Resolução de Entidades [31].
Existem na realidade dois subproblemas relacionados ao problema de resolução
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 território é inteiramente
recoberto pela Floresta Amazônica. É também berço de grandes nomes como <pessoa>Marina Silva</pessoa>, política, e <pessoa>Glória
Perez</pessoa>, novelista.
D2
Ao lado da então ministra da Casa Civil, <pessoa>Dilma Rousseff</pessoa>,
<pessoa>Lula</pessoa> acabou recebendo uma amostra do óleo na
<pessoa>Marina</pessoa> da <pessoa>Glória</pessoa>, no Rio, para
onde o evento foi transferido.
D3
A candidata <pessoa>Dilma</pessoa>, vencedora do primeiro turno das
eleições, 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 Identificadas (a) e
como uma Sequência Rotulada (b).
O primeiro subproblema consiste em determinar o conjunto de referências distintas no corpus que são utilizadas para se referir a mesma entidade no mundo real. Este
é caso de “Marina Silva” em D1 e “Marina” em D3 , e também de “Dilma Rousseff” em
D2 e “Dilma” em D3 . Este subproblema é conhecido como Identificação [31] ou Coreferência [68]. Note que este problema também pode ser causado por erros de escrita,
formatação, etc., ou mesmo pelo uso de apelidos (p.ex., “Dilma”) e anáforas (p.ex., “a
ministra”).
O segundo subproblema consiste em distinguir quando referências 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 também de “Glória Perez” em D3 e “Glória”
em D2 . Este problema é chamado de Desambiguação [31]. Note que neste caso específico o problema foi causado por uma falha do processo de identificação de entidades
em D2 . Tais problemas são comuns e, dependendo do domínio de aplicação, podem ser
exacerbados pelo uso de abreviações.
A solução do problema de resolução de entidades pode ser determinante para a
qualidade dos resultados obtidos a partir da análise das entidades extraídas. Por outro
lado, se neglicenciado, este problema pode comprometer o conhecimento derivado destes
resultados. Por exemplo, as análises realizadas pelo Observatório das Eleições poderiam
ser seriamente afetadas se referências ao candidato “José Serra” e à “Serra da Piedade”
não sofressem desambiguação.
Na literatura recente, o problema de resolução entidades tem sido tratado através
do cálculo da similaridade entre os atributos associados às entidades (no caso de bancos
de dados) [51] ou utilizando, quando possível, grafos de co-ocorrência de entidades [31].
Em corpora textuais, ferramentas linguísticas têm sido usadas para solução deste problema [96]. No caso do Observatório das Eleições, o problema foi tratado através de
uma solução simples baseada em classificação usando centroides [67], que neste caso são
usado para representar o contexto em que determinada entidade é tipicamente encontrada
93
em termos de vocabulário recorrente.
2.6. Bases de Dados Disponíveis na Web
Vários trabalhos que coletaram dados de redes sociais online oferecem disponibilizam os dados coletados para a comunidade acadêmica. A seguir, algumas bases contendo dados públicos disponíveis na Web são relacionadas.
• Dados sobre Orkut, Flickr, LiverJournal e YouTube. Foram utilizados no trabalho [87] e estão disponíveis em http://socialnetworks.mpi-sws.org/
data-imc2007.html
• Dados sobre os vídeos de duas categorias inteiras do YouTube. Coletados em
2007 e utilizados no artigo [41]. Disponível em http://an.kaist.ac.kr/
traces/IMC2007.html.
• Dados do Flickr coletados ao longo do tempo. Esses dados foram utilizados na
referência [86] e estão disponíveis em http://socialnetworks.mpi-sws.
org/data-wosn2008.html.
• Dados sobre a popularidade de vídeos do YouTube com registro do crescimento e
fontes dos acessos ao longo do tempo. Foram utilizados na referência [57] e estão
disponívis em http://vod.dcc.ufmg.br/traces/youtime/.
• Grafo completo contendo 55 milhões de usuários do Twitter e cerca de 1.8 bilhões
de tweets. Esses dados foram utilizados nas referências [40, 24] e estão disponíveis
no endereço http://twitter.mpi-sws.org/.
• Dados sobre o grafo de amizade e postagens de amostra de usuários do Facebook.
Utilizados na referência [111] e disponíveis em http://socialnetworks.
mpi-sws.org/data-wosn2009.html.
• Coleção de usuários do YouTube, manualmente classificados como spammers, promoters ou usuários legítimos. Esses dados foram utilizados nos seguintes trabalhos [26, 29, 75]. A base de dados está disponível em http://homepages.
dcc.ufmg.br/~fabricio/testcollectionsigir09.html.
• Coleção de dados do Del.icio.us e do Digg. Coleção utilizada em diferentes artigos e disponível em http://www.public.asu.edu/~mdechoud/
datasets.html.
2.7. Conclusões
Redes sociais online se tornaram extremamente populares e parte do nosso dia
a dia, causando o surgimento de uma nova onda de aplicações disponíveis na Web. A
cada dia, grandes quantidades de conteúdo são compartilhadas, e milhões de usuários
interagem através de elos sociais. Apesar de tanta popularidade, o estudo de redes sociais
ainda está em sua infância, já que estes ambientes estão ainda experimentando novas
tendências e enfrentando diversos novos problemas e desafios.
94
Redes sociais online compõem ambientes perfeitos para o estudo de vários temas
da computação, incluindo sistemas multimídia e interação humano-computador. Além
disso, por permitir que usuários criem conteúdo, aplicações de redes sociais vêm se tornando um tema chave em pesquisas relacionadas à organização e tratamento de grandes
quantidades de dados, além de constituírem um ambiente ideal para extração de conhecimento e aplicação de técnicas de mineração de dados.
Este trabalho oferece uma introdução ao pesquisador que pretende explorar o
tema. Inicialmente, foram apresentadas as principais características das redes sociais mais
populares atualmente. Em seguida, discutimos as principais métricas e tipos de análises
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 técnicas.
Agradecimentos
Este trabalho foi parcialmente financiado pelo Instituto Nacional de Ciência e Tecnologia para a Web (InWeb), pelo CNPq, FAPEMIG e UOL (www.uol.com.br).
Referências
[1] comscore: Americans viewed 12 billion videos online in may 2008. http://
www.comscore.com/press/release.asp?press=2324. Acessado em
Março/2010.
[2] Developer analytics. http://www.developeranalytics.com. Acessado
em Março/2010.
[3] Facebook application directory. http://www.facebook.com/apps. Acessado em Março/2010.
[4] Facebook platform. http://developers.facebook.com. Acessado em
Março/2010.
[5] Facebook Press Room, Statistics. http://www.facebook.com/press/
info.php?statistics. Acessado em Março/2010.
[6] Gnuplot. http://www.gnuplot.info/. Acessado em Agosto/2010.
[7] Google OpenSocial. http://code.google.com/apis/opensocial/.
Acessado em Março/2010.
[8] List of social network web sites. http://en.wikipedia.org/wiki/
List_of_social_networking_websites. Acessado em Março/2010.
[9] Matlab. http://www.mathworks.com/products/matlab/. Acessado
em Agosto/2010.
[10] Needle in a Haystack: Efficient Storage of Billions of Photos. Facebook Engineering Notes, http://tinyurl.com/cju2og. Acessado em Março/2010.
95
[11] New york times. a web site born in u.s. finds fans in brazil. http://
www.nytimes.com/2006/04/10/technology/10orkut.html. Acessado em Março/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 Março/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 835–844, 2007.
[17] R. Albert, H., Jeong, and A. Barabasi. Error and attack tolerance of complex
networks. Nature, 406(6794):378–382, 2000.
[18] R. Albert, H. Jeong, and A. Barabasi. Diameter of the world wide web. Nature,
401:130–131, 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):11149–11152, 2000.
[21] B. Williamson. Social network marketing: ad spending and usage. EMarketer
Report, 2007. http://tinyurl.com/2449xx. Acessado em Março/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 761–764, 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. Gonçalves. Characterization and analysis of user profiles in online video sharing systems.
Journal of Information and Data Management, 1(2):115–129, 2010.
96
[26] F. Benevenuto, T. Rodrigues, V. Almeida, J. Almeida, and M. Gonçalves. Detecting
spammers and content promoters in online video social networks. In Int’l ACM
Conference on Research and Development in Information Retrieval (SIGIR), pages
620–627, 2009.
[27] F. Benevenuto, T. Rodrigues, V. Almeida, J. Almeida, M. Gonçalves, 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):1–25, 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 45–52, 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 49–62, 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 conflicting 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. Multitube–where web 2.0 and multimedia could meet. IEEE MultiMedia,
14(1):9–13, 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: Definition, history, and scholarship.
Journal of Computer-Mediated Communication, 13(1-2), 2007.
[36] V. Braitenberg and A. Schüz. 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):107–117, 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:309–320,
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 945–954, 2009.
97
[40] M. Cha, H. Haddadi, F. Benevenuto, and K. Gummadi. Measuring user influence
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 world’s largest user generated content video system. In
ACM SIGCOMM Conference on Internet Measurement (IMC), pages 1–14, 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 721–730, 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 3123–3128, 2008.
[44] P. Chatterjee, D. L. Hoffman, and T. P. Novak. Modeling the clickstream: implications for web-based advertising efforts. Marketing Science, 22(4):520–541,
2003.
[45] D. Chau, Pandit, S. Wang, and C. Faloutsos. Parallel crawling for online social
networks. In World Wide Web Conference (WWW), pages 1283–1284, 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 57–70, 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
89–98, 2004.
[49] E. Cortez, A. S. da Silva, M. A. Gonçalves, 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 Int’l
Workshop on Quality of Service (IWQoS), 2008.
[51] J. de Freitas, G. L. Pappa, A. S. da Silva, M. A. Gonçalves, 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 1–8, 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
344–354, 2006.
98
[53] F. Duarte, B. Mattos, A. Bestavros, V. Almeida, and J. Almeida. Traffic 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):68–74, 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 251–262, 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 584–589, 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 482–490, 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 traffic characterization: A view
from the edge. In ACM SIGCOMM Conference on Internet Measurement (IMC),
pages 15–28, 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 influenza epidemics using search engine query data. Nature,
457:1012–4, 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 file-sharing workload. In ACM
Symposium on Operating Systems Principles (SOSP), 2003.
[66] Z. Gyöngyi, H. Garcia-Molina, and J. Pedersen. Combating web spam with trustrank. In Int’l. Conference on Very Large Data Bases (VLDB), pages 576–587,
2004.
99
[67] E.-H. Han and G. Karypis. Centroid-based document classification: Analysis and
experimental results. In Proceedings of the 4th European Conference on Principles
of Data Mining and Knowledge Discovery, pages 424–431, 2000.
[68] J. Hobbs. Coherence and coreference*. Cognitive science, 3(1):67–90, 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 1027–1036, 2008.
[70] R. King. When your social sites need networking, BusinessWeek, 2007. http:
//tinyurl.com/o4myvu. Acessado em Março/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 Int’l 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 Int’l World Wide Web Conference (WWW), 2010.
[74] J. D. Lafferty, A. McCallum, and F. C. N. Pereira. Conditional random fields:
Probabilistic models for segmenting and labeling sequence data. In Proceedings
of the Eighteenth International Conference on Machine Learning, ICML’01, pages
282–289, 2001.
[75] H. Langbehn, S. Ricci, M. Gonçalves, 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):1–16,
2010.
[76] S. Lee, P. Kim, and H. Jeong. Statistical properties of sampled networks. Physical
Review E, 73(30):102–109, 2006.
[77] K. Lerman. Social information processing in news aggregation. IEEE Internet
Computing, 11(6):16–28, 2007.
[78] J. Leskovec, L. A. Adamic, and B. A. Huberman. The dynamics of viral marketing.
ACM Transactions on the Web (TWEB), 1(1):228–237, 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: Definition, properties, and implications. Internet Mathematics, 2(4), 2005.
[81] L. Lovász. Random Walks on Graphs: A Survey. Combinatorics, 2:1–46, 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. Schütze. Introduction to Information Retrieval. Cambridge University Press., 2008.
[84] S. Milgram. The small world problem. Psychology Today, 2:60–67, 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 flickr social network. In ACM SIGCOMM Workshop on Social Networks
(WOSN), pages 25–30, 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 29–42, 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 43–56, 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 63–75, 2009.
[91] M. Newman. The structure of scientific collaboration networks. 98(2):404–409,
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:167–256, 2003.
[94] M. Newman. Coauthorship networks and patterns of scientific collaboration.
101(1):5200–5205, 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 Artificial Intelligence, pages 1689–1694, 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
955–964, 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 147–155, 2009.
[99] N. O. Report. Social networks & blogs now 4th most popular online activity, 2009.
http://tinyurl.com/cfzjlt. Acessado em Março/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. WWW’09 Keynote, 2009.
http://tinyurl.com/mmmaa7. Acessado em Março/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 851–860, 2010.
[104] W. Santos, G. Pappa, W. Meira Jr., D. Guedes, A. Veloso, V. Almeida, A. Pereira,
P. Guerra, A. Silva, F. Mourão, T. Magalhães, F. Machado, L. Cherchiglia, L. Simões, 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. Observatório da web: Uma plataforma de monitoração, síntese e visualização de eventos massivos em tempo real.
In Anais do XXXVII Seminário Integrado de Hardware e Software, SEMISH’10,
pages 110–120, 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 35–48, 2009.
[106] S. Schroeder. 20 ways to aggregate your social networking profiles, Mashable,
2007. http://tinyurl.com/2ceus4. Acessado em Março/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 1041–1044, 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 43–48, 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 (WOSN’09), 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 37–42, 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: finding topic-sensitive influential twitterers. In ACM international conference on Web search and data mining
(WSDM), pages 261–270, 2010.
[117] C. Williamson. On filter effects in web caching hierarchies. ACM Transactions on
Internet Technology (TOIT), 2(1):47–77, 2002.
[118] J. Zhang, M. Ackerman, and L. Adamic. Expertise networks in online communities: Structure and algorithms. In World Wide Web Conference (WWW), pages
221–230, 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.
Capítulo
3
Web das Coisas: Conectando Dispositivos Físicos
ao Mundo Digital
Tiago C. de França, Paulo F. Pires, Luci Pirmez, Flávia 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 número de dispositivos físicos (chamados objetos
inteligentes) conectados a internet. Esses dispositivos podem ser sensores sem fio,
celulares ou qualquer outro aparelho eletrônico do cotidiano das pessoas. A Web das
Coisas (WoT, do inglês, Web of Things) propõe que os objetos inteligentes sejam
integrados a Web, permitindo, desta forma, que os usuários possam acessar tais objetos
através de URLs, realizando pesquisas e reutilizando os recursos dos mesmos em
aplicações Web chamadas mashups. Este minicurso introduz os conceitos e tecnologias
da WoT e apresenta a arquitetura de software subjacente atualmente empregada. Em
seguida, são apresentados exemplos práticos de construção de aplicações baseadas no
paradigma da WoT utilizando a plataforma Sun SPOT.
104
3.1. Introdução
Graças ao impressionante progresso no campo de dispositivos embarcados, objetos
físicos tais como eletrodomésticos, máquinas industriais, sensores sem fio e atuadores
podem atualmente se conectar a internet. Exemplos desses pequenos e versáteis
dispositivos são: Chumby [Chumby 2011], Gumstix [Gumstix 2011], Sun SPOTs [Sun
2011], Ploggs [Ploggs 2011], Nabaztag [Nabaztag 2011], Pokens [Pokens 2011], etc.
Segundo a Aliança IPSO (do inglês, IP for Smart Objects), em um futuro
próximo um grande número 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 estarão conectados diretamente a internet. A
conexão desses objetos do dia a dia com a internet é denominada Internet das Coisas (do
inglês, Internet of Things - IoT) [Duquennoy 2009]. A IoT oferece novas oportunidades
de projetos para aplicações interativas as quais, além de conter documentos estáticos,
conterão informação em tempo real referentes a lugares e objetos do mundo físico.
Recentemente surgiu um novo paradigma de desenvolvimento de aplicações
inspirado na idéia da IoT, conhecido como Web das Coisas (do inglês Web of Things WoT) [Duquennoy 2009], [Guinard 2010]. Esse novo conceito se baseia no uso de
protocolos e padrões amplamente aceitos e já em uso na Web tradicional, tais como
HTTP (Hypertext Transfer Protocol) e URIs (do inglês, Uniform Resource Identifier).
O objetivo da WoT é alavancar a visão de conectividade entre o mundo físico e o
mundo digital, fazendo com que a Web atual passe a englobar também objetos do
mundo físico (chamados objetos inteligentes, do inglês “smart things”) os quais
passarão a ser tratados da mesma forma que qualquer outro recurso Web.
Na WoT, o protocolo HTTP não é utilizado apenas como protocolo de
comunicação para transportar dados formatados em conformidade com alguma
especificação (como no caso das tecnologias de serviços Web). Em vez disso, o
protocolo HTTP é utilizado como mecanismo de suporte padrão a toda interação com os
objetos inteligentes. Essa interação ocorre por meio dos principais métodos (GET,
POST, PUT e DELETE) desse protocolo, os quais permitem que as funcionalidades dos
objetos sejam expostas em interfaces Web bem definidas. Tais interfaces são
construídas de acordo com os princípios REST (do inglês, Representational State
Transfer) [Fielding 2000], [Guinard e Trifa 2009] os quais permitem que os serviços
dos objetos inteligentes sejam expostos como recurso em uma abordagem ROA (do
inglês, Resource-Oriented Architecture) [Guo 2010], [Mayer 2010]. Além da
padronização e simplificação no processo de desenvolvimento, a utilização do protocolo
HTTP também elimina problemas de compatibilidade entre diferentes fabricantes,
protocolos e formatos específicos [Duquennoy 2009].
A realização da visão 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 extensão é obtida através da
utilização do protocolo HTTP e dos princípios REST na criação de APIs (do inglês,
Application Programming Interface) RESTful que façam com os objetos inteligentes se
tornem recursos Web. A forma como tais objetos inteligentes são 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. Além disso, através do uso de plataformas de middleware, por exemplo, podem
ser providos serviços no topo dos recursos conectados a Web, de modo a facilitar a
rápida combinação de múltiplos recursos para criar aplicações de valor agregado
denominadas mashups físicos [Delicato et al. 2010], [Guinard et al. 2009]. Esses
mashups são aplicações ad-hoc da Web 2.0 que permitem colaboração e
compartilhamento de informações através da composição de recursos disponíveis na
Web [Bezerra et al. 2009].
O objetivo geral deste minicurso é apresentar o estado da arte no
desenvolvimento de aplicações para a “Web das Coisas”. Seus objetivos específicos
são: (i) fornecer uma visão geral do conceito de “Internet das Coisas” e sua evolução
para a “Web das Coisas”; (ii) apresentar a arquitetura de software atualmente
empregada nos projetos de “Web das Coisas”; (iii) apresentar soluções atuais da WoT;
e, por fim, (iv) apresentar como aplicações 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 próximo tanto computadores como objetos físicos estejam
conectados a internet [Atzori et al. 2010]. Essa interconexão de dispositivos na internet,
chamada Internet das Coisas (IoT, do inglês 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 propõe a adoção dos padrões Web a fim de oferecer uma base comum
para que diferentes tipos de dispositivos possam ser beneficiados pelas tecnologias
existentes na Web, além de facilitar o desenvolvimento de aplicativos para tais
dispositivos. Nesta Seção são descritas as principais características da Internet das
Coisas, seguida da apresentação da Web das Coisas.
3.2.1. Internet das Coisas
Atualmente, a Internet das Coisas (IoT) vem ganhando grande destaque no cenário das
telecomunicações e está sendo considerada a revolução tecnológica que representa o
futuro da computação e comunicação [Tan e Wang 2010], [Atzori et al. 2010]. Devido a
importância da IoT, o Conselho Nacional de Inteligência dos EUA (NIC) a considera
como uma das seis tecnologias civis mais promissoras e que mais impactarão a nação
no futuro próximo. O NIC prevê que em 2025 todos os objetos do cotidiano (por
exemplo, embalagens de alimento, documentos e móveis) poderão estar conectados a
internet [NIC 2008].
Graças ao paradigma IoT, estima-se que uma grande quantidade de objetos
estarão conectados à internet, se tornando os maiores emissores e receptores de tráfego
da rede. Esses objetos podem ser quaisquer dispositivos, tais como eletrodomésticos,
pneus, sensores, atuadores, telefones celulares, entre outros, que possam ser
identificados e interligados a internet para trocar informações e tomar decisões 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 dimensões do mundo das tecnologias da
106
comunicação e informação da internet no futuro. Nessa figura é possível observar “o
que” pode ser conectado a internet, “quando” pode ser conectado e “onde” pode se
conectar.
Obviamente, a ampla difusão do paradigma IoT acarretará um forte impacto na
vida cotidiana dos usuários. Isso ocorrerá porque diversas aplicações estarão a
disposição desses usuários, entre elas: aplicações de controle de ambiente; aplicações de
assistência a vida em ambientes de saúde; aplicações de automação e produção
industrial, logística, segurança, entre outras [Atzori et al. 2010], [Yun e Yuxin, 2010].
As mudanças proporcionadas pela IoT também trarão novas oportunidades de negócio
que, impulsionadas pelas demandas da população, contribuirão de maneira inestimável
para a economia [ITU Internet Reports 2005], [Tan e Wang 2010], [Yongjia 2010].
Figura 3.1 - Uma Nova Dimensão, adaptado de [ITU Internet Reports 2005]
O termo IoT recebeu diferentes definições na literatura. Algumas definições 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 definições focaram no termo genérico
“coisas” e as pesquisas que focam nesse termo buscam a integração de objetos em um
arcabouço comum. Também surgiram definições que focaram em questões semânticas,
observando a IoT do ponto de vista da comunicação entre dispositivos distintos. De
fato, para a TIC (Tecnologia da Informação e Comunicação), a expressão composta
“Internet das Coisas” representa uma rede mundial de objetos heterogêneos e
endereçáveis, interligados e se comunicando através de protocolos de comunicação
padronizados. A Figura 3.2 ilustra o fato exposto acima, de que o paradigma da IoT
pode ser visto de acordo com três visões principais: uma focada nas coisas, outra
focada na semântica 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 comunicação [Atzori et. al
2010]. Por outro lado, os trabalhos que apresentam propostas focadas na semântica dos
objetos da IoT são importantes devido a grande quantidade de itens que estarão
conectados a internet em um futuro próximo. Tais trabalhos apresentam propostas que
estão focadas na representação, armazenamento, interconexão, pesquisa e organização
da informação gerada na IoT, buscando soluções para a modelagem das descrições que
permitam um tratamento adequado para os dados gerados pelos objetos [Atzori et al.
2010].
107
Os trabalhos que focam na visão orientada a internet procuram criar modelos e
técnicas para a interoperabilidade dos dispositivos em rede. Um exemplo é o padrão
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 visões [Atzori et
al. 2010]
Apesar de existirem diversos trabalhos na literatura que tratam temas
relacionados à IoT, ainda é necessário superar uma série de desafios tecnológicos e
sociais para que tal paradigma seja amplamente utilizado e difundido. Um tipo de
desafio tecnológico está relacionado com os baixos recursos computacionais e de
energia dos dispositivos da IoT. Portanto, os trabalhos nessa área, além de apresentarem
propostas que sejam escaláveis, dado que será potencialmente enorme o número de
dispositivos que farão parte da IoT, precisam também apresentar soluções que utilizem
os recursos dos dispositivos de forma eficiente. Um outro tipo de desafio consiste na
definição de modelos de desenvolvimento de aplicações que tratem questões tais como
a padronização do acesso aos serviços e informações oferecidos pelos dispositivos,
segurança e privacidade, modelo de programação, etc. O paradigma Web das Coisas,
descrito na seção a seguir, se preocupa em apresentar soluções para esse tipo de desafio.
3.2.2. Web das Coisas
A inclusão de dispositivos físicos e aparelhos eletrônicos (redes de sensores sem fio,
telefones celulares, etc.) na internet traz consigo inúmeras possibilidades de novas
aplicações, as quais podem utilizar as informações e serviços desses dispositivos com
diferentes propósitos. Entretanto, a maioria dos objetos são atualmente conectados a
internet (e algumas vezes a Web) utilizando softwares e interfaces proprietárias, o que
108
torna onerosa a criação de aplicações que integram dados e serviços providos por
diferentes dispositivos [Guinard 2010]. Além disso, o uso das linguagens, protocolos e
interfaces específicas de cada tipo de dispositivo também faz com que o
desenvolvimento de aplicativos para os mesmos seja uma tarefa complexa, pois é
necessário que o desenvolvedor possua conhecimento especializado para cada
dispositivo utilizado no projeto. Dessa forma, para facilitar o desenvolvimento de
serviços no topo desses dispositivos, permitindo também que os serviços e os dados dos
mesmos sejam compostos em diferentes aplicações, é necessário utilizar uma linguagem
comum a diferentes dispositivos [Guinard e Trifa 2009], [Guinard 2010].
A WoT propõe que os protocolos Web sejam utilizados como linguagem comum
para integração de dispositivos físicos no meio digital. A inclusão dos dispositivos
físicos na Web permite que os seus dados e serviços sejam reutilizados em diferentes
aplicações [Duquennoy et al. 2009]. A integração dos dispositivos a Web ocorre no
nível de aplicação, isto é, acima da conectividade de rede [Guinard et al. 2010]. Tal
integração permite que ferramentas e técnicas da Web (por exemplo, navegadores,
ferramentas de busca e sistemas de cache), linguagens da Web (por exemplo, HTML e
JavaScript) e técnicas de interação com o usuário (por exemplo, navegação, vinculação
e bookmarking) possam ser aplicadas para objetos do mundo real [Guinard e Trifa
2009], [Guinard et al. 2010]. Desta forma, a WoT possibilita a agregação de valor às
informações providas pelos objetos físicos através da utilização de todos os recursos
disponíveis na Web (por exemplo, cache, balanceamento de carga, indexação e
pesquisa), o que por sua vez alavanca a concretização da visão da IoT [Guinard e Trifa
2009].
Atualmente é possível encontrar trabalhos que apresentam propostas de sistemas
que integram objetos com a internet. Um exemplo são os projetos que promovem a
integração 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 através de serviços Web. Porém,
essas abordagens não são tão 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 físico pode enviar
seus dados para pontos descentralizados e esses dados podem ser utilizado e reutilizados
em diferentes aplicações [Guinard 2010].
Uma possível abordagem para implementar o conceito de WoT são os padrões
WS-* (como o SOAP). Os WS-* geralmente utilizam o protocolo HTTP para realizar
tarefas de comunicação na pilha de protocolos utilizada pelos dispositivos. Nesse caso,
o HTTP é utilizado para transportar a mensagem SOAP (a qual é codificada em XML),
evitando assim possíveis 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 através do emprego dos padrões WS-* é alcançada através da
adição de uma camada de software nas aplicações. Tal adição implica uma maior
complexidade de software, não sendo, desta forma, a solução mais adequada para ser
aplicada em dispositivos com recursos limitados [Guinard e Trifa 2009].
Diferentemente da abordagem WS-*, a Web das Coisas propõe que a Web atual
seja estendida de modo a incorporar objetos e dispositivos embarcados do mundo real
como qualquer outro serviço Web. A extensão da Web proposta pela WoT é realizada
109
através da adoção do protocolo HTTP como protocolo de aplicação. Isso significa que
esse protocolo deve ser utilizado como interface base para realizar toda a interação com
os recursos disponíveis [Guinard e Trifa 2009], [Shelby 2010], e não apenas para
transportar passivamente as mensagens trocadas.
Uma abordagem que está sendo bastante utilizada juntamente com protocolo
HTTP na criação de sistemas distribuídos na Web é o estilo arquitetural REST [Mayer
2010] (do inglês, Representation State Transfer). Esse estilo arquitetural pode ser
empregado para desenvolver sistemas que seguem uma arquitetura orientada a recursos
(ROA, do inglês Resource Oriented Architecture) [Mayer 2010]. O REST define um
conjunto de princípios que, ao serem adotados, dão origem a sistemas RESTful. Os
sistemas RESTful são menos acoplados, mais leves, eficientes e flexíveis do que os
sistemas Web baseados em WS-* e podem ser facilmente reutilizados [Guinard e Trifa
2009], [Sandoval 2009]. Além disso, os princípios REST podem ser mapeados nos
métodos básicos do protocolo HTTP (GET, POST, UPDATE e DELETE) para criar
sistemas CRUD (Create, Read, Update, Delete) de uma aplicação RESTful. Os recursos
dos sistemas RESTful são identificados e encapsulados por um URI. A utilização do
protocolo HTTP como protocolo de aplicação admite que os recursos possuam várias
representações e permite que os clientes selecionem, dentre as representações
disponíveis, aquela que melhor se adéqüe as necessidades da aplicação [Sandoval
2009]. Essas características fizeram do REST a opção mais adequada para construção
de APIs Web para acesso a objetos do mundo real [Guinard e Trifa 2009], [Ostermaier
et al. 2010].
A Web das Coisas emprega os princípios REST para disponibilizar as
funcionalidades dos dispositivos inteligentes na Web utilizando duas abordagens. Na
primeira abordagem, são implantados servidores Web embarcados em dispositivos
inteligentes e as funcionalidades desses dispositivos são disponibilizadas na forma de
recursos RESTful. Na segunda abordagem, quando um objeto inteligente não possui
recursos de hardware suficientes para executar um servidor embarcado, é possível
utilizar outro dispositivo como ponte para disponibilizar as funcionalidades do
dispositivo inteligente na Web através de uma interface RESTful.
Embora a utilização de uma arquitetura RESTful permita que objetos físicos se
tornem parte da Web, a WoT também propõe a utilização de mecanismos que foquem
no desenvolvimento e prototipagem de aplicativos interativos que façam com que os
recursos dos objetos físicos sejam utilizados em diferentes aplicações [Guinard e Trifa
2009], [Guinard 2010]. Nesse sentido, os trabalhos da WoT propõem que sejam
utilizadas aplicações da Web 2.0 chamadas mashups. Os mashups são aplicativos
criados a partir da composição de recursos Web. Como qualquer aplicação da Web 2.0,
os mashups são construídos com base em um conjunto de tecnologias (por exemplo,
Atom [Atom 2011]) que dão suporte ao desenvolvimento de interfaces altamente
interativas e simples ao usuário, semelhante ao que acontece com aplicativos desktop
[Bezerra et al. 2009]. Os mashups criados a partir da composição de dados e serviços de
dispositivos físicos com outros recursos Web são chamados mashups físicos. Esse tipo
de mashup foca no reuso e prototipagem de objetos físicos do mundo real em diferentes
aplicações. [Duquennoy et al. 2009], [Guinard 2010].
Logo, é possível resumir que na WoT o protocolo HTTP é adotado como
linguagem comum entre diferentes dispositivos e o seu emprego em conformidade com
110
o princípio 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 aplicações. A
função dos mashups físicos é permitir que os usuários construam aplicações formadas a
partir da composição dos recursos e dados desses dispositivos os quais se tornam
passíveis de serem combinados e recombinados em tempo de execução para resolverem
requisitos de mais alto nível.
3.3. Concretizando a Web das Coisas: REST & ROA
Para uma melhor compreensão da Web das Coisas, esta Seção apresenta os conceitos
envolvidos com o desenvolvimento de aplicações Web RESTful. Além dos conceitos,
também é apresentada uma abordagem prática da aplicação dos mesmos no contexto de
aplicações RESTful.
3.3.1. REST
O termo REST, descrito por Roy Fielding (2000) em sua tese de doutorado, define um
conjunto de princípios que podem ser aplicados na construção 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 são utilizados na concepção da implementação de
sistemas focados em recursos [Mayer 2010]. Um recurso pode ser qualquer componente
de uma aplicação que seja importante o suficiente para ser endereçado na Web através
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 instituição, ou mesmo cada curso dessa
instituição, os quais possuem disciplinas que por sua vez são subrecursos do curso e
assim por diante. Esta Subseção aborda os princípios REST, o modelo de arquitetura
orientada a recursos e a construção de sistemas RESTful.
3.3.1.1. Princípios REST
Os princípios 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 aplicação para sistemas de hipermídia,
colaborativos e distribuídos, baseado no modelo de comunicação requisição/resposta
que pode ser utilizado para realizar diferentes tarefas. O HTTP é um protocolo sem
manutenção 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 requisições. O HTTP define um conjunto de
métodos que são utilizados nas requisições, dentre os quais se destacam os métodos
GET, POST, PUT e DELETE [Lucchi et al. 2008]. Outra característica importante
desse protocolo é a negociação da representação de dados, a qual pode ser feita através
da utilização dos cabeçalhos (por exemplo, Accept ou Accept-Language) da requisição.
A Figura 3.3 mostra o formato de uma requisição HTTP. Nessa figura é possível
observar os campos do cabeçalho de uma requisição HTTP contendo o método GET, o
caminho (path) do recurso solicitado e a versão do protocolo HTTP. Uma requisição
111
contendo o método GET pode possuir dados incluídos no path da requisição. Esses
dados são separados do path do recurso pelo caractere de interrogação “?” e diferentes
dados são separados pelo caractere “&” (cada dado possui uma variável e um valor os
quais são separados pelo sinal de igualdade). O campo Host especifica o endereço do
servidor na internet e o número da porta do recurso solicitado. O campo User-Agent
contém informações sobre o agente de usuário (nessa figura, o agente é o mozilla/5.0)
que originou a requisição. O campo Accept indica quais representações o cliente espera
receber (nesse caso as representações podem ser HTML, XML OU JSON [JSON
1999]). O campo Connection permite que o emissor da requisição especifique algumas
informações concernentes a uma requisição em particular (o valor keep-alive que
aparece na requisição apresentada na figura é utilizado para indicar que uma conexão do
protocolo de transporte deve permanecer aberta para ser reusada no envio e recepção de
múltiplas requisições e respostas). Para maiores detalhes sobre o protocolo HTTP ver
[RFC2068 1997] e [RFC2616 1999].
Figura 3.3 - Requisição HTTP contendo o método GET
Como o HTTP possibilita a utilização de diferentes representações, as aplicações
podem ser construídas independentemente da forma como os dados serão transferidos
[RFC2616 1999]. As características do HTTP fornecem o suporte necessário para a
realização dos princípios REST. Esses princípios são: identificação única e global para
os recursos, uma interface uniforme de acesso aos recursos, endereçabilidade dos
recursos (permite que os mesmos sejam vinculados), suporte a múltiplas e
independentes representações para o recurso e interação sem manutenção de estado
[Sandoval 2009].
O princípio da identificação dos recursos está relacionado ao uso de URIs que
fornecem endereços únicos e globais para identificação de um recurso [Pautasso et al.
2008]. URIs também são utilizadas para indicar o escopo da informação provendo
meios que permitem a navegação 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
requisição da Figura 3.3 indica que light é um subrecurso de spot-1265. Uma URI
também é utilizada para endereçar a interação entre recursos sem a necessidade do uso
do corpo da resposta. No contexto da Web, o uso de URIs possibilita a utilização de
links para recursos os quais podem ser estabelecidos utilizando esquemas bem
conhecidos [Mayer 2010].
O princípio da interface uniforme define que o servidor deve ser capaz de
determinar o que deve ser feito ao receber uma requisição HTTP em uma URI apenas
112
observando do método presente nessa requisição [Pautasso et al. 2008], [Mayer 2010].
Os métodos das requisições HTTP (GET, POST, PUT ou DELETE) são utilizados para
indicar ao provedor do recurso a ação que deve ser realizada. Assim, cada método
representa uma ação específica sobre o recurso, podendo ser executadas quatro ações
(operações): obter a representação de um recurso (GET), criar um novo recurso (POST),
alterar um recurso (PUT) e remover um recurso (DELETE). Essas operações
geralmente são descritas como sendo o CRUD (Create, Retrieve, Update e Delete) da
aplicação [Sandoval 2009]. Por exemplo, o método GET da requisição exemplificada na
Figura 3.3 indica ao servidor (localizado em www.labnet.ufrj.br) que o cliente espera
receber uma representação do recurso “/light” o qual é subrecurso de “/spot-1265”. Essa
figura é um exemplo de uma requisição que está em conformidade com os princípios de
endereçabilidade e interface uniforme.
O princípio da vinculação de recursos está relacionado com o uso da
abordagem HATEOAS (do inglês, Hypermedia as Engine Of Application State). Nessa
abordagem, a vinculação dos recursos é realizada através de links que são 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 é possível graças a utilização de um esquema de nomes global que possibilita que
qualquer recurso Web seja ligado a outro. Tal característica permite que o servidor
ofereça links para que o cliente mude de um estado da aplicação para outro, tornando a
aplicação dinâmica. Ou seja, as aplicações são consideradas como uma máquina de
estado onde cada página representa um estado e os links representam todas as possíveis
transições de estado a partir do estado corrente. Sempre que possível, os links de
navegação entre recursos relacionados devem ser disponibilizados na representação do
primeiro recurso acessado. Por exemplo, considere um sistema de uma instituição de
ensino que possui um recurso chamado “lista_cursos”, o qual lista todos os cursos dessa
instituição quando tal recurso é acessado. O provedor do recurso deve oferecer links
criados a partir da URI de identificação de cada recurso que representa um curso da
instituição. Esses links são oferecidos com o objetivo de permitir que cada curso possa
ser acessado a partir da representação obtida do recurso “lista_cursos”.
O princípio da representação de um recurso define como serão os formatos
das mensagens trocadas entre cliente e servidor. A representação de um recurso
representa o valor do dado no momento em que foi recebida a requisição [Sandoval
2009]. Um recurso pode possuir várias representações. As opções de representações de
recurso permitem que o consumidor do recurso escolha, entre as representações
disponíveis, aquela que ele deseja receber. Exemplos de representações de recurso são o
XML, JSON, HTML, entre outros. A especificação das representações que o cliente
deseja receber podem ser passadas no campo Accept do cabeçalho HTTP. Por exemplo,
o campo Accept da requisição apresentada na Figura 3.3 indica três opções de
representações que o cliente espera receber, as quais são: text/html (indicando formato
HTML), application/xml (formato XML) e application/json (indicando formato JSON).
O último princípio REST define que um servidor deve ser stateless, ou seja, sem
estado. Esse princípio define que não pode haver manutenção de informações sobre o
usuário em sessões no lado do servidor. Assim, cada requisição enviada ao provedor do
recurso deve ter todas as informações necessárias para a sua compreensão. Se alguma
informação 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 sessões com informações para cada usuário ele
poderia ter seu desempenho afetado quando estivesse tratando de muitos acessos
concorrentes [Pautasso et al. 2008]. Além disso, esse princípio diminui a dependência
do cliente com relação ao provedor do recurso, pois as requisições submetidas são
independentes de um servidor específico. Um exemplo dessa situação ocorre quando
um cliente que recebeu um link ao acessar o recurso em um servidor, o qual ficou
inativo logo após responder ao cliente (por problemas de hardware, por exemplo) e foi
automaticamente substituído 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
usuário [Webber et al. 2010].
3.3.2. ROA
Apesar dos princípios REST terem sido apresentados neste minicurso juntamente com o
uso das estruturas de URI e dos mecanismos do HTTP, como também fazem muitos
outros autores ([Sandoval 2009], [Webber et al. 2010], [Mayer 2010]), o REST é
independe de tecnologia e seus princípios não estão obrigatoriamente interligados a
Web. O REST também não é um si uma arquitetura, mas possui termos genéricos que
podem ser utilizados para definir uma arquitetura. A falta de uma arquitetura que possa
ser empregada no desenvolvimento de aplicações que seguem os princípios REST pode
levar o desenvolvedor ou arquiteto de software a empregar de forma equivocada esses
princípios [Pautasso et al. 2008]. Por exemplo, as aplicações que empregam os
princípios REST podem se tornar um híbrido de REST com RPC (Remote Procedure
Call) [Richardson e Ruby 2007], [Pautasso et al. 2008], o que não é desejável.
Em 2007, Richardson e Ruby apresentaram uma arquitetura orientada a recursos
(do inglês, Resource-Oriented Architecture – ROA) especificando em detalhes como
empregar os princípios REST juntamente com as tecnologias da Web (HTTP e URI) em
um modelo de boas práticas que podem ser aplicadas no desenvolvimento de serviços
RESTful. Esta Subseção apresenta as principais características 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 correspondência
intuitiva com o recurso que elas identificam e a sua estrutura deve variar de forma
previsível. 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 são os subrecursos disponíveis
em um diretório da URI. Ou seja, ao observarem essas URIs, os clientes esperarão que
um dado de temperatura possa ser acessado a partir do diretório “rssf/temperatura” e
que um aluno (por exemplo, John) possa ser acessado a partir do diretório “alunos”.
Outra característica relacionada ao uso de URIs abordada em ROA diz respeito
ao relacionamento entre URIs e recursos. Um recurso deve possuir no mínimo uma
URI, mas nada impede que ele possua várias. Porém, sempre que possível, um recurso
deve possuir apenas uma URI. Isso porque, utilizar várias URIs para identificar o
mesmo recurso diminui a importância 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 várias URIs será mais difícil para um proxy HTTP, por onde passam as
requisições de uma rede, identificar se uma resposta contendo uma representação de um
114
recurso já está armazenada em seu cache. Do ponto de vista de um usuário, é mais
difícil associar a URI com um recurso quando este possui vários URIs.
3.3.2.2. Endereçabilidade
A propriedade ROA que define que um recurso deve ser endereçável 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 endereçabilidade
também é comum para as aplicações REST-RPC (aplicações que são um híbrido entre
REST e RPC), pois toda aplicação na Web precisa ser endereçável para poder ser
acessada. Richardson e Ruby (2007) apontaram que, para o usuário final, a
endereçabilidade é o aspecto mais importante das páginas ou serviços Web. Um recurso
endereçável pode ser acessado sempre que sua URI for utilizada na Web. Por exemplo,
esses recursos podem ser acessados através de links de hipertexto, ou mesmo quando a
URI é enviada de um usuário para outro através do e-mail. Ser endereçável também
permite que um documento enviado como resposta a uma requisição possa ser mantido
em cache nos proxies HTTP. Por exemplo, a página endereçada pela URI
http://www.labnet.nce.ufrj.br/projetos/webofthings pode ser mantida em cache para ser
devolvida como reposta a uma segunda requisição 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 aplicação RESTful deve ser sem estado, ROA define
como construir uma aplicação sem estado. Ser sem estado significa que uma requisição
HTTP deve ser independente de outras requisições anteriores. Para que isso seja
possível, as requisições HTTP devem ser auto-contidas, ou seja, uma requisição HTTP
deve ter em si toda informação necessária para que possa ser processada. Um servidor
que não mantém estado deve ser capaz de processar uma requisição sem precisar utilizar
informações de requisições anteriores. Se uma informação é suficientemente importante
para ser mantida como uma sessão no servidor, então esta informação deve ser
transformada em um recurso.
Apesar da expressão “sem estado”, ROA define dois tipos de estado: o estado da
aplicação, o qual deve ser mantido no cliente; e o estado do recurso, que deve ser
mantido no servidor. Um exemplo de estado da aplicação 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 parâmetros da consulta (geralmente esses
parâmetros são passados na URI) para o provedor do recurso. Ao receber o resultado da
consulta, o cliente poderá navegar entre páginas que mostram esses resultados. A
navegação ocorre quando o cliente passa de uma página contendo um subconjunto do
resultado da busca para outra página contendo outro subconjunto do resultado dessa
busca. Para tanto, o cliente mantém os parâmetros da consulta (as palavras chave
utilizadas) e a identificação da página atual na qual está localizado (página um, dois,
três, etc.). Ao navegar entre as páginas que contêm o resultado da busca, o cliente deve
incluir nas requisições os parâmetros da consulta e a página que está querendo acessar.
Dessa forma, o servidor só precisará tratar o estado da aplicação ao receber uma
requisição.
O estado do recurso deve ser mantido no servidor e deve ser igual para todos os
clientes. Por exemplo, quando um serviço de fotos da Web (como o Flickr) salva uma
115
nova foto, essa deve ser considerada um novo recurso. Essa figura ganha sua própria
URI e por isso poderá ser acessada nas próximas requisições. 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 permissões necessárias a apague.
3.3.2.4. Representação
As representações de um recurso podem ser enviadas tanto do cliente para o servidor
quanto do servidor para o cliente. As representações são 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 contrário do envio de uma
representação ocorre quando um cliente envia uma requisição para o servidor
interessado em obter uma representação de um recurso.
Quando o cliente deseja obter uma representação de um recurso do servidor,
esse cliente deve ser o mais explícito possível sobre qual representação deseja receber,
já que um recurso pode possuir mais de uma representação. ROA define duas formas de
especificar uma representação. A primeira forma é utilizar a URI para indicar qual é a
representação que o cliente deseja receber. Por exemplo, na requisição
http://twitter.com/statuses/public_timeline.{xml, json, rss} a URI é utilizada para
especificar o tipo de representação (XML, JSON ou RSS). Segundo Richardson e Ruby
(2007) utilizar URI é a forma mais explícita com que o cliente anuncia o tipo de
representação que ele espera receber. A segunda forma de especificar a representação é
utilizar os cabeçalhos Accept ou Accept-Language do protocolo HTTP para indicar ao
servidor a representação (XML ou JSON, por exemplo) ou o idioma (inglês, português,
etc.) do recurso que o cliente deseja receber.
3.3.2.5. Links e Conectividade
As representações dos recursos podem ser utilizadas para fornecer links para outros
recursos relacionados com o primeiro recurso acessado. Por exemplo, quando uma
busca é feita no serviço de busca do Google, a representação enviada para o cliente
contém links para cada resultado dessa consulta. O termo conectividade definido pelo
ROA é um sinônimo de HATEOAS, visto que o conceito é o mesmo: os recursos
podem conter links para outros recursos em suas representações.
3.3.2.6. Interface Uniforme
Em uma abordagem ROA as operações realizadas sobre os recursos são mapeadas nos
quatro métodos básicos do protocolo HTTP. O método GET é utilizado para recuperar a
representação de um recurso. A resposta a uma requisição GET inclui em seu corpo
uma representação do recurso. O método DELETE é utilizado para apagar um recurso
já existente. A resposta para uma requisição DELETE pode conter uma mensagem
indicando o status da operação solicitada ou apenas um código HTTP.
Em ROA os métodos utilizados para criar recursos são o PUT e o POST. O PUT
também é utilizado para atualizar um recurso já existente. Apesar do ROA especificar
as situações quando utilizar o método POST ou PUT para criar um novo recurso, muitos
sistemas RESTful utilizam apenas o POST com essa finalidade, visto que o método
PUT também é utilizado para atualizar um recurso [Sandoval 2009], [Webber et al.
116
2010]. As requisições PUT e POST podem conter em seu corpo uma representação do
recurso que será criado ou atualizado.
Além desses métodos, ROA define como utilizar os métodos HEAD e
OPTIONS do HTTP para obter informações sobre um recurso. O HEAD é utilizado
para obter metadados sobre um recurso sem que a resposta para uma requisição possua
a representação completa desse recurso. O OPTIONS é utilizado para verificar qual
método HTTP um recurso suporta. A resposta a uma requisição que contém o método
OPTIONS fornece o subconjunto da interface uniforme (HTTP) que este recurso
suporta através do cabeçalho Allow (por exemplo, Allow: GET, HEAD indicam que um
recurso suporta esses dois métodos).
Outra definição apresentada em ROA diz respeito aos efeitos que uma
requisição causa sobre um recurso. As requisições podem ser seguras (Safe) ou
idempotente. As requisições seguras são aquelas que são utilizadas para obter uma
representação de um recurso ou alguma outra informação sobre esse recurso sem causar
alteração no estado do servidor. Por exemplo, uma requisição GET pode ser enviada
centenas de vezes para obter uma representação de um recurso sem que nenhuma dessas
requisições cause alterações no recurso solicitado. As requisições que alteram o estado
do recurso são consideradas idempotente quando outras requisições iguais a primeira
não são capazes de causar uma alteração diferente a causada pela primeira requisição. O
conceito de idempotente é análogo ao da matemática, que utiliza esse termo para
indicar, por exemplo, que na multiplicação o zero é idempotente, pois qualquer número
multiplicado por zero sempre vai ser igual zero. Analogamente, uma requisição é
idempotente se a alteração ocasionada por essa requisição for mantida mesmo que
outras requisições semelhantes sejam enviadas em seguida. Por exemplo, ao apagar um
recurso ele continuará sem existir ainda que outras requisições DELETE sejam enviadas
para esse recurso.
3.3.3. Desenvolvimento de Serviços RESTful
Desenvolver um serviço Web RESTful não é diferente de desenvolver uma aplicação
Web tradicional. É necessário se preocupar com os requisitos do negócio, satisfazer as
necessidades dos usuários os quais manipularão os dados e lidar com limitações de
hardware e arquiteturas de software. A principal diferença, contudo, é que o foco reside
na identificação dos recursos e na abstração sobre as ações específicas a serem tomadas
por esses recursos.
É possível comparar o desenvolvimento de serviços Web RESTful com o
desenvolvimento orientado a objetos, pois existem algumas similaridades. No
desenvolvimento orientado a objetos é realizada a identificação dos dados que se deseja
representar juntamente com as ações que esse objeto pode realizar. Porém, as
similaridades acabam na definição da estrutura do dado, porque com os serviços Web
RESTful existem chamadas específicas que fazem parte do próprio protocolo de troca
de mensagens.
Os princípios do desenvolvimento de um serviço web RESTful podem ser
resumidos em quatro passos:
1. Levantamento de requisitos – Esse passo é similar às tradicionais práticas de
coleta de requisitos do desenvolvimento de software.
117
2. Identificação de recursos – Esse passo é similar ao desenvolvimento orientado
a objetos onde é realizada a identificação dos objetos, mas sem se preocupar
com a troca de mensagens entre objetos.
3. Definição de representação de recursos – Para viabilizar a troca de mensagens
entre clientes e servidores, é necessário definir o tipo de representação que será
usada. Geralmente o XML é utilizado, porém atualmente o formato JSON está
sendo cada vez mais popular [Sandoval 2009]. Porém, qualquer forma de
representação de recursos pode ser utilizada. Por exemplo, é possível utilizar o
XHTML ou qualquer outra forma binária de representação, embora seja
necessário deixar os requisitos serem os guias das escolhas sobre as
representações.
4. Definição de URI – O último passo é a definição do ponto de acesso ao recurso,
o qual consiste em especificar as URIs para que os clientes possam endereçar os
servidores a fim de trocar as representações de recursos.
Esse processo de desenvolvimento não é feito de forma estática, pelo contrário,
ele deve ser realizado através de passos iterativos os quais giram em torno dos recursos
[Sandoval 2009]. Por exemplo, pode acontecer que, durante a etapa de definição das
URIs, descobre-se que uma das repostas da URI não é coberta em um recurso
identificado. Nesse caso, deve-se voltar para definir um recurso adequado. Na prática, o
que acontece é que na maioria dos casos os recursos já definidos cobrem os requisitos
da aplicação, então basta combinar os recursos dentro de meta-recursos para tratar os
novos requisitos [Sandoval 2009].
3.3.3.1. Requisitos do Serviço Web de Exemplo
Para explicar melhor como funciona o desenvolvimento de serviços RESTful, é descrita
nesta Subseção a modelagem de um desses serviços. O serviço Web RESTful modelado
é uma aplicação Web de um laboratório de faculdade formado por um grupo de pessoas
(usuários) onde cada pessoa é responsável por um ou vários trabalhos. Esse simples
exemplo permite que seja apresentado o emprego dos princípios REST na prática, sem
preocupações com regras complexas de lógica do negócio.
A modelagem da aplicação é feita seguindo um processo orientado a objetos
[Sandoval 2009] e apenas o necessário para o entendimento do desenvolvimento de
sistemas RESTful é apresentado. Desta forma, várias questões existentes na modelagem
de software e assuntos afins foram omitidas.
Considere-se que, após a etapa inicial de levantamento de requisitos, foram
especificados os seguintes casos de uso da aplicação (essas são as principais
funcionalidades da aplicação): (i) um usuário pode criar uma conta com um nome de
usuário e uma senha; (ii) um usuário pode publicar os trabalhos sob sua
responsabilidade (uma publicação nesse caso consiste de uma página Web contendo
uma descrição do trabalho); (iii) qualquer pessoa, registrada ou não, pode ver os
trabalhos publicados na página do laboratório; (iv) qualquer pessoa, registrada ou não,
pode ver o perfil dos usuários; (v) os usuários cadastrados podem atualizar seus dados
(por exemplo, alterando sua senha); e (vi) qualquer pessoa pode pesquisar por termos
para encontrar publicações cadastradas.
118
Nas próximas Subseções são endereçados
desenvolvimento de nosso sistema Web de exemplo.
os
passos
seguintes
do
3.3.3.2. Identificação de Recursos
A especificação dos recursos dos serviços é uma etapa posterior a listagem dos casos de
uso. Com base nos requisitos, é possível perceber que serão necessários usuários e
trabalhos. O recurso usuários retorna um usuário ou uma lista de usuários. Além disso,
cada usuário pode publicar seus trabalhos. Assim, também serão necessários recursos
para um trabalho e para uma lista de trabalhos. Com base nessa observação os seguintes
recursos foram identificados: usuário, lista de usuário, trabalho e lista de trabalhos.
3.3.3.3. Representação de Recursos
Nesta etapa são definidas as representações dos recursos da aplicação. Sabe-se que o
protocolo HTTP permite a definição de qualquer tipo de representação (inclusive
formatos proprietários de dados). Contudo, é recomendado que sejam utilizadas
estruturas padrões, entre as quais estão o XML e o JSON. Logicamente, essa escolha
deve ser feita com base nos requisitos da aplicação, os quais irão ditar que tipo de
representações devem ser providas [Sandoval 2009]. Sempre que possível, é desejável
que sejam fornecidas várias representações para um mesmo recurso. Assim, os
consumidores do recurso poderão escolher dentre as opções disponíveis, aquela que é
mais adequada para ele.
O formato ideal de uma representação é uma questão de concepção. É
necessário considerar quais ações serão realizadas pelo servidor e a finalidade com a
qual os clientes utilizarão os recursos. Como regra geral, XML deve sempre ser
considerada como potencial representação, porque muitas linguagens oferecem
bibliotecas para processar streams XML [Sandoval 2009] (isso facilita o processamento
das mensagens e favorece a interoperabilidade entre as aplicações).
Após a definição do formato, é necessário definir o encadeamento (linkability)
das representações. O encadeamento das representações 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 usuário da lista.
O servidor do exemplo desta Subseção irá utilizar XML e JSON para representar
os recursos. A representação XML será utilizada pelo servidor para enviar uma
representação 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 representações
de recurso do servidor para o cliente.
A Figura 3.4 ilustra uma representação do recurso usuario no formato XML.
Apenas o conteúdo dos elementos nome, nome_usuario e senha são armazenados no
servidor, pois eles são parte de um recurso do usuário. O nome indica apenas o nome do
usuário. O nome_usuario deve ser único em todo sistema, pois ele será utilizado para
identificar o usuário. O elemento link é utilizado para apontar algum recurso no serviço
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
representação do recurso é solicitada. Por exemplo, o link para o usuário identificado
pelo nome_usuario “johnSmith” pode ser criado assim que o provedor do recurso
119
recebe uma requisição para criar esse novo usuario ou quando o provedor recebe uma
requisição para um recurso que lista todos os usuários do sistema.
<usuario>
<nome> john </nome>
<nome_usuario> johnSmith </nome_usuario>
<senha> abc123 </senha>
<link> /johnSmith </link>
</usuario>
Figura 3.4 - Representação XML do recurso usuario
A segunda estrutura criada define uma lista de usuários (Figura 3.5). O
documento XML da Figura 3.5 declara uma lista de usuários dentro do elemento
usuarios. Nessa estrutura é possível observar o conceito de encadeamento na prática:
com a lista de usuários é possível buscar por um usuário específico 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 representação contendo os usuários do sistema ele poderá
acessar cada usuario da lista através do seu respectivo link.
<usuarios>
<contagem> 50 </contagem>
<link></link>
<usuario>
<nome> john </nome>
<nome_usuario> johnSmith </nome_usuario>
<link> /johnSmith </link>
</usuario>
...
<usuario>
<nome> henrique </nome>
<nome_usuario> hribeiro </nome_usuario>
<senha> ribeir0123 </senha>
<link> /hribeiro </link>
</usuario>
</usuários >
Figura 3.5 - Representação XML do recurso lista de usuários
A estrutura da representação do recurso trabalho é utilizada na inclusão 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 usuário que postou a mensagem. Dependendo do que se pretende fazer com essa
representação, não será necessário passar todas as informações desse recurso para o
servidor. Por exemplo, quando um cliente cria um novo recurso trabalho, ele não 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 representação 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 representação da lista de trabalhos.
Essa estrutura contém uma coleção de trabalhos, e cada trabalho contém o usuário que o
postou.
120
<trabalho>
<id_trabalho> WebOfThings </id_trabalho>
<conteudo> A Web englobando o mundo físico... </conteudo>
<link> /webofthings </link>
<usuario>
<nome> tiago </nome>
<nome_usuario> tcruzfranca </nome_usuario>
<link> /tcruzfranca </link>
</usuario>
</trabalho>
Figura 3.6 - Representação XML do recurso trabalho
<trabalhos>
<contador> 50 </contador>
<link> /trabalhos </link>
<trabalho>
<id_trabalho> smarbuild </id_trabalho>
<conteudo> edifícios 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 - Representação XML do recurso trabalhos
As representações JSON possuem os mesmos elementos chaves para os mesmos
recursos. Uma definição da representação JSON do recurso usuario pode ser vista na
Figura 3.8, enquanto a representação JSON do recurso lista_usuarios pode ser vista na
Figura 3.9. A Figura 3.10 apresenta a estrutura JSON de representação de todos os
usuários.
{"usuario":{"nome_usuario":"juan","senha":"123456", "link":"/usuario/juan"}}
Figura 3.8 - Representação JSON do recurso usuário
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 - Representação 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 - Representação JSON de todos os recursos usuario
A representação 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 - Representação 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 - Representação JSON de lista_trabalhos
3.3.3.4. Definição de URI
A definição das URIs é uma etapa crucial, pois elas definirão a API do sistema. A API
definida deve ser lógica, hierárquica, e o mais estável possível. Uma boa API é aquela
que é utilizada facilmente e não muda com freqüência. Além disso, a idéia de uma API
RESTful é manter uma URI única e confiável para cada recurso.
Na definição da URI, a primeira coisa necessária é um endereço Web, no nosso
exemplo utilizaremos o endereço http://www.dcc.ufrj.br/. Ainda, serão adotadas duas
convenções na definição das URIs RESTful. Primeiro, os itens e identificadores que não
mudam serão nomeados utilizando palavras-chave como parte da URI (por exemplo, a
palavra “usuários” foi utilizada para definir a URI que aponta para o recurso lista de
usuários). A segunda convenção é a utilização de palavras-chaves entre chaves “{}”. Ao
aplicar essa convenção para definir a lista de URIs para os recursos, as URIs obtidas
são:
•
http:// www.dcc.ufrj.br /usuarios - uma requisição com o método GET enviada
para essa URI irá retornar uma lista de usuários. Se o método POST for
utilizado, será criado um novo usuario. Nesse caso, o corpo da mensagem
conterá uma representação XML do usuário que deve ser criado. Os outros
métodos (PUT e DELETE) não serão suportados, pois as listas de usuários não
podem ser alteradas ou apagadas;
122
•
http:// www.dcc.ufrj.br /usuarios/{nome_usuario} - uma requisição contendo o
método GET enviada para essa URI irá retornar uma representação de um
usuário contendo um identificador nome_usuario. Se o método PUT for
utilizado, o recurso acessado (usuario) será atualizado. Já o método DELETE é
utilizado para excluir um usuário;
•
http://www.dcc.ufrj.br/trabalhos - uma requisição com o método GET enviada
para essa URI retornará uma lista com todos os trabalhos. Se o método POST
for utilizado, um novo trabalho será criado;
•
http://www.dcc.ufrj.br/trabalhos/{id_trabalho} – se o método GET for utilizado,
o acesso a essa URI retornará uma representação para um trabalho associado ao
id_trabalho enviado. O método DELETE irá indicar ao servidor que o cliente
espera que o trabalho seja apagado. Os métodos POST e PUT não serão
utilizados para esse recurso; e
•
http://www.dcc.ufrj.br/trabalhos/usuarios/{nome_usuario} – se o método GET
for utilizado em uma requisição submetida para essa URI, uma lista de todos os
trabalhos do usuário com o nome_usuario será retornada (nenhum outro método
é suportado).
O uso adequado da URI (conforme os princípios REST e ROA) fornece a
informação semântica necessária para interação com os recursos. O uso inadequado da
URI pode causar interpretações confusas. Por exemplo, quando uma URI é utilizada
para indicar o tipo de representação do recurso, como faz o twitter, por exemplo,
dúvidas podem ser geradas no consumidor do recurso. O twitter oferece diferentes
representações através da URI http://twitter.com/statuses/public_timeline.{xml, json,
rss}. Essa abordagem poderá gerar dúvidas no cliente que consome o recurso, pois
segundo os princípios REST o protocolo de comunicação deveria ser utilizado para
indicar o tipo de representação desejado. Por exemplo, o que aconteceria se uma
requisição HTTP indicando que o cliente espera receber uma representação XML
através do campo Accept do HTTP fosse submetida para a URI
http://twitter.com/statuses/public_timeline.json? Não seria possível especificar se a
representação obtida poderia ser um XML ou um JSON. A pesar disso, ROA incentiva
o uso de URI para indicar o tipo de representação de um recurso que o servidor deve
retornar, porque essa seria a forma mais simples e explícita do cliente indicar o tipo de
representação que espera receber.
A definição sobre qual abordagem usar para indicar a representação do recurso é
uma decisão do desenvolvedor ou arquiteto de software. Essa decisão deve ser tomada
com base na observação de qual será a melhor abordagem para os usuários do sistema.
Por exemplo, uma abordagem semelhante a do twitter pode facilitar o desenvolvimento
de clientes (aplicações que vão utilizar esse recurso), pois, para recursos que são apenas
para leitura, é possível utilizar somente uma requisição HTTP (com o método GET)
contendo o tipo de representação embutida na URI. Enviar esse tipo de requisição é
mais fácil do que instanciar uma nova requisição HTTP e modificar o cabeçalho Accept
a cada nova requisição.
123
3.3.4. Descritor WADL
A linguagem WADL (Web Application Description Language) é uma especificação
formal baseada em XML utilizada para descrever aplicações Web baseadas no
protocolo HTTP [Hadley 2006]. Quando os provedores de aplicações Web RESTful
desejavam fornecer descrições sobre os recursos, eles utilizavam descrições 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
padrão de descrição de aplicações Web RESTful, cujo propósito é semelhante ao do
descritor WSDL utilizado para descrever serviços SOAP [WSDL 2011]. Porém, a
WADL foi criada especialmente para descrever interfaces RESTful [Ferreira Filho
2010]. Os principais benefícios na utilização de descritores como o WADL é a
possibilidade de automatizar a criação de código através de um formato padronizado e
portável que independe de linguagem ou aplicação específica [Webber et al. 2010].
A Tabela 3.1 apresenta os principais elementos de um documento WADL
juntamente com uma descrição de cada um deles [Hadley 2009], [Ferreira Filho 2010].
Tabela 3.1 – Principais elementos de um descritor WADL
Elemento
application
resources
resource
method
response
representation
Descrição
É o elemento raiz e contém os demais elementos do documento WADL
Esse elemento atua como um contêiner para cada recurso fornecido pela
aplicação, a URI do provedor dos recursos é indicado neste elemento
através 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 saída de um método do protocolo
HTTP que deve ser aplicado a um recurso.
Esse elemento descreve a saída resultante da realização de um método do
HTTP no recurso.
Esse elemento descreve uma representação do estado de um recurso.
A Figura 3.13 é um exemplo de documento WADL gerado pela ferramenta
Jersey [Jersey 2011] que é uma ferramenta para implementação de serviços RESTful
utilizando a linguagem Java. No exemplo é apresentada a descrição do recurso
identificado pelo path “/spot-1265/light” e que pode retornar dois tipos de
representação: XML e JSON.
Apesar das vantagens do uso de um descritor, os defensores dos princípios
REST vão de encontro à idéia de utilizar documentos formais que estabeleçam contratos
entre os clientes e os provedores de recursos. Segundo eles, a idéia de utilizar
descritores vem de uma mentalidade herdada dos serviços Web baseados em SOAP cuja
filosofia é contrária ao REST. Segundo Webber et al. (2010), o emprego adequado de
hipermídia como mecanismo de manutenção do estado da aplicação fornece toda
semântica necessária para que o consumidor realize toda manipulação que deseja sobre
os recursos. Desta forma, não seria necessária a utilização de um contrato formal (como
a WADL) o que resulta em um menor acoplamento entre cliente e servidor.
Resumidamente, as principais desvantagens da utilização de WADL são [Webber et al.
2010]:
•
Existem poucas ferramentas para manipulação dessa linguagem;
124
•
As aplicações Web passam a ser vistas como aplicações estáticas devido ao uso
de uma linguagem de descrição de interfaces;
•
Há um aumento no acoplamento entre o cliente e o servidor, que acaba fazendo
com que alterações no lado do servidor gerem conseqüências no lado do cliente
como acontece com os serviços Web que utilizam WSDL; e
•
A linguagem de descrição não fornece informações suficientes para direcionar a
interação com os recursos, isto é, o consumidor do documento WADL não sabe
qual interação 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 Serviços Web WS-* (SOAP, WSDL, etc.) são técnicas de integração de
aplicações distribuídas que visam manter o baixo acoplamento entre as partes
envolvidas [Guinard e Trifa 2009]. Na Web das Coisas os princípios REST têm sido
amplamente aplicados na integração dos dispositivos inteligentes a Web porque esses
princípios parecem ser mais adequados para dispositivos com poucos recursos de
hardware [Wilde 2007], [Guinard e Trifa 2009]. Esta Subseção apresenta algumas
comparações entre REST e WS-* SOAP que podem facilitar a compreensão de tal
escolha (maiores detalhes sobre essa comparação podem ser vistos em [Pautasso et al.
2008]).
A primeira diferença entre o REST e o WS-* SOAP está na forma como o
protocolo HTTP é empregado. Com REST, o HTTP é utilizado para definir a interação
entre o cliente da aplicação e o provedor do recurso. Nesse caso, toda a semântica
presente nos quatro métodos (GET, POST, PUT, DELETE) do protocolo HTTP é
utilizada na definição 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 aplicações. Nessa abordagem, as mensagens SOAP são
adicionadas ao corpo do HTTP para comunicação remota através de firewalls [Pautasso
et al. 2008], [Guinard e Trifa 2009]. Nos WS-* SOAP o método POST do HTTP é
utilizado na troca de mensagens entre clientes e servidores e a informação sobre qual
funcionalidade deve ser executada está presente na mensagem SOAP e não na
requisição HTTP [Pautasso et al. 2008]. É por esse motivo que se diz que para os
125
serviços Web SOAP o protocolo HTTP desempenha funcionalidade de transporte
mesmo ele sendo um protocolo do nível de aplicação. Enquanto as aplicações WS-*
SOAP utilizam a Web como meio de troca de mensagens, as aplicações Web RESTful
são parte da Web a qual é vista como um terreno comum para as aplicações [Pautasso et
al. 2008].
Além do HTTP, as mensagens SOAP também podem ser encapsuladas e
transportadas dentro de outros protocolos (por exemplo, os protocolos TCP e SMTP
podem ser utilizados para esse propósito) [Pautasso et al. 2008]. Isso é possível porque
o SOAP possui um formato próprio de mensagem (baseado em XML), porém 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 restrição de banda de rede disponível [Tyagi 2006].
Além disso, um formato pré-definido de mensagem força o cliente a tratar aquele tipo
de mensagem caso ele deseje utilizar um serviço. Com REST é possível oferecer
diferentes tipos de representações. Assim, um cliente pode, por exemplo, escolher se
para ele é mais adequado receber uma representação JSON ou um XML. Porém,
fornecer vários formatos exige mais esforço 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 distribuídos com acoplamento fraco entre as partes.
Porém, avaliar qual das duas abordagens atinge esse objetivo conseguindo um menor
acoplamento é uma tarefa subjetiva, pois para definir o acoplamento vários aspectos
devem ser observados (como tempo/disponibilidade, clareza de localização, e evolução
do serviço) [Pautasso et al. 2008]. Geralmente o termo “fraco acoplamento” é
relacionado à capacidade de fazer modificações no provedor do serviço sem afetar o
cliente. Nesse caso, os serviços Web RESTful são menos acoplados, pois as operações
sobre os recursos não mudam, já que tais operações são baseadas nos métodos do
HTTP, os quais não mudam mesmo quando ocorre alguma alteração no serviço.
Contudo, quando acontecem mudanças nos parâmetros passados nas mensagens, ambos
(SOAP e REST) compartilham o mesmo nível de acoplamento [Pautasso et al. 2008].
Outra diferença entre REST e SOAP está na forma como essas abordagens
utilizam URIs. Com REST a URI não é utilizada apenas para identificar o recurso, mas
também para encapsular toda informação necessária para identificar e localizar os
recursos sem a necessidade de um registro centralizado [Pautasso et al. 2009]. Entre
outros benefícios, empregar URIs dessa forma permite que os recursos sejam marcados
e que links hipermídia sejam fornecidos para o cliente para que o mesmo interaja com
os recursos do sistema. O WS-* também utiliza URI, mas não da mesma forma que em
uma abordagem REST, o que acarreta na necessidade de utilização de outros
mecanismos para agregar informação ao serviço [Pautasso et al. 2009].
Prosseguindo com as comparações entre os serviços Web SOAP e as aplicações
RESTful, é possível observar diferenças entre a forma como os clientes consomem os
serviços. Com SOAP, os clientes utilizam um documento de descrição formal dos
serviços disponíveis. Esse documento é o WSDL (Web Service Description Language)
[WSDL 2007]. O uso de descritores fornece aos clientes meios que permitem a geração
126
automática de código para consumir esses serviços. Porém, sua utilização pode
ocasionar falhas no cliente caso ocorram modificações no servidor [Pautasso et al.
2008]. As aplicações RESTful não precisam utilizar um contrato formal (apesar disso
ser possível, conforme apresentado na Subseção 3.3.4) entre o cliente e o servidor.
Freqüentemente os recursos de uma aplicação RESTful são descritos de forma textual
ou por meio da documentação da API da aplicação [Pautasso et al. 2008]. Além dessas
abordagens, também surgiram alguns provedores de serviços RESTful que oferecem
bibliotecas (em diferentes linguagens de programação) para serem usadas pelos clientes
que desejam consumir os recursos que o servidor oferece [Ferreira Filho 2010].
Por ser mais simples, por tornar as aplicações criadas com base em seus
princípios parte da Web permitindo que todos os recursos e disponíveis na Web possam
ser utilizados para o mundo físico e por causa do menor tamanho das suas mensagens os
princípios REST são considerados mais adequados para serem utilizados na integração
de dispositivos com baixa capacidade de hardware na Web [Wilde 2007]. Porém, ainda
existe uma série de desafios que precisam ser superados. Dentre eles destaca-se o
modelo de pull da Web ocasionado pelo HTTP que não prevê um modelo de
comunicação assíncrona onde o cliente é notificado da ocorrência 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 endereço IP (Internet Protocol) e não são, portanto, diretamente
localizáveis/endereçáveis na internet. No entanto, é muito provável 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 poderão
ser diretamente integrados a Web e assim as suas funcionalidades serão acessadas
através de interfaces RESTful.
Embora tais dispositivos habilitados sejam susceptíveis de serem amplamente
distribuídos em um futuro próximo, a integração direta de dispositivos do mundo real
com a Web ainda é uma tarefa bastante complexa. Principalmente nos casos em que os
dispositivos não suportam IP e/ou HTTP, como ocorre normalmente no contexto de
redes de sensores sem fio (RSSF), por exemplo. Quando o endereço IP não é suportado,
é necessário utilizar um padrão de integração diferente. Nessas situações, nas quais os
dispositivos não são capazes de se comunicar via IP, é possível utilizar um dispositivo
intermediário chamado Smart Gateway. Smart Gateways possuem duas funções básicas:
fornecer uma interface RESTful com URIs que identificam e fornecem acesso aos
objetos físicos (dispositivos inteligentes) e seus subrecursos; e realizar a comunicação
com os objetos físicos 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 através de suas APIs.
Cada gateway tem um endereço IP, executa um servidor HTTP e compreende os
protocolos proprietários dos diferentes dispositivos conectados a ele através do uso de
controladores (drivers) dedicados. Como exemplo, considere uma requisição para um
nó sensor proveniente da Web através da API RESTful. O gateway mapeia essa
requisição em uma solicitação da API proprietária do dispositivo e a transmite usando o
127
protocolo de comunicação que tal dispositivo compreende (por exemplo, usando o
protocolo Zigbee). Um Smart Gateway pode suportar vários tipos de dispositivos
através de uma arquitetura de controladores. A Figura 3.14, mostra um exemplo de
Smart Gateway que suporta três tipos de dispositivos, comunicando-se com eles através
de seus protocolos de comunicação correspondentes.
Os Smart Gateways também podem ser usados para orquestrar a composição
de vários serviços de baixo nível em serviços Web de mais alto nível. Esses serviços
Web de mais alto nível são mashups criados a partir da composição dos recursos dos
dispositivos disponibilizados através 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 serviço 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 são os Smart Hubs
[Mayer 2010]. Os Smart Hubs permitem que sejam criadas infraestruturas que
interligam dispositivos inteligentes à Web a fim de prover serviços avançados no topo
desses dispositivos. Desta forma, os Smart Hubs oferecem a possibilidade de ter
dispositivos interagindo entre si para que sejam fornecidas funcionalidades que vão
além do que cada dispositivo poderia prover individualmente. O Smart Hub utiliza
serviços de descoberta de dispositivos inteligentes a fim de obter e armazenar
informações sobre esses dispositivos. O processo de descoberta e armazenamento de
informações sobre novos dispositivos realizado pelo Hub é conhecido como vinculação
de recurso (attaching resource). Os Smart Hubs oferecem serviços de consulta e
publicação de recursos dentro da infraestrutura da WoT e são implementados para
estabelecer conexões entre si de forma que seja mantida uma infraestrutura em árvore.
Essa infraestrutura permite que os recursos de diferentes dispositivos não 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 físico e a Web com o intuito de expor objetos inteligentes como serviços
RESTful. Um controlador é tipicamente formado por: um módulo 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 comunicação entre clientes HTTP e esse dispositivo. Porém, a
implementação de um controlador WoT pode diferir na forma como o dispositivo é
acessado pelo software. Um controlador pode atuar como um proxy reverso
encaminhando requisições HTTP para um dispositivo que possui um servidor
embarcado ou pode dissociar o processo de comunicação entre o cliente HTTP e o
dispositivo (nesse caso, o objeto físico é acionado por meio de sua API para realizar a
tarefa especificada na requisição HTTP).
3.4.1. Comunicação Orientada a Eventos
Os Smart Hubs e Smart Gateway fornecem serviços de comunicação orientada a
eventos. Esse serviço é importante porque a comunicação com o protocolo HTTP é
síncrona (o modelo de comunicação é requisição e resposta – request/reply), o que não
permite que o cliente seja notificado da ocorrência 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 incêndio. Não é possível prever quando
ocorrerá um incêndio, por isso é necessário prover meios que permitam que o cliente
saiba da ocorrência dos eventos de interesse (no caso, a ocorrência de incêndio).
Para monitorar a ocorrência de um evento, os clientes podem consultar os
dispositivos constantemente utilizando AJAX, por exemplo. Porém, essa abordagem
não é adequada, pois poderia fazer com que a bateria dos dispositivos se esgotasse
rapidamente. Para evitar tal situação, é possível utilizar o Smart Gateway e o Smart Hub
para fornecer um modelo de comunicação assíncrona 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 comunicação assíncrona 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
disponibilização de conteúdo é 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 ocorrência de um evento nesse servidor.
Outros meios de comunicação assíncrona também podem ser utilizados, tais
como: e-mail, twitter e URIs de serviços externos que devem ser acessados pelo
gateway ou hub para publicação do evento. Por exemplo, se um usuário deseja que os
dados do dispositivo sejam publicados em sua conta no twitter, ele deve fornecer
informações sobre a sua identificação e as credenciais do twitter. Então, qualquer
cliente que deseje obter as informações do dispositivo precisa apenas se associar a conta
do mesmo no twitter.
Outra alternativa de comunicação assíncrona na Web é o modelo Comet, o qual
pode ser utilizado para que o servidor envie dados para o cliente [Duquennoy et al.
129
2009]. Porém esse modelo consome mais recurso no lado do servidor, pois é necessário
que o servidor armazene informações sobre cada cliente para poder anunciar os dados
referentes a um evento [Duquennoy et al. 2009].
3.5. Web das Coisas: Desenvolvendo Aplicações na Plataforma Sun SPOT
Esta Seção descreve como dispositivos físicos e suas funcionalidades podem ser
disponibilizados na Web conforme as soluções propostas na WoT. Para tal, são
apresentados exemplos práticos utilizando os dispositivos embarcados Sun SPOT (Sun
Small Programmable Object Technology), os quais são programados usando a
linguagem Java [Sun SPOT 2011]. Nesta Seção também são apresentados dois mashups
que compõe os recursos dos SPOTs com outros recursos da Web.
A Subseção 3.5.1 apresenta a plataforma Sun SPOT. A Subseção 3.5.2 apresenta
como os objetos físicos podem ser integrados a Web, incluindo exemplos práticos de
como disponibilizar as funcionalidades de dispositivos Sun SPOT na forma de recursos
RESTful. A Subseção 3.5.3 apresenta a construção de mashups físicos que compõem os
dados e funcionalidades disponibilizados pelos SPOTs.
3.5.1. Introdução a Plataforma Sun SPOT
O dispositivo Sun SPOT é uma plataforma de sensores desenvolvida pela
Sun Microsystems/Oracle [Sun SPOT, 2011]. Esse dispositivo é acionado por código
Java e pode ser utilizado em diversos projetos com os mais variados propósitos. Eles
podem, por exemplo, ser utilizado em carros robóticos ou no monitoramento de
fenômenos físicos devido aos dispositivos de sensoriamento acoplados a eles [Sun
SPOT, 2011]. Existem dois tipos de dispositivos Sun SPOT: os free-range SPOTs e a
estação base [Sun SPOT, 2011]. A Figura 3.15 ilustra esses dois tipos de dispositivos
(uma estação 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
recarregável, dispositivos de sensoriamento, sendo um de temperatura, outro de
luminosidade e um acelerômetro. Além disso, eles também possuem dois botões (os
botões podem ser utilizados para acender leds do SPOT ou até mesmo para mudar
algum parâmetro na aplicação), oito leds de três cores (vermelho, verde e azul), quatro
pinos genéricos de entrada e saída (que podem ser utilizados para acoplar outros
130
dispositivos eletrônicos), quatro pinos de saída de alta tensão e uma interface USB [Sun
SPOT, 2011]. Atualmente os SPOTs possuem as seguintes configurações de hardware:
um processador ARM de 32 bits que opera a uma freqüência de 400 MHz; 1 MB de
memória RAM; 4 ou 8 MB de memória flash; e um Chipcon 2420 para comunicação a
rádio em redes aderentes ao padrão IEEE 802.15.4 dispondo de 11 canais de 2,4 GHz
[Sun SPOT, 2011]. Os SPOTs podem ser identificados pelo seu endereço MAC IEEE
de 64 bits. Além disso, esse dispositivo oferece um protocolo de roteamento o LQRP
(do inglês Link Quality Routing Protocol), o qual pode ser utilizado ou estendido pelo
usuário. O código Java da aplicação é executado em uma máquina virtual chamada
Squawk VM (Virtual Machine), compatível com a plataforma Java ME (Micro Edition)
na configuração CLDC1.1 (do inglês, Connected Limited Device Configuration), que
permite que o código seja executado sem depender de um sistema operacional. Portanto,
é a Squawk que realiza todas as funcionalidades necessárias para execução de uma
aplicação, a qual deve possuir uma classe que estende a classe MiDlet [Sun SPOT,
2011].
A estação base (EB) possui apenas uma interface de comunicação sem fio
baseada em rádio 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.
Aplicações para a plataforma Sun SPOT podem ser desenvolvidas em um
computador pessoal e posteriormente instaladas nos SPOTs. Para tal, é necessário
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 automatização do processo de
compilação, implantação, geração de documentos e execução de uma aplicação. Essa
ferramenta é usada principalmente na construção de aplicações 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 aplicações para Sun
SPOT. A implantação do código de uma aplicação nos SPOTs pode ser feita
transferindo o código através da interface USB ou utilizando uma abordagem OTA
(“over the air”). A implantação do código através do cabo USB exige que o SPOT
esteja conectado fisicamente ao computador que contém o código compilado. A
implantação de código via OTA utiliza o enlace de rede sem fio IEEE 802.15.4 para
enviar o código a um SPOT específico. Utilizando essa última abordagem, a estação
base é utilizada para enviar esse código e o endereço MAC do SPOT de destino deve
ser especificado.
Uma aplicação para Sun SPOT deve possuir uma classe que estende a classe
MiDlet. A classe MiDlet possui três métodos abstratos que devem ser implementados
pela classe que a estende: startApp(), pauseApp(), e destroyApp(boolean unconditional).
O método que é executado inicialmente pela Squawk é o startApp, sendo executado
assim que o SPOT for iniciado. Os outros dois métodos pauseApp e destroyApp podem
conter uma implementação vazia. A
Figura 3.16 mostra um exemplo básico de uma classe que estende MiDlet. A
Squawk executa uma aplicação por vez; isto significa que apenas uma classe estendendo
MiDlet pode ser executada. Porém, a Squawk permite que uma aplicação execute várias
131
threads de forma paralela. Maiores detalhes sobre a plataforma Sun SPOT podem ser
obtidas em [Sun SPOT, 2011], onde também é possível obter informações 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 aplicação para a plataforma Sun SPOT
3.5.2. Integração de Dispositivos na Web
Essa Subseção apresenta os procedimentos de como os dispositivos físicos podem ser
disponibilizados na forma de serviços Web RESTful. A disponibilização dos
dispositivos pode ocorrer de duas formas: através da inclusão de um servidor
embarcado executado diretamente no dispositivo; ou por meio de Smart Gateways, que
permitem que até mesmo os dispositivos que não possuem um servidor embarcado
(devido a restrições de hardware ou por restrição 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 requisições HTTP. Além disso, o servidor também permite que esses
132
recursos sejam acessados por meio de uma interface RESTful [Guinard e Trifa 2009].
No caso dos dispositivos não suportarem a pilha de protocolo IP, é necessário fazer uso
de um proxy para receber as requisições Web da rede TCP/IP e enviar tais requisições
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 serviços do dispositivo. Por exemplo, o proxy pode implementar serviços de
descoberta, que permitem que os dispositivos de um mesmo tipo sejam adicionados
(quando estiverem na área de atuação do proxy) e removidos do proxy (se o dispositivo
se tornar inacessível) [Guinard e Trifa 2009], [Mayer 2010].
A Subseção 3.5.2.1 apresenta um servidor embarcado para plataforma Sun
SPOT que permite que as funcionalidades desse dispositivo sejam providas na forma de
serviços RESTful. Nessa mesma Subseção é apresentado um proxy que permite que
requisições Web sejam encaminhadas para os SPOTs. A Subseção 3.5.2.2 apresenta o
protótipo de um Smart Gateway e demonstra a associação de dois SPOTs ao Gateway.
Um SPOT possui um servidor embarcado enquanto o outro SPOT não. Dessa forma, é
exemplificado um cenário básico da inclusão de dispositivos físicos na Web. A
Subseção 3.5.2.3 apresenta como os SPOTs associados ao Smart Gateway são
acessados na Web. A Subseção 3.5.2.4 mostra como obter representações dos estados
dos recursos através de exemplos dessas representações.
3.5.2.1. Técnica de Implementação de Servidores Web em Dispositivos
Embarcados
A utilização de servidores embarcados em objetos físicos permite que as
funcionalidades de tais objetos sejam disponibilizadas como recursos Web. Porém, as
metodologias utilizadas na criação de serviços Web não foram projetadas para serem
empregadas em dispositivos que possuem hardwares restritos e são 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 série de
requisitos. Em [Shelby, 2010] foram apresentados os requisitos e padronizações para
servidores embarcados. Um exemplo de requisito a ser atendido de forma padronizada é
a compressão das mensagens do protocolo HTTP.
Esta Subseção apresenta as principais características de um servidor embarcado
desenvolvido para a plataforma Sun SPOT disponibilizado entre os projetos de
demonstração que acompanham a nova versão do SDK lançada em Outubro de 2010
[Gupta 2010], [Gupta e Simmons, 2010], [Sun SPOT, 2011]. Esse servidor faz parte do
projeto WebOfThings e está disponível 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 binárias a fim de reduzir o
tamanho das mensagens que utilizam esse protocolo. As mensagens HTTP compactadas
são transmitidas sobre UDP em redes sem fio de baixa taxa de transmissão e pequena
largura de banda como, por exemplo, as redes IEEE 802.15.4/ZigBee. O draft Reverse
HTTP descreve um método que permite que as requisições HTTP sejam enviadas para
dispositivos que não podem ser acessados diretamente (por exemplo, dispositivos que
estejam atrás de um firewall ou de NAT - network address translation). A RFC 5785
133
descreve como serviços Web podem obter meta-informações sobre o servidor acessando
o path “/.well-know/” que simboliza as localizações dos recursos.
O projeto WebOfThings provê uma solução para que as funcionalidades dos
SPOTs sejam disponibilizadas sob a forma de recursos Web. Conforme apresentado na
Subseção 3.5.1, os SPOTs se comunicam entre si e com a EB utilizando padrão IEEE
802.15.4 e esses dispositivos não 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 requisições Web retransmitindo-as
para os SPOTs [Gupta 2010], [Gupta e Simmons, 2010]. Para isso, a EB deve manter
uma referência para cada SPOT. Para tal, a EB utiliza como registro de identificação do
SPOT parte do endereço físico (MAC) desse SPOT. O serviço de descoberta é o
responsável por realizar o registro dos SPOTs na EB. Esse serviço 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 identificação. Essa
identificação é utilizada para disponibilizar o SPOT como um recurso Web e as
funcionalidades desse SPOT são subrecursos do mesmo. Por exemplo, o dispositivo de
sensoriamento de temperatura do spot-1265 (identificação de um SPOT) é um
subrecurso desse SPOT. Após a etapa de registro, os SPOTs podem receber requisições
Web.
As requisições advindas da Web são enviadas para a estação base, a qual faz uso
da URI da requisição 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). Após a EB identificar qual SPOT está
sendo solicitado na requisição HTTP, ela comprime a requisição recebida e a
retransmite através 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 requisição HTTP para um SPOT que contém
um servidor embarcado.
Quando uma requisição HTTP é recebida pelo SPOT, o servidor HTTP é
utilizado para descompactar essa requisição e criar um objeto contendo todas as
informações incluídas nessa mensagem (por exemplo, o objeto criado, dentre outras
134
informações, pode ter o path de um recurso e o método presente na requisição). Esse
objeto que representa a requisição HTTP é utilizado para identificar o recurso solicitado
por meio do path, além de indicar qual operação deve ser realizada sobre esse recurso.
As operações que podem ser executadas sobre um recurso são: criar, recuperar, atualizar
e apagar. Essas operações são executadas com base no respectivo método da requisição
HTTP (GET, POST, PUT ou DELETE) em conformidade com a propriedade ROA e o
princípio REST de interface uniforme. É necessário ressaltar que os recursos não
precisam tratar todos os métodos HTTP utilizados em serviços RESTful. Por exemplo,
os dispositivos de sensoriamento apenas enviam o valor sensoriado; logo esses recursos
são acessados por requisições que contém o método GET do HTTP e os demais
métodos não são suportados, pois não possuem utilidade para esse recurso. Os leds por
outro lado, podem retornar uma representação contendo as cores com que eles estão
acesos (por exemplo, utilizando valores RGB – red, green, blue) quando recebem uma
requisição com o método GET. Ou podem alterar sua cor com base em parâmetros de
uma requisição que contém o método PUT.
Após o tratamento da requisição HTTP, o servidor do SPOT envia uma
mensagem de resposta HTTP com um código de sucesso ou um código de erro (por
exemplo, um 200 OK que indica que o conteúdo da requisição foi processado com
sucesso ou um 404 que indica que o recurso não foi encontrado). As mensagens HTTP
de sucesso podem conter uma representação do recurso solicitado (por exemplo, as
requisições HTTP que contém o método GET). Nesse caso, o próprio recurso retorna
uma representação (em HTML, JSON ou XML, por exemplo) que é incluída 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 requisição. 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 serviços RESTful.
A Figura 3.18 apresenta as principais classes do projeto WebOfThings que são
executadas na EB. Essas classes implementam as funcionalidades que permitem que os
SPOTs registrados sejam acessados como qualquer serviço Web RESTful. Nessa classe
é criada uma instância de NanoAppServer. Em NanoAppServer estão implementadas as
funcionalidades que permitem que as requisições sejam encaminhadas para o SPOT
adequado, como se esse dispositivo fosse um recurso Web. A classe Main também
instancia TCPHandle passando a referência do objeto NanoAppServer criado
anteriormente.
TCPHandle tem como objetivo receber as requisições HTTP advindas da Web
em uma porta pré-definida. Para cada requisição advinda da Web, TCPHandle devolve
uma resposta via Web ao emissor de tal requisição. Por exemplo, ao receber uma
requisição HTTP advinda da Web, TCPHandle cria um objeto do tipo HttpRequest que
contém todas as informações da requisição HTTP recebida da Web. Para tal,
TCPHandle utiliza o método estático parse da classe HttpRequest passando como
parâmetro a requisição HTTP recebida da Web. A instância de HttpRequest que
equivale a requisição HTTP advinda da Web possui todos os campos da mensagem
HTTP compactados (por exemplo, os campos do cabeçalho da requisição são
representados por bytes específicos). Em seguida, TCPHandle acessa NanoAppServer
para obter a resposta para essa requisição HTTP.
135
Em NanoAppServer é acessado o método processRequest da classe MainApp
passando como parâmetro a instância 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 instância de DeviceManager
que identifica se o SPOT solicitado está entre os SPOTs cadastrados na EB. Se um
SPOT for identificado, a instância de HttpRequest é encaminhada para esse SPOT por
meio do método sendAndGetResponse de UDP6Forwarder. O método
sendAndGetResponse de UDP6Forwarder encaminha a requisição e aguarda a resposta
do SPOT. Finalmente, a resposta enviada pelo SPOT é entregue por TCPHandler ao
cliente que fez a requisição (qualquer erro em algumas das etapas anteriores fará com
que uma resposta contendo um código de erro seja enviada para o cliente Web).
Figura 3.18 - Principais classes do projeto WebOfThings executadas na
Estação Base
A Figura 3.19 apresenta as principais classes que são 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 aplicação. Em WoTServer é instanciada a classe NanoAppServer
que implementa as funcionalidades do servidor HTTP. Nos SPOTs, NanoAppServer
armazena as instâncias das classes que implementam as funcionalidades dos recursos,
bem como uma identificação para cada uma dessas instâncias. Essa identificação é
utilizada para relacionar um recurso com o path de uma requisição. Por exemplo, uma
instância da classe LightSensor que permite que o dispositivo de sensoriamento de
luminosidade seja disponibilizado como recurso Web é identificada pela String “/light”
e uma requisição 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 necessária para as
classes que implementam as funcionalidades de um recurso.
136
Figura 3.19 - Principais Classes do projeto WebOfThings Executadas nos
SPOTs
Em WoTServer também é instanciada a classe UDP6Handler que realiza a tarefa
de comunicação utilizando os níveis de rede da plataforma Sun SPOT. As mensagens
no nível de rede são recebidas em UDP6Handler e o conteúdo de cada mensagem é um
array de bytes que equivale a requisição HTTP compactada. Esse array de bytes é
passado para o método estático parse da classe HttpRequest que retorna uma referência
para um objeto do tipo HttpRequest que representa a requisição descompactada.
UDP6Handler faz uso do objeto que equivale a requisição para obter um objeto
HttpResponse que equivale a resposta adequada para a requisição 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 contêm todas as funcionalidades necessárias para manipulação das requisições e
respostas, respectivamente. A classe HttpMessage contém os métodos que realizam a
compressão e descompressão das mensagens HTTP (cabeçalhos, tipos MIME, entre
outros). A classe HttpRequest fornece todos os métodos para acesso aos cabeçalhos e
parâmetros da requisição HTTP (por exemplo, obtenção do método da requisição
HTTP). Os objetos do tipo HttpResponse são criados com base no recurso indicado no
path da requisição (por exemplo, uma requisição utilizada para obter uma representação
do valor da temperatura faz com que uma resposta seja gerada na instância da classe que
implementa as funcionalidades desse recurso). Quando um recurso não existe ou o
método indicado na requisição não é suportado pelo recurso, é criada uma instância de
HttpResponse com um código de erro.
A Figura 3.20 apresenta o diagrama de seqüência das mensagens trocadas
durante a execução do servidor embarcado nos SPOTs: da etapa de inicialização ao
tratamento das requisições dos clientes que desejam obter uma representação de algum
recurso disponibilizado. A classe WoTServer instancia a classe NanoAppServer e todas
137
as classes dos recursos. Em seguida, as instâncias das classes que implementam os
recursos são passadas para NanoAppServer juntamente com o path que os identifica
através do método registerApp dessa classe. A próxima classe a ser instanciada é
UDP6Handler que recebe um parâmetro do tipo int e uma referência para a instância de
NanoAppServer. O parâmetro int indica a porta onde deve ser aberta a conexão no nível
de rede da plataforma Sun SPOT. Essa porta deve ser a mesma utilizada pela EB para
encaminhar as requisições Web para o SPOT.
Figura 3.20 - Diagrama de seqüência das mensagens trocadas durante a
execução do servidor embarcado nos SPOTs
O objeto do tipo UDP6Handler deve permanecer em um laço contínuo ouvindo
mensagens na porta indicada. As requisições e respostas HTTP trafegam no enlace de
rede sem fio dentro de datagramas. A comunicação utilizando datagramas é realizada
através dos métodos da classe UDPConnection que estende a interface
DatagramConnection disponível no SDK. Após receber o datagrama, UDP6Handler
passa o conteúdo do datagrama como parâmetro do método estático parse da classe
HttpRequest a fim de receber uma referência para um objeto do tipo HttpRequest que
representa a requisição HTTP recebida (mensagem 5 do diagrama de seqüência).
A referência para o objeto que representa a requisição é utilizada por
UDP6Handler para obter um objeto HttpResponse que equivale a resposta para essa
requisição. Essa referência do objeto que representa a requisição é passada para
NanoAppServer através do método getResponse (mensagem 6 do diagrama de
seqüência). Então, NanoAppServer utiliza a instância do objeto que representa a
requisição como parâmetro do método findMatchingAppAndAdjustPath para buscar
entre a coleção dos recursos aquele que está sendo solicitado. Nesse momento, é
extraído o path da requisição o qual identifica o recurso desejado. Quando o recurso
solicitado é identificado, a instância da classe que implementa as funcionalidades do
138
recurso processa a requisição gerando uma resposta adequada (se ocorrer algum erro,
uma resposta é criada contendo um código de erro). Finalmente, a resposta é
compactada (mensagem 7 do diagrama de seqüência) através do método toByteArray da
classe HttpResponse que repassa a tarefa de compressão para a classe HttpMessage. Um
array de bytes é obtido desse processo o qual é inserido no datagrama, através do
método write. Então o datagrama que contém a resposta HTTP é enviado através do
método send em UDP6Handler.
3.5.2.2. Implementação de Gateways
Esta Subseção contém uma descrição do protótipo de um Smart Gateway desenvolvido
a partir da extensão do proxy reverso apresentado na Subseção 3.5.2.1. A descrição
desse protótipo tem como objetivo fornecer uma visão mais aprofundada sobre um
Smart Gateway. No protótipo, dois tipos de dispositivos foram conectados ao gateway
através do uso de controladores. Ambos os dispositivos são Sun SPOTs, porém um
dispositivo possui um servidor embarcado e o outro não. No segundo caso, o gateway se
comunica com o SPOT utilizando a API deste através de um controlador desenvolvido
para tal finalidade. Desta forma, pretende-se exemplificar como um dispositivo que não
possui servidor embarcado pode ter seus recursos disponibilizados na Web através de
um Smart Gateway.
A Figura 3.21 mostra os principais componentes do gateway. Os controladores
de cada dispositivo possuem um módulo 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 módulo do gateway que faz a gerência 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 módulo apresentado na Figura 3.21 é o DespacharRequisicao. Esse
módulo utiliza as URIs das requisições para obter a informação necessária 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 referência de um objeto Java contendo as informações da requisição é
passada para o controlador. O controlador, por sua vez, utiliza as informações da
requisição 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 requisição. Se
algum erro ocorrer durante esse processo, uma resposta contendo um código de erro é
devolvida ao cliente.
139
Figura 3.21 - Componentes básicos do Smart Gateway e de dois tipos de
dispositivo (um SPOT com servidor embarcado e o outro sem sendo a
comunicação realizada através da API deste)
As principais classes do Smart Gateway utilizadas para registrar e identificar
controladores, além de encaminhar requisições da Web para esses controladores são
apresentadas na Figura 3.22. Nessa figura, a classe MainApp é chamada a cada nova
requisição. As requisições são encaminhadas para o controlador adequado com base no
path dessas requisições.
A Figura 3.23 apresenta as principais classes de um controlador. Tais classes
serão explicadas no contexto de um exemplo. O controlador utilizado para SPOTs que
possuem um servidor embarcado foi desenvolvido de forma análoga, mas é apresentado
na Subseção 3.5.2.1. Os controladores estendem a classe WebApplication e devem ser
registrados na classe MainApp quando uma instância do controlador juntamente com o
path que será utilizado para identificá-lo são passados para NanoAppServer. Os
controladores são Singletons, isto é, só existe uma instância de cada controlador por
Smart Gateway.
A classe DeviceDiscovery é implementada como uma Thread que executa em
intervalos pré-definidos a tarefa de enviar anúncios sobre o gateway a fim de cadastrar
novos dispositivos dinamicamente. Essa classe também é utilizada para controlar a
saída de dispositivos que não possam mais ser alcançados (devido ao esgotamento da
bateria do dispositivo, ou por qualquer outro motivo). Por exemplo, se um dispositivo
conectado não responder a três anúncios consecutivos ele pode ser considerado
140
inalcançável, enquanto nos dois primeiros anúncios 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 mantém uma lista de todos os dispositivos e realiza o
acesso aos recursos dos mesmos através da classe DeviceAccess. Uma requisição
identifica através do path um recurso (representado pelo controlador), um dispositivo
específico (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”
são os quatro últimos dígitos do endereço MAC desse SPOT. Por último, o trecho
“/temperatura” é utilizado para identificar o dispositivo de sensoriamento de
temperatura desse SPOT.
A classe Device contém toda informação necessária para que seja realizado um
acesso específico a um dispositivo. Uma nova instância 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 instância de
Device. Um controlador pode evitar o acesso contínuo 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 anúncio 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 informações: MAC, nome, timestamp e uma lista contendo
as funcionalidades (recursos) dos SPOT. A Figura 3.24 ilustra a estrutura JSON
utilizada para prover as informações necessárias 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 são acessadas por meio de sua API.
{"gateway_id":”MAC_gateway”,”timestamp”:”timestamp”}
Figura 3.24 - Estrutura JSON utilizada no serviço 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 anúncio de capacidade enviada pelos SPOTs que não
possuem servidor embarcado para o gateway
Figura 3.26 - Diagrama de classes dos SPOTs que não possuem servidor embarcado
A classe SpotAPI é a classe executada pela Squawk, pois estende MiDlet. A
classe SPOT_Advertise é responsável pelas tarefas de associação a um Smart Gateway.
A classe Resource é responsável por acessar o recurso adequado quando recebe uma
mensagem do gateway. A classe SPOTCommunication é utilizada para ouvir e
responder mensagens direcionadas aos recursos. Na implementação realizada neste
protótipo o SPOT fica ouvindo na porta 200 mensagens cujo conteúdo é um documento
142
JSON. O JSON indica qual tipo de dado (temperatura ou de luminosidade) que o SPOT
deve retornar.
3.5.2.3. Exposição de Dispositivos como Recursos REST
Como visto extensivamente ao longo deste Capítulo, na Web das Coisas as
funcionalidades dos dispositivos são acessadas por meio de URIs. Dessa forma, os
recursos de um SPOT associado a um gateway devem ser acessados através 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 são vistas como seus subrecursos [Mayer
2010].
A URI de acesso ao recurso de um SPOT tem o formato http://{endereço do
gateway}/{identificação do controlador}/{identificação do SPOT}/{recurso do SPOT}.
O endereço do Smart Gateway o identifica na Web; a identificação do controlador
indica o tipo de dispositivo associado ao gateway que o cliente deseja acessar; e a
identificação do SPOT indica qual dispositivo associado ao gateway que deve ser
acessado (os SPOTs são identificados pelos quatro últimos dígitos do seu endereço
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 dígitos do MAC são “1265” pode ser feito através da URI
http://localhost:8888/spotserver/spot-1265/light, onde “/light” identifica o subrecurso
do SPOT. Os SPOTs que não possuem servidor embarcado também são 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 dígitos 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 também permite que o sistema forneça links para que os
clientes naveguem entre os subrecursos de um recurso. Por exemplo, uma requisição
enviada para http://localhost:8888/spotserver/spot-1265 retorna uma listagem com links
para todos os recursos disponíveis nesse SPOT. Esses links permitem que o cliente
mude da representação do estado de um recurso para outras representações de diferentes
recursos. Além disso, também é possível utilizar links que conduzem o cliente nas
interações que podem ser realizadas com o recurso.
3.5.2.4. Representação de Estado
Os dispositivos conectados a Web fornecem dois tipos de representação de
recursos: HTML e JSON. A representação HTML foi adotada para simplificar a
interação dos clientes (humanos) como os recursos disponibilizados, permitindo a
navegação dentro da estrutura por meio de links para os recursos filhos (subrecursos).
Esse tipo de representação 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 usuário acesse tal dispositivo (a Figura 3.27
mostra um exemplo da página principal do gateway). Os SPOTs que possuem um
143
servidor embarcado enviam uma representação HTML contendo seus subrecursos com
links para cada um deles (ver Figura 3.28).
As representações JSON são disponibilizadas quando um SPOT que não possui
servidor embarcado é acessado ou quando uma requisição especificando que a
representação deve ser JSON é submetida a um SPOT com servidor embarcado. No
caso dos SPOTs sem servidor embarcado, a representação 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 - Representação HTML da página inicial do Smart Gateway
Figura 3.28 - Listagem dos recursos disponíveis em um SPOT com servidor
embarcado
{"resource":{"typeOfResource":"temperature","scale":"Celsius","value","32",
"timestamp":"1300223762980","deviceId":"temperatura","link":"/temperatura
"}}
Figura 3.29 - Representação JSON do recurso temperatura
3.5.3. Técnicas de implementação de Mashups Físicos
Essa Subseção apresenta dois exemplos de composição, em mashups físicos, dos
recursos dos dois SPOTs (com e sem servidor embarcado) conectados ao Smart
Gateway. Os mashups físicos têm como objetivo compor as informações e
funcionalidades dos dispositivos inteligentes em serviços 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 padrão de
desenvolvimento de mashups.
O primeiro mashup apresenta os dados dos dois SPOTs em um gráfico (ver
Figura 3.30). Esse gráfico apresenta a variação da temperatura das últimas doze
amostras obtidas antes do momento da requisição. Para a construção do mashups, foi
implementado um serviço Web que acessa os dispositivos de sensoriamento de
temperatura dos SPOTs a cada hora e armazena a representação do recurso acessado em
um repositório (para esses exemplos foi utilizado um banco de dados relacional) que
atua como histórico de dados. É importante lembrar que as representações de recursos
dos dois SPOTs foram obtidas como as de qualquer outro recurso na Web. O SPOT
responsável pela geração dos dados representados pela linha laranja do gráfico foi
colocado dentro de um ambiente fechado que possui ar condicionado. O SPOT
responsável pela geração dos dados representados pela linha azul do gráfico foi
colocado em uma ambiente aberto (e obviamente sem ar condicionado) para coletar a
temperatura do ambiente.
A integração na Web permitiu que os dados dos SPOTs fossem utilizados em
gráficos que podem ser visualizados na maioria dos navegadores Web. O mashup criado
possibilita, por exemplo, que o responsável pela central do ar condicionado tenha uma
visualização de alto nível sobre os dados de temperaturas obtidos pelos sensores,
permitindo que esse usuário possa avaliar de forma simples e rápida se o sistema de
refrigeração está mantendo a temperatura interna do laboratório independentemente da
variação de temperatura do ambiente externo.
Figura 3.30 - Gráfico de Temperaturas coletadas pelos SPOTs colocados em
diferentes ambientes em um intervalo de 12 horas
A Figura 3.31 apresenta a integração de um SPOT com um mapa Web [Google
Maps Api 2010]. O mapa possui uma marcação com um ícone em uma localidade prédefinida. Quando esse ícone é acionado através 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 usuário clica no ícone apresentado no mapa, é obtida
uma representação JSON de um dado coletado pelo dispositivo de sensoriamento do
145
SPOT. Essa representação contém o valor da temperatura monitorada pelo dispositivo
de sensoriamento, o horário em que o dado foi coletado e uma descrição do local onde o
sensor está localizado (nesse caso, dentro de um laboratório). A localização no mapa foi
fornecida manualmente através da inserção das coordenadas geográficas do local. É
possível utilizar algum mecanismo (um GPS, por exemplo) que forneça coordenadas
geográficas de forma automatizada para o mashup. Porém, como o objetivo aqui é
apenas ilustrar a integração de recursos da Web com dispositivos físicos, as
coordenadas geográficas da localização do SPOT foram fornecidas manualmente.
O mashup apresentado na Figura 3.31 permite que o administrador de um
sistema possa realizar alguma ação remotamente com base na informação oferecida pelo
mashup. Por exemplo, o administrador de vários servidores espalhados por diversas
instituições de ensino do país 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 ação emergencial seria tomada com base na
informação do mashup que combina a localização (oferecida pelo mapa) com o dado de
temperatura (fornecido pelos sensores).
Figura 3.31 - Mashup físico que apresenta em uma mapa da Web a localização
de um SPOT e o valor da temperatura local obtida através do acesso Web ao
dispositivo de sensoriamento desse SPOT
3.6. Conclusão
Neste trabalho foram descritos os princípios básicos da Web das Coisas. As tecnologias
Web foram apresentadas como base viável para a integração 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. Também foram apresentados projetos de
implementação de alguns desses componentes.
Graças 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 integração de
dispositivos [Guinard e Trifa 2009]. Devido a isso, o uso de padrões Web para dar
suporte a interação entre e com dispositivos inteligentes tem sido considerado uma
promissora solução. Embora HTTP introduza uma sobrecarga de comunicação e
aumente a latência média, os parâmetros de qualidade providos em geral são suficientes
que tais atrasos não prejudiquem a comunicação entre dispositivos. Entretanto, outros
trabalhos buscaram soluções de compressão desse protocolo a fim de reduzir o aumento
da mensagem ocasionado pelo uso do HTTP, [Shelby, 2010], [Chopan,2009].
As vantagens oferecidas pela introdução de suporte para os padrões da Web
diretamente no nível de dispositivo são benéficas para o desenvolvimento de uma nova
geração de aplicações que conterão informações do mundo real além dos conteúdos
estáticos como acontece atualmente. O emprego dos padrões Web também como base
comum para diferentes dispositivos torna muito mais simples a programação dos
mesmos. Aplicar os mesmos princípios de design que foram responsáveis para o
sucesso da Web, em particular abertura e simplicidade, pode alavancar
significativamente a ubiqüidade e versatilidade da Web como um terreno comum para
dispositivos de rede e aplicações. Além disso, como a maioria das linguagens de
programação suportam HTTP, percebe-se a enorme comunidade de desenvolvedores da
Web como potenciais desenvolvedores de aplicações para a Web das Coisas.
Agradecimentos
Este trabalho foi parcialmente suportado pelas agências de fomento CNPq,
FINEP e FAPERJ, sob os processos de número 201090/2009-0, 306938/2008-1 e
477229/2009-3 para Flávia 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.
Referências
Ant. Apache Ant, 2010. Disponível em <http://ant.apache.org/>. Acessado em 08 de
março de 2011.
Atom. Atom Enable, 2004.Disponível 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. 2787–2805.
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. Disponível em: <
http://www.sbc.org.br/bibliotecadigital/download.php?paper=1550>. Acessado em
14 de Novembro de 2010.
Chumby, 2011. Disponível 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.
Disponível
em:
<http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=5066664>. Acessado em
05 de Novembro de 2010
Eclipse, 2011. Disponível em <http://www.eclipse.org/>. Acessado em 08 de março de
2011.
EMML. Enterprise Mashup Markup Language, Open Mashup Alliance, 2010.
Disponível em <http://www.openmashup.org/>. Acessado em 18 de Novembro de
2010.
Ferreira Filho, O. F. Serviços semânticos: uma abordagem RESTful. Dissertação de
mestrado,
USP,
2010.
Disponível
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. Disponível em <http://code.google.com/intl/ptBR/apis/maps/index.html>. Acessado em 3 de Março 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.
Disponível
em
<http://www.bibsonomy.org/bibtex/2dcc3fabe2de456144254afdcc8e06776/flint63>.
Acessado em 28 de Janeiro de 2011.
Gumstix, 2010. Disponível 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. Disponível 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.
Disponívelem<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. Disponível 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. Disponível 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. Disponível em <http://jersey.java.net/>. Acessado em 16 de Março de
2011.
JSON. JavaScript Object Notation, 1999. Disponível em < JavaScript Object
Notation>. Acessado em 18 de Março 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.
Disponível
em
<http://www.vladtrifa.com/files/publications/Mayer10.pdf>.
Acessado em 02 de Dezembro de 2010.
Nabaztag, 2009. Disponível em
Acessado em 5 de Janeiro de 2011.
<http://www.nabaztag.com/brasil/index.html>.
NetBeans, 2011. Disponível em <http://netbeans.org/>. Acessado em 08 de Março 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. Disponível em <http://www.dni.gov/nic/NIC_home.html>. Acessado em 10 de
Fevereiro de 2011.
Oracle,
JDK
(Java
SE
Development
Kit),
2010.
Disponível
em
<http://www.oracle.com/technetwork/java/javase/downloads/index.html>. Acessado
em 08 de Março 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. Disponível em
<http://portal.acm.org/citation.cfm?id=1367606>. Acessado em 02 de Dezembro de
2010.
Plogg.
Wireless
Energy
Management,
2010.
Disponível
<http://www.plogginternational.com/>. Acessado em 5 de Janeiro de 2011.
em
Poken, 2010. Disponível em <http://www.poken.com/>. Acessado em 5 de Janeiro de
2011.
149
Presto.
Mashup
Developer
Community,
2010.
Disponível
em
<http://www.jackbe.com/enterprise-mashup/>. Acessado em 20 de Janeiro de 2011.
Reverse
HTTP.
draft-lentczner-rhttp-00.
IETF,
2009.
Disponível
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. Disponível em
<http://tools.ietf.org/html/rfc2068>. Acessado em 20 de Fevereiro de 2011.
RFC 2616.
Hypertext Transfer Protocol - HTTP/1.1, 1999. Disponível
RFC 4287. The Atom Syndication Format, 2005. Disponível
em
RFC 4944. Transmission of IPv6 Packets over IEEE 802.15.4 Networks, IETF 2007.
Disponível em <http://tools.ietf.org/html/rfc4944>. Acessado em 10 de Março de
2011.
RFC 5785. Defining Well-Known Uniform Resource Identifiers (URIs), 2010.
Disponível em <http://tools.ietf.org/html/rfc5785>. Acessado em 20 de Fevereiro de
2011.
Richardson L.; Ruby, S. RESTful Web Services. O’Reilly 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, Disponível 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. Disponível
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.
Disponível
em
<http://www.oracle.com/technetwork/articles/javase/index-137171.html>. Acessado
em 3 de Março de 2011.
Webber, J.; Parastidis, S.; Robinson, I. REST in Practice, Hypermedia and Systems
Architecture. O´Reilly, 2010, p. 86-95; 386-387.
Wilde,
E.
Putting
Things
to
REST,
2007.
Disponível
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 Zürich, Zürich, Switzerland, No.
663, February 2010
WSDL. Web Service Description Language, W3C, 2007. Disponível
<http://www.w3.org/TR/wsdl20/>. Acessado em 15 de março 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.
Capítulo
4
Gerência 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, specific devices applied, proposed architectures and future perspectives.
Resumo
A Internet como uma plataforma de comunicação ubíqua tem evoluído rapidamente nos
últimos anos. Cada vez mais, os serviços estão migrando para uma rede totalmente IP,
enfatizando os limites da Internet atual e motivando a construção da Internet do Futuro.
As novas arquiteturas de rede são mais complexas, mais distribuídas e, idealmente, mais
seguras. No entanto, como novas tecnologias também surgem, novos requisitos e preocupações com segurança são ressaltados. Desta forma, a Internet do Futuro destaca a
importância da gerência de identidade dos usuários finais em relação ao fornecimento e
utilização dos seus dados pessoais e a necessidade de acesso a uma arquitetura de serviços dinâmicos. Este minicurso apresenta uma visão geral sobre o estado da arte em
pesquisas relacionadas ao gerenciamento de identidades na Internet do Futuro, particularmente nas redes da próxima geração, enfatizando os desafios, os métodos de criptografia utilizados, os dispositivos específicos, as arquiteturas propostas e perspectivas
futuras.
152
4.1. Introdução
A Internet atual desempenha um papel fundamental na sociedade fornecendo intercâmbio
de informações e ambiente de comunicação nas relações comerciais e interações sociais.
Pessoas do mundo inteiro dependem hoje da Internet para manter o contato com a família
e amigos, localizar, acessar e trocar informações, desfrutando de comunicação multimídia
e utilizando serviços de software avançados. Com a popularização da Internet, as expectativas aumentaram em relação às novas aplicações e serviços em diferentes áreas, tais
como saúde, transporte automotivo e de emergência.
A grande utilização da Internet atual tem demonstrado as suas restrições e motivado o desenvolvimento da chamada Internet do Futuro. Uma das principais premissas
para a Internet do Futuro é a disponibilidade e eficiência de vários serviços e, acima de
tudo, sua constante disponibilização ao público [Paul et al. 2011]. A Internet do Futuro
se diferencia da Internet existente pelo aumento da dependência na informação distribuída, pelo controle descentralizado, e por avanços ditados pelo mercado e por regulamentações, além de uma forte exigência de segurança [FOKUS 2009]. A Internet do
Futuro é caracterizada por quatro dimensões, ilustradas na Figura 4.1, sendo a Internet
por e para as Pessoas, a Internet de Conteúdo, a Internet dos Serviços e a Internet das
Coisas, apoiadas por uma infraestrutura de rede, conhecida como Rede da Próxima Geração [Chim et al. 2011, Gomez-Skarmeta et al. 2010, Weber et al. 2010].
Figura 4.1. Dimensões da Internet do Futuro e a infraestrutura de rede
Os conceitos e serviços da Internet do Futuro possuem novas exigências e produzem condições diferentes, tornando impossível a utilização direta de soluções propostas
para a Internet existente. A segurança é um fator fundamental para a Internet do Futuro e
para os seus serviços por pretenderem ser universais e onipresentes. A heterogeneidade,
dinamicidade, interdependência e autonomia existentes entre os elementos da Internet do
Futuro aumentam as vulnerabilidades de segurança e a dificuldade de proteger a rede, os
serviços e as aplicações contra entidades maliciosas.
O gerenciamento de identidades tem atraído atenção nos últimos anos como uma
153
forma eficiente de prover confiança entre as entidades da Internet do Futuro, e de proteger
ou mitigar os efeitos de entidades maliciosas [Sabena et al. 2010, Sarma and Girão 2009].
O gerenciamento de identidade (do inglês, Identity Management ou IdM) identifica as entidades, e controla o acesso a recursos por meio de restrições impostas [Josang et al. 2005].
Existe um consenso entre os pesquisadores sobre o papel vital do gerenciamento de identidades em muitas aplicações estratégicas, incluindo aquelas visionadas pela Internet do
Futuro em diferentes contextos como entretenimento, saúde, investigações policiais, serviços fornecidos pelo governo (governo eletrônico ou e-government), comércio ubíquo
ou u-commerce, inteligência empresarial e segurança corporativa.
Em específico para as redes da próxima geração, a gerência de identidade desempenha um papel fundamental. Essas redes têm como base a transferência de pacotes para
prover serviços, incluindo aqueles de telecomunicação, e para se beneficiar de múltiplas
tecnologias e infraestruturas de comunicação, sendo as funcionalidades relacionadas aos
serviços independentes das tecnologias subjacentes de transporte dos pacotes. Essas redes
se caracterizam por uma forte separação entre as funções de controle relacionadas à transmissão dos pacotes e ao provimento de serviços. Elas também possuem acesso irrestrito
de usuários a diferentes provedores de serviços e uma variedade de sistemas de identificação para facilitar o controle da rede, além de necessitarem apresentar características
unificadas para um mesmo serviço quando considerada a perspectiva do usuário. Para
todas essas características, a gerência de identidade pode auxiliar a rede tendo conhecimento do perfil dos usuários, das características dos serviços e das políticas de acesso,
a fim de prover os serviços da forma mais eficiente possível aos usuários e garantindo a
transparência de operações desempenhadas pela rede, como a garantia da qualidade de
serviço, a mobilidade, o uso de diferentes tecnologias e outras.
Em face aos avanços e a importância que o uso de identidades vem ganhando, a gerência de identidades requer cada vez mais um suporte tecnológico [Hansen et al. 2008].
Um sistema de gerência de identidades (SGI) objetiva proporcionar assistência tecnológica para o controle e o monitoramento de identidades, entretanto, uma ferramenta holística para todos os fins de gestão de identidade ainda é inexistente. Os principais fatores
que vêm motivando e impulsionando o desenvolvimento de SGIs para a Internet do Futuro
são descritos a seguir.
Assistência à gerência de várias identidades digitais. Os usuários possuem atualmente
muitas contas (identidades digitais), onde os dados de autenticação, tais como senhas ou PINs, têm de ser memorizados. Como o conceito de identificação 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 serviços diferentes serão oferecidos. Os usuários precisam
de apoio conveniente para gerir essas identidades e os correspondentes métodos de
autenticação.
Auxílio na gerência de informações indesejadas ou na sobrecarga de informações. Os
usuários precisam de apoio prático para situações em que são abordados indesejadamente por outras pessoas ou até mesmo máquinas. A gestão de identidade pretende
facilitar o uso inteligente dos contatos dos usuários 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
comunicação de hoje não garantem a autenticidade e facilitam o roubo de identidades. Os sistemas que suportam métodos de autenticação, integridade e não repúdio,
tais como as assinaturas digitais, podem impedir o uso não autorizado despercebido
de identidades digitais. No entanto, o uso eficiente de sistemas de gerência de identidades também pode assistir na prevenção do uso não autorizado de identidades
digitais.
Falta de privacidade. Os usuários deixam rastros de dados usando redes de comunicação, sendo que a maioria dessas informações é 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 usuário pode controlar o quanto de suas informações é divulgado. O anonimato e pseudonimato são
métodos para controle e divulgação dessas informações que estão em desenvolvimento e que são considerados em sistemas de gerência de identidade atuais.
Controle e o monitoramento de identidades nas redes da próxima geração. Na perspectiva de infraestrutura de rede, o controle e o monitoramento de identidades auxilia no bom provimento de serviços. Conhecer a identidade de entidades e consequentemente o perfil dessas entidades, facilita a priorização no transporte de pacotes, auxilia as operações para garantir qualidade de serviço (QoS), torna mais
eficiente a identificação de redes diferentes que compõem a infraestrutura de rede e
torna mais confiável o controle de acesso. Entretanto, atualmente, diferentes arquiteturas de gerência de identidade existem, requerendo uma unificação dos sistemas
de controle e gerência de identidades a fim de garantir uma melhor eficiência das
operações da rede.
Em geral, os sistemas de gerência de identidade seguem três paradigmas principais: o paradigma puro de identidade, o paradigma voltado ao acesso do usuário e o
paradigma voltado a serviços. O paradigma puro de identidade sugere a criação, a gestão
e a supressão de identidades como operações básicas. O paradigma voltado ao acesso do
usuário implica na autenticação para ter acesso a um serviço. E o paradigma voltado ao
serviço personaliza a entrega de serviços sob-demanda aos usuários e seus dispositivos.
Esses paradigmas aplicam técnicas e ferramentas adequadas para cada um deles. O uso de
identidades digitais, biometria, cartões inteligentes e técnicas de criptografia baseada em
identidades são exemplos dessas técnicas e ferramentas aplicadas [Josang et al. 2005].
Com base nessas considerações, este minicurso apresenta uma visão geral sobre
o estado da arte em pesquisas relacionadas ao gerenciamento de identidades na Internet
do Futuro, com enfâse no gerenciamento de identidades nas redes da próxima geração.
Este minicurso ressalta os desafios, os métodos de criptografia utilizados, os dispositivos
específicos, as arquiteturas propostas e as perspectivas futuras. Inicialmente, os conceitos
de Internet do Futuro, de redes da próxima geração e de sistema de gerenciamento de
identidade são descritos. Em seguida, o minicurso está fundamentado sobre as redes da
próxima geração, ressaltando os requisitos de um sistema de gerência de identidade para
Internet do Futuro, o estado da arte das arquiteturas de gerência de identidade, os desafios
existentes e as perspectivas futuras. O minicurso será concluído com a descrição das
155
principais ferramentas de gerência de identidade e uma apresentação prática sobre o uso
de sistemas de cartões inteligentes multiaplicações empregados para gerenciar e unificar
identidades digitais, enfatizando as dificuldades 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 intensificando com o aumento de financiamentos oriundos de organizações
comerciais, acadêmicas e governamentais para a execução de projetos de pesquisa e desenvolvimento. Não há, entretanto, uma visão uniforme sobre o que a Internet do Futuro
será, nem existe um acordo sobre quais são os objetivos das diversas atividades concorrentes da Internet do Futuro. Embora muitas discussões neste contexto tenham como foco
os aspectos técnicos (por exemplo, questões relacionadas a como o endereçamento ou o
roteamento devem ser feitos na Internet do Futuro), um consenso nas discussões sobre a
Internet do Futuro é a perspectiva voltada a serviços.
Dessa forma, nesta seção a Internet do Futuro será abordada sob uma perspectiva
menos orientada a protocolo e mais orientada a serviços. Para a maioria dos usuários, a
Internet é definida como um conjunto de serviços. A maioria das pessoas associam a Internet com o fácil acesso à informação e motores de pesquisa, a disponibilidade de vídeos,
músicas ou serviços de entretenimento e o acesso on-line a plataformas de negociação,
serviços de comunicação pessoal ou plataformas de redes sociais, visto que a maioria dos
usuários da Internet não estão cientes da importância da rede subjacente, ou seja, da infraestrutura de rede propriamente dita. Entretanto, entender como os usuários utilizarão a
Internet do Futuro e a relação dos serviços com as redes de comunicação subjacentes são
primordiais para identificar os requisitos que a infraestrutura de rede deve apoiar.
Primeiro, é importante salientar que os serviços da Internet do Futuro estão sendo
construídos com base nas seguintes tecnologias:
Acesso ubíquo 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 fio,
assume-se que a conectividade será cada vez mais onipresente e barata. Na verdade, assume-se que o acesso à rede será tão difundido quanto o acesso atual à
eletricidade.
Novas técnicas da interação homem-computador: a disponibilidade da tecnologia de
sensores compacta e barata e as novas tecnologias de visualização revolucionarão a
forma como se interage com os computadores. A interação com computadores através de gestos e visores embutidos nos objetos do cotidiano irá mudar a forma como
se utiliza os computadores. Inovações significativas são esperadas nesta área, como
novas técnicas de interação homem-computador para ajudar a distinguir produtos.
Sensores e a disponibilidade de contexto rico em informações: a tecnologia de sensores está permitindo novas formas de interação homem-máquina, como também novas aplicações. Espera-se que os sensores sejam integrados em muitos produtos
de uso diário, dando acesso a informações contextuais. O acesso ubíquo aos dados fornecidos por sensores favorecerá o desenvolvimento de novas aplicações e
serviços.
156
Conteúdos e serviços gerados pelo usuário (mashups): as tecnologias que permitem o
fácil gerenciamento de conteúdos e serviços gerados pelo usuário estão se desenvolvendo rapidamente. Estima-se que o próximo grande passo seja o desenvolvimento de tecnologias de mashup, permitindo que os usuários combinem facilmente
conteúdos e serviços existentes para fornecer novos formatos e serviços integrados [Benslimane et al. 2008]. As tecnologias de Web semântica têm um grande
potencial para fomentar o avanço da tecnologia mashup, uma vez que elas têm evoluído a cada dia e tornam-se maduras e acessíveis o suficiente para o uso por uma
grande quantidade de usuários.
Tendo como referência o comportamento da maioria dos usuários da Internet,
acredita-se que alguns avanços irão moldar a evolução da Internet do Futuro. Dentre
esses avanços, destacam-se os serviços personalizados. Começando com resultados de
buscas personalizadas e sensíveis ao contexto, considera-se que haverá um número cada
vez maior de produções da mídia direcionadas a grupos de interesse especiais, e serviços de entretenimento que adaptam a música preferida ou o estilo do filme ao humor dos
usuários [Alduán et al. 2011, Chai et al. 2011, Choi et al. 2011]. Fortemente relacionadas com os serviços personalizados estão as redes sociais, que associam usuários com
interesses comuns. Elas representam digitalmente as relações pessoais e fornecem uma
referência importante para as questões de identidade e de confiança na Internet. Estima-se
ainda que as redes sociais se tornarão móveis e cientes do contexto no futuro próximo.
Outros avanços que deverão auxiliar na definição da Internet do Futuro são a privacidade e o anonimato. Essas duas questões vêm se tornando cada vez mais importantes
para os usuários da Internet [Maghiros et al. 2006]. Apesar da consciência para essas duas
questões ainda ser pouco desenvolvida no contexto atual dos utilizadores da Internet, os
primeiros sinais de mudança já são observados. Hoje, existe um mercado especializado
de empresas que oferecem serviços de privacidade na Internet para pessoas famosas, e
espera-se que a sensibilidade dos usuários da Internet para as preocupações ligadas à privacidade e ao anonimato também aumente.
Além desses avanços, a era dos computadores pessoais instalados com um grande
número de aplicações está chegando ao fim. No futuro, a tendência é ver muitos clientes
usando a rede para prover desde o armazenamento de dados até o uso de aplicativos,
os quais serão fornecidos como serviços. Isso auxiliará os usuários a lidar melhor com
atividades assessórias, como backups e atualizações de software. Além disso, o poder
de computação pode ser acessado quando necessário, através de servidores dedicados
organizados em rede (por vezes, chamados de computação em nuvem [Li et al. 2009,
Zhou et al. 2010]), reduzindo assim os custos de manutenção do sistema.
Outras questões, como robustez, disponibilidade, confiabilidade e segurança, serão de grande preocupação para os usuários da Internet uma vez que eles dependerão cada
vez mais desses serviços [Heegaard and Trivedi 2009]. A Internet do Futuro precisa ser
tratada como uma infraestrutura crítica semelhante às redes de energia ou fontes de água
fresca. No entanto, os meios para alcançar um elevado nível de robustez na Internet do
Futuro será muito diferente comparado ao uso de estruturas de controle hierárquicas. A
robustez na Internet do Futuro tende a ser alcançada usando abordagens distribuídas.
157
4.2.1. Exemplos de serviços da Internet do Futuro
Espera-se que um grande número de novos serviços sejam criados com o advento da Internet do Futuro. Essa subseção apresenta exemplos de serviços da Internet do Futuro
como forma de mostrar a importância na evolução da mesma e a necessidade de garantir
um controle e monitoramento de identidades eficiente e seguro. Essa subseção oferece
uma visão geral dos novos serviços, enfatizando que todos eles têm como suporte a infraestrutura de rede subjacente apresentada na subseção 4.2.2.
Garantias de armazenamento distribuído
Até recentemente, o armazenamento de dados era realizado em mídias como discos rígidos ou DVDs e era considerado como armazenamento centralizado. Esse modelo de
armazenamento possui várias desvantagens. A informação, por exemplo, não está disponível em todos os lugares, versões antigas dos arquivos geralmente não são arquivadas e
os meios físicos têm vida útil limitada. Como muitos usuários de computadores pessoais
não fazem backups regulares, existe um risco elevado de perda de dados de alto valor
pessoal como fotos de férias, gravações de áudio ou vídeos pessoais.
No futuro, estima-se que os dados pessoais irão ser armazenados em redes de
armazenamento distribuído. Os serviços de armazenamento irão oferecer virtualmente
uma quantidade ilimitada de memória, e irão manter um histórico de todas as alterações
nos arquivos do usuário, além de tornar os dados acessíveis em qualquer lugar para uma
ampla quantidade de dispositivos diferentes. Eles irão ainda prestar serviços de privacidade, e oferecerão garantias de armazenamento, através de um certo número de cópias
redundantes, por exemplo.
Vários protótipos de serviços de armazenamento totalmente distribuído já existem. Eles têm como base tecnologias par-a-par. Entretanto, esses protótipos normalmente
não possuem algumas das características mencionadas como a privacidade e a disponibilização dos dados a qualquer momento, em qualquer lugar e a qualquer dispositivo. Além
disso, a capacidade de armazenamento disponibilizada é geralmente limitada. Os sistemas muitas vezes supõem que os dispositivos de armazenamento cooperativos estão localizados em computadores tradicionais, e por isso não possuem interfaces que permitam
a interação direta com dispositivos como câmeras, telas sensíveis ao toque incorporadas
aos dispositivos móveis ou roupas inteligentes.
Armazenamento da vida cotidiana através de multimídia
Com o armazenamento em rede tornando-se bastante disponível e com a miniaturização
de microfones e câmeras, será cada vez mais comum para as pessoas a gravação de grande
parte dos acontecimentos de sua vida. Hoje, já existem pessoas carregando sempre uma
câmera e registrando tudo o que vêem. No entanto, esta tecnologia tem muito mais potencial. Os dados recolhidos por microtelefones e câmeras podem ser combinados com
informações provenientes do próprio uso de outros dispositivos técnicos, como carros ou
motos, e de sensores incorporados em objetos do quotidiano.
Tal comportamento, ajudará a prover serviços inovadores aos usuários, como buscas personalizadas e eficientes, assim como assistirá o gerenciamento da infraestrutura
de rede contribuindo para a qualidade dos serviços. Atualmente, existem grupos de pes-
158
quisa que investigam os efeitos de comportamentos sociais nos serviços fornecidos pela
Internet [Benevenuto et al. 2009, Boccaletti et al. 2006]. Também existem iniciativas que
aplicam o conhecimento adquirido na caracterização do comportamento dos usuários desenvolvendo soluções para gerência de redes orientada ao contexto e ao comportamento
dos usuários [Boldrini et al. 2010, Hui et al. 2011, Li and Sandrasegaran 2005]. Entretanto, os principais desafios existentes nessa abordagem são a integração de várias fontes
de dados e a indexação automatizada para a sustentação da recuperação eficiente da informação relevante. Por razões óbvias, a proteção de privacidade eficaz deve ser implementada em soluções que seguem essa abordagem.
Serviços de saúde
Os serviços médicos fornecidos por profissionais vêm sofrendo grandes modificações. A
disponibilidade de dispositivos baratos de monitoramento em rede da saúde e os avanços
nos sensores embarcados em todos os objetos do dia-a-dia dará aos médicos detalhes
sobre nossos corpos. Pessoas com riscos especiais providenciarão acesso direto aos dados
sobre as funcionalidades essenciais de seus corpos, além de se visionar a disponibilização
de serviços de monitoramento do corpo on-line, facilitando uma assistência rápida em
caso de emergência.
Com a disponibilidade de maiores quantidades de dados médicos, haverá uma
tendência da personalização da medicina. A medicina personalizada começa com a seleção de combinações de fármacos otimizados para uma condição específica do paciente,
oferecendo a oportunidade de produzir medicamentos personalizados, combinando produtos químicos de maneiras específicas para otimizar os efeitos positivos para o paciente,
reduzindo assim os efeitos colaterais indesejados.
No contexto dos serviços de saúde, pode-se também vislumbrar novas formas de
diagnóstico on-line. Perguntas como "Estou grávida?"poderiam ser respondidas por um
sistema de busca semântica, permitindo que o sistema tenha acesso aos dados coletados
por sensores instalados no banheiro, por exemplo. Muitas tarefas de diagnóstico padrão
podem ser potencialmente oferecidas como serviços on-line conectados a mashups médicos integrando fabricantes farmacêuticos, comerciantes, comunidades on-line e sistemas
de busca semântica especializados.
Serviço de entretenimento personalizado
Com a Internet do Futuro, existe uma forte tendência sobre a personalização dos serviços
de entretenimento. As ofertas on-line de músicas, filmes ou jogos não levará apenas em
conta as preferências estáticas em relação aos diferentes estilos de música ou de tipos
de jogos, mas também considerarão o contexto mais amplo, e em especial o humor, as
habilidades e os interesses dos usuários. As estações de rádio on-line proporcionarão
a música que melhor corresponda às atividades atuais. Dependendo se o usuário está
cozinhando ou limpando a cozinha, ele receberá diferentes estilos de músicas e as músicas
tocadas podem até ser selecionadas com base no tempo disponível para a realização da
atividade.
Em geral, é esperado um crescimento da interação entre os objetos do mundo real
e os objetos que só existem em mundos virtuais. As chamadas interfaces de realidade
159
mista permitirão novas formas de participar de jogos multiparticipantes on-line. Os jogos
multiparticipantes já são utilizados por milhões de usuários, e os números ainda tendem a
crescer. Nestes jogos a interação social é fundamental, pois os jogadores formam grupos
a fim de resolver problemas juntos. Com a integração da realidade virtual e o mundo
real, os grupos formados e a interação entre os participantes levam a novas experiências
e informações que podem inclusive serem utilizadas para um gerenciamento eficiente da
infraestrutura de rede.
4.2.2. Redes da próxima geração
As redes da próxima geração, do inglês Next Generation Networks ou NGN, são visionadas como uma resposta aos operadores e fornecedores de redes e serviços a fim de
substituir as redes de telefonia existentes, bem como introduzir uma nova plataforma
de serviços convergentes entre as redes fixas e as redes móveis [Akyildiz et al. 2006,
Park and Rappaport 2007, Prasad et al. 2008, Song and Jamalipour 2005]. É geralmente
um consenso que a principal diferença entre as redes de telecomunicações tradicionais e
as redes da próxima geração seja a mudança de um paradigma de redes de comunicação
voltadas a aplicações específicas, separadas e verticalmente integradas para um paradigma
de uma única rede capaz de executar qualquer serviço. A NGN está essencialmente relacionada ao fornecimento de novos serviços que serão disponibilizados de forma pervasiva
e ubíqua, ou seja, em qualquer lugar, a qualquer hora e em qualquer dispositivo, através
de qualquer meio de acesso escolhido pelo cliente.
Espera-se das redes da próxima geração uma coexistência e intercomunicação entre as redes com fio (xDSL, Metro Ethernet, FTTH, ISDN e outras), as redes sem fio
(2G, 3G, WLAN, WiMAX/WiBro e outras), bem como as redes por satélites e as redes de radiodifusão, todas interligadas por um backbone de redes que utilizam o protocolo IP (Internet Protocol) e pela Internet. Neste ambiente de rede heterogêneo, além
dos desafios tradicionais com segurança, QoS (Quality of Service) e tarifação, os novos desafios como mobilidade generalizada, descoberta e seleção de rede devem existir [Song and Jamalipour 2005]. Fornecer uma gerência eficaz, segura e eficiente do ambiente e da operação das redes da próxima geração é um enorme desafio. Esta subseção
apresenta um breve panorama das redes da próxima geração tendo como base a definição e arquitetura funcional usada pela ITU-T (International Telecommunication Union,
Standadization Sector) [ITU-T 2004].
Uma NGN é uma rede baseada em pacotes de suporte à transferência de diferentes
tipos de tráfego, como voz, vídeo e dados [Sakellari p053]. A Figura 4.2 apresenta uma
visão geral da arquitetura funcional da NGN [ITU-T 2004]. Essa rede espera integrar os
serviços oferecidos pelas redes tradicionais e os inovadores serviços IP em uma única
plataforma de serviços, sendo que essa integração deve ser mais transparente possível
para o usuário final [Salsano et al. 2008]. A NGN faz uma forte distinção lógica e física
entre a rede de serviços, a rede de transporte de dados (também chamada de rede de
base ou núcleo da NGN) e a rede de acesso. A rede de serviços possui funcionalidades
relacionadas aos serviços, independentes das tecnologias de transporte subjacentes. As
funcionalidades da rede de serviços se concernem às aplicações e aos serviços 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 próxima geração
de dados oferecendo transferência física de informações entre as entidades envolvidas no
processo de comunicação (como os usuários, os computadores ou os dispositivos móveis).
A rede de acesso é composta pelas várias tecnologias de acesso ao meio de comunicação
existentes como as tecnologia de comunicação com fio e sem fio.
A rede de serviço é composta por vários servidores, tais como servidor Web,
os servidores de Autenticação, Autorização e Contabilidade, do inglês Authentication,
Authorization and Accounting (AAA), o servidor SIP Proxy, o servidor LDAP, entre outros. Ela é responsável apenas pelo fornecimento dos serviços e das aplicações para os
usuários da NGN. A conexão entre a rede de serviços 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 transferência de
informações entre as entidades pares e deve suportar os diferentes serviços oferecidos
pela rede de serviços. Além da transferência de pacotes, as funcionalidades voltadas ao
controle e gerenciamento da infraestrutura de rede também são implementadas na rede de
base [Choi and Hong 2007, Kim and Shin 2008]. A rede de base também é responsável
por tornar transparente para os usuários e serviços a convergência de redes e tecnologias.
A rede de acesso em NGN é derivada das tecnologias de acesso existentes. Para
acomodar vários meios de acesso, esta rede é separada da rede de base, servindo como um
161
nível intermediário entre os equipamentos dos usuários e o núcleo da rede da próxima geração. Cada tecnologia de acesso deverá ser usada tal como foi previamente especificada.
Dessa forma, a rede de acesso consiste na prática de um conjunto de redes diferentes tais
como redes sem fio ad hoc, redes de comunicação por satélite, redes cabeadas e outras.
A arquitetura das redes da próxima geração precisa oferecer uma flexibilidade de
configuração para suportar várias tecnologias de acesso. Ela precisa também de um apoio
distribuído e de mecanismos de controle e de gerência de identidade abertos. Estes devem
proporcionar uma separação e identificação nos serviços oferecidos pela operação da rede
de transporte e melhorar a oferta de serviços diversificados da NGN.
As funcionalidades voltadas à gerência de rede permitem ao operador da NGN
controlar a rede e prover os serviços da NGN com a qualidade, segurança e confiabilidade
esperadas. As funcionalidades de gerência são aplicáveis às redes de transporte e de
serviços da NGN, e cobrem as áreas de gerência de falhas, configuração, contabilização,
desempenho e segurança. As funções de usuário final são formadas por interfaces que
permitem ao usuário se conectar à rede de acesso da NGN, por meio de equipamentos
móveis ou fixos.
4.3. Gerência de Identidade
Desde o início de sua história, o ser humano sente a necessidade de estabelecer relações
comerciais. Os povos primitivos já utilizavam o comércio, na forma de escambo, através
do qual trocavam os alimentos que possuíam em excesso por outros de que necessitavam. Ao longo da história, as relações comerciais passaram por profundas mudanças, que
possibilitaram a evolução dessas relações e a criação de novas oportunidades. O desenvolvimento da Internet gerou uma revolução nas relações comerciais, aproximando pessoas e
criando novas necessidades de produtos e serviços. Com o surgimento do mundo virtual,
novas ferramentas foram desenvolvidas, o que gerou mudanças na forma de relacionamento e nos conceitos envolvidos nas transações.
Para que as relações comerciais sejam estabelecidas, é necessário que as partes
envolvidas possuam algum nível de conhecimento sobre a outra parte. Conhecer a outra
parte é importante para saber que nível de confiança pode ser depositado nela e se ela é
idônea, pressupondo assim, se irá cumprir ou não a sua parte na transação. Nas relações
tradicionais, em que há algum tipo de contato direto entre as partes, a troca de informações
ocorre de forma natural. Até mesmo a impressão causada pelo contato entre as partes pode
influenciar no estabelecimento de confiança entre elas.
Nos novos serviços fornecidos pelas redes da próxima geração, assim como nos
serviços virtuais em geral, é ainda mais importante conhecer a outra parte envolvida na
comunicação ou nas transações. No contexto do mundo virtual, a resposta para perguntas
relacionadas ao parceiro comercial ou provedor de serviços envolvem conceitos sobre
entidade, identidade, identificador e credencial. Conhecer esses conceitos é importante
para compreender como acontecem as operações de autenticação e autorização, e como
elas podem ser aplicadas no provimento de serviços da Internet do Futuro.
Para que uma transação aconteça, é necessário que haja algum nível de confiança
entre as partes. Quando essa confiança não pode ser estabelecida diretamente, é neces-
162
sária a interação por meio de um intermediário confiável para ambas as partes (também
chamado de terceira parte), como demonstrado na Figura 4.3. Nas relações comerciais
tradicionais, o papel do intermediário é feito por um fiador em uma locação, por exemplo,
ou por uma instituição financeira nos casos de compra com cheque ou cartão de crédito.
No mundo virtual, muitos negócios são feitos sem o contato direto entre as partes. Neste
caso, para que as relações de confiança sejam estabelecidas, é importante o envolvimento
de uma terceira parte. Esta terceira parte é responsável por fornecer informações sobre o
parceiro, dando origem ao conceito de identificação.
Figura 4.3. Relação comercial envolvendo um intermediário
As identidades das partes envolvidas na transação são controladas e monitoradas
por sistemas de gerência de identidade (SGIs). Estes são programas ou frameworks que
administram uma coleção de identidades, realizam sua autenticação, gerenciam seu uso e
as informações vinculadas à identidade [Maliki and Seigneur 2007]. Os SGIs tradicionais
são utilizados como mecanismos de autenticação e autorização, sendo esse primeiro mecanismo responsável por estabelecer a confiança entre o sistema e a identidade informada,
e o segundo responsável por fornecer à identidade permissões para realizar determinadas
ações no sistema. Além disso, os sistemas tradicionais criam perfis relacionados às identidades e armazenam informações sobre o seu uso. No entanto, novos modelos têm sido
propostos, alguns otimizados para atender aos objetivos do usuário, outros otimizados
para tratar de questões relacionadas à infraestrutura de redes ou requisitos das aplicações
e serviços. Essa mudança de paradigma é necessária para atender às novas características
resultantes da NGN.
4.3.1. Entidade, identidade e credencial
Considerando a importância da identificação, esta subseção descreve os conceitos envolvidos no processo de identificação, tais como entidades, identidades, identificadores e
credenciais.
• Sistema é um conjunto de software e hardware que armazena informações sobre
entidades, credenciais, identidades e processamento das operações relacionadas aos
seus ciclos de vida. Pode ser uma rede de serviços armazenando informações sobre
seus clientes, por exemplo. Um sistema geralmente protege seus dados ou serviços
e, portanto, utiliza autenticação e autorização.
• Entidade pode ser um pessoa, um serviço de rede, um dispositivo computacional
em rede ou um dispositivo de telefonia móvel. As entidades existem no mundo
163
real. Elas usam credenciais e possuem um ciclo de vida separado do ciclo de vida
de qualquer identidade, identificador ou credencial associada.
• Identidade é um instrumento utilizado por uma entidade para fornecer informações
sobre si para o sistema. Ao contrário da entidade, a identidade é um conceito virtual
e não existe no mundo real. Uma identidade sempre está associada a uma entidade
e geralmente é formada por um identificador único. O identificador é utilizado para
provar a propriedade da identidade (por meio de credenciais) e fornecer informações (perfil) a um sistema. O sistema irá utilizar essas informações para tomar
decisões sobre a entidade associada.
Uma entidade pode ter várias identidades, usando identidades diferentes para acessar sistemas diversos, a menos que esses sistemas se comuniquem e troquem informações sobre as entidades. Identidades diferentes também podem ser utilizadas
para acessar um único sistema, quando a entidade o utiliza para fins diferentes. Por
exemplo, um usuário pode ter uma identidade de usuário comum e outra como um
contador da empresa.
• Identificador é o índice único de uma identidade. Normalmente, um identificador é
usado pelo sistema para referenciar uma identidade. Deve ser exclusivo dentro de
um sistema, mas pode ser reutilizado em vários sistemas.
• Credencial é utilizada para provar uma identidade em um sistema. Podem haver
vários tipos de credenciais, mas todas são utilizadas para provar a um sistema (com
um nível aceitável de segurança) que uma entidade tem realmente o direito de usar
determinada identidade. Algumas credenciais são estabelecidas entre a entidade e
o sistema (como uma senha) e algumas são emitidas por uma terceira parte (como
um passaporte).
A Figura 4.4 demonstra a relação entre entidade, identidade, identificador, credencial e sistema.
Figura 4.4. Relação entre entidade, identidade, identificador e credencial
Os conceitos de identificadores e credenciais podem parecer confusos e em alguns,
casos até podemos usar um no lugar do outro. A principal diferença entre identificadores e
credenciais é o fato de que um identificador deve necessariamente ser único e a credencial
não. Apesar de ser único, o identificador pode ser a união de outros itens não únicos.
164
As credenciais podem ser geradas automaticamente pelo sistema (como as senhas
temporárias geradas pelo sistema quando um usuário a esquece) ou podem ser criadas
a partir de características particulares, como as características biométricas, por exemplo.
Podem ser utilizados também métodos híbridos, ou seja, métodos que utilizam tanto a
criação manual de uma identidade quanto a sua geração automática. Os métodos híbridos
permitem ao usuário escolher seu identificador e, caso este já esteja em uso, o sistema
oferece identificadores alternativos. Uma visão sobre algumas possíveis fontes e tipos de
informação são mostradas na Figura 4.5.
1 e apenas 1 por sistema
0 ou mais
Informações Pessoais
Itens Públicos
Nome
Sobrenome
Data de nascimento
Chave pública PKI
Assinatura
Fotografia da face
Itens Privados
Chave Privada PKI
Senhas
PINs
Identificador
Biometria
Impressão digital
Scan da íris e retina
Assinatura manuscrita
Imagem da face
Gerados pelo Sistema
Número de Passaporte
Número de Identidade
Número de CPF
Credenciais
Figura 4.5. Fontes de informação
Para que uma entidade consiga acessar o sistema, primeiramente ela informa o
seu identificador. Isso é necessário para informar ao sistema quem está solicitando o
acesso. O próximo passo é fornecer provas de que essa entidade tem permissão para usar
esse identificador, o que é feito informando a credencial. Uma vez concedido o acesso,
o sistema irá conceder alguns privilégios para que a entidade possa efetuar determinadas
ações. Essa concessão de privilégios é chamada de autorização. Dentro deste contexto, há
também o conceito de auditoria, que é um registro do que aconteceu e quando aconteceu.
A fim de complementar os procedimentos descritos previamente, o sistema realiza um
conjunto de registros, associando a entidade às suas ações. O ideal é que os registros
sejam comprobatórios, fornecendo informações que possam ser utilizadas em caso de
conflitos.
Esse conjunto de procedimentos descritos no parágrafo anterior descreve as quatro principais operações de um SGI, a identificação, a autenticação, a autorização e a
auditoria. Um resumo desses procedimentos são descritos a seguir.
• Identificação é a ação de uma entidade fornecer uma identidade ao sistema por meio
de um identificador;
• Autenticação é a ação do sistema verificar a legitimidade de uma identidade por
meio da verificação de credenciais;
165
• Autorização é a ação do sistema conceder privilégios a uma entidade após a autenticação da sua identidade;
• Auditoria é a ação de registrar as ações 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 pública. Uma credencial privada é usada pela entidade para provar sua identidade, enquanto a credencial pública é
usada pelo sistema para validar a anterior. Assim, uma credencial pode existir em pares:
• Credencial Privada é qualquer informação usada pela entidade para informar quem
é ou o que é. Pode ser secreta (como senha, PIN, chave secreta), elementos físicos
(token, cartão corporativo, cartão bancário), ou características físicas (biométricas,
como face, impressão digital).
• Credencial Pública é a contrapartida da credencial privada, utilizada para verificar
se a credencial privada é válida. Por exemplo, uma fotografia é uma credencial de
verificação da face de uma pessoa (uma credencial biométrica utilizada como uma
credencial privada). Outros exemplos de credencial pública são a assinatura, o hash
de uma senha (verifica se a senha informada gera o mesmo hash) ou uma chave
pública criptográfica, sendo a chave pública uma reprodução matemática da chave
privada criptográfica.
As credenciais são associadas a uma identidade específica, o que requer a criação
de um vínculo entre a credencial e a identidade. Esses vínculos são criados a partir de
mecanismos que geram uma associação entre partes de informações. Um sistema pode
acessar uma base de dados através de um vínculo ou de outro mecanismo sugerido pela
entidade. Os vínculos de informações podem ser criados pelo próprio sistema ou por uma
terceira parte. Exemplos de vínculos são informações de uma base de dados ligando um
usuário ao hash de sua senha, ou um certificado digital vinculado a uma chave pública.
Ou ainda, uma carteira de habilitação, que vincula a assinatura ou fotografia ao nome,
associando nome ao endereço ou nome à permissão para dirigir.
4.3.2. Ciclo de Vida
Assim como entidades, identidades e identificadores, as credenciais possuem um ciclo de
vida bem definido. Esse ciclo define o que acontece nas diversas fases da sua existência.
O ciclo de vida das entidades envolve os mesmos conceitos do ciclo de vida das pessoas:
criação, vida e morte. O problema está em sincronizar esse ciclo de vida às suas identidades e credenciais, considerando os estágios intermediários, pois podem haver regras
específicas a serem aplicadas de acordo com a idade, como votar aos 16 anos e dirigir aos
18. As entidades também podem ser máquinas ou telefones celulares. Neste caso, a credencial é criada quando o equipamento é produzido e ativada após a compra. É preciso ter
cuidado também com dispositivos compostos, por exemplo, deve-se definir se o telefone
166
é o aparelho celular ou apenas o cartão SIM (Subscriber Identity Module ou módulo de
identificação do assinante). Na verdade cada um tem sua própria identidade, e podem ser
rastreados individualmente ou ser adicionados a uma lista negra.
As identidades são associadas às entidades. O estágio de criação geralmente é
marcado pelo seu registro no sistema. Já o estágio de morte não pode ser um simples fim,
uma vez que os registros podem precisar ser guardados depois que a conta for cancelada.
O período de vida pode incluir atualizações da credencial e suspensões, 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 fim de manter os registros.
Já um identificador é um ponteiro único para uma identidade e geralmente possui
o mesmo ciclo de vida da identidade associada. No entanto, os identificadores podem
ser retidos indefinidamente, para garantir que não sejam realocados, o que poderia causar
confusão ou permitir fraudes posteriormente. Frequentemente as credenciais e os vínculos
têm seus próprios ciclos de vida, separados do ciclo de vida da entidade/identidade associada. As senhas podem existir apenas por 90 dias e geralmente são válidas por menos de
10 anos.
Criação
As credenciais e os vínculos são emitidos por provedores para as entidades, ou pelo menos acordado entre eles. Um provedor pode ser um sistema, quando emite credenciais
para que os usuários possam ser autenticados, ou um intermediário confiável tanto para
o sistema quanto para a entidade, a fim de gerar um vínculo adequado para autenticação
entre as duas partes. O vínculo pode incluir datas, para controlar o período de validade
da credencial. A emissão da credencial pode ser solicitada pelo usuário ao solicitar um
vínculo, como solicitação de um passaporte ou aquisição de um certificado digital, ou
desencadeada por eventos do tipo registro de nascimento, ao chegar a uma certa idade, a
conexão de um dispositivo à rede, por exemplo.
Vida
Algumas vezes as credenciais e seus vínculos necessitam de manutenção, como alterações
regulares da senha, renovação dos certificados digitais, dos passaportes ou da carteira de
habilitação. A renovação é uma forma simplificada do processo completo de registro. As
características dinâmicas das credenciais permitem que seu ‘valor conhecido’ mude durante a sua vida. As credenciais também podem ser suspensas. Isso é similar à revogação
de um certificado digital, exceto pelo fato de que é reversível.
Morte
As credenciais podem ‘morrer’ porque expiraram ou porque foram revogadas. Elas geralmente têm uma ‘data de expiração’ definida e depois desse período não será mais válida.
167
Alguns sistemas podem exigir que uma credencial não expire, pelo menos durante um período. Por exemplo, o controle de imigração pode insistir que um passaporte seja válido
por mais que seis meses a partir da data de entrada.
As credenciais também podem ser canceladas precocemente, devido a algum problema, como a não existência da entidade, a mudança nas circunstâncias ou a credencial
compromentida, esquecida ou descoberta por um fraudador. A maior dificuldade com
relação à revogação e suspensão é que a credencial em si não traz informações suficientes
sobre a sua validade, para isso é necessário utilizar recursos externos, tais como as listas
de revogação para verificar sua validade. Se a origem tornar-se indisponível ou apenas tiver informações sobre as credenciais revogadas por um período de tempo, há uma grande
probabilidade de que uma credencial seja ‘ressuscitada’. Neste caso será impossível resolver conflitos relacionados a seu uso histórico.
4.3.3. Sigle Sign-On
A autenticação única, ou single sign-on, é possibilitada devido aos benefícios que ela
oferece aos usuários, como a conveniência de não terem que lembrar de diferentes dados
de autenticação para múltiplos sistemas e devido aos diversos problemas que múltiplas
autenticações acarretam, como ter que redefinir senhas dezenas de vezes. A autenticação
única vem sendo considerada como um bom mecanismo de autenticação para as redes
NGN. Esse tipo de autenticação auxiliaria o controle de acesso aos diferentes tipos de
rede e ao ambiente heterogêneo resultante da NGN. Além disso, a autenticação única
parece promissora em relação aos possíveis benefícios que ela traria para a Internet do
Futuro como um todo, visto que diferentes serviços serão disponibilizados e uma única
autenticação facilitaria o uso desses serviços.
A autenticação única pode ser implementada de várias formas. Uma solução temporária é armazenar informações de logon do usuário para outros serviços. Dessa forma,
quando o usuário faz logon, ele ganha acesso a todos os serviços adicionais. A vantagem disso é que não é necessário acessar diretamente outros sistemas. Porém, isso pode
violar políticas de segurança ou contratos. Uma alternativa é integrar os serviços protegidos com a solução de autenticação única, de modo que um logon forneça as credenciais
que podem ser automaticamente armazenadas no cliente e informadas quando necessário
a outros serviços. Exemplos disso são o padrão Kerberos e o SiteMinder da Computer
Associates.
Todas as soluções que usam autenticação única, como as soluções de e-mail (Gmail),
armazenamento de arquivo (Google Docs), agenda e criação de páginas (Google sites) da
Google, por exemplo, devem utilizar as mesmas credenciais (no caso, senhas) para todos
os serviços. Isso permite o uso de senhas mais seguras (desde que o sistema force o usuário a usar uma senha mais complexa), uma vez que o usuário deverá lembrar apenas uma
credencial.
4.3.4. Usuários, Provedores de Identidade e Provedores de Serviços
Como mostra a Figura 4.6, em um sistema de gerência de identidade típico, podemos
identificar três entidades envolvidas: os usuários, o provedor de identidade e os provedores de serviços.
168
• Usuário (U) é uma entidade que utiliza um serviço fornecido por um provedor de
serviços. Os usuários utilizam SGIs para acessar serviços que exigem a certificação
de seus atributos por uma terceira parte. Isso é comum em acessos que envolvem
a Internet, pois os usuários não confiam na segurança da transmissão de dados.
Quando uma informação sensível, como o número do cartão de crédito, informações médicas ou credenciais, são transmitidas para uma empresa desconhecida, o
usuário hesita em usar a Internet. Portanto, a gerência de identidade tem por objetivo aumentar a confiança em processos que envolvem a Internet.
• Provedor de identidade (IdP) é uma entidade que controla as credenciais do usuário e provê serviços de autenticação. As companhias que fornecem algum grau de
identificação, como as Autoridades Certificadoras, normalmente fornecem alguns
serviços que se enquadram na definição de SGI. Tais serviços geralmente integram
uma cadeia de segurança exigida por algum tipo de negócio on-line, como um servidor de autenticação ou criptografia SSL.
• Provedor de serviços (PS) ou parte confiável é uma entidade que oferece um
ou mais serviços possíveis de serem acessados pelos usuários e utiliza os serviços
de uma IdP para autenticar um usuário. Os motivos que levam os provedores de
serviços a implantar um SGI coincidem, em partes, com os motivos que levam os
usuários a utilizá-lo. As organizações também atribuem importância às possibilidades de aumento de segurança. Além disso, é importante para ambas as partes ter
certeza sobre a autenticidade do parceiro de comunicação. Especialmente quando
se pode evitar fraudes utilizando este meio.
A Figura 4.6 ilustra a interação entre essas três entidades do sistema de gerência de
identidade. Na figura, o usuário solicita um serviço a um provedor de serviços. Este por
sua vez confia em um provedor de identidades, que fornece informações de autenticação
sobre o usuário.
Figura 4.6. Partes de um sistema de gerência de identidade
169
Regulamentos, tais como proteção da privacidade, devem ser respeitados por provedores de serviços. Uma SGI pode ajudar a organização a garantir e simplificar o cumprimento da legislação. Por influenciar a quantidade e a qualidade dos dados transmitidos,
a quantidade de informações pessoais fornecidas pelo usuário deve ser reduzida, por meio
do uso de pseudônimos e credenciais. Os pseudônimos são identificadores de entidade.
Uma entidade titular do pseudônimo pode ser identificada por meio dele. Denomina-se
pseudonimato o uso de pseudônimos como identificadores.
4.4. Requisitos de um Sistema de Gestão de Identidade na Internet do Futuro
Esta seção tem por objetivo definir os requisitos de SGIs que melhor satisfazem às necessidades da Internet do Futuro. Como mencionado anteriormente, segurança, privacidade
e identidade são alguns dos maiores desafios do desenvolvimento da nova Internet. SGIs
deficientes podem agravar problemas de segurança já existentes e criar novas oportunidades para obter informações pessoais de usuários [Dhamija and Dusseault 2008]. Especialistas têm indicado consistentemente privacidade, segurança e usabilidade como
requisitos essenciais de um SGI [Glässer and Vajihollahi 2008].
Privacidade
Privacidade é um requisito importante em todos os contextos da Internet do Futuro para
que haja compatibilidade legal. A Internet de serviços assim como toda a infraestrutura
de comunicação têm que cumprir leis e regulamentos relativos a direitos e privilégios dos
usuários e provedores. Dessa forma, as preocupações com a privacidade são o principal
fator para adoção de sistemas de gerência de identidade. Como a Internet do Futuro
pode envolver a transferência de informações sensíveis para diferentes partes, proteger a
privacidade permite evitar que informações pessoais dos usuários sejam usadas de forma
indevida, causando a perda de autonomia e liberdade.
Questões de privacidade
• Rastreamento de usuários entre domínios. Alguns SGIs têm a capacidade de rastrear um usuário em todos os sítios web que ele visita. Para manter a privacidade,
é necessário que o usuário permaneça anônimo ou use pseudônimos, para escolher
IdPs que não integrem todas as transações de todos os PSs e, finalmente, não auditem as ações do usuário. Muitos SGIs implementam partes dessa abordagem. No
entanto, espera-se que no contexto da Internet do Futuro, SGIs deverão implementar o máximo de anonimato e pseudonimato possível em todas os níveis: rede de
serviço, rede de base e rede de acesso.
• Acesso às informações sobre ações dos usuários. Nos SGIs atuais, o IdP é envolvido sempre que uma operação de autenticação é necessária em um provedor de
serviço. Dessa forma, o IdP pode guardar vestígios de todas as ações do usuário.
Além disso, em muitos sistemas, o usuário não é envolvido em todas as trocas de informações de identidade entre o IdP e o PS. Em novos SGIs, é necessário preservar
a privacidade das ações dos usuários.
170
• Proporcionalidade e subsidiariedade violadas com frequência. Muitas das leis de
privacidade têm como base o princípio da proporcionalidade e subsidiariedade. Esses princípios estabelecem que a quantidade de dados pessoais coletados seja proporcional ao objetivo para o qual eles são coletados, garantindo sempre a privacidade dos usuários. Muitas vezes os provedores de serviços violam esses princípios.
Esses provedores devem ser precisos com relação às informações pessoais necessárias para oferecer um serviço, e não devem solicitar mais informações do que as
necessárias. Torna-se dessa forma imprescindível a utilização de formas anônimas
para oferecer o mesmo serviço.
Segurança
Um SGI deve ser tão robusto quanto possível em relação a ataques contra disponibilidade,
integridade e confidencialidade dos seus serviços e informações. Isso é especialmente importante devido à grande concentração de informações do usuário que são armazenadas
e detalhadas. Todavia, há sempre o risco de espionagem, manipulação e roubo de identidade. Se alguém está usando uma identidade estrangeira sem autorização, pode ser difícil
ou até impossível para a pessoa autorizada provar que não era ela quem estava agindo.
Fraude digital não é facilmente detectável pelo parceiro contratual. Não é apenas a identidade que está sendo capturada, mas também a reputação ligada à identidade. Um SGI
deve prevenir o roubo de reputação tão bem quanto deve prevenir o plágio e permitir o
não-repúdio, se necessário.
Um requisito básico para segurança é que a autenticação seja exigida antes de todo
acesso a dados que seja disponibilizado para as pessoas autorizadas. A forma de autenticação depende do tipo de dado e da ação efetuada. O tipo e grau de segurança exigido
depende do significado e do valor dos dados processados. Quando há apenas a coleta
de informações, como em uma navegação na web, a segurança pode não ser tão importante como quando uma pessoa administra seu histórico médico. Devido a quantidade de
informações de identidade armazenadas e administradas por organizações, a segurança
também é um requisito essencial para o PS. Os frameworks de SGIs atuais implementam
técnicas, métodos e políticas para a segurança de informações de identidades. No entanto,
ainda existem várias vulnerabilidades [Alpár et al. 2011] como as descritas a seguir.
Questões de Segurança
• O IdP é um ponto único de falhas. Os sistemas de gerência de identidade exigem
que o usuário e o PS atribuam alto grau de confiança ao IdP. Todas as informações
da identidade são armazenadas nos IdPs, e os usuários não podem fazer nada além
de confiar neles para preservar sua privacidade e as informações de sua identidade.
Essa característica também pode ser usada para transformar um SGI em um sistema de vigilância em massa. Se o IdP se tornar uma autoridade, então ele pode
acessar diretamente todos os dados armazenados e relacionados aos serviços aceitos por esse IdP. Os sistemas de gerência de identidade devem impor a exigência de
que o usuário controle parte dos dados necessários para efetuar login no PS. Além
disso, o IdP precisa ser implementado ou seguir alguma forma de organização distribuída que preveja redundância e confiablidade em caso de falhas ou de ataques
171
que possam comprometer as informações das entidades.
• O risco de phishing. Muitos dos SGIs atuais apenas oferecem um meio de autenticar o usuário, sendo impossível para o usuário autenticar o IdP ou o PS. Isso
é necessário para prevenir ataques de phishing, em que os atacantes induzem o
usuário a revelar sua identidade e credenciais. Para prevenir ataques de phishing é
importante que os usuários possam autenticar o PS e o IdP. A autenticação mútua
precisa, então, ser incorporada aos SGIs.
• Quantidade de identidades por usuário. Uma das maiores vantagens dos SGIs para
usuários é a autenticação simples, que não obriga os usuários a lembrarem de todos
os nomes de usuário e senhas, exceto aquele utilizado para obter acesso ao IdP. A
partir dessa perspectiva, os usuários devem confiar em apenas um IdP para acessar
seus serviços. Todavia, usar apenas um IdP significa que, se ele for comprometido,
todos os dados da identidade também serão comprometidos. Portanto, é aconselhável que os usuários distribuam as informações de suas identidades em múltiplos
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 características dos serviços, dos usuários, comportamento da rede
e outros.
Usabilidade
Tornar os SGIs simples e fáceis de usar reduz as barreiras para sua adoção. A usabilidade
refere-se a “eficácia, eficiência e satisfação com que usuários específicos alcançam objetivos em um ambiente particular”[Levin et al. 2009]. O IEEE define usabilidade como
“facilidade com que um usuário pode aprender a operar, gerar entradas para, e interpretar
as saídas de um sistema ou componente”. A usabilidade geralmente é mais importante
para usuários privados do que para organizações profissionais. Qualquer melhoria na usabilidade é mais uma questão de acessibilidade. A ausência de usabilidade pode causar
um impacto negativo na funcionalidade, segurança e privacidade. Apesar de muitos SGIs
afirmarem que são desenvolvidos tendo o usuário em mente, eles ainda apresentam muitos
problemas de usabilidade [Alpár et al. 2011]. Considerando o ambiente heterogêneo da
Internet do Futuro e a complexidade que possa ocasionar a falta de usabilidade, os SGIs
para a Internet do Futuro precisam ser fáceis de usar e suas operações devem ser o mais
transparente possível para o usuário.
Questões de usabilidade
• Independência de localização. Um aspecto importante de usabilidade que está faltando nos SGIs atuais é a independência de localização. O sistema de identidade
deve permitir ao usuário criar, administrar e usar sua identidade independentemente
da sua localização e dos dispositivos que ele esteja usando. Deve ser possível ao
usuário acessar um PS usando o SGI não apenas do seu computador pessoal, mas
de qualquer lugar. Os sistemas de gerência de identidade não podem depender de
dados armazenados em um único equipamento do usuário, ainda mais considerando
172
as redes da próxima geração, a popularização de dispositivos portáteis e a facilidade
de acesso a diferentes tipos de rede de comunicação.
• Distinção de identidades. Os usuários podem ter diversas identidades, mesmo que
o escopo seja o mesmo. Essa distinção de identidades gera diferentes responsabilidades ou perfis. Usuários podem ter diferentes perfis que o permitem fazer ações
diferentes em um determinado serviço. Além disso, o impacto das ações do usuário dependem do seu perfil. Os SGIs atuais não permitem aos usuários administrar
esses perfils facilmente. Basicamente, os usuários são forçados a manter e administrar vários identificadores para separar diferentes perfis. Os cenários de uso comum
criam um problema porque não há como indicar qual perfil, ou qual identidade, o
usuário quer usar para acessar determinado serviço. Os sistemas de gerência de
identidade devem fornecer uma forma para os usuários conhecerem e selecionarem qual a melhor identidade a utilizar mesmo que uma assinatura não tenha sido
solicitada explicitamente.
• Múltiplas credenciais. Um caso especial da questão anterior é quando transações
exigem a cooperação de vários serviços, possivelmente de múltiplos PSs. O problema surge se o usuário precisa apresentar credenciais para mais de um serviço, e as
credenciais dependem do perfil que o usuário assume. O usuário precisa ter todas
as credenciais exigidas para efetuar a transação, mas pode apresentá-las apenas se
estiver autenticado e usando o perfil correto. Os sistemas de gerência de identidade
devem prover uma forma de determinar automaticamente o conjunto completo de
credenciais e os perfis que o usuário pode assumir abrangendo aquelas credenciais.
• Administração de perfis de usuários. Quando um usuário acessa um serviço, frequentemente envolve o processamento de informações pessoais. Algumas dessas
informações podem ser armazenadas no IdP, enquanto que outras informações estão armazenadas no PS. Muitos PSs armazenam as mesmas informações para um
determinado usuário a fim de permitir que um perfil possa ser administrado e alterado. Isso pode ser útil para permitir ao usuário atualizar seus dados sempre que
sentir necessidade. A questão é se os SGIs podem simplificar a administração do
perfil do usuário para usuários finais tão bem quanto os PSs e IdPs.
Funcionalidade, confiabilidade, auxílio à legalidade, acessibilidade e interoperabilidade são requisitos gerais que também devem ser considerados na implementação de um SGI [ICPP 2003, Weber et al. 2010].
Funcionalidade
A principal funcionalidade de um SGI é ajudar o usuário a administrar sua identidade. O
SGI tem que oferecer a possibilidade de administrar identidades parciais e dados da identidade. O processo técnico de criação do conjunto de dados de entrada e de atualização
ou exclusão devem ser implementados. Esse conjunto de dados de entrada também deve
incluir assinaturas digitais, certificados ou credenciais.
173
Isso também é necessário para o SGI que possui interfaces para comunicação com
parceiros, especialmente em redes de comunicação. O SGI pode atuar como um gateway
para comunicação digital. Atuando como gateway, ele pode gerenciar a troca de dados
entre todos os parceiros de comunicação. Os sistemas de gerência de identidade incluem a
funcionalidade gateway por definição, pois a gerência de identidade é sempre um processo
entre o usuário e outra parte. Para PSs e IdPs, os requisitos básicos de funcionalidade não
diferem em grande parte dos usuários. Tipicamente, as organizações devem gerenciar
informação de identidades de membros e associados, ou seja, diferentes tipos de identidades. As funções para controlar essa complexidade e mantê-los atualizados fazem parte
dos requisitos básicos de funcionalidade que devem ser considerados na proposição de
um SGI.
Confiabilidade
Este é um pré-requisito para todas as transações que definem se um usuário confia no PS
ou no sistema. Mesmo em sistemas em que o usuário tem controle total sobre o hardware,
sotware e fluxo de dados, certa quantidade de confiança ainda é necessária, porque a complexidade do sistema exige transparência. Então, a reputação do fornecedor de software e
hardware se torna uma vantagem. Embora a ideia de confiança dependa de vários fatores,
a privacidade, segurança e usabilidade são condições prévias para confiabilidade. Além
disso, aspectos legais influenciam na percepção de confiança.
Auxílio à legalidade
Agências responsáveis pelo controle e aplicação de leis, tais como repartições policiais ou
de práticas investigativas criminais, geralmente se interessam por coletar a maior quantidade possível de informações para gerar evidências e tornar processos criminais mais
fáceis e eficazes. Qualquer SGI deve observar os requisitos legais para aplicação das leis
nos países em que serão usados. Entretanto, esses requisitos podem ser contraditórios
em difernetes países e até mesmo regiões de um mesmo país, pois resultam de culturas e
realidades diferentes.
Acessibilidade
Toda tecnologia deve ser acessível para que seja amplamente aceita. Isso se aplica a
todos os tipos de usuários. Entretanto, essa questão deve considerar se o SGI apenas
adiciona uma sobrecarga à rede ou se realmente melhora a funcionalidade e qualidade
dos serviços e transações. Este é um objetivo político em muitos países em que o direito à
decisão sobre informações pessoais é um direito básico, e como tal não deve depender da
situação financeira da pessoa. As organizações devem olhar o SGI não como um custo,
mas pela ótica do custo-benefício. Em outras palavras, os benefícios de um SGI precisam
compensar os custos diretos e indiretos.
174
Interoperabilidade
A compatibilidade e a integração com sistemas já existentes é um requisito básico para
um SGI. Os sistemas de gerência de identidade devem implementar interfaces compatíveis com padrões internacionais. A fim de serem largamente utilizados, essas interfaces
devem ser aceitas e suportadas pelos órgãos governamentais e agências dominantes nos
mercados visionados para o SGI. Essas partes interessadas irão procurar influenciar qualquer padrão para que possam suportá-lo. É inteiramente possível que alguns agentes sejam resistentes a interfaces compatíveis a fim de proteger sua posição no mercado. Neste
caso, a popularização do SGI como um produto será mais difícil. As regras de segurança
podem regular tendências isolacionistas no mercado. Alcançar interoperabilidade em diferentes contextos é impossível sem uma fundamentação coerente na cultura e sociedade
em que os SGIs pretendem ser usados. Aqui podemos fazer uma analogia com o domínio de linguagens de programação e de ter uma semântica bem definita para a linguagem
de programação. Caso contrário, diferentes implementações na mesma linguagem irão
produzir diferentes interpretações de alguns conceitos da linguagem conduzindo a uma
operação inconsistente do mesmo programa em diferentes implementações.
4.5. Iniciativas de gerência de identidade para as redes da próxima geração
Como mencionado na Seção 4.1, o foco deste minicurso é apresentar o estado da arte
das principais iniciativas voltadas à gerência de identidade na Internet do Futuro, especialmente aquelas focada nas redes da próxima geração. Com base na literatura, nós
classificamos essas iniciativas em projetos e arquiteturas, alianças e especificações consolidadas. As próximas subseções são organizadas segundo esta classificação e descrevem
as iniciativas encontradas na literatura com base nas publicações existentes.
4.5.1. Projetos e arquiteturas
Esta subseção apresenta os principais projetos relacionados à gerência de identidade na
Internet do Futuro. Além de uma descrição geral desses projetos, as arquiteturas de SGIs
propostas ou em desenvolvimento por alguns desses projetos são apresentadas.
PRIME - Gerência de privacidade e identidade para Europa
O projeto PRIME [PRIME 2010] aborda a falta de infraestrutura de gerência de identidade para a Internet, identificando suas principais carências, tais como segurança e privacidade, e visando definir um equilíbrio dos requisitos emergentes para os SGIs. O objetivo
do projeto consiste em desenvolver um protótipo de trabalho para melhorar a privacidade
dos SGIs, permitindo gerenciar as múltiplas identidades que um consumidor pode obter
através de suas interações pela Internet. Exemplos de interações são as operações comerciais realizadas através da Internet [Androulaki et al. 2009]. A meta principal do PRIME
é adotar tecnologias emergentes para Internet do Futuro ou alterar tecnologias já utilizadas
a fim de adaptar melhor os SGIs ao novo contexto de redes.
175
Arquitetura de gerência de identidade do projeto PRIME
A arquitetura de SGI proposta pelo PRIME foi desenvolvida para suportar uma ampla
gerência do ciclo de vida dos dados relacionados à identidade. O foco principal é apoiar
usuários na administração dos dados de suas identidades [Sommer et al. 2008]. O desenvolvimento da arquitetura segue a necessidade de mantê-la aberta para futuras ampliações.
Tal característica segue a abordagem modular para a arquitetura com uma boa separação
funcional entre os componentes principais. Outro princípio é a simplicidade. O projeto
geral é feito de tal forma que as interações entre as entidades tenham o máximo de privacidade e os dados sejam revelados apenas quando necessário.
A Figura 4.7 mostra um resumo dos componentes na arquitetura PRIME. No conjunto repositório de dados cada repositório armazena dados e metadados mantidos pela
entidade à qual os dados pertencem ou a qualquer outra entidade. Um sistema centrado no
usuário terá um repositório único, para armazenar seus próprios dados em formato criptografado, e uma empresa terá múltiplos repositórios de dados, devido às suas necessidades
de gerenciamento. Os repositórios de dados podem ser acessados por outros componentes internos ao sistema PRIME, assim como por outras entidades solicitantes, como um
usuário ou um serviço.
Sistema de Interface da Aplicação
Controle de Identidade
Ponto de
Extensão de
Privacidade
Componente
Opcional
Gerente de
Obrigação
Unidade de Federação
Negociação
Gerente de Garantia
Controle de Garantia
Controle de Acesso e
Execução de
Identidade
Repositório
de Dados
Controle de
Acesso e Decisão
de Identidade
Gerenciamento de
Confiança
Reputação
Repositório
de Políticas
Figura 4.7. Arquitetura PRIME
Um dos componentes chave na arquitetura PRIME é o componente de Controle de
Acesso e Decisão de Identidade (Access Control Decision – ACD), desenvolvido para ser
aproveitado na implementação de um protocolo de negociação entre duas entidades. O
componente ACD é um componente central que faz o acesso aos dados e toma decisões
relacionadas à liberação de unidades individuais de dados. O componente de Controle
176
de Acesso e Execução (Access Control Enforcement – ACE) controla todos os acessos
aos dados. Ele permite ao ACD acessar e ler dados a partir do repositório, caso o acesso
tenha sido concedido. O componente é análogo à função de execução em arquiteturas
de controle de acesso, com a diferença fundamental de que o ACD possui funções mais
avançadas que as utilizadas atualmente para tomar tais decisões. Todo o acesso aos repositórios é feito através do componente ACE. O componente de aplicação recorre ao
componente ACD para tomar uma decisão de acesso. As políticas são armazenadas em
um dos possíveis repositórios de política, que são acessados pelo ACD.
O componente de negociação, do inglês negotiation, implementa a funcionalidade
de negociação cujo principal objetivo é impulsionar a troca de dados entre as entidades,
especialmente para estabelecer a confiança e a trocar os dados necessários. O componente
de negociação opera sobre os pedidos em respostas compostas, onde composto significa
a possibilidade de incluir vários atributos ou informações sobre atributos. Ele consulta
o componente ACD obtendo as políticas de decisões para unidades de dados atômicas
envolvidas na negociação. O componente agrega os resultados recebidos do componente
ACD. O acesso aos dados é feito através do componente ACE.
As fontes de dados, especializadas no estabelecimento de confiança, podem ser
implementadas em um sistema SGI. A arquitetura PRIME define um componente para
gerência de confiança, que é capaz de fornecer certificados de dados para outros componentes obtidos a partir de uma avaliação local. Uma funcionalidade principal do componente de gerência de confiança é criar e verificar certificados sobre a confiabilidade das
plataformas.
O componente controle de garantia (assurance control) é responsável por garantir
a segurança, tanto durante o uso local quanto em interações com outras entidades. Uma
das características do AC é agregar informações obtidas a partir de componentes de gerência de confiabilidade de uma das múltiplas plataformas que compreendem os serviços
do sistema. O componente de controle de garantia cria controles e avaliações de controle
que auxiliam a entidade na tomada de decisões.
A unidade de federação é responsável pela certificação e troca de dados. Ela pode
implementar diferentes protocolos. O protocolo proposto pelo projeto PRIME é voltado
a sistemas de certificação privada (sistemas de credenciais anônimas) devido às inúmeras
vantagens em termos de privacidade. A unidade de federação é um componente único que
implementa trocas de dados de acordo com as regras do componente de negociação e com
as intervenções do usuários. Outros protocolos já existentes podem ser integrados a este
componente a fim de tornar a arquitetura PRIME compatível com protocolos pertinentes.
A interface de aplicação do sistema é um componente importante desta arquitetura. Ela provê uma interface entre o PRIME e o usuário, permitindo ao sistema fornecer
informações sobre as interações relacionadas à identidade, além de permitir a administração de dados e políticas. Com relação à arquitetura, a interface deve ter acesso a outros
módulos da arquitetura PRIME a fim de impedir que processos externos controlem o sistema sem que o usuário perceba.
O componente controle de identidade, do inglês identity control, controla o fluxo
de dados através da arquitetura e facilita o registro de componentes, tornando a arquitetura
177
extensível e flexível. O componente controle de identidade de duas entidades se comunicam para trocar dados, de acordo com as políticas configuradas. Tanto o componente de
controle de identidade, quanto o componente de negociação podem interagir com outros
componentes da arquitetura devido ao seu papel de controlador geral e e controlador de
negociação.
A arquitetura PRIME é constituída por mais alguns componentes que possuem
funcionalidades convencionais e, por isto, são mencionadas brevemente. O componente
de auditoria registra informações de eventos de processamento e ações 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 avançadas para entrega e administração de serviços personalizados, otimizados e independentes da localização
O projeto DAIDALOS [DAIDALOS 2006] foi um dos primeiros voltados a gerência de
identidade fortemente centrado nas infraestruturas de redes e serviços. Um dos resultados
desse projeto é o conceito de Identidade Virtual (VID) e sua aplicação em tais infraestruturas, onde o VID denota a entidade em uma função específica ou contexto de uso, e não
a entidade em sua totalidade [Sarma and Girão 2009].
A identificação de informações relacionadas a um prestador de serviços ou entidade é realizada localmente e gerenciada por diferentes entidades ou prestadores de
serviços. Um esquema VID assegura a divulgação coordenada de todos esses dados. Um
VID é um identificador pseudonômico que permite o acesso a um subconjunto de dados
pessoais do usuário. O proprietário do VID decide o âmbito e detalha exatamente o que
pode ser divulgado. A gerência de identidade age em nome de usuários, monitorando
e controlando estados de VIDs e seu ciclo de vida. Ele avalia e verifica a existência de
ameaças associadas à divulgação de informações no âmbito de uma VID, em pontos específicos, e controla as mudanças de estados dos ciclos de vida do VID. Isto significa que, se
o usuário revogar uma VID, o gerenciamento de identidade deve parar todas as operações
que a envolvem.
O acesso ubíquo a serviços e conteúdos de terceiros está se tornando uma norma na
Internet e em computação pervasiva, como descrito na Seção 4.2. O projeto DAIDALOS
pretende utilizar a computação pervasiva para organizar tecnologias de comunicação a
fim de melhorar a experiência do usuário. DAIDALOS visa ajudar os usuários a acessar
serviços, não importando onde eles estejam. Na Internet do Futuro, serão disponibilizados
diversos serviços eletrônicos aos usuários. Os acessos a serviços em qualquer lugar e a
qualquer hora, facilitados pelo aumento da cobertura através de várias tecnologias de
rede, permitirá que os usuários estejam constantemente conectados aos serviços através
de diferentes canais de rede. Neste contexto, os provedores de serviços se preocuparão
em atrair a atenção dos usuários, e os provedores de rede se preocuparão com aumento do
uso das redes. A computação pervasiva no DAIDALOS visa apoiar os usuários comuns
na gerência de identidades [Taylor et al. 2011] .
178
Arquitetura de gerência de identidade do projeto DAIDALOS
Tendo em vista a necessidade de criar uma nova geração de infraestrutura de comunicação centrada no usuário que forneça o suporte adequado à Internet do Futuro, o projeto
DAIDALOS busca integrar tecnologias de redes heterogêneas permitindo aos operadores
de rede e provedores de serviços oferecer novos serviços. O objetivo da arquitetura de
gerência de identidade desse projeto possibilita aos usuários acessar a uma vasta gama de
serviços multimídia personalizados.
A Figura 4.8 ilustra a funcionalidade principal dos componentes no Daidalos Pervasive Service Platform (PSP). A camada de gerência de serviços e identidade permite
acesso ubíquo a serviços. Essa funcionalidade inclui serviço de descoberta e recomposição para serviços de valor agregado para usuários. O componente de descoberta de
serviço é necessário para apoiar serviços criados posteriormente ao desenvolvimento da
arquitetura. Os provedores de serviços podem anunciar serviços e os usuários podem encontrar os serviços que necessitam. Uma vez que cada provedor irá oferecer apenas um
determinado número de serviços, será incluído um componente composição de serviços
a fim de permitir a oferta de novos serviços compostos a partir dos serviços existentes. O
componente gerência de identidade garante que uma infraestrutura de segurança e privacidade possa ser aplicada aos serviços de descoberta e composição.
Figura 4.8. Arquitetura Daidalos Pervasive Service Platform (PSP)
O componente gerência de serviços de ontologia define a interoperabilidade através de serviços e mecanismos como um glossário de provedores de serviços e consumidores. Este também é um aspecto chave do componente de composição de serviço,
validando as várias semânticas de serviços. Os componentes sessão e gerência de recur-
179
sos apóiam um ambiente de gerência em tempo de execução para serviços compostos,
em que os provedores de serviços e operadores podem aplicar políticas combinadas a
personalizações do usuário.
A camada gerência de experiência do usuário é responsável por monitorar e controlar as experiências do usário. O componente gerência de contexto coleta dados brutos
sobre o contexto usando vários sensores, refina-os e oferece esta informação em um formato mais apropriado para a plataforma ou para aplicações e serviços que os solicitem.
O componente gerência de aprendizagem controla o aprendizado com base no comportamento histórico dos usuários, tais como interação com os serviços, e usa esse conhecimento para manter atualizadas as preferências dos usuários para vários serviços. Através
do componente de gerência de preferência, as preferências podem ser aplicadas às plataformas de serviços, como a alteração de parâmetros de qualidade de serviço (QoS), ou
fornecidas aos aplicativos e serviços de terceiros. O componente negociação de privacidade aprimora os mecanismos de negociação entre os usuários e os serviços.
O componente gerência de identidade do DAIDALOS é fundamental para a aceitação dos usuários predominantes aos serviços, pois fornece os meios para acesso a serviços seguros, enquanto locadores de serviços podem cobrar pelos serviços prestados. O
modelo de identidade está envolvido em todos os estágios do ciclo de vida de uma conta,
desde sua criação, até o login em dispositivos, a seleção de serviços e uso. A gerência
de identidade DAIDALOS usa identidades virtuais para assegurar que as identidades dos
usuários não serão reveladas aos vários provedores de serviços envolvidos na prestação
de serviços compostos.
SWIFT - Difusão segura de identidades para telecomunicações federadas
O projeto Europeu SWIFT [FIDIS 2010] é financiado pelo programa FP7, do inglês 7th
Framework Programme. O projeto aproveita a tecnologia de gerência de identidade para
integrar o serviço e a infraestrutura de transporte a fim de beneficiar usuários e prestadores
de serviços. O objetivo é estender as funções de gerência de identidade e a federação para
redes sem negligenciar a usabilidade e privacidade.
A arquitetura proposta por SWIFT atua como um backbone para o sistema inteiro. Ela depende da noção de identidade digital que é fornecida por atributos de ligação,
autenticação e outras informações sobre o usuário. Uma vez que a informação nunca é
armazenada em um único lugar, a arquitetura age como um ponto de contato para serviços
externos obterem informações sobre o usuário ou sobre uma de suas identidades digitais.
Arquitetura de gerência de identidade do projeto SWIFT
Com base no projeto DAIDALOS, o projeto SWIFT aprimorou as soluções de gerência
de identidade, dando foco às operadoras de telecomunicações. O resultado é uma arquitetura estendida, desenvolvida para prover segurança e privacidade capazes de abranger as
necessidades de futuras soluções de gerência de identidade. Essa arquitetura é uma solução de privacidade inter-camadas que aprimora as soluções existentes e atua em uma nova
infraestrutura de controle de acesso. A arquitetura utiliza cartões eletrônicos de identificação, fornecendo uma visão integrada dos dispositivos dos usuários, buscando solucionar
180
problemas de compatibilidades com soluções inteligentes [Barisch et al. 2010].
A Figura 4.9 ilustra a arquitetura proposta pelo projeto SWIFT. A arquitetura contém cinco habilitadores de segurança no dispositivo do usuário, interligados pelo gerenciador de VID (VIDM) e pelo gerenciador de credenciais (CM). O VIDM é utilizado
pelo usuário para interagir com o componente central do sistema, a fim de realizar tarefas
relacionadas à gerência de identidade. A arquitetura fornece uma interface gráfica para
o usuário a fim de selecionar, criar ou destruir identidades virtuais, estabelecer sessões
com os PSs e com os agregadores de identidade. A arquitetura utiliza os habilitadores de
segurança conectados. Permite a configuração de atributos de políticas de liberação. Se
necessário, ele permite a criação de credenciais através do gerenciador de credenticiais.
O CM é reponsável pela criação de credenciais necessárias para autenticação e autorização em oposição ao PS e ao agregador de identidades. Dentro do contexto SWIFT, essas
credenciais também são conhecidas como instruções da arquitetura.
Figura 4.9. Arquitetura SWIFT
O gerenciador de credenciais é responsável pela criação de credenciais utilizadas
para autenticação e autorização entre o PS e o agregador de identidades. O CM provê
uma interface abstrata para o cartão eletrônico de identificação, para o habilitador de
inicialização de credenciais (CBS) e para o habilitador de credenciais anônimas (ACE).
Uma das funções do cartão eletrônico de identificação é oferecer um armazenamento
seguro de credenciais e atributos do usuário. Essa funcionalidade aumenta a segurança
do dispositivo do usuário, além de possibilitar a utilização de serviços independentes da
conexão com o agregador de identidade ou com o provedor de atributos.
O ACE também pode oferecer uma credencial anônima. Se necessário, o CM
pode especificar credenciais para interagir com outros sistemas de gerência de identidade
por intermédio do CBS. Uma vez que o usuário pode possuir dispositivos com diferentes
181
recursos e capacidades de segurança, os quais podem ser utilizados em diferentes contextos, o habilitador de transferência de identidade (ITE) permite utilizar a identidade através
desses dispositivos. Além disso, o VIDM pode controlar a representação da identidade
do usuário na rede e na camada de serviço por meio do gerenciador de pseudônimos
inter-camadas.
4.5.2. Alianças
Uma vez que sistemas de gerência de identidade necessitam de uma boa padronização
para garantir o uso abrangente das arquiteturas desenvolvidas, diversas alianças entre
companhias vêm sendo criadas para auxiliar no uso das novas arquiteturas de gerência
de identidade. Esta subseção apresenta as pricipais alianças existentes desde às que focam apenas na gerência de identidade para a Internet convencional até as alianças que
focam em padrões para a Internet do Futuro.
Liberty Alliance
A Liberty Alliance [Liberty 2001] tem por objetivo estabelecer padrões abertos, diretrizes
e melhores práticas para gerência de identidade, focalizando, principalmente, identidades
para serviços Web. O projeto desenvolvido por esta aliança promove uma abordagem de
gerência de identidade federada, voltada para a construção de relacionamentos de confiança entre as empresas e para a capacidade de confederar contas de usuários isolados
entre círculos de confiança bem definidos [Glässer and Vajihollahi 2008]. A função da
aliança Liberty é fornecer suporte ao desenvolvimento, implantação e evolução de um
padrão aberto e interoperável para redes de identidades federadas.
O objetivo da aliança Liberty é permitir um mundo conectado, em que os usuários
e as empresas possam realizar transações mais facilmente, ao mesmo tempo que protegem sua privacidade e a segurança de informações vitais dessa identidade. Um usuário
pode federar suas diferentes identidades em uma identidade única fornecida por um IdP, a
fim de acessar serviços fornecidos por PSs que participam de um mesmo círculo de confiança, autenticando-se apenas uma vez no IdP. Isso baseia-se em um relacionamento de
confiança pré-estabelecido entre o IdP e todos os PSs do círculo de confiança. O modelo
oferece um nível de pseudoanonimato através do uso de pseudônimos ao invés de identificadores reais na comunicação entre o IdP e o PS, aumentando assim a privacidade do
usuário.
FIDIS
A FIDIS (Future of Identity in Information Society) [FIDIS 2010] é uma Rede de Excelência (do inglês, Network of Excellence ou NoE) suportada pela União Européia. Esta
aliança integra esforços de pesquisa das diferentes nações européias buscando solucionar
problemas desafiadores, tais como suporte a identidade e identificação, interoperabilidade
de identidades, conceitos de identificação, roubo de identificadores, privacidade, segurança e perfis de usuários, além de buscar soluções para problemas forenses. Uma das
principais atividades de pesquisa da aliança está focada na melhor definição de identidade
182
e identificação.
A FIDIS define 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 inventário de definições
no domínio de identidade e seus respectivos casos de uso. Ele cataloga ainda os modelos existentes de gerência de identidade, assim como desenvolve uma visão geral das
perspectivas futuras de tais modelos [Glässer and Vajihollahi 2008].
4.5.3. Especificações consolidadas
Atualmente, existem várias especificações de sistemas de gerência de identidade consolidadas, tais como Security Assertion Mark-up Language (SAML), OpenID, Shibboleth e
outras. Apesar dessas especificações não serem exclusivas para as redes da próxima geração, ressalta-se que futuramente essas especificações devem ser compatíveis entre si, a
fim de fornecer um framework de gerência de identidade coeso. Considerando o contexto
de Internet do Futuro, esses padrões deverão evoluir cada vez mais a fim de atender, não
apenas às necessidades de determinados segmentos da indústria, mas também assumir arquiteturas e infraestruturas de redes específicas, o que pode culminar no desenvolvimento
de diferentes padrões.
SAML
O SAML resulta dos trabalhos do OASIS [OASIS 2011] Security Services Technical Committee, mas a versão atual do SAML conta com uma grande contribuição da Liberty Alliance. O SAML é um padrão XML para troca de dados de autenticação e autorização
entre serviços. Esse padrão XML resolve dois problemas, autenticação única e identidades federadas, e geralmente é destinado a parceiros comerciais que buscam um padrão
para troca segura de informações. O SAML foi criado por especialistas em segurança, da
indústria e da academia, especificamente para prover a interoperabilidade entre serviços
de autenticação web.
O princípio utizado pelo projeto SAML é a identidade federada. O modelo de
identidade federada permite que organizações usem métodos diferentes de autenticação e
autorização que sejam capazes de interoperar, estendendo a capacidade de cada serviço
existente na organização, ao invés de forçar sua troca. A identidade federada também
permite ajudar usuários a obterem vantagens dos sistemas de autenticação existentes reduzindo, assim, o número de senhas que eles têm que lembrar [Morgan et al. 2004].
OpenID
OpenID [OpenID 2006] é um framework aberto, descentralizado e gratuito voltado para
a identidade digital do usuário. OpenID permite aos usuários de Internet acessar diferentes sites, baseados em uma única identidade digital, o que elimina a necessidade de
diferentes nomes de usuário e senha para cada sítio web [Miloucheva et al. 2008]. Seu
desenvolvimento iniciou em 2005 e obteve expressiva atenção, tanto da comunidade de
183
desenvolvimento web quanto de grandes corporações. Hoje, Google, IBM, Microsoft,
VeriSign e Yahoo! são membros da Fundação OpenID.
Shibboleth
O Shibboleth [Shibboleth 2011] é uma iniciativa originada no ambiente acadêmico, cujo
objetivo é facilitar o compartilhamento de recursos de pesquisa entre instituições acadêmicas. Ele é um padrão que tem como base pacotes de software de código aberto com
acesso único para web entre ou dentro dos limites organizacionais. Esse padrão permite
que sites tomem decisões de autorização para acesso individual a fim 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 usuário e ao seu local de origem controlar os atributos liberados para cada
aplicação. Isso também simplifica a gerência de identidade e permissões para organizações, suportanto usuários e aplicações.
RAPID
No RAPID (Roadmap for Advanced Research in Privacy and Identity Management), a
gerência de identidade obedece as definições e o ciclo de vida de identidades digitais e
perfis, assim como as definições de ambientes para troca e validação de informações e
o conceito de identidades parciais. Três requisitos básicos de um SGI são destacados:
(1) a confiabilidade e a fidelidade, (2) a divulgação controlada de informações e (3) o
apoio à suporte. O projeto estuda os obstáculos e problemas no desenvolvimento de um
sistema que suporta Identidades Digitais Múltiplas e Confiáveis a fim de direcionar futuras
pesquisas na área [Glässer and Vajihollahi 2008].
HIGGINS
Higgins [Higgins 2011] é um framework de identidade para Internet, com código aberto,
desenvolvido para integrar identidade, perfil e informações de relacionamentos sociais
através de múltiplos sites, aplicações e dispositivos. Higgins não é um protocolo, mas
uma infraestrutura desenvolvida para suportar uma experiência consistente do usuário.
Ele trabalha como todos os protocolos de identidade digital, incluindo WS-Trust, OpenID,
SAML, XDI, LDAP, entre outros. Higgins permite construir aplicações e serviços que irão
trabalhar com diversos sistemas de gerência de identidade, permitindo ao desenvolvedor
incorporar padrões de identidade aos softwares. Do ponto de vista do usuário, Higgins
oferece às pessoas maior controle sobre suas identidades digitais, como as identidades online, informações pessoais e relacionamentos sociais. A arquitetura do framework permite
adaptar as tecnolocias existentes conforme necessário. Higgins também é compatível com
diversos protocolos e serviços relacionados à segurança e gerência de identidade.
184
Concordia
O projeto Concordia é uma iniciativa global projetada para desenvolver a interoperabilidade entre dos protocolos de gerência de identidade utilizados atualmente. Ele define
casos de uso e requisitos do mundo real que podem ser utilizados em múltiplos protocolos de gerência de identidade simultaneamente, em vários cenários de implatanção,
encorajando e facilitando a criação de soluções de protocolos apropriados para diferentes
tecnologias. Para a gerência de identidade, ele busca por soluções voltadas ao usuário e
gerência de identidade federada.
Na perspectiva da comunidade de código aberto, os projetos Higgins e Concordia
estão criando um framework de identidade multiprotocolo e promovendo a interoperabilidade entre protocolos de autenticação diferentes. Além de implementar uma estrutura
de identidade de código aberto que suporte abordagens tanto trandicionais quanto voltadas ao usuário. O framework do Higgins está criando um modelo de dados de identidade
atrativo e um serviço de atributo de identidade que oferece acesso uniforme a atributos de
identidade independente do objetivo final. Paralelamente, Concordia oferece dicas úteis
relacionadas a um modelo de referência de identidade e tem desenvolvido e experimentado soluções para suportar a interoperabilidade entre diferentes soluções de gerência de
identidade. Os projetos Higgins e Concordia são relevantes e devem ser tomados como
ponto de partida para reforçar e tratar adequadamente soluções para a Internet do Futuro [Rotondi 2008].
4.6. Ferramentas e tecnologias para gerência de identidade
Ao longo da história das civilizações, diversos métodos para evitar que uma informação
fosse obtida por pessoas não autorizadas foram criados. Os primeiros métodos utilizados para comprovar a identidade baseavam-se no uso de senhas ou palavras-chave. Segundo esses métodos, uma informação só poderia ser obtida pela entidade que possuisse
a palavra-chave. No entanto, o roubo ou a simples presunção da senha permitia que entidades não autorizadas obtivessem a informação original.
Dessa forma, a fim de aumentar o nível de segurança, foram criados os chamados
“tokens” de autenticação. Os tokens são dispositivos que têm a finalidade de fornecer
acesso à uma determinada informação 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 nível de segurança maior. Com o crescente uso
dessa tecnologia, surgiu a necessidade de prover ao token a capacidade de ser inviolável garantindo, assim, que somente o verdadeiro dono da informação obtivesse acesso a
ela. Assim, foram desenvolvidos diversos modelos de dispositivos para a identificação.
Cronologicamente, os modelos de maior importância para uma identificação digital são:
• Cartões de fita magnética
• Cartões inteligentes (smart cards) e cartões inteligentes sem contato (contactless
smart cards)
• RFID cards (Radio-Frequency IDentification)
185
• Cartões inteligentes multiaplicação
Os modelos citados foram criados para aumentar a segurança assim como a capacidade de armazenamento e a facilidade de uso. Os cartões de fita magnética, usados
amplamente no início dos anos 80, começaram a ter sua segurança comprometida pelo
alto índice de falsificações (como clonagens) e têm perdido espaço para os cartões inteligentes. Estes possuem características que os tornam invioláveis e possuem maior espaço
de armazenamento. com base na tecnologia dos cartões inteligentes, foram desenvolvidos os cartões sem contato, que utilizam radiofrequência para acesso e são providos de
métodos extras de segurança. Seguindo a mesma linha, foram desenvolvidos os cartões
RFID, cuja principal característica é a identificação do usuário a uma distância maior,
funcionando como um dispositivo de controle e rastreamento.
A popularização dos tokens permitiu o aumento no uso de cartões inteligentes por
diversos serviços. Uma pessoa que necessitasse acessar diversos serviços utilizando este
dispositivo de segurança, deveria possuir diversos tokens, um para cada serviço. Para diminuir a quantidade de tokens, os cartões multiaplicação foram criados com o objetivo de
englobar diversos tokens em um só, facilitando o acesso aos diversos serviços oferecidos
e que antes deveriam ser acessados utilizando cartões diferentes.
Atualmente, duas técnicas principais são utilizadas para provar a identidade de
uma entidade, algo que o usuário sabe ou algo que ele possui (senhas, cartões, documentos). Entretanto, estas técnicas podem ser burladas pela presunção da senha e pelo
empréstimo do cartão. Para aumentar a segurança no processo de identificação, foi adicionado mais uma dimensão para confirmação da identidade: algo que o usuáro é. Neste
ponto entra a Biometria, capaz de identificar um usuário utilizando alguns de seus fatores
físicos e biológicos.
Dessa forma, os principais métodos de identificação utilizados atualmente são a
identificação por senha, a identificação por token e a identificação por características físicas e biológicas. Através desse conjunto, é possível garantir uma complexidade maior,
dificultando a quebra de privacidade e oferecendo mais segurança para a gerência de identidade.
Dentre as diversas tecnologias usadas para a gerência de identidade, algumas se
destacam pelo seu alto índice de uso, de segurança e de praticidade. Neste escopo, podemos citar os cartões inteligentes, a aiometria e os cartões multiaplicação. As próximas
subseções descrevem essas três principais tecnologias de gerência de identidade dando
enfoque aos seus usos na Internet do Futuro.
4.6.1. Cartões Inteligentes (Smart Cards)
Os cartões inteligentes, também conhecidos como Smart Cards, são cartões que se parecem, em forma e tamanho, a um cartão de crédito convencional de plástico com tarja
magnética. A diferença entre os dois dispositivos é que o cartão inteligente possui capacidade de processamento, pois possui um microprocessador e memória embutidos, ambos
com sofisticados mecanismos de segurança. Mais especificamente, o cartão inteligente
possui um módulo de memória ROM, um módulo de memória RAM e um módulo de
memória EEPROM. O primeiro módulo armazena as instruções que serão enviadas ao
186
processador. O segundo módulo armazena os dados que são processados. E o terceiro
módulo armazena os dados propriamente ditos. Um cartão inteligente conta ainda com
uma CPU e módulos tanto para a entrada e saída de dados, quanto para a criptografia dos
dados armazenados no cartão.
Tipos de Cartão
Os cartões inteligentes usados atualmente diferem em dois fatores principais, o tamanho
e a forma de acesso ao meio. As principais formas de comunicação dos cartões atuais são
por contato ou por radiofrequencia. Os cartões com comunicação por contato devem ser
inseridos em um leitor, enquanto os carões sem contato se utilizam de comunicação por
radiofrequência para troca de informações entre o cartão e o leitor de informações.
Os cartões inteligentes com contato foram usados inicialmente em bancos na
França. Sua capacidade de guardar chaves privadas e executar modernos algoritmos de
criptografia tornou possível prover um alto nível de segurança às informações. A drástica
redução do preço desses dispositivos tornou seu uso cada vez mais frequente, gerando a
criação de novas aplicações que utilizam este recurso de segurança, especialmente aplicações que implementam a identificação, controle de acesso, armazenamento seguro de
dados e assinaturas eletrônicas.
Os cartões inteligentes sem contato se diferem dos clássicos cartões inteligentes
pela forma de comunicação. Ambos, a memória e o microprocessador utilizam a interface
sem contato para fazer a transmissão de dados. Esses cartões têm a sua energia transferida sem qualquer contato físico, permitindo acesso a várias aplicações sem que o usuário
necessite segurar o cartão na mão, sendo possível mantê-lo dentro de uma bolsa ou carteira. Muitas aplicações foram desenvolvidas para utilizar esse tipo de cartão, tais como
controle de acesso em transporte público, cartões corporativos e passes para entrada em
estabelecimentos. Este tipo de cartão também elimina um possível erro de fabricação dos
contatos elétricos.
Os smart cards têm um ciclo de vida bem definido. O processo de produção é
composto por cinco fases. O ciclo de vida começa no produtor do hardware do cartão,
que é responsável pela fabricação do chip a ser adicionado ao cartão. O produtor de
hardware também deve fornecer todo suporte ao hardware do equipamento fornecido.
Uma vez criado o chip, é iniciado o processo de confecção do cartão. A confecção do
cartão depende do objetivo para o qual ele será utilizado, podendo ser do tamanho de um
cartão de crédito ou do tamanho de um cartão SIM. Para o processo de instalação de um
sistema para o funcionamento do cartão inteligente, é necessário mais um intermediário,
o emissor do cartão. Este tem a função de fornecer um cartão pronto para ter aplicações
instaladas, garantindo um sistema operacional seguro para a execução das aplicações.
Uma vez que o cartão esteja pronto, basta fazer as instalações da aplicação requerida. Este processo é feito pelo provedor de serviços. O provedor de serviços oferece
um cartão com sua aplicação, a qual deverá estar configurada para o funcionar no sistema
operacional fornecido pelo emissor do cartão. No final do processo está o usuário, que
utilizará o cartão para a sua identificação.
187
Evolução e Adaptações
Desde seu surgimento, os cartões inteligentes passaram por profundas mudanças no processo de fabricação. De acordo com as principais mudanças, a evolução destes cartões é
dividida em quatro gerações. A Figura 4.10 ilustra as principais características de cada
geração. Na primeira geração, o produtor de hardware é o principal responsável pela fabricação do cartão. O produtor de hardware tinha um contato direto com o provedor de
serviços, pois toda a escrita no cartão era feita durante o primeiro processo. Com isso,
o produtor de hardware era contratado apenas para inserir a aplicação do provedor de
serviços dentro do chip do cartão.
Figura 4.10. Características das quatro gerações dos cartões inteligentes
Na segunda geração houve a divisão da camada da aplicação em três diferentes
processos. A primeira camada é constituída por um conjunto de instruções de hardware,
a segunda por um conjunto de classes e a terceira pela aplicação em si. Isso permitiu
segmentar melhor as camadas, tornando possível aproveitar as classes de aplicações e a
camada de hardware para outras aplicações. Na terceira geração, houve a inclusão do
fabricante e do emissor do cartão ao processo. Estes têm como função a inserção de
informações adicionais, como o PIN, que deverá ser usado pelo emissor e pelo provedor
de serviços como um método segurança no cartão inteligente.
Finalmente, na última geração de cartões inteligentes, houve uma grande mudança
na separação das atividades de cada envolvido na produção do cartão. Agora, o produtor
de hardware é responsável por produzir toda a Camada de hardware e as classes de aplicações, facilitando e minimizando a necessidade de mudanças 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 aplicação que o provedor de
serviços escolha para colocar dentro do cartão. Nesta geração foi considerado um novo
agente, o que irá utilizar e modificar os dados, o usuário. De posse do cartão, o usuário
pode atualizá-lo a fim de manter suas informações em dia.
188
Sistemas operacionais para cartões inteligentes
Atualmente são dois os principais sistemas operacionais utilizados em cartões inteligentes, o MULTOS e o sistema operacional criado para o Java Card. O Java Card é um
cartão inteligente que provê suporte a todos os padrões de cartão inteligentes. No entanto, o Java Card tem uma diferença básica com relação aos cartões inteligentes. Uma
máquina virtual, a Java Virtual Machine (JVM) é implementada em sua memória ROM.
Esta máquina virtual controla o acesso a todos os recursos do cartão, como memória e
entrada e saída de dados, e suporta a funcionalidade de operações características de sistemas operacionais para cartões inteligentes. O funcionamento da dessa máquina virtual
inicia com a execução de um subconjunto de código chamado Java byte code para que as
funções sejam acessadas pelo leitor do cartão garantindo a confiabilidade do cartão.
O Java Card é composto por classes padrão e um conjunto de rotinas que permitem que as aplicações Java sejam executadas diretamente. O sistema operacional do Java
Card permite que os aplicativos do cartão inteligente sejam escritos em linguagem Java, o
que de fato traz independência para desenvolvimento de software. Além disso, ele fornece
uma boa base para cartões de múltiplas aplicações, suportando mais de um aplicativo por
vez. A compilação de código no Java Card traz consigo, incluído na compilação, um
conversor que verifica cada classe e otimiza o código para os recursos limitados de um
cartão inteligente.
O MULTOS (Multiple Operating System) foi desenvolvido originalmente pela
Mondex International. É um sistema multiaplicação de alta segurança, desenvolvido especialmente para cartões inteligentes, possibilitando que diversas aplicações sejam instaladas, ao mesmo tempo, no cartão. O MULTOS tem sua própria linguagem de programação, a MEL (MULTOS Executable Language), que é otimizada para os sistemas de
cartões inteligentes. Entretanto, o sistema fornece compiladores para várias linguagens,
como Assembly, C, Java e Visual Basic. Com isso, a característica mais importante do
MULTOS é a independência de linguagem. O MULTOS é a única plataforma com suporte
à programação em linguagem Assembly. Para programação em C, o MULTOS possui um
compilador que oferece fácil portabilidade para aplicativos já existentes para o sistema
operacional MULTOS.
Diferente do Java Card, o MULTOS provê suporte um pouco diferente à linguagem de programação Java. Ambos, Java Card e MULTOS, suportam a linguagem Java
e ambos possuem um compilador Java que traduz as classes Java. A diferença é que
no Java Card, as classes são convertidas em código Java byte code, já no MULTOS, o
compilador traduz as classes Java para a linguagem codificada MEL, que já é otimizada
para trabalhar em Cartões Inteligentes. Tanto o MULTOS quanto o Java Card são muito
utilizados. Entretanto, devido à linguagem para otimização de código do MULTOS, este
oferece um pequeno ganho de desempenho para o cartões inteligentes.
4.6.2. Biometria
Biometria é o estudo estatístico das características físicas ou comportamentais dos seres vivos. Utiliza características físicas ou comportamentais das pessoas como forma de
identificá-las unicamente. Os sistemas chamados biométricos baseiam o seu funciona-
189
mento em características de diversas partes do corpo humano. Os olhos, a palma da mão,
as digitais, a retina ou íris dos olhos são as mais utilizadas para identificação. A ideia
fundamental é a de que cada indivíduo é único e possui características físicas e comportamentais diferentes.
A autenticação biométrica tem a vantagem de checar as características pessoais
do usuário, o que torna a identificação do usuário mais fiel, diminuindo a possibilidade
de fraude. As impressões digitais têm o seu reconhecimento baseado em imagens. A
estrutura dessas impressões é composta por vales e minúcias, que têm as suas localizações mapeadas para que seja feita a comparação com outras imagens. Esta técnica de
identificação é a mais antiga e a mais aceita para identificação de pessoas.
O reconhecimento de face tem como base a imagem da face. A estrutura da face é
salva como uma imagem para uma futura comparação. No passado, os algoritmos de reconhecimento de face usavam somente modelos geométricos, mas atualmente eles baseiamse em modelos matemáticos e de identificação de padrões para proceder a comparação
das imagens. Os grandes avanços obtidos na última década fizeram com que esta tecnologia obtivesse maior aceitação. Esta é uma tecnologia intuitiva, pois este é o modo como
pessoas reconhecem seus amigos e como é feita pela verificação de documentos.
Esses dois métodos são os mais aceitos atualmente para uma possível implementação como padrão para gerência de identidade. Devido à fácil captura dos dados, as
digitais e a face têm preferência, sendo necessário apenas um sensor de digitais e uma
webcam para capturar os dados.
Cartões RFID
Por engano, alguém pode se referir a cartões inteligentes sem contato como cartões RFID,
mas são tecnologias diferentes. Os cartões RFID têm como característica a identificação
por rádiofreqüência. Sua identificação é feita de forma automática através da captura
de dados em uma rede sem fio. Essa tecnologia inclui antenas e bobinas eletrônicas
programadas com uma informação única. O processo de identificação é simples e rápido,
onde só é necessária a captura da freqüência. A maioria desses cartões não é inviolável,
pois não contam com um hardware robusto. Os cartões RFID são mais utilizados para o
controle de acesso e rastreamento, principalmente em ambientes em que não é necessário
o reconhecimento, mas apenas a verificação do indivíduo, garantindo uma rapidez ao
processo.
Cartões multiaplicação
Olhando pela perspectiva de um desenvolvedor, um cartão multiplicação é um cartão
com várias aplicações carregadas na memória do cartão. A maioria das aplicações de
um cartão inteligente têm seus próprios dados e raramente compartilham-as, tornando-as
independentes. Para garantir essa independência o sistema operacional deve garantir o
acesso apropriado para cada aplicação.
4.7. Conclusões
Vários esforços vêm sendo observados na literatura em direção ao desenvolvimento da
Internet do Futuro. Essa nova Internet pretende sanar problemas e limitações encontradas
190
na Internet atual, sobretudo aqueles relacionados ao provimento de serviços de forma
segura, confiável e robusta. A Internet do Futuro é visionada em organização em quatro
dimensões, apoiadas por uma infraestrutura de rede denominada rede da próxima geração.
A rede da próxima geração ou NGN é um conceito de redes que tem como base
a transferência de pacotes para prover serviços e se beneficiar de múltiplas tecnologias
e infraestruturas de comunicação existentes. Uma NGN é composta por uma rede de
serviços, uma rede de base e uma rede de acesso. A rede de serviços é responsável pelos
serviços 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 comunicação sejam
elas com fio ou sem fio.
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 serviços, muitos
deles personalizados, e depende de informações relacionadas ao perfil dos usuários e serviços para atingir um funcionamento eficiente que garanta QoS, privacidade, segurança,
disponibilidade e confiabilidade dos serviços. Nos diferentes níveis da NGN, a gerência
de identidade é uma funcionalidade cada vez mais necessária e importante.
Entretanto, sistemas de gerência de identidade ainda possuem atualmente desafios. Dentre esses desafios, encontram-se questões relacionadas à segurança, privacidade
dos dados dos usuários e usabilidade que devem ser tratados a fim de se tornarem mais
adequados à sua aplicação na Internet do Futuro. Além dessas questões, os sistemas de
gerência de identidade desenvolvidos para a Internet do Futuro necessitam ser interoperáveis, uma vez que tecnologias heterogêneas são esperadas a trabalharem em conjunto.
Além das arquiteturas de gerência de identidade, o capítulo apresenta uma visão
geral sobre as alianças existentes, as especificações consolidadas e as ferramentas de gerência de identidade utilizadas atualmente. As alianças e as especificações consolidadas
são descritas com o objetivo de mostrar o estado da arte em relação aos esforços que
vêm sendo realizados em direção a padronizações de sistemas de gerência de identidade.
As ferramentas mais comuns utilizadas para auxiliar sistemas de gerência de identidade
como os cartões inteligentes, a biometria e os cartões RFID são descritos a fim de prover uma descrição sobre o que vêm sendo utilizado nos sistemas, assim como uma visão
relacionada a seus avanços e perspectivas futuras.
Com base nesse levantamento do estado da arte sobre sistemas de gerência de
identidade para Internet do Futuro, observamos que as propostas existentes ainda são bastante incipientes. As arquiteturas apesar de se dizerem voltadas à Internet do Futuro, ainda
não possuem ou tratam características realmente relacionadas ao novo paradigma de rede.
Além disso, as arquiteturas existentes são bastante conceituais, requerendo uma especificação mais detalhada e formal sobre os conceitos e usos desses conceitos na prática. Elas
necessitam ainda definir de forma mais clara como os módulos e componentes conceituais
serão na realidade implementados e como serão suas aplicações no contexto heterogêneo
das redes da próxima geração. Especificações e análises formais são requeridas a fim de
mostrar os custos referentes ao uso de cada uma dessas arquiteturas na rede.
Em relação aos padrões existentes, estes não consideram de fato as características
e os possíveis usos dos sistemas de gerência de identidade nas redes da próxima geração.
191
Um grande campo de oportunidades e de desenvolvimento é observado em relação aos
sistemas de gerência de identidade e suas aplicações nas redes da próxima geração. O que
se observa é que a existência de padrões realmente voltados a Internet do Futuro ainda
são inexistentes e muito trabalho ainda é necessário em direção à especificação desses
padrões.
Sobre as ferramentas existentes para gerência de identidade, observa-se a evolução
que elas vêm passando. Atualmente, a biometria e os cartões multiaplicação parecem ser
as ferramentas mais promissoras por se adequarem aos requisitos e características das
redes da próxima geração. A capacidade dos cartões multiaplicação servirem para uso
considerando diferentes serviços vai de encontro à característica da Internet do Futuro de
prover diferentes serviços requerendo mecanismos que facilitem a gerência de identidade
pelos usuários sem sobrecarrega-los com a necessidade de memorizar diferentes senhas e
identificadores. Entretanto, questões de segurança ainda precisam ser tratadas nesse tipo
de ferramenta.
Referências
[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):2127–2159.
[Alduán et al. 2011] Alduán, M., Sánchez, F., Alvarez, F., Jiménez, D., Menéndez, 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.
[Alpár et al. 2011] Alpár, 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. MS’10.
[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 49–62, 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):13–15.
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 efficient 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):3004–3014.
[DAIDALOS 2006] DAIDALOS (2006). The Daidalos Project.
daidalos.org, último acesso 28 de Março 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:24–29.
[FIDIS 2010] FIDIS (2010). Future of Identity in the Information Society. www.fidis.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.
[Glässer and Vajihollahi 2008] Glässer, U. and Vajihollahi, M. (2008). Identity Management Architecture. In ISI, pages 137–144.
[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, DIM’10, pages
45–48, 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:38–45.
[Heegaard and Trivedi 2009] Heegaard, P. E. and Trivedi, K. S. (2009). Network survivability modeling. Computer Networks, 53(8):1215–1234.
193
[Higgins 2011] Higgins (2011).
Higgins - Open Source Identity Framework.
http://www.eclipse.org/higgins, último acesso 28 de Março 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): Identification 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
14–25, 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 593–598, Los Alamitos, CA, USA. IEEE Computer Society.
[Liberty 2001] Liberty
(2001).
The
Liberty
Alliance
http://www.projectliberty.org, último acesso: 28 de Março 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:12–17.
[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 Março de 2011.
[OpenID 2006] OpenID (2006). The OpenID Project. http://openid.net, último acesso
28 de Março 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):70–78.
[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:2–42.
[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):72–78.
[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 42–49, 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):268–279.
[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 Girão 2009] Sarma, A. and Girão, J. (2009). Identities in the Future Internet
of Things. Wireless Personal Communication, 49:353–363.
[Shibboleth 2011] Shibboleth
(2011).
The
Shibboleth
http://shibboleth.internet2.edu, último acesso 28 de Março 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 1418–1422.
[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:74–81.
[Weber et al. 2010] Weber, S., Martucci, L., Ries, S., and Mühlhäuser, 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
Capítulo
5
Resource Allocation in Clouds: Concepts, Tools
and Research Challenges
Glauco Estácio Gonçalves, Patrícia Takako Endo, Thiago Damasceno
Cordeiro, André Vitor de Almeida Palhares, Djamel Sadok, Judith Kelner,
Bob Melander, Jan-Erik Mångs
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
Computação na Nuvem é um modelo de computação atrativo, uma vez que permite que
recursos sejam provisionados sob demanda. Tal processo de alocação e realocação 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
expansão do mercado de Computação na Nuvem, diversos problemas relativos à
alocação de recursos permanecem abertos. Este minicurso introduz os conceitos e
tecnologias essenciais da Computação em Nuvem e apresenta algumas questões de
pesquisa na área, focando nos desafios e soluções para alocação 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
http://aws.amazon.com/ec2/
2
http://code.google.com/intl/appengine/appengine/
3
http://www.microsoft.com/windowsazure/
4
http://www.salesforce.com/platform/
5
http://cloudcomputing.sys-con.com/node/770174
6
http://www.gartner.com/it/page.jsp?id=1526414
200
about the elasticity of their applications. Metaphorically, one can say that consumers
expect that provider’s 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 provider’s 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 developer’s 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
7
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 Cloud’s 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 reconfigured 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
http://www.dropbox.com/
9
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.
Mediation
System
Developer Developer
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
http://s3.amazonaws.com/ec2-downloads/ec2.wsdl
11
http://kenai.com/projects/suncloudapis/pages/Home
12
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 Citrix’s Xen13 and the Kernel-based
Virtual Machine (KVM)14. From the realm of proprietary solutions, some examples are
VMWare ESX15 and Microsoft’s 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
http://www.xen.org/products/cloudxen.html
14
http://www.linux-kvm.org/page/Main_Page
15
http://www.vmware.com/
16
http://www.microsoft.com/hyper-v-server/en/us/default.aspx
17
http://hadoop.apache.org/
18
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 Google’s 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 datacenter’s
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
hardware’s 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 operator’s offerings and the developer’s
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
http://cordis.europa.eu/fp7/ict/ssai/home_en.html
21
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
http://www.gridforum.org/
23
http://occi-wg.org/about/specification/
24
http://www.dmtf.org/vman
25
http://www.virtualbox.org/
26
http://www.libvirt.org/
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 developer’s
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 developer’s application
covers, aside from the software, some additional information about the application’s
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 provider’s 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 Modeling
Resource Discovery
and Monitoring
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 it’s 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
http://www.w3.org/RDF/
28
https://noc.sara.nl/nrg/ndl/
29
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 component’s 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
http://doc.3tera.com/AppLogic24/AppLogic.html
31
http://www.w3.org/TR/2007/WD-sml-20070806/
32
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 developer’s 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 application’s 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 client’s 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
PlanetLab, http://www.planet-lab.org/
35
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 Amazon’s 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
Cluster A
NC
NC
NC
NC
Private
Network
NC
NC
NC
NC
Private
Network
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.
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 Amazon’s 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 Telefónica38. 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 interface’s 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
http://www.esa.int/esaMI/ESAC/index.html
37
http://public.web.cern.ch/public/
38
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 VMWare’s
vCloud API.
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 Amazon’s 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
http://docs.amazonwebservices.com/AmazonS3/latest/dev/
40
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
Workspace
Resource
Manager
Context Broker
EC2 WSDL
Workspace
Service
Workspace
Control
Workspace
Pilot
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 EC2’s
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.
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
Amazon’s EC2. A further advantage of OpenNebula is that it can easily be extended to
implement other interfaces, as well as Nimbus.
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., Griffith, 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) “What’s 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., Gonçalves, G., Sadok, D.,
Kelner, J., Melander, B., Souza, V., Mångs, 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 Warfield, 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: simplified data processing on large
clusters. In OSDI’04: Proceedings of the 6th conference on Symposium on
Opearting Systems Design & Implementation, pages 10–10, 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., Gonçalves, G. E., Kelner, J., Sadok, D. (2010) “A Survey on Open-source
Cloud Computing Solutions”. Workshop em Clouds, Grids e Aplicações, Simpósio
Brasileiro de Redes de Computadores e Sistemas Distribuídos.
Erl, T. (2009) “SOA design patterns”, Prentice Hall, Boston.
Ghemawat, S., Gobioff, H., and Leung, S. (2003) “The Google file system”. In 19th
Symposium on Operating Systems Principles, pages 29–43, 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. 5634–5640.
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 Definition of Cloud Computing”. National
Institute of Standards and Technology, Information Technology Laboratory.
Metsch, T., Edmonds, A., Nyrén, 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. 50–55, January.
Veras, M. (2009) “Datacenter: Componente Central da Infraestrutura de TI”. Brasport
Livros e Multimídia, Rio de Janeiro.
Verdi, F. L., Rothenberg, C. E., Pasquini, R., and Magalhães, 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 235–246. 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 unified 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
Patrocínios:

Capa livro texto minicursos A4 - SBRC 2011

Transcrição

Documentos relacionados

cloud computing

Jornal de Negócios − Semana Informática Cloud não convence a

SOBRE O PROJETO DE MARCA E IDENTIDADE VISUAL S4N Qual

Jornal de Negócios − Semana Informática Cloud

bios oradores conferência

Investimento em nuvem e mobilidade pode

Termos de Uso - Trader.Cloud

Novos IBM power Systems: sistemas mais inteligentes

catálogo - recursos naturais catalogue

- Kriativ.tech