WP-Middleware - Projeto SmartMetropolis | IMD-UFRN

Transcrição

Universidade Federal do Rio Grande do Norte
Instituto Metrópole Digital
SmartMetropolis – Plataformas e Aplicações para Cidades Inteligentes
WP5 - Middleware
Habilitadores Genéricos da Plataforma FIWARE
Natal-RN, Brasil
Agosto de 2016
Equipe Técnica
Docentes
Prof.ª Dra. Thais Vasconcelos Batista (Coordenadora) – DIMAp-UFRN
Prof. Dr. Augusto José Venâncio Neto – DIMAp-UFRN
Prof. Dr. Carlos Eduardo da Silva – IMD-UFRN
Prof. Dr. Everton Ranielly de Sousa Cavalcante – DIMAp-UFRN
Prof. Dr. Frederico Araújo da Silva Lopes – IMD-UFRN
Prof. Dr. Nélio Alessandro Azevedo Cacho – DIMAp-UFRN
Discentes
Arthur Emanoel Cassio da Silva e Souza
Claudio Silva Trindade
Helber Wagner da Silva
Jorge Pereira da Silva
Juliana de Araújo Oliveira
José Estevam de Andrade Junior
Marcus Vinicius Alves Maia
Robéria Silva da Penha
Stefano Momo Loss
Thalyson Luiz Gomes de Souza
Sumário
1 Introdução ................................................................................................................................ 7
2 Interfaces NGSI-9 / NGSI-10 .................................................................................................. 9
2.1 Entidades de Contexto ...................................................................................................... 9
2.2 Interface NGSI-9............................................................................................................. 11
2.3 Interface NGSI-10........................................................................................................... 14
3Applications and Services Ecosystem and Delivery Framework ........................................... 18
3.1. Data Visualization (SpagoBI) ........................................................................................ 20
2.1.3. Exemplo de uso e Problemas Encontrados ............................................................. 21
3.1.4. Próximasatividades ................................................................................................. 30
3.2. Repository GE................................................................................................................ 31
3.2.1. Objetivos ................................................................................................................. 31
3.2.2. Descrição ................................................................................................................ 31
3.2.2. Exemplo .................................................................................................................. 37
3.3. Revenue Settlement and Sharing System ...................................................................... 40
3.4. Store (WStore) ............................................................................................................... 42
3.5. Application Mashup (WireCloud) ................................................................................. 45
2.5.3. Exemplo de uso e Problemas Encontrados ............................................................. 47
3.5.4. Próximas atividades ................................................................................................ 54
3.6. Marketplace (WMarket) ................................................................................................ 54
4 Cloud Hosting ........................................................................................................................ 57
4.1 Objetivos ......................................................................................................................... 57
4.2 Descrição ........................................................................................................................ 58
4.2.1 Docker ...................................................................................................................... 59
4.2.2 IaaS - Openstack ...................................................................................................... 62
4.2.3 Openstack Swift ....................................................................................................... 70
4.2.4 SelfServiceInterfaces ............................................................................................... 72
4.2.5 AppManagement ...................................................................................................... 74
4.2.6 PolicyManager ......................................................................................................... 76
4.3 Exemplo de uso do Cloud Portal .................................................................................... 77
4.4 Considerações Relevantes............................................................................................... 79
5 Data/Context Management .................................................................................................... 82
5.1. Cloud Messaging (AEON) GE ...................................................................................... 82
5.1.1. Objetivos ................................................................................................................. 82
5.1.2. Descrição ................................................................................................................ 82
4.1.3. Exemplo de uso ....................................................................................................... 84
5.2. Complex Event Processing (CEP) GE ........................................................................... 88
5.2.1. Objetivos ................................................................................................................. 88
4.2.2. Descrição ................................................................................................................ 88
5.2.3. Exemplo de uso ....................................................................................................... 92
5.2.4. Problemas Encontrados........................................................................................... 97
5.2.5. Próximas atividades ................................................................................................ 97
5.3. Big Data Analysis (Cosmos) GE ................................................................................... 97
5.3.1. Objetivos ................................................................................................................. 97
5.3.2. Descrição ................................................................................................................ 98
Ecossistema Cosmos ....................................................................................................... 101
5.3.3. Exemplo de uso e Problemas Encontrados ........................................................... 102
5.3.5. Próximos passos .................................................................................................... 103
5.4. Orion GE ...................................................................................................................... 104
5.4.1. Objetivos ............................................................................................................... 104
5.4.2. Descrição .............................................................................................................. 104
5.4.3. Exemplo de uso e Problemas Encontrados ........................................................... 105
5.4.4. Próximos passos .................................................................................................... 110
5.5. Stream Oriented (Kurento) GE .................................................................................... 110
5.5.1. Objetivos ............................................................................................................... 110
5.5.2. Descrição .............................................................................................................. 110
5.5.3. Exemplo de uso ..................................................................................................... 113
5.6. Comprehensive Knowledge Archive Network (CKAN) GE ....................................... 117
5.6.1. Objetivos ............................................................................................................... 117
5.6.2. Descrição .............................................................................................................. 117
5.6.4. Problemas Encontrados......................................................................................... 120
5.6.5. Pendências ............................................................................................................ 120
5.6.6. Próximos Passos ................................................................................................... 120
6 Advanced Middleware and Interfaces to Network and Devices .......................................... 122
6.1. KIARA Advanced Middleware ................................................................................... 122
6.1.1. Objetivos ............................................................................................................... 122
6.1.2. Descrição .............................................................................................................. 122
6.1.3 Exemplo ................................................................................................................. 125
6.1.4 Próximos Passos .................................................................................................... 129
6.2. OpenFlow Network Interface and Control (OFNIC) ................................................... 129
6.2.1. Objetivos ............................................................................................................... 129
6.2.2. Descrição .............................................................................................................. 129
7Internet of Things (IoT) Services Enablement...................................................................... 131
7.1 Backend Configuration Manager (IoT Discovery) ....................................................... 132
7.1.1 Descrição ............................................................................................................... 133
7.1.2 Exemplos de Uso ................................................................................................... 135
7.2 IoT Broker..................................................................................................................... 141
7.2.1 Descrição ............................................................................................................... 141
7.2.2 Exemplos de Uso ................................................................................................... 144
7.3 Backend Device Management IDAS: ........................................................................... 148
7.3.1 Descrição: .............................................................................................................. 148
7.3.2 Objetivos: ............................................................................................................... 150
7.4 Protocol Adapter (MR CoAP): ..................................................................................... 153
7.4.1 Descrição: .............................................................................................................. 153
7.4.2 Objetivos: ............................................................................................................... 153
7.5 Gateway Data Handling - EspR4fastData .................................................................... 154
7.5.1 Descrição ............................................................................................................... 154
7.5.2 Exemplo de Uso ..................................................................................................... 162
8 Security ................................................................................................................................ 167
8.1 Objetivos ................................................................................................................... 167
8.2 Conceitos Básicos e Definições ................................................................................ 167
8.2.1 Gerenciamento de Identidade e Acesso (Identity and Access Management) ........ 168
8.2.2 Segurança Cibernética (CyberSecurity)................................................................. 169
8.2.3 Confiança e Gestão de Confiabilidade (Trust and Trustworthiness Management) 170
8.3 Aplicação de Exemplo .............................................................................................. 171
8.4 Visão arquitetural do Capítulo Técnico .................................................................... 174
8.5 Descrição do Identity and Access Management GE ................................................. 176
8.5.1 Visão Geral da Arquitetura do KeyRock ............................................................... 176
8.5.2 Descrição do Exemplo da Aplicação ..................................................................... 179
8.5.2.1 Autenticando um usuário no KeyRock ............................................................... 179
8.6 Descrição dos Componentes de Autorização (PEP Proxy GE e Authorization PDP GE)
............................................................................................................................................ 188
8.6.1. Conceitos Básicos sobre Controle de Acesso ....................................................... 189
8.6.2 Visão Geral da Arquitetura do Authorization PDP GE e PEP Proxy GE.............. 192
8.6.3 Representando Políticas de Controle de Acesso usando XACML ........................ 194
8.6.4. API para Administração de domínio de política ................................................... 196
8.6.5. API para Administração de Política...................................................................... 201
8.6.6 Cenários de Uso ..................................................................................................... 208
8.7 Descrição do CyberSecurity ......................................................................................... 212
8.8 Descrição do Trustworthy Factory GE ......................................................................... 215
8.9 Considerações Finais .................................................................................................... 218
8.9.1 Problemas Encontrados.......................................................................................... 218
8.9.2 Pendências ............................................................................................................. 219
8.9.3 Próximos passos ..................................................................................................... 219
9 FIWARE Ops ....................................................................................................................... 221
9.1 Objetivos ....................................................................................................................... 221
9.2 Descrição ...................................................................................................................... 221
9.2.1 OPS-Deploy ........................................................................................................... 222
9.2.2.1 FIDASH .............................................................................................................. 224
9.2.2.3 Maintenance Calendar ........................................................................................ 229
9.2.3 OPS-Health ............................................................................................................ 230
9.2.4 OPS-Toolkit ........................................................................................................... 231
9.3 Exemplo .................................................................................................................... 232
9.4 Considerações Relevantes............................................................................................. 238
Referências.............................................................................................................................. 239
1 Introdução
Este relatório apresenta detalhes acerca dos habilitadores genéricos (generic enablers)
do FIWARE, uma plataforma genérica e extensível proposta com apoio da Comunidade
Européia. Tais habilitadores genéricos são os elementos principais que constituem o FIWARE
e implementam as especificações abertas disponibilizadas pelas APIs da plataforma. Conforme
descrito no relatório técnico anterior, de maio de 2016, a plataforma FIWARE é, até o momento,
a única plataforma capaz de satisfazer uma série de requisitos considerados fundamentais no
contexto de cidades inteligentes e, por isso, foi escolhida para ser usada no contexto desse
projeto e detalhada neste relatório. O FIWARE tem sido amplamente utilizado na Europa em
diversos casos de sucesso, proporcionando uma vasta gama de aplicações de cidades inteligentes
desenvolvidas e em operação utilizando a plataforma. Isso justifica-se principalmente pelo fato
de o FIWARE ser uma plataforma aberta, livre de royalties, que provê um conjunto de APIs que
facilitam o desenvolvimento de aplicações para cidades inteligentes e disponibiliza
implementações de referência para cada API.
Este relatório apresenta uma descrição detalhada dos principais habilitadores genéricos
do FIWARE, agrupados pelos chamados capítulos técnicos de acordo com o conjunto de
funcionalidades às quais estão relacionadas. Além disso, esse relatório também descreve a
implementação de alguns exemplos de pequena escala que foram desenvolvidos no intuito de
promover um primeiro uso prático da plataforma, bem como identificar potenciais problemas e
dificuldades no seu uso.
Esse documento está estruturado da seguinte forma. A seção 2 apresenta duas interfaces
padronizadas (NGSI-9 e NGSI-10) que são adotadas pelo FIWARE e usadas na descrição dos
serviços. A seção 3 apresenta uma visão geral dos habilitadores genéricos da plataforma
FIWARE, relacionados à aplicações, serviços e dados. A seção 4 apresenta o capítulo técnico
denominada Cloud Hosting, que abrange os habilitadores genéricos que fornecem capacidades
estruturais para a execução, processamento e monitoramento de aplicações de forma a garantir,
principalmente, dependabilidade. A seção 5 apresenta os habilitadores genéricos relacionados
com Data/Context Management que facilitam o desenvolvimento de aplicações inovadores que
requerem gerenciamento, processamento e exploração de informação contextual, bem como,
fluxos de dados em tempo real e em grande escala. A seção 6 apresenta uma visão geral dos
objetivos e da descrição dos habilitadores genéricos sobre Advanced middleware and interfaces
to Network and Devices, que inclui a descrição do GE KIARA Advanced Middleware e do GE
OFNIC (OpenFlow Network Interface and Control). A seção 7 apresenta os habilitadores
genéricos oferecidos pelo FIWARE para suporte ao desenvolvimento de aplicações no domínio
de IoT, a saber: Backend Device Management, Protocol Adapter, IoT Template Handler,
Backend Configuration Manager (IoT Discovery), IoT Broker e Gateway Data Handling . Os
Habilitadores Genéricos a serem apresentados atuam em diversas camadas de IoT, oferecendo
um conjunto de funcionalidades e abstrações que facilitam o compartilhamento/consumo de
dados e desenvolvimento de aplicações, contribuindo assim para mitigar os desafios
supracitados. A seção 8 descreve o Capítulo Técnico de Segurança da plataforma FIWARE, que
é construído em torno de três áreas temáticas: Gerenciamento de Identidade e Acesso (Identity
and Access Management); Segurança Cibernética (CyberSecurity); e Confiança e Gestão de
Confiabilidade (Trust and Trustworthiness Management). A seção 9 apresenta o FIWARE
Operations (FI-Ops), que fornece um conjunto de ferramentas que facilitam a implantação,
configuração e operação de instâncias FIWARE.
2 Interfaces NGSI-9 / NGSI-10
Como serão apresentados nos próximos capítulos, o projeto Fiware dispõe de diversos
Habilitadores Genéricos (Generic Enablers - GEs) que utilizam o conceito de entidades de
contexto, que são representações virtuais de entidades e/ou objetos do mundo real. Uma entidade
de contexto pode ser usada, por exemplo, para representar um sensor, uma casa, uma pessoa,
etc. Esses GEs oferecem diversos serviços que permitem, dentre outras coisas, compartilhar,
manipular, pesquisar e processar dados acerca de entidades de contexto, facilitando o
desenvolvimento de aplicações que utilizam informações contextuais. Em alguns casos os GEs
precisam comunicar-se entre si para proverem serviços aos usuários. Para melhor gerenciar a
interação entre usuários e GEs, e entre os próprios GEs, os serviços são oferecidos por meio de
interfaces padronizadas. Essas interfaces seguem a especificação NGSI1 (Next Generation
Service Interfaces) definida pela OMA (Open Mobile Aliance) como forma de padronizar a troca
de informações referentes a entidades de contexto.
Neste capítulo serão apresentadas duas interfaces (NGSI-9 e NGSI-10) definidas na
especificação NGSI, adotada pelo projeto FIWARE. Também será introduzido o conceito de
entidades de contexto, necessário para a compreensão das funcionalidades definidas para cada
uma das interfaces.
2.1 Entidades de Contexto
No FIWARE, informações contextuais são representadas por meio de estruturas
genéricas conhecidas como entidades de contexto. Uma entidade de contexto pode ser usada
para representar, de forma virtual, elementos do mundo real, tais como uma pessoa, um lugar,
um sensor, etc. A figura 1 ilustra o modelo de informação definido na especificação NGSI. Esse
modelo de informação mostra como informações contextuais podem ser representadas e
associadas à entidades de contexto.
1
especificação NGSI - http://technical.openmobilealliance.org/Technical/release_program/docs/NGSI/V1_020120529-A/OMA-TS-NGSI_Context_Management-V1_0-20120529-A.pdf
Figura 1. Modelo de informação definido na especificação NGSI [4]
Informações contextuais são organizadas por meio de elementos de contexto (context
elements). Um elemento de contexto pode possuir associado a si um conjunto de atributos de
contexto(context element attributes) e metadados (meta-data). Entidades de contexto devem
possuir um identificador (EntityId) e um tipo (EntityType), essa tupla <identificador, tipo>
identifica de forma única uma entidade. Por exemplo, podemos criar uma entidade de contexto
do tipo pessoa, com identificador maria, outras entidades do tipo pessoa não podem possuir o
identificador maria.
Informações que caracterizam uma entidade de contexto são representadas por meio de
atributos de contexto. Um atributo de contexto é uma tripla <nome, tipo, valor>. Por exemplo,
uma das informações que caracteriza a entidade maria pode ser a sua posição geográfica, que
pode ser representada por um atributo de contexto chamado localização, do tipo geolocalização
e com valor “5.8475293, -35.2079996” indicando que mariaencontra-se em Natal-RN.
Opcionalmente, um atributo de contexto pode possuir associado a si alguns metadados
que trazem informações contextuais relacionadas a um atributo, como por exemplo, a precisão
de seu valor, sua atualidade, etc. Metadados são representados pela tripla <nome, tipo, valor>.
Tomando como exemplo o atributo de contextolocalização da entidademaria, a precisão de seu
valor poderia ser representada pelo metadado com nome precisão, do tipo inteiro e com valor
20, indicando que a localização fornecida está sujeita a uma margem de erro de 20 metros.
A figura 2 seguir ilustra como a representação, em formato Json, da entidade de contexto
usada como exemplo.
Figura 2. Representação em formato Json de uma entidade de contexto.
2.2 Interface NGSI-9
A interface NGSI-9 foi desenvolvida com a finalidade de padronizar a troca de
informações acerca da disponibilidade de entidades de contexto.
Usando a interface NGSI-9 o cliente pode realizar:
1. Consultas acerca da disponibilidade entidades de contexto e
informações
(atributos de contexto) associadas a elas;
2. Subscrições afim de ser notificado sobre a disponibilidade de entidades de
contexto e informações associadas a elas;
3. Registro e atualização de entidades de contexto.
A tabela 1 apresenta 5 (cinco) operações que são disponibilizadas por sistemas que
implementam a interface NGSI-9. As operações devem ser acessadas por meio do protocolo
HTTP, o verbo HTTP utilizado em todas elas é POST. Tipicamente, a URI base para acesso à
essas operações é: http://<endereço do host>/NGSI9/
Operação
Descrição
registerContext
Permite registrar e atualizar dados referentes a uma entidade de
contexto. No corpo da mensagem HTTP devem ser passadas as
informações relacionadas a entidade a ser registrada/atualizada
(nome, atributos, metadados, etc)
discoverContextAvailability
Permite realizar a descobertas acerca das entidades de contexto
disponíveis. No corpo da mensagem HTTP devem ser informados
os critérios de busca.
subscribeContextAvailability
Permite realizar uma subscrição para ser notificado acerca da
disponibilidade de entidades de contexto. No corpo da mensagem
HTTP devem ser informado a entidade de contexto e atributos de
interesse, além do endereço de callback para o qual devem ser
enviadas as notificações.
updateContextAvailabilitySubsc
ription
Permite atualizar as entidades de contexto e atributos de interesse
de uma subscrição que foi previamente realizada.
unsubscribeContextAvailability
Cancela o interesse em receber notificações acerca de uma
subscrição.
{notificationURI}
Operação a ser implementada pelo usuário que deseja realizar
subscrições afim de receber notificações acerca da disponibilidade
de entidades de contexto. As notificações são enviadas para a URI
informada pelo usuário (notificationURI) no momento da
subscrição.
Tabela 1 - Operações definidas na interface NGSI-9
Embora as operações definidas na interface NGSI-9 sejam oferecidas de maneira
padronizada e utilizando o protocolo HTTP, essas operações não seguem com fidelidade os
princípios REST (Representational State Transfer), que define uma série de princípios e boas
práticas a serem seguidos para a concepção de sistemas hipermídia distribuídos. Estes princípios
são amplamente difundidos, recomendados e seguidos atualmente. Para isso, o projeto FIWARE
criou um conjunto de operações conhecidas como “operações de conveniência” como
alternativa ao uso da interface NGSI-9. Essas operações seguem com mais fidelidade os
princípios REST, podendo ser acessadas por meio do protocolo HTTP e utilizando os verbos
POST, PUT, GET e DELETE. Essas operações, no entanto, suportam apenas um subconjunto
das funcionalidades definidas na especificação NGSI-9. A Tabela 2 apresenta essas operações.
Operação
contextEntities/{EntityID}
/attributes
/attributes/{attributeName
}
/attributeDomains/{attrib
uteDomainName}
/contextEntityTypes/{type
Name}
Name}/attributes
Verbo
HTTP
Descrição
GET
Recupera informações sobre uma entidade de contexto
POST
Realiza o registro sobre a disponibilidade de uma entidade
de contexto
GET
Recupera o valor dos atributos de uma entidade de
contexto
POST
Regrista informações sobre atributos de uma entidade de
contexto
GET
Recupera o valor de um atributo de uma entidade de
contexto
POST
Registra informações sobre o valor de um atributo de uma
entidade de contexto
GET
Recupera o valor dos atributos de entidades de contexto
que pertencem a determinado domínio.
POST
Registra informações sobre atributos pertencentes a
determinado domínio
GET
Recupera informações sobre entidades de contexto
pertencentes a determinado tipo.
POST
Registra informações sobre entidades de contexto
pertencentes a determinado tipo
GET
Recupera informações sobre entidades de contexto que
pertencem a determinado tipo
POST
Registra informações sobre entidades de contexto que
GET
Recupera informações sobre atributos que pertencem a
determinado domínio e cujas entidades pertencem a
determinado tipo
contextEntityTypes/{typeN
ame}/attributes/{attribute
POST
Name}
Registra informações sobre atributos que pertencentes a
determinado domínio e cuja entidade pertence a
determinado tipo
Name}/attributeDomains/
{attributeDomainName}
contextAvailabilitySubscri
ptions
/contextAvailabilitySubscr
iptions/{subscriptionID}
GET
Recupera informações sobre atributos pertencentes a
determinado tipo e cuja entidade pertence a determinado
domínio
POST
Registra informações sobre atributos pertencentes a
determinado domínio e cuja entidade pertence a
determinado tipo
POST
Realiza uma subscrição pra ser notificado a respeito da
disponibilidade de entidades de contexto
PUT
Atualiza uma subscrição previamente registrada
DELETE
Cancela uma subscrição
Tabela 2 . Operações de conveniência alternativas ao uso da interface NGSI-9
Embora as operações de conveniência acima descritas tenham sido criadas como uma
alternativa ao uso da interface NGSI-9, é importante deixar claro que, geralmente, ambas as
alternativas são suportadas pelos Habilitadores Genéricos oferecidos pelo FIWARE, ficando a
cargo do usuário decidir qual alternativa utilizar.
2.3 Interface NGSI-10
A interface NGSI-10 foi desenvolvida com a finalidade de padronizar a troca de
informações contextuais acerca de entidades de contexto.
Usando as operações da interface NGSI-10 o cliente pode:
1. Cadastrar, atualizar e deletar informações acerca de entidades de contexto;
2. Recuperar de forma síncrona e assíncrona informações contextuais acerca de
entidades de contexto e seus atributos;
A tabela 3 apresenta as 5 operações definidas na especificação da interface NGSI-10. As
operações a seguir devem ser acessadas por meio do protocolo HTTP, o verbo HTTP utilizado
em todas elas é o
POST. Tipicamente, a URI base para acesso à essas operações é:
http://<endereço do host>/NGSI0/
Operação
Descrição
updateContext
Permite registrar, atualizar e deletar dados referentes a uma entidade de
contexto. No corpo da mensagem HTTP devem ser passadas as
informações relacionadas a entidade a ser registrada, atualizada ou
deletada. Para cada elemento de contexto passado na requisição deve
haver, associado a ele, o atributo updateAction com um dos seguintes
valores:
● update, cadastra uma nova entidade de contexto e seus atributos
caso eles ainda não existam, ou os sobrescreve caso já existam;
● append, adiciona novas atributos a uma entidade de contexto, e;
● delete, deleta uma entidade de contexto.
subscribeContext
Permite ao usuário realizar uma subscrição afim de receber, de forma
assíncrona, informações contextuais sobre determinada entidade. No
corpo da mensagem HTTP o usuário deve passar as informações nas quais
ele tem interesse e o endereço de callback para o qual as notificações
devem ser encaminhadas.
updateSubscription
Permite ao usuário atualizar informações acerca de uma subscrição
previamente registrada. No corpo da mensagem HTTP o usuário deve
passar o identificador da subscrição previamente registrada e as novas
informações de interesse.
unsubscribeContext
Permite ao usuário cancelar o interesse em receber notificações referentes
a uma subscrição previamente registrada. No corpo da mensagem HTTP o
usuário deve informar o identificador da subscrição.
queryContext
Permite realizar buscas síncronas acerca de entidades de contexto e seus
atributos. No corpo da mensagem HTTP o usuário deve especificar quais
informações ele deseja buscar.
Operação a ser implementada pelo usuário que deseja realizar subscrições
{notificationURI}/Query afim de receber notificações acerca de informações contextuais de
entidades de contexto. As notificações são enviadas para a URI informada
Context
pelo usuário (notificationURI) no momento da subscrição.
Tabela 3. Operações definidas para a interface NGSI-10
Assim como na especificação NGSI-9, as operações especificadas na interface NGSI-10
não seguem com fidelidade os princípios REST. Então, assim como aconteceu para a interface
NGSI-9, o projeto FIWARE criou também um conjunto de “operações de conveniência”
alternativas ao uso da interface NGSI-10. As operações de conveniência seguem com mais
fidelidade os princípios REST, podendo ser acessadas por meio do protocolo HTTP e utilizando
os verbos POST, PUT, GET e DELETE. Essas operações, no entanto, suportam apenas um
subconjunto das funcionalidades definidas na especificação NGSI-10. A Tabela 4 apresenta
essas operações.
Operação
contextEntities/{EntityID}/
attributes
Verbo
HTTP
Descrição
GET
Recupera informações sobre uma entidade de contexto
POST
Realiza o registro de uma nova entidade de contexto ou a
adiciona novos atributos à entidade caso a entidade já exista.
PUT
Atualiza o valor dos atributos de uma entidade de contexto.
DELETE
Deleta uma entidade de contexto.
GET
Recupera informações sobre os atributos de uma entidade de
contexto
POST
Adiciona novos atributos a uma entidade de contexto já
existente
PUT
Atualiza o valor dos atributos de uma entidade de contexto
DELETE
Deleta os atributos de uma entidade de contexto
GET
Recupera o valores dos atributos de contexto e dos
metadados associados pertencentes a determina entidade e
cujo nome do(s) atributo(s) é igual ao nome informado
attributes/{attributeName} POST
Adiciona um novo atributo a uma entidade de contexto
DELETE
Deleta os atributos de uma entidade de contexto cujo nome é
igual ao nome informado
GET
Recupera o valo de um atributo de contexto específico
PUT
attributes/{attributeName}/
{attributeID}
DELETE
contextEntities/{EntityID}/ GET
attributeDomains/{attribute
Atualiza o valor de um atributo de determinada entidade de
contexto
Deleta um atributo específico de uma entidade de contexto
Recupera todos os atributos pertencentes a uma domínio
específico.
DomainName}
contextEntityTypes/{typeN GET
ame}
Recupera todas as informações referentes à entidades de
contexto pertencentes a determinado tipo
ame}/attributes
Recupera todos os atributos de contexto associados à
entidades de contexto pertencentes a determinado tipo
ame}/attributes/{attributeN
ame}
Recupera todos os valores dos atributos cujo nome do
atributo é igual ao informado e cujas entidades de contexto
ame}/attributeDomains/{at
tributeDomainName}
Recupera as informações de todos os atributos pertencentes a
determinado domínio e cujas entidades pertencem a
determinado tipo
contextSubscriptions
contextSubscriptions/{subs
criptionID}
POST
Registra o interesse em receber informações sobre entidades
de contexto de forma assíncrona
PUT
Atualiza os dados referentes a uma subscrição previamente
registrada
DELETE
Cancela em o interesse em receber informações referentes a
determinada subscrição
Tabela 4 . Operações de conveniência alternativas ao uso da interface NGSI-10
Embora as operações de conveniência acima descritas tenham sido criadas como uma
alternativa ao uso da interface NGSI-10, é importante deixar claro que geralmente ambas as
alternativas são suportadas pelos Habilitadores Genéricos oferecidos pelo FIWARE, ficando a
cargo do usuário decidir qual alternativa utilizar.
3Applications and Services Ecosystem and Delivery Framework
Nesta seção será apresentada uma visão geral dos habilitadores genéricos (Generic
Enablers) da plataforma FIWARE, relacionados à aplicações, serviços e dados. Estes
habilitadores genéricos, juntos, dão suporte à criação de um ecossistema de aplicações, serviços
e dados sustentável, que promove a inovação e oferecem o suporte ao gerenciamento de serviços
em um framework de negócios, durante todo o ciclo de vida de um serviço, a partir de sua
criação, composição com outros serviços, até a monetização e compartilhamento de receitas
relacionadas ao serviço.
Os habilitadores genéricos que fazem parte da arquitetura de referência da plataforma
podem ser agrupados em três grandes blocos arquiteturais, como mostra a Figura 3.
Business API Ecosystem GE: Define um conjunto de APIs padrão para uma descrição
uniforme de produtos e ofertas. Este ecossistema inclui funcionalidades, que permitem a venda
de ativos digitais (ou seja, aplicações, serviços e dados) para os consumidores, bem como,
desenvolvedores de aplicações e é responsável por gerenciar as ofertas e vendas desses ativos.
Application Mashup Framework GE: Este GE tem como objetivo suportar o mashup
de aplicações, com foco na criação de dashboards para visualização de dados e também
operações para os dados e serviços utilizados. O framework utiliza a noção de aplicação e
mashup de dados para permitir que usuários com conhecimento e usuários com pouca ou
nenhuma habilidade de programação, possam facilmente desenvolver, de forma visual, mashups
de aplicações e gerar diferentes dashboards.
Data Visualization Framework GE: Responsável pela criação de visualizações e
geração de relatórios significativos sob grandes conjuntos de dados, para apresentá-los aos
interessados e fornecer análises de dados personalizadas, permitindo que haja interação dos
interessados com o conjunto de dados apresentado, a fim de realizar uma análise específica.
Figura 3. Modelo Arquitetural do framework de Aplicações, Serviços e Dados
A Figura 3 mostra um modelo exemplificando como os GEs podem ser usados numa
arquitetura real. O provedor de serviços precisa disponibilizar interfaces para aceitar transações
comerciais de consumidores que, por exemplo, queiram comprar um serviço no Business API
Ecosystem. Além de fazer todas as preparações necessárias para que o cliente realmente utilize
o serviço, conforme descrito no contrato. Independente de como estes GEs estejam organizados
na arquitetura, a interação entre eles e outros componentes da arquitetura é assegurada através
de especificações ligadas às interfaces suportadas pelos GEs, através do qual toda comunicação
e interação é realizada.
Do lado esquerdo da Figura 3, há os GEs (Application Mashup e Data Visualization) do
provedor de serviços que podem ser usados para gerenciar diferentes tipos de dashboards, de
acordo com a composição das aplicações. O provedor de serviços pode colocar aplicações,
serviços ou dados em uma loja (parte do Business API Ecosystem GE), que provê
funcionalidades de descoberta, monetização, compartilhamento e gestão de receitas.
Adicionalmente, o Business API Ecosystem GE interopera com componentes externos (lado
direito da Figura 3), encarregados de recuperar informações de contabilidade dos serviços. Os
GEs do provedor de serviços também podem interagir com componentes externos, por exemplo,
o Data Portal, para recuperar dados e mostrar diversos tipos de análises.
3.1. Data Visualization (SpagoBI)
3.1.1. Objetivos
O SpagoBI fornece recursos analíticos para obtenção de conhecimento sobre os dados e
permite transformá-los em conhecimento viável para processos de tomada de decisão eficazes.
O SpagoBI inclui não apenas ferramentas de relatórios e gráficos usuais, mas também soluções
inovadoras como: inteligência de localização, tempo real, mobile, mineração de dados, big data,
etc. Sua abordagem modular, arquitetura escalável e padrões abertos garantem uma fácil
personalização e desenvolvimento de soluções de fácil utilização [41].
3.1.2. Descrição
SpagoBI é uma ferramenta que usa diversas outras tecnologias para, por exemplo,
permitir a produção de relatórios usando visualização de informação estruturada (listas, tabelas,
tabelas de referência cruzada, gráficos). Para isso, trabalha com tecnologias como JasperReport,
BIRTReport, BO e Accessibility. A ferramenta também permite a realização de análises
multidimensionais através do mecanismo Online Analytical Processing (OLAP). Além disso, o
SpagoBI oferece ferramentas de visualização de dados poderosas, para construção de
dashboards/cockpits, como JfreeCharts, HighCharts e ExtCharts. O SpagoBI pode interagir
com outros GEs da plataforma FIWARE, como o CKAN, utilizando o SpagoBI Server, e com
o Orion, através da API NGSI [41].
A Figura 4 mostra os principais componentes da arquitetura do SpagoBI. O SpagoBI
Studio é um ambiente de desenvolvimento baseado no Eclipse que permite que o desenvolvedor
possa projetar e modificar documentos analíticos. Ele dá suporte aos usuários durante a
concepção dos documentos e durante a instalação e teste de processos no SpagoBI Server. O
SpagoBI Meta é um módulo focado especificamente no gerenciamento de metadados e
consultas. Ele gerencia os metadados, permitindo que o usuário saiba mais sobre os dados em
fase de avaliação e permitindo que o administrador saiba a origem dos dados, para fornecer a
documentação automática ou para fazer análises de impacto [41].
SpagoBI SDK é uma ferramenta específica usada na integração de serviços fornecidos
pelo servidor. Ela é usada no SpagoBI Studio para permitir que os usuários possam fazer
downloads/uploads dos documentos analíticos diretamente do servidor. SpagoBI Analytics são
as aplicações que exploram as funcionalidades do SpagoBI para atender as necessidades do
mercado.
Figura 4. Arquitetura do SpagoBI
SpagoBI Server fornece Worksheet Engine, uma ferramenta que permite que o usuário
final possa construir uma consulta usando a interface web Qbe e, em seguida, criar um conjunto
de gráficos e tabelas através de uma interface fácil de usar. O projeto SpagoBI incorpora a
plataforma de tecnologia Business Intelligence and Reporting Tools (BIRT) em seus
produtos. Precisamente, o SpagoBI Studio contém um designer de relatório visual para a criação
de BIRT Designs, enquanto que oSpagoBI Server contém o Worksheet Engine para gerar os
designs que podem ser implantados a qualquer ambiente Java. O SpagoBI Server permite que o
usuário defina os parâmetros para qualquer documento de análise.
2.1.3. Exemplo de uso e Problemas Encontrados
Nesta seção será descrito um exemplo de uso do SpagoBI Server para gerar um
dashboard/cockpit, a partir de um conjunto de dados armazenados em um arquivo XLS. A figura
5 mostra a interface principal do SpagoBI Studio, que oferece um conjunto de funcionalidades
representadas pelos ícones do lado esquerdo da tela: retornar para a página principal, acesso ao
menu, que inclui funcionalidades de análise previamente setadas pelo administrador, mostrar
pastas contendo arquivos e análises, criação de análises a partir de um modelo de dados, entre
outras.
Figura 5. Tela Home SpagoBI
O primeiro passo para a criação do dashboard deste exemplo é a criação do conjunto de
dados que será acessado pelo servidor. A Figura 6 mostra a tela de criação de um novo dataset.
Do lado esquerdo, o SpagoBI Server mostra um conjunto de datasets previamente criados que
pode ser utilizados para teste. Ao clicar no botão “Add”, ele abre a tela a direita, onde deve-se
preencher os campos do dataset: rótulo, nome, descrição, categoria e escopo.
Figura 6. Tela de Criação de um Dataset
Uma vez preenchidos os dados iniciais do dataset, deve-se definir o tipo de dataset que
será utilizado. Neste exemplo este tipo é um arquivo XLS que contém os dados que vão ser
mostrados no dashboard. A Figura 7 mostra a tela onde foi selecionado o tipo “File” e foi feito
o upload do arquivo. Este tipo, pode ser um conjunto de dados armazenados no CKAN ou no
Orion Context Broker, entre outros.
Figura 7. Tela de Definição do Tipo de Dataset
Após definir o tipo do dataset e fazer o upload, o SpagoBi permite uma pré-visualização
dos dados através da aba “Preview”. A Figura 8 mostra esta pré-visualização dos dados
inseridos. A Figura 9 mostra a visualização dos metadados dos campos, inicialmente todos eles
estão como ATTRIBUTE, porém o SpagoBI Server permite que o usuário altere esse metadado
para MEASURE, indicando que ele pode realizar algum tipo de medição durante a análise. Após
fazer estas mudanças o usuário deve clicar na opção “Save” no canto superior direito.
Figura 8. Tela de Preview do Dataset
Figura 9. Tela de Metadados dos Campos de um Dataset
Para inciar a criação do dashboard/cockpit, deve-se acessar o menu lateral “Document
Browser”. A Figura 10 mostra a tela exibida ao clicar nesta opção. O usuário deve selecionar
“Cockpit” na opção CREATE DOCUMENT.
Figura 10. Tela de Criação de Cockpit
O SpagoBI Server vai abrir uma nova tela de edição do dashboard, como mostra a Figura
11. Nesta tela o usuário pode colocar vários widgets, que irão apresentar os dados em algum
tipo de gráfico que o usuário defina. Para isso, ele deve clicar no ícone com símbolo de mais no
canto superior direito e logo aparecerá o widget para que ele possa configurar.
Figura 11.Tela de Edição do Cockpit
As telas seguintes (Figuras 12, 13, 14 e 15) mostram as configurações que podem ser
feitas no widget. Na tela da Figura 12, o SpagoBI Server apresenta várias opções de análises que
pode ser feitas sobre os dados. No exemplo foi utilizada a SuperStore_Demo_Analysis. Ao clicar
nesta análise o servidor abre uma tela com algumas opções de gráficos para visualização (em
linhas, barras ou pizza). Basta clicar e arrastar a opção desejada para a área da “Custom
Configuration”. Ao lado direito da Figura 12, também pode-se acessar os campos definidos no
arquivo XLS que se deseja mostrar no gráfico.
Ao finalizar as configurações do gráfico, o SpagoBI Server renderiza este gráfico no
widget. A Figura 19 mostra o resultado final do dashboard criado seguindo os passos mostrados
nas telas.
Figura 12. Arquitetura do RSS GE
3.1.4. Próximasatividades
As próximas atividades a serem desenvolvidas usando esse GE são:
-Desenvolver exemplo de integração com o CKAN
-Desenvolver exemplo de integração com o Orion Context Broker usando a API NGSI
3.2. Repository GE
3.2.1. Objetivos
O Repository GE é um elemento central do FIWARE Business Framework (em conjunto
com a Store GE e o MarketPlace GE) que consiste em uma implementação de referência que
fornece uma API uniforme e consistente para acessar descrições de serviço USDL (Unified
Service Description Language) e arquivos de mídia associados para aplicações de âmbito
empresarial.
3.2.2. Descrição
Um prestador de serviços pode usar o Repositório GE para publicar a descrição de vários
aspectos do serviço, de acordo com uma linguagem de descrição unificada em um local comum
para armazenamento (central ou distribuído e replicado), de referência e/ou segurança. Na
Figura 20 é possível visualizar a interação do Repository GE com os demais GEs dentro do
Business Frameworks.
Figura 20 - Repositório no contexto de Business Framework.
Normalmente, um repositório está sob o controle de uma autoridade e, é de
responsabilidade dessa autoridade, manter o controle de versões, autenticidade e datas de
publicação.
O Repository GE segue princípios da web, tais como: a identificação dos recursos através
de URI, facilitando o acesso por meio da Internet, compatibilidade com diversas linguagens de
descrição como RDF, XML, RSS, JSON, além de fornecer um formato de saída legível usando
HTML ('text/html'). Cmo foco principal, o enable especifica a estrutura dos dados no formato
de Linked Data através do suporte RDF, além de permitir consultar esses dados de forma
dinâmica com SPARQL.
Em geral, as principais funcionalidades do Repository GE são:
•
•
•
Salvar recursos como serviços em uma linguagem de descrição unificada,
permitindo buscas automáticas por aplicações;
Salvar descrição de aplicações como suporte a outros Generic Enablers da
FIWARE;
Permitir tanto requisições como acesso em diferentes formatos das descrições do
serviços e das aplicações.
Arquitetura do Repository GE
As especificações para a arquitetura do Repository GE são superficiais devido a
variabilidade dos ambientes nos quais o Repositório pode ser implementado. Nela são
apresentados um protocolo de acesso através de uma URL pelo Browser ou diretamente por
uma aplicação. A arquitetura possui módulos básicos para negociação de conteúdo, controle de
acesso e Gerenciamento do conteúdo. O módulo de negociação de conteúdo irá definir, por
exemplo, o tipo de conteúdo de entrada, RDF, HTML ou JSON. O módulo de controle de acesso
irá verificar a autenticidade da requisição para uma coleção especificada por exemplo. Por fim,
o gerenciador de conteúdo será responsável pelo acesso direto ao conteúdo, como um sistema
gerenciador de banco de dados. A figura 21 apresenta uma proposta de Arquitetura do
Repository GE.
Figura 21 - Exemplo alto nível de uma arquitetura proposta pelo Repository GE.
A seguir será discutido o que é RDF e suas tecnologias dependentes e como esse modelo
constrói a estrutura dos dados armazenados no Repository GE.
Formato de representação através de RDF e Linked-USDL
RDF é um modelo de dados baseado em Grafo, onde cada vértice do grafo é um recurso
identificado por uma URI, e cada par de vértice se relaciona através de triplas:
● Sujeito: Vértice que representa recurso;
● Predicado: Aresta descrevendo o relacionamento entre sujeito e objeto;
● Objeto: Vértice que representa Recurso.
Figura 22 - Ilustração de uma tripla RDF.
Observando a figura 22 vemos que RDF descreve a relação entre Ian e Mary, através de
um grafo usando uma ontologia foaf, que é um vocabulário padrão para descrever pessoas. Dessa
forma, RDF, diferente de uma modelo relacional de banco de dados, consegue atribuir
significados das relações entre os dados, associado a isso, é criado um padrão em que todos
devem seguir, que no exemplo da figura é a forma de descrever pessoas através de foaf.
Existem vários formatos para persistir dados RDF entre eles o Repository GE especifica:
rdf+xml, turtle, x-turtle, n3, rdf+n3, n-triples. Porém, o suporte depende da implementação.
Assim como foaf é um ontologia RDF para descrição de pessoas, Linked-USDL é uma
linguagem de descrição de serviços modelada em RDF.
O Repository GE persiste os modelos de serviço através da descrição desses em LinkedUSDL. O motivo da adoção de Linked-USDL como a linguagem de descrição de serviços está
no fato de que cada serviço pode ser identificado por uma URL, e como um serviço é modelado
com RDF, é possível fazer buscas especificas de forma automática usando SPARQL.
Organizando Recursos em Coleções
Os recursos armazenados no Repositório GE são organizados através de coleções. Essas
coleções, além de categorizar os recursos, definem uma hierarquia de acesso ao repositório, ou
seja, para acessar uma recurso é necessário especificar a coleção a que ele pertence. Por
exemplo, uma descrição de serviço, muitas vezes tem documentação adicional, representações
e outras informações de garantia, que podem ser agrupados em uma coleção.
Especificação da API
O Repository GE especifica uma API para acesso e gerenciamento de recursos
(obrigatório na implementação) e também para coleções.
A API do Repositório é baseado em princípios REST (Representational State Transfer)
e geralmente retorna respostas XML ou JSON codificado. A seguir será apresentado como são
feitas as operações no repositório através de solicitação HTTP, para manipulação de recursos e
coleções.
Os Recursos são compostos por metadados e o conteúdo. É possível criar, obter, atualizar
e excluir recursos e, assim, é possível gerir recursos diferentes dentro do repositório. A tabela 5
mostra os atributos que formam a estrutura interna de um Recurso:
Atributo
Tipo
Descrição
Id
String
Caminho que identifica o recurso.
name
String
Nome que identifica o recurso e também a coleção que ele
está posicionado. Cada nome de recurso deve respeitar a
expressão regular ((.*[^a-zA-Z0-9._-]+.*)|(.*.meta$))+.
creationDate
Date
Data em que o recurso foi criado.
modificationDate
Date
Data da última modificação do recurso.
creator
String
Nome do criador do recurso.
contentURL
String
URL do conteúdo do recurso. Ela não pode ser atualizado.
contentMimeType
String
Tipo do conteúdo do recurso armazenado. Ele não pode ser
atualizado manualmente.
contentFileName
String
Nome do arquivo.
Content
bytes[]
O conteúdo armazenado na representação de array de bytes.
Tabela 5. Atributos que foram a estrutura interna dos recursos
Através da API é possível manipular os metadados de um recurso, o conteúdo de um
recurso em RDF, e ainda fazer consultas complexas utilizando SPARQL. As operações com
Recursos especificadas pela API estão descritas na tabela 6.
Operação
Verbo
HTTP
Descrição
/FiwareRepository/v2/collec/collection/
resource.meta
GET
Busca metadados de Recurso
informando o id da coleção (collection)
e o nomedo recurso (resource).
resource.meta
POST
Cria metadados de Recurso informando
o id da coleção (collection) e o name do
recurso (recurso).
resource.meta
PUT
Atualiza metadados de Recurso
resource.meta
DELETE
Deleta Recurso informando o id da
coleção (collection) e o name do recurso
(recurso).
resource
GET
Busca conteúdo de Recurso informando
o id da coleção (collection) e o nomedo
recurso (resource).
resource
POST
Insere ou atualiza conteúdo de Recurso
/FiwareRepository/v2/service/query?qu
ery={ShortQuerySPARQL}
GET
Consulta diretamente a base de dados
em RDF passando como parâmetro uma
Query String em SPARQL.
/FiwareRepository/v2/service/query
POST
em RDF. Passando como corpo da
mensagem a Query String longa em
SPARQL.
/FiwareRepository/v2/service/query/co
ntentURL
GET
buscando o recurso pela seu atributo
contentURL.
Tabela 6 . Operações com Recursos especificadas pela API
3.2.2. Exemplo
O Repository RI é uma implementação das especificações do Repository GE. Através do
endereço do GitHub 2 é possível obter as informações necessárias para instalação e testes da
ferramenta, que serão descritas, de forma resumida, nos próximo tópicos.
Processo de instalação
De antemão é necessário ter o Git e o Maven instalados na máquina. Com isso é
necessário clonar o projeto do Repository RI do Github:
git clone https://github.com/conwetlab/Repository-RI.git
No projeto baixado do github, é necessário atualizar o script de instalação do Apache Tomcat,
localizado em “/Repository-RI/scripts/installTomcat8.sh”, modificando os seguintes trechos
do arquivo:
wget http://apache.rediris.es/tomcat/tomcat-8/v8.0.33/bin/apache-tomcat-8.0.33.zip
unzip apache-tomcat-8.0.33.zip
mv apache-tomcat-8.0.33 apache-tomcat
export CATALINA_HOME=$INSPWD/apache-tomcat
echo "export CATALINA_HOME=\"$INSPWD/apache-tomcat\"" >> ~/.bashrc
chmod +x $INSPWD/apache-tomcat/bin/*.sh
Finalmente, executa-se o script de instalação:
./install.sh
Inicialização
O script de instalação inicia automaticamente o Repository RI. Porém, caso o sistema
operacional esteja sendo iniciado, o Repositóry RI pode ser inicializado dando start no Tomcat
2
https://github.com/Fiware/apps.Repository-RI
e no Virtuoso. Esse processo é realizado conforme os passos a seguir:
●
Inicializar o Virtuoso:
cd ~/Repository-RI/virtuoso7/var/lib/virtuoso/db/
~/Repository-RI/virtuoso7/bin/virtuoso-t -f &
cd ~/Repository-RI
●
Inicializar o Tomcat:
.~/Repository-RI/apache-tomcat/bin/startup.sh
Testes
Criar um arquivo resource.xml contendo o metadado do Recurso como conteúdo,
conforme a figura a seguir:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<resource>
<creator>Creator</creator>
<creationDate></creationDate>
<modificationDate></modificationDate>
<name>resource</name>
<contentUrl>http://testresourceurl.com/resource</contentUrl>
<contentFileName>resourceFileName</contentFileName>
</resource>
Submeter o arquivo através de uma operação POST especificando o caminho (caso as
coleções não existam, elas serão criadas). O comando de submissão pode ser visualizado a
seguir:
curl -v -H "Content-Type: application/xml" -X POST --data "@resource.xml"
http://[SERVER_HOST]/FiwareRepository/v2/collec/collectionA/collectionC
Criar um arquivo com conteúdo em RDF, no exemplo um serviço de máquina virtual
está descrito em Linked-USDL no formato “xml+rdf”, conforme a Figura a seguir:
Figura 23: Exemplo de conteúdo de um Recurso.
Por fim, submeter o arquivo criado especificando o formato dos dados RDF, o nome do
arquivo, e o caminho completo no qual os metadados do recurso foram salvos. O processo de
submissão bem sucedido pode ser visualizado na Figura 24
Figura 24: Submissão de conteúdo de um Recurso.
O serviço registrado no Repository pode ser consultado através da linguagem SPARQL
através do seguinte comando:
curl -v -H "Accept: application/json" -H "Content-Type: text/plain" -X POST --data "SELECT ?x WHERE
{?x <http://www.w3.org/2000/01/rdf-schema#Cost> ?y}"
http://localhost:8080/FiwareRepository/v2/services/query
O resultado retornado é no formato JSON como pode ser visualizado a seguir:
{"vars":1,
"columns":
[{"values":
["http://www.w3.org/1999/02/22-rdf-syntax-ns#Standard_M1__Small_default"],
"name":"x"
}]}
3.3. Revenue Settlement and Sharing System
3.3.1. Objetivos
O Revenue Settlement and Sharing System (RSS) é o encarregado de distribuir as receitas
originadas pelo uso de um determinado serviço entre as partes envolvidas. Em particular, o foco
é na distribuição de receitas entre o fornecedor do Marketplace/Store e o provedor de serviços
responsável pelo serviço (aplicações finais, serviços de aplicações backend) [42]. Principais
recursos oferecidos:
● Armazenamento de transações comerciais
● Definição de modelos para compartilhamento das receitas
● Determinação da renda do serviço
● Emissão de relatórios sobre as receitas
● Gerenciamento de controle de despesas
2.3.2. Descrição
O compartilhamento de receitas é baseado num modelo de negócios (revenue sharing
models), que determina como essas receitas devem ser distribuídas. O RSS GE deve ser
alimentado, através das APIs disponíveis, com esses modelos e informações adicionais sobre o
provedor de serviços. Diferentes modelos de negócios podem ser atribuídos para um provedor
de serviços, cada um deles, baseado na combinação de parâmetros tais como, a classe do
produto. Por exemplo, o modelo utilizado para calcular o pagamento de um provedor de serviços
para música, pode ser diferente de um modelo de provedor de serviços para aplicações.
Conceitos básicos do RSS:
Charging Data Record (CDR): Um documento CDR contém informações de cobrança
gerados durante uma transação comercial, incluindo informações dos serviços cobrados, o
prestador de serviços, o cliente, o valor cobrado, etc [42].
Application/Product Class: Define um grupo de serviços ou aplicações com
características similares. Cada aplicação ou serviço registrado no RSS GE pertence a uma classe
application/product [42].
Revenue Sharing Model (RS Model): Um modelo RS especifica a forma de dividir o
montante total cobrado entre os diferentes participantes relacionadas à aplicação. Estes modelos
incluem informações sobre o prestador de serviços, o tipo de evento levado em consideração no
modelo (assinatura, pay-per-use, etc), etc. Modelos RS são aplicados para completar classes de
aplicação, de modo que todas as informações de cobrança dos serviços dentro de uma classe de
aplicação são distribuídas de acordo com o mesmo modelo RS [42].
Settlement: Refere-se ao processo de agregação da informação de cobrança incluída em
conjunto de CDRs e o cálculo da quantidade a ser paga aos diferentes participantes de acordo
om o modelo RS relacionado à aplicação. Este processo é realizado periodicamente para todos
os prestadores de serviços registrados no RSS GE ou manualmente lançados por um
administrador de sistema para um provedor de serviço concreto [42].
Expenditure Limit:São limites de despesa que o usuário pode definir, que podem ser
aplicados em transações comerciais ou por um período de tempo.
A Figura 25 mostra a arquitetura do RSS GE. Esta arquitetura é dividida em dois
principais módulos funcionais:
Settlement Management:Este módulo é encarregado pelo gerenciamento do processo
settlement, incluindo o gerenciamento de CDRs e modelos RS. O gerenciamento de CDRs inclui
um serviço onde a Store GE pode alimentar documentos CDR contendo informações de
cobrança e um gerente encarregado de salvar e recuperar estes documentos do banco de dados.
O gerenciamento de modelos RS também inclui um serviço onde estes modelos podem ser
alimentados e recuperados e um gerente para salvar e recuperar os modelos a partir de banco de
dados. O módulo Settlement executa o processo em si.
Expenditure Limits and Control Management:Este módulo é responsável por gerenciar
o controle de despesas, incluindo o gerenciamento de limites de despesa e saldo acumulado.
Também é responsável por verificar se uma transação pode ser feita de acordo com os limites
de despesas previamente definidos e o saldo.
3.4. Store (WStore)
3.4.1. Objetivos
Essa é a implementação de referência do Wstore GE que fornece aos usuários uma loja
integrada para a venda de bens digitais, incluindo: serviços, APIs, conjuntos de dados,
aplicativos, Mashups, etc., para os consumidores, bem como desenvolvedores de aplicações e
serviços da Internet do futuro e para a gestão end-to-end de ofertas e vendas.
3.4.2. Descrição
O Store GE é baseado no conceito de organização. Uma organização será gerenciada
como um grupo de usuários. Neste contexto, algumas ofertas podem ser adquiridas através da
compra e ser acessível a todos os usuários dentro de uma organização. Assim como organizações
têm mais de um usuário membro, este mesmo usuário pode ser membro de mais de uma
organização e pode adquirir várias ofertas em cada uma delas. No Store GE uma oferta pode ser
publicada por uma organização, invés de um usuário. Usuários não podem publicar ofertas, a
menos que estejam agindo em nome de uma organização. O Identity Management GE é
responsável pelo gerenciamento das organizações dentro da plataforma FIWARE e interage com
a Store [43].
Por prover diferentes funcionalidades, é necessário definir um modelo para controle de
privilégios e forma de acesso dos usuários à Store. As funções de usuários definidos consoante
os privilégios e as possíveis interações com a Store GE são as seguintes:
Admin: É responsável pela administração do sistema, que inclui, administração do
banco de dados, registro das instâncias do Repository GE para armazenar os modelos de serviços
oferecidos na Store GE, registro de instâncias do RSS GE para realizar a distribuição das receitas
geradas entre as partes envolvidas em uma oferta e de instâncias da Store GE em instâncias do
MarketPlace GE, onde a oferta está sendo publicada.
Provider: É responsável pela publicação de ofertas de serviços.
Costumer: Esta função pode comprar uma oferta que pode ou não fazer parte dos
serviços adquiridos por qualquer das organizações de que ele é membro.
Developer: Pode comprar uma oferta que defina um plano de preço especial para
desenvolvedores, e que talvez inclua um modelo RS entre o Provider e o Costumer.
A Figura 26 mostra a arquitetura da Store GE que está dividida em uma série de módulos
funcionais e mostra as relações entre a Store GE e outros GEs. Os usuários podem utilizar a
Store GE através do seu portal web, enquanto outros GEs, aplicações finais e serviços podem
utilizar a API definida pela Store GE para gerenciar e realizar a compra de ofertas previamente
descobertas no MarketPlace GE. A figura também ilustra a conexão com o Application Mashup
GE, que usa a Store para adquirir diferentes componentes web, que são usados para compor
diferentes mashups e para publicar o resultado destas composições na Store.
Figura 26. Arquitetura da Store GE
A Store também se conecta ao Marketplace GE, para registrar qualquer nova oferta que
tenha sido publicada e ao Repository GE, a fim de armazenar os documentos USDL que
descrevem essas ofertas e seus documentos associados (WSDL, WADL, etc.). Além destes GEs,
a Store também se conecta ao RSS GE, que é utilizado para realizar a divisão do pagamento
entre os respectivos participantes. A Store usa o Identity management GE para obter
informações sobre usuários, organizações, funções, e aplicações [43].
Para realizar estas conexões a Store GE tem módulos responsáveis por realizar a
comunicação com os outros GEs (Marketplace Interface, Repository Interface, IdM interface).
O módulo Administration é utilizado por usuários com a função Admin, para gerenciar a Store
e registrar sua instância nas instâncias do Marketplace. O módulo Offering gerencia as ofertas
do provedor, ou seja, ele cria novas ofertas, publica novos recursos, e liga recursos à ofertas,
publica e coloca ofertas à venda. Este módulo também é responsável por ofertas adquiridas e
oferecer ao consumidor a informação sobre essas ofertas e seus recursos associados [43].
A Figura 26 também mostra o módulo User Manager, que é responsável pela gestão de
usuários, supervisionando os diferentes papéis e privilégios, a fim de controlar o acesso a
diferentes funcionalidades da Store. Outro módulo da Store GE é o Contracting, que é
responsável pela gestão de assinaturas e compras das diferentes ofertas publicadas na Store. O
módulo Search é responsável pela busca de ofertas publicadas de acordo com filtros e
parâmetros definidos pelos usuários.
3.5. Application Mashup (WireCloud)
3.5.1. Objetivos
Mashups de aplicações Web integram dados heterogêneos, lógica de aplicação e
componentes de interface gráfica (widgets/gadgets) provenientes da Web para criar novas
aplicações compostas. Esses Mashups podem ser desenvolvidos manualmente utilizando
tecnologias de programação web tradicionais, mas não conseguem aproveitar plenamente esta
abordagem. O Application Mashup GEvisa definir paradigmas de desenvolvimento que não
exigem conhecimentos de programação e, portanto, são direcionados aos usuários finais (sendo
eles funcionários de negócios, clientes ou cidadãos). Eles também ajudam a alavancar a
inovação através da experimentação e prototipagem rápida [44].
Principais características:
● Suporte a uma linguagem Mashable Application Component Definition Language
(MACDL), independente de plataforma.
● Suporte a esquemas XML/RDF para a MACDL.
● Compatibilidade com a especificação USDL.
● Suporte ao formato zipado (WGT), que permite que os componentes da aplicação
possam ser convenientemente armazenados e distribuídos.
● Suporte ao wiring, que é um mecanismo que permite que o usuário final possa facilmente
conectar widgets em um Mashup para criar dashboards/cockpits direcionados a eventos.
● Suporte ao piping, que é um mecanismo que permite que o usuário final facilmente
conecte os widgets à serviços back-end ou fontes de dados através de um conjunto
extensível de operadores.
● Suporte a renderização virtual de widgets na interface gráfica do Mashup da aplicação.
● Suporte ao gerenciamento do ciclo de vida dos widgets, operadores e mashups.
● Fornecer um modelo de execução capaz de implantar e executar um mashup de um
arquivo MACDL.
● Permitir que os usuários finais possam armazenar e compartilhar seus mashups de
aplicações recém-criadas com outros colegas e usuários por meio da comunicação com
a Store GE.
2.5.2. Descrição
A Figura 27 mostra a arquitetura genérica do Application Mashup GE. Este GE provê as
funcionalidades necessárias para o desenvolvimento e execução de mashups. A figura mostra
os três principais componentes que formam o núcleo deste GE: Composition Editor, Mashup
Execution Enginee Local Catalogue.
Figura 27. Arquitetura do Application Mashup GE
Composition Editor: É uma ferramenta baseada em tecnologias web, com a qual, usuários
podem interagir via web browser a fim de criar seus próprios mashups de aplicação. Este
componente deve, pelo menos, oferecer aos usuários finais uma espécie de workspace onde eles
podem espacialmente colocar ou organizar widgets, além de uma visão adicional do mecanismo
de wiring para definir a interligação entre os widgets.
Mashup Execution Engine: Este componente coordena a execução dos widgets e controla o
fluxo de dados entre widgets. Ele pode acessar o Local Catalogue para implantar e executar os
widgets armazenados.
Local Catalogue: Este componente é onde as aplicações, quer tenham sido compradas na
FIWARE Business API Ecosystem GE ou instalados (uploaded) pelo usuário final, são
armazenadas, configuradas e definidas como prontas para implantação e execução. Este
componente deve ser uma espécie de vitrine para o usuário logado no Application Mashup GE.
Nesta seção será descrito um exemplo de uso do ambiente Wirecloud pelo usuário final,
a fim de fazer mashup de aplicações. Este exemplo segue o guia de usuário [45].
Figura 28. Criação de Workspace
A Figura 28 mostra a criação de um novo workspace no ambiente Wirecloud, onde foi
definido o nome History Info. A tela mostrada na Figura 29 mostra algumas configurações que
podem ser definidas no workspace criado: se é publico, layout e número de colunas.
Figura 29. Configurações do Workspace
Uma vez que o workspace foi criado e configurado, é necessário adquirir widgets e
operadores para fazer o mashup da aplicação. Esta aquisição pode ser feita diretamente na Store
GE, caso o usuário tenha uma conta FIWARE válida, ou fazendo o upload dos widgets e
operadores no workspace. Este upload é feito através da opção “My Resources”, a Figura 30
mostra o upload de um dos widgets utilizados neste exemplo.
Figura 30. Uploada de Widget no Workspace
A Figura 31 mostra os widgets e operadores disponíveis para serem utilizados no
Mashup das aplicações. É necessário adicionar os widgets e operadores que serão necessários
ao workspace criado, isso é feito através de um clique no ícone de mais ao lado do nome do
workspace e no próprio widget ou operador que se deseja adicionar (Figura 32).
Figura 31. Recursos Disponíveis
Figura 32. Adição de Widget no Workspace
Uma vez que os widgets e operadores estão adicionados ao workspace, o Wirecloud vai
mostrar uma tela, como a da Figura 33, onde aparece o widget no mapa e do gráfico linear. O
usuário pode configurar ou remover um widget através desta interface, clicando nele. Na Figura
34 o widget do mapa foi configurado para mostrar a localização inicial do Santander.
Figura 33. Tela com Widgets no Workspace
Figura 34. Configurações de um Widget
Figura 35. Widget Configurado
Uma das principais funcionalidades oferecidas pelo Wirecloud, é o processo de wiring,
onde o usuário final pode definir o fluxos de mensagens entre os componentes do mashup e
como eles se interligam, de forma visual, através da interação com a interface. A tela da Figura
36 mostra a área de wiring do exemplo. O usuário pode buscar os componentes disponíveis
clicando no ícone mais a esquerda do wiring.
Figura 36. Área de Wiring
Para adicionar o componente à área de wiring, basta clicar no ícone logo abaixo da
imagem que representa o componente (Figura 36), para indicar que uma nova versão deste
componente está em uso, e arrastá-lo para a área. Após inserir cada componente, o usuário
podeligar campos de saída e entrada de forma a definir o fluxo de mensagens entre os widgets
e o comportamento da aplicação como um todo. As Figuras 37 e 38 mostram o wiring feito para
o exemplo, onde há três operadores, NGSI Source, que recupera entidade do Orion Context
Broker, NGSI Entity To PoI, que converte estas entidades em pontos de interesse, que devem
ser mostrados no widget do mapa e um operador que gera dados históricos que podem ser
visualizados no widget do gráfico linear.
Figura 37. Exemplo de Wiring entre Widgets e Operadores
Figura 38. Workspace após Wiring
3.5.4. Próximas atividades
-Descrever API Javascript para Mashup de aplicações, Widget API e NGSI API
-Desenvolver exemplo integrado ao Orion Context Broker
3.6. Marketplace (WMarket)
3.6.1. Objetivos
Componente de negócios focado em agregar ofertas vindas de diferentes Stores que
permite que compradores finais visualizem as ofertas publicadas por diferentes fornecedores e
selecionem aquelas que trarão maiores benefícios. A principal funcionalidade do Marketplace é
fornecer uma interface uniforme para descoberta de ofertas de serviços e aplicações de acordo
com a demanda dos consumidores. Há diferentes papéis para cada tipo de usuário do
Marketplace.
O fornecedor de serviços coloca ofertas no marketplace ou em alguma store. O
consumidor pode então realizar buscas e comparar as ofertas de acordo com os preços. O
Marketplace utiliza o Repository GE para acessar as descrições do serviços. Um serviço também
pode ser publicado através de uma store e o acesso ao Marketplace é dado aos usuários pelo
Channel Maker. [46]
3.6.2. Descrição
Principais características do Marketplace GE:
● Comparação de ofertas
● Reviews de Stores e ofertas
● Recomendações
● Integração total com a WStore
● Busca semântica baseada em um seguimento do mercado
A Figura 39 mostra a arquitetura de referência para implementação do Marketplace GE.
A ideia geral é que todas as funcionalidades irão funcionar em um enorme banco de dados
(virtual) de entidades relevantes para o business framework, como: pessoas, organizações,
produtos, serviços, ofertas, classificações, etc.
O Marketplace GE é estruturado em cinco componentes: Registry and Directory, que
contém informações das stores cadastradas, participantes e seus papéis (fornecedor, comprador,
vendedor, etc) e se encarrega de registrar, atualizar e deletar informações sobre entidades
relevantes para o marketplace. Offering & Demand, é o componente responsável pela troca de
ofertas de serviços entre as lojas e pelo gerenciamento de ofertas fora o prazo.
O componente Discovery & Matching é responsável pela descoberta de ofertas e pela
realização da correspondência de uma determinada oferta de acordo com a demanda, que pode
ser explicitamente expressada nas ofertas, ou implicitamente contida nos critérios de busca.
Recommendation é o componente que fornece recomendações de serviços de acordo com o
perfil do usuário, contexto, bem como atividades anteriores e as experiências dos participantes
do marketplace. O componenteReview and Rating permite que os usuários deem um retorno
textual ou através de uma classificação baseada na quantidade de estrelas, para os serviços e
stores utilizadas por eles. Comentários de usuários e sua classificação geral sobre as aplicações
e serviços podem ser usados para melhorar a qualidade da recomendação.
Figura 39. Arquitetura do Marketplace GE
O Marketplace pode ser acessado pelos consumidores de serviços e prestadores de
serviços (stores), através de uma interface de usuário HTML (Marketplace Portal), ou através
de uma API de programação, que permite a incorporação da funcionalidade do marketplace em
aplicações e ambientes existentes.
4 Cloud Hosting
As aplicações para o contexto de Cidades Inteligentes (do inglês, Smart Cities) demandam uma
infraestrutura com suporte a um amplo conjunto de tecnologias, tais como, Big Data, internet
das coisas, computação em nuvem, etc. Para atingir esse grande requisito, a plataforma
FIWARE especifica um capítulo denominado Cloud Hosting. O capítulo técnico de Cloud
Hosting abrange os habilitadores genéricos que fornecem capacidades estruturais para a
execução, processamento e monitoramento de aplicações de forma a garantir, principalmente, a
dependabilidade.
4.1 Objetivos
O Capítulo de Cloud Hosting [8] tem por objetivo principal oferecer habilitadores genéricos
para basilar à concepção de uma nuvem moderna que hospede uma infraestrutura a ser utilizada
para desenvolver, implantar e gerenciar aplicativos e serviços relacionados à Internet do Futuro.
Os princípios e premissas norteadores para atingir esse objetivo são:
•
Auto serviço sob demanda: o consumidor pode dispor automaticamente de
capacidades computacionais, tais como tempo de servidor, rede e armazenamento,
conforme necessário sem a necessidade de interação humana manual com cada
provedor de serviço.
•
Amplo acesso à Rede: os recursos estão disponíveis através de rede computacionais
e podem ser acessado através de mecanismos padrões para multiplataformas por
vários dispositivos (por exemplo, celulares, tablets, laptops e estações de trabalho).
•
Conjunto de recursos: os recursos computacionais (armazenamento, processamento,
memória e largura de banda de rede) de um provedor são reunidos para servir vários
consumidores usando um modelo multi-proposital, com diferentes recursos físicos e
virtuais atribuídos dinamicamente e redistribuídos de acordo com a demanda do
consumidor
•
Elasticidade rápida: os recursos podem ser rapidamente provisionados e liberados,
em alguns casos, de forma automática, promovendo a elasticidade sob demanda.
•
Pague pelo uso: o uso dos recursos pode ser monitorado, controlado e reportado,
garantindo a transparência tanto para o provedor quanto para o consumidor
possibilitando o modelo pague pelo que utilizou (do inglês pay-as-you-go).
•
Dependabilidade: para ser confiável, um serviço deve exibir/implementar os
seguintes atributos:
o Disponibilidade: prover o serviço de forma correta com alta prontidão.
o Confiabilidade: o serviço deve ser contínuo, garantir uma alta
disponibilidade.
o Segurança: ausência de consequências catastróficas para o usuário(s) e para
o ambiente.
o Integridade: ausência de alterações inadequadas no sistema.
o Manutenção: capacidade de um sistema de sofrer modificações e reparos.
o Confidencialidade: ausência de divulgação não autorizada de informações.
•
Transparência: fornecer a capacidade de inspecionar um serviço para que a qualidade
entregue e garantida do contrato de serviço possa ser verificada e observada.
4.2 Descrição
O Capítulo Cloud Hosting oferta habilitadores genéricos basilares à concepção de uma
moderna infraestrutura de nuvem que hospede um conjunto de recursos que possam ser usados
para desenvolver, implementar e gerenciar aplicativos e serviços da Internet do Futuro. Nesse
intuito foi definida a arquitetura exibida na figura 40.
Figura 40. Arquitetura do Cloud Hosting
Atualmente, o Cloud Hosting define os habilitadores: Docker, IaaS, ObjectStorage,
SelfServiceInterfaces, Software Deployment and Configuration (SDC), PaaS, Monitoring,
AppManagement, PolicyManager [8]. Esses componentes compõem a arquitetura do capitulo
de Cloud Hosting que é organizada pela interação entre múltiplos componentes (GEs próprios
do capítulo e alguns GEs de outros capítulos). Por exemplo, os componentes em amarelo: IDM
GE, Context Broker GE, etc, indicam os GEs desenvolvidos fora do Capítulo Cloud Hosting,
mas que são utilizados por ele. Os componentes em verde: Compute, Volume, Network, Image,
Orchestration, Monitoring, indicam os serviços nativos advindos da nuvem OpenStack que são
utilizados na nuvem FIWARE sem nenhuma modificação. Por outro lado, os componentes azuis
indicam os GEs que são baseados em serviços correspondentes na nuvem OpenStack com
modificações para melhorias (Object Storage, Application Management), ou não estão baseados
na OpenStack mas visam o alinhamento e/ou contribuição em lançamentos futuros (por
exemplo, Policy) da Openstack. Os GEs: Platform as a Service (PaaS) e Software Deployment
and Configuration (SDC) foram substituídos pelo Application Management and Orchestration
GE.
4.2.1 Docker
A Docker é uma plataforma aberta para desenvolvimento e execução de aplicações
embarcadas. Através dos conceitos de Docker Images e Docker Containers, as aplicações
podem ser disponibilizadas e executadas, respectivamente. A arquitetura do Docker, com a
representação da interação entre Docker Images e Docker Containers, é apresentada na figura
41. O Docker é composto basicamente por três partes, a saber: o Docker Daemon, o Docker
Registry e a parte Client. O Docker Daemon é executado como um serviço do sistema
operacional sobre o qual os Containers são executados. O Docker Registry é o catálogo de
Images interno ao Docker Host. A parte Client permite a interação do usuário desenvolvedor
com o Docker. A interação ocorre via linha de comandos. Os principais comandos do Docker
Client são exibidos na tabela 7.
Figura 41. Arquitetura Conceitual do Docker.
Comando
Descrição
docker build –f dockerfile
Constrói uma Docker Image de acordo com o Docker File.
docker images
Lista as Docker Images registradas internamente.
docker run
Executa um Docker Container a partir de uma Docker Image
previamente registrada.
docker os
Lista os Docker Containeres.
Tabela 7. Principais Comandos do Docker.
A Docker Images (DI) são modelos descritivos do conteúdo/software necessário a execução
da aplicação. Os desenvolvedores criar suas DIs ou podem obtê-las via o catálogo disponível
nohttps://hub.docker.com/. Inclusive, alguns dos próprios GEs da FIWARE como, por exemplo:
WireCloud, Orion, IDM, C-Kan e PEP-PROXY (linkar como documetno). A descrição de uma
DI é realizada através da criação de um arquivo denominado “DockerFile”. O DockerFile segue
uma sintaxe simples muito similar a utilizada em scripts bash do Linux. Por exemplo, para criar
uma DI que representasse um servidor Apache Tomcat3, o DockerFile teria o conteúdo similar
ao apresentado na figura 42.
Figura 42. Trecho do DockerFile para Servidor Apache Tomcat.
O trecho do DockerFile para execução do servidor Apache Tomcat apresentado na figura
42 exibe alguns comandos básicos para construção de um DockerFile. O comando FROM (linha
01) qual DI será a base, ponto de partida, para criação desta nova DI. O ENV (linhas 02, 04, 11
e 12) define variáveis de ambiente utilizáveis pela DI. O comando RUN (linha 06) efetua a
execução de comandos bash do Linux. O comando ADD (linha 11) copia um arquivo para dentro
do diretório de arquivos da DI. O comando EXPOSE (linhas 14 e 15) especificam as portas TCP
que serão abertas pela DI. Por fim, o comando CMD executa um comando bash Linux para
execução em segundo plano, num conceito similar ao de processo.
A execução da DI ocorre através da criação de uma instância do Docker Container. O
Docker Container (DC) é o componente de execução da plataforma Docker. O DC funciona de
forma similar a um diretório, onde todos os arquivos necessários à execução de uma aplicação
3
http://tomcat.apache.org/
são postos. O DC possui estados para identificar seu ponto de execução, tendo os estados
possíveis entre: run, started, stopped, moved, e deleted. Fazendo uma conexão entre a plataforma
Docker e uma plataforma de nuvem IaaS, as DI equivalem-se a imagens das máquinas virtuais
enquanto que o DC, as Instâncias.
4.2.2 IaaS - Openstack
O OpenStack é um sistema de provisão e controle de uma estrutura computacional em
nuvem. Ele permite a gerencia de grandes conjuntos de recursos, tais como: máquinas virtuais,
armazenamento e recursos de rede ao longo de um datacenter. Estes recursos são gerenciados
através de uma interface web que dá aos administradores total capacidade de controle sobre a
provisão de recursos aos respectivos usuários [9]. A história do OpenStack teve início através
do conjunção de uma coleção de projetos de software open-source os quais as empresas ou
serviços provedores de nuvens poderiam usar para configurar e executar sua nuvem [10]. Os
contribuintes iniciais para o OpenStack foram a Rackspace e a NASA. A Rackspace forneceu o
código da plataforma Cloud Files que provia o armazenamento de objetos, enquanto que a
NASA disponibilizou o código da plataforma Nebula para a parte da computação [10].
A plataforma FIWARE atualmente utiliza alguns componentes da versão Kilo do Openstack
como base para seu Generic Enabler de infraestrutura de nuvem. Os componentes utilizados
são: Openstack Nova, Openstack Glance, Openstack Cinder, Openstack Neutron, Openstack
Heat.
4.2.2.1 Openstack Nova
O componente Openstack Nova [11] é um serviço que permite o controle estrutural da
parte relacionada à computação em uma nuvem de infraestrutura, ou seja, permite o controle do
ciclo de vida de máquinas virtuais (VMs) para provisão de processamento distribuído e escalar
na nuvem. Todas as atividades necessárias para suportar o ciclo de vida das VMs (execução,
salvamento, desligamento, etc) dentro da nuvem OpenStack são tratados pelo serviço Nova.
O acesso ao serviço Openstack Nova pode ocorrer de três maneiras: via linha de comandos,
através do componente Openstack Horizon (dashboard web para gerência da nuvem Openstack)
ou pela Nova API. Os clientes da linha de comando e do dashboard são apenas implementações
de acesso à Nova API, tornando esta a forma principal de acesso ao serviço Opentack Nova.
A versão Openstack Kilo suporta a Nova API versão v2.1, sendo que as versões v1.1 e v2.0
podem ser habilitadas pela ativação de extensões [12]. A Nova API é baseada no modelo REST
e, portanto, é uma API de acesso HTTP onde os verbos da requisição são alterados para refletir
a ação desejada sobre o recurso. Por exemplo, para listar as máquinas virtuais faz-se necessário
executar uma requisição HTTP do tipo GET e direcioná-la ao endpoint da Nova API com o path
“/v2.1/{tenant_id}/servers”. O parâmetro “tenant_id” relaciona-se com conjunto de recursos
ligados a um “tenant” que seria uma subdivisão dos recursos de um usuário. Cada requisição a
Nova API deve conter ainda um token de autenticação do usuário que deve estar incluído no
cabeçalho da requisição com o identificador “x-auth-token” e um arquivo que segue no corpo
da requisição no formato JSON com os atributos necessários a requisição. A versão v2.1 oferece
um amplo conjunto de ações que podem ser executadas sobre os “servers” (instâncias de
máquinas virtuais na nuvem).
A grande maioria das ações da Nova API são endereçadas ao path “/v2.1/{tenant_id}
/servers/{server_id}/action”, adicionando-se no corpo da requisição um arquivo no formato
JSON que possua o atributo referente a ação especifica. Por exemplo, para pausarmos uma
máquina virtual é necessário efetuar uma requisição a Nova API nos moldes supracitados e
incluir o atributo “pause” com valor “null” no arquivo corpo da requisição. Subsequentemente,
uma requisição para ativar uma máquina virtual se utiliza do atributo “start” com o valor “null”
ao invés do atributo “pause”, embora nos outros aspectos as requisições sejam iguais. Os
parâmetros “tenant_id” e “server_id” representam o identificador do tenant e do servidor que se
quer acessar, respectivamente.
As ações básicas de criar, deletar ou atualizar as máquinas virtuais são apresentadas na tabela
8, bem como algumas outras ações principais.
Ação
Verbo
HTTP
Descrição
/v2.1/{tenant_id}/servers
GET
Lista os IDs, nomes e links de todas as máquinas
virtuais daquele tenant_id.
/v2.1/{tenant_id}
/servers/detail
GET
Lista todas as máquinas virtuais daquele
tenant_id com detalhes.
/v2.1/{tenant_id}/servers/
GET
Exibe os detalhes de uma única máquina virtual.
/v2.1/{tenant_id}/servers
POST
Cria uma máquina virtual, inicializando pela
primeira vez.
PUT
Atualiza os atributos editáveis sobre uma
máquina virtual. Por exemplo, o atributo name.
{server_id}
{server_id}
{server_id}
DELETE
Deleta a máquina virtual.
{server_id}/diagnostics
GET
Lista alguns dados básicos sobre o uso da
máquina virtual. Por exemplo, uso de CPU e
memória.
{server_id}/ips
GET
Lista os endereços IPs vinculados a máquina
virtual.
{server_id}/metadata
GET
Lista os itens de meta dados associados à
máquina virtual.
{server_id}/os-instanceactions
GET
Lista um breve histórico de ações efetuadas
sobre a máquina virtual.
{server_id}/osvolume_attachments
POST
Vincula um volume à uma máquina virtual. O
volume fornece um armazenamento persistente e
funciona como um disco rígido externo.
{server_id}/osvolume_attachments/
{attachment_id}
DELETE
Desvincula um volume de uma máquina virtual.
{server_id}/osvolume_attachments
GET
Lista os volumes vinculados a uma máquina
virtual.
/v2.1/{tenant_id}/flavors
GET
Lista os “flavors”. Os “Flavors” são a
configurações (numero de vCPU, quantidade de
memória, espaço de disco virtual) disponíveis
para execução de máquinas virtuais.
/v2.1/{tenant_id}/flavors
POST
Cria um “flavor”.
/v2.1/{tenant_id}/flavors/
{flavor_id}
DELETE
/v2.1/{tenant_id}/os-
GET
Lista as pares de chaves disponíveis para o
tenant especificado.
POST
Cria ou importa um par de chaves.
keypairs
Deleta o “flavor”
keypairs
DELETE
Delata o par de chaves.
keypairs/{keypair_name}
/v2.1/{tenant_id}/images
GET
Listas as “Images” (veja seção 3.2.1.2).
/v2.1/{tenant_id}/images/
GET
Lista os detalhes da Images.
{image_id}
/v2.1/{tenant_id}/images/
DELETE
Deleta a Image.
{image_id}
/v2.1/{tenant_id}/os-fixed-
GET
Exibe detalhes de um endereço IP fixo. Os
endereços IP fixos são aqueles vinculados assim
que a máquina virtual é inicializada. Geralmente,
os IPs fixos são de acesso restrito a nuvem.
POST
Reserva ou libera um IP fixo.
GET
Lista os endereços IPs flutuantes. Os endereços
IPs flutuantes são aqueles vinculados para incluir
acesso a uma rede especifica. Geralmente, os IPs
flutuantes são IPs públicos que garantem acesso
fora da nuvem à máquina virtual.
POST
Cria ou aloca um IP flutuante a um projeto.
ips/{fixed_ip}
/v2.1/{tenant_id}/os-fixedips/{fixed_ip}/action
/v2.1/{tenant_id}/osfloating-ips
/v2.1/{tenant_id}/osfloating-ips
DELETE
Deleta ou desaloca um IP flutuante.
floating-ips/{floating_ip_id}
Tabela 8. Principais Ações da Nova API.
4.2.2.2 Openstack Glance
O Openstack Glance [12] é um sistema de pesquisa e de recuperação de Images de
máquinas virtuais. A Image é uma imagem inicial de uma máquina virtual, sendo composta por
um disco virtual que contém um sistema operacional inicializável. A imagem do disco fornece
o modelo para sistemas de arquivos da máquina virtual. As Images são armazenadas pelo serviço
Openstack Glance permitindo a sua utilização na instanciação de novas máquinas virtuais. O
acesso ao Openstack Glance ocorre de forma similar ao Openstack Nova, isto é, através de três
maneiras possíveis: um cliente de linha de comando, o componente Openstack Horizon ou via
Glance API.
A Glance API é a forma de acesso primária ao Openstack Glance. Atualmente, a Glance
API suportada é a versão v1.0. As requisições seguem o mesmo padrão visto para o Openstack
Nova, isto é, são requisições HTTP no modelo REST, direcionadas ao endpoint do serviço
Openstack Glance. As principais ações da Glance API, exibidas na tabela 9, são relacionadas
com a criação, atualização e consultas das Images de uma nuvem Openstack.
Ação
Verbo
HTTP
Descrição
/v1/images
GET
Lista todas as Images públicas.
/v1/images
POST
Lista todas as máquinas virtuais daquele tenant_id
com detalhes.
/v1/images/{image_id}
GET
Exibe os detalhes da Image.
HEAD
PUT
DELETE
Exibe meta dados relacionados a uma Image.
Faz a atualização de uma Image através do upload
de um novo arquivo ou atualiza os respectivos meta
dados.
Deleta uma Image.
Tabela 9. Principais Ações da Glance API.
4.2.2.3 Openstack Cinder
O serviço Openstack Cinder fornece recursos de armazenamento em bloco persistente
na forma de dispositivos de armazenamento que são acessados pela vinculação de Volumes às
máquinas virtuais em execução [11]. Os Volumes são semelhantes a disco rígidos virtuais que
podem facilmente serem anexados ou desacoplados da uma máquina virtual, mantendo o estado
dos dados inalterado entre essas operações. Outro serviço ofertado pelo Openstack Cinder é a
possibilidade de manter cópias de seguranças dos Volumes armazenadas no Openstack Swift
(veja 3.2.3). Quatro serviços compõem o Openstack Cinder, a saber:
I.
Cinder-Volume: Efetua a gerência dos dispositivos de armazenamento virtuais em
detrimento dos dispositivos físicos.
II.
Cinder-Scheduler: Através de agendamento e rotas permite a escolha adequada do
serviço de Volume. Essa escolha depende de configuração do usuário que pode ser uma
rotação simples entre os serviços de volume em execução, ou pode ser mais sofisticada
com o uso do Scheduler Filter. O Scheduler Filter que sejam aplicados filtros
relacionados à Capacidade, Zona de disponibilidade, tipos de volume, etc..
III.
Cinder-Backup: Fornece um meio para fazer cópias de segurança de um bloco
armazenamento para OpenStack Swift.
IV.
Cinder-API:é uma aplicação no padrão WSGI responsável pela autenticação e
encaminhamento das requisições ao serviço de Volume. Atualmente, está em sua versão
v2.0. A tabela 10 apresenta as operações principais da Cinder-API. As requisições são
feitas da mesma forma que ocorrem nas interfaces: Nova API e Glance API.
Ação
Verbo
HTTP
Descrição
/v2/{tenant_id}/volumes
POST
Cria um Volume
GET
Lista os Volumes.
/v2/{tenant_id}/volumes/{volume_id}
GET
Exibe os detalhes do Volume.
/ /v2/{tenant_id}/volumes/{volume_id}
PUT
Atualiza um Volume.
DELETE
Deleta um Volume.
POST
Salva os meta dados do Volume.
GET
Exibe os meta dados do Volume.
PUT
Atualiza os
Volume.
/metadata
/metadata
/metadata
meta dados do
Tabela 10. Principais Ações da Cinder API.
4.2.2.4 Openstack Neutron
O Openstack Neutron é o serviço de rede da nuvem Openstack [11]. Ele permite definir
redes, conectividade entre rede e endereçamento na nuvem, incluindo a gerencia de várias
tecnologias diferentes de rede. Através do Opentasck Neutron o usuário da nuvem pode criar
redes lógicas, roteadores, portas facilitando a administração e segurança de suas máquinas
virtuais. Nesse intuito, esse serviço oferece a Networking API para configurar e gerenciar uma
variedade de serviços de rede que vão desde encaminhamento L3, NAT, balanceamento de
carga, firewalls de borda, IPsec e Virtual Private Network (VPN). As principais ações da
Networking API são exibidas na tabela 11.
Ação
Verbo
HTTP
Descrição
POST
Cria um Volume
GET
Lista os Volumes.
GET
Exibe os detalhes do Volume.
/ /v2/{tenant_id}/volumes/{volume_id}
PUT
Atualiza um Volume.
DELETE
POST
Salva os meta dados do Volume.
GET
Exibe os meta dados do Volume.
Deleta um Volume.
/metadata
/metadata
/metadata
PUT
Atualiza os
Volume.
meta dados do
Tabela 11. Principais Ações da Networking API.
4.2.2.3 Openstack Heat
O Openstack Heat é o serviço responsável pela orquestração de recursos na nuvem
Openstack. Ele fornece a capacidade de orquestrar o provisionamento e o gerenciamento
contínuo das coleções de recursos básicos (VMs, redes, etc.), incluindo o auto escalonamento e
interdependia entre eles [8]. A orquestração é um mecanismo que possibilita executar uma
composição de aplicações em uma nuvem através de modelos no formato de arquivos textos. O
formato nativo definido pela Openstack Heat é o Template Orchestration Heat (HOT). Os
modelos do HOT são descritos em YAML. YAML4 é uma notação concisa que segue as
convenções estruturais (dois pontos, retornos, recuo) similares às utilizadas em Python5 ou
Ruby6. Por exemplo, a figura 43 exibe um modelo HOT para instancia uma máquina virtual
simples. Nesse modelo são definidas a versão do modelo (linha 01), uma breve descrição (linha
02) e os recursos a serem disponibilizados, no caso, uma instância de máquina virtual (linhas
04-10).
Figura 43. Modelo HOT para instanciar uma Máquina Virtual.
O principal acesso ao Opentask Heat é via Orchestration API que atualmente está em sua
versão v1 [12]. O recurso registrado no Openstack Heat é denominado “stack”. Podem ser
gerados stacks dos recursos: máquinas virtuais, endereços IPs flutuantes, volumes, grupos de
4
5
6
https://pt.wikipedia.org/wiki/YAML
https://www.python.org/
https://www.ruby-lang.org/pt/
segurança e usuários. Também pode ser gerado um stack a partir de um recurso em execução.
As principais ações da Orchestration APIsão exibidas na tabela 12.
Ação
Verbo
Descrição
HTTP
/v1/{tenant_id}/stacks
POST
Cria um Stack.
/v1/{tenant_id}/stacks
GET
Lista os dados do Stack.
/v1/{tenant_id}/stacks/{stack_name}/
GET
Exibe os detalhes do Stack.
PUT
Atualiza um Stack.
{stack_id}
{stack_id}
DELETE
Deleta um Stack.
{stack_id}
{stack_id}/snapshots
POST
Cria uma imagem temporal (Snap
Shot) do Stack. Similar ao
conceito de cópia de segurança.
{stack_id}/snapshots
GET
Lista os snapshots do Stack.
DELETE
Deleta o snapshot.
{stack_id}/snapshots/{snapshot_id}
{stack_id}/snapshots/{snapshot_id}
POST
Restaura o Stack ao estado salvo
no snapshot.
/restore
Tabela 12. Principais Ações da Orchestration API.
4.2.3 Openstack Swift
O ObjectStorage GE é baseado no OpenStack Swift[8] e visa proporcionar forma
escalável, flexível e eficiente para armazenar e recuperar objetos do tipo "blob" e seus meta
dados associados, bem como, possibilitar a execução algumas operações sobre eles na forma de
storlets. O Openstack Swift [11]foidesenhado para o armazenamento de dados de maneira
escalável e redundante, através de clusters de servidores com armazenamento padrão da ordem
de petabytes. Esse serviço de armazenamento é, também, um sistema de guarda de grande
quantidade de dados estáticos, permitindo a rápida recuperação e atualização destes por um
longo prazo. Nesse propósito, o Swift usa uma arquitetura distribuída sem ponto central de
controle, proporcionando maior escalabilidade, redundância e permanência. Os objetos
armazenados são gravados em vários dispositivos de hardware, sendo que o Openstack Swift
garante a replicação e integridade dos dados em todo o cluster. Os clusters de armazenamento
permitem um escalonamento horizontal através da adição de novos nós. Quando um nó
apresenta falha, o Swift busca restaurar o seu conteúdo de outros nós ativos. Todo esse
gerenciamento é feito através de camadas de software, permitindo o uso de várias tecnologias
de disco rígido, bem como servidores de baixo custo. Fato que torna o Swift ideal para o
armazenamento de baixo custo (scale-out).
O Openstack Swift oferece ainda a Object Storage API que pode ser integrada diretamente
nas aplicações ou usada para backup, arquivamento e retenção de dados. Os elementos
principais dessa API são: os Accounts, os Containers e os Objects. Os Accounts representam
uma conta vinculada a um usuário. O usuário pode possuir mais de uma Account. Cada Account
possui um conjunto de Containers. Os Containers são similares a diretórios, embora não possam
conter outros Containers. Eles são os locais lógicos onde os Objects são armazenados. Os
Objects representam o conteúdo a ser armazenado. As principais operações da Object Storage
API, atualmente na versão v1, são apresentadas na tabela 13. Novamente, as requisições seguem
o mesmo padrão apresentados no componente Openstack explicado anteriormente.
Ação
Verbo
HTTP
Descrição
/v1/{account}
GET
Lista os detalhes da Account e os Containers que a
compõem.
/v1/{account}
POST
Cria, Atualiza ou Deleta meta dados sobre a Account. A
distinção de cada ação se dá pela presença de cabeçalhos
específicos na requisição. Por exemplo, para deletar
utiliza-se o “X-Remove-Account-Meta-Subject”.
/v1/{account}/
GET
Exibe detalhes sobre o Container e lista os objetos
armazenados ordenados pelo atributo “name”.
PUT
Cria um Container.
{container}
/v1/{account}/
{container}
/v1/{account}/
DELETE
Deleta um Container.
{container}
/v1/{account}/
GET
Efetua o download do Object.
PUT
Cria ou atualiza o Object.
{container}/
{object}
/v1/{account}/
{container}/
{object}
/v1/{account}/
COPY
Copia o Object.
DELETE
Deleta o Object.
{container}/
{object}
/v1/{account}/
{container}/
{object}
/v1/{account}/
HEAD
Exibe os meta dados vinculados ao Object.
POST
Cria ou atualiza objetos de meta dados relacionados ao
Object.
{container}/
{object}
/v1/{account}/
{container}/
{object}
Tabela 13. Principais Ações da Object Store API.
4.2.4 SelfServiceInterfaces
O Generic Enabler SelfServiceInterfaces (SSI) [27] busca facilitar o uso e a
administração da infraestrutura de nuvem da FIWARE, tendo como objetivo principal:
proporcionar uma interface de usuário para melhor interação do usuário com seus serviços
implantados na nuvem FIWARE, bem como, bibliotecas para suporte facilitado aos
administradores. Nesse proposito, define componentes que permitam realizar as ações de criar,
deletar e editar os vários elementos de contexto da nuvem FIWARE (Image, Flavors, Volumes,
Containers, Objects, etc). A arquitetura do GE SSI (Figura 44) define três elementos principais:
User Portal, Toolkit e Cloud Library (elementos em cinza). Os outros elementos (em branco)
apresentados são os outros GEs com os quais o SSI interage diretamente. Por exemplo, SSI age
diretamente sobre o GE de IaaS mas também utiliza o GE de identificação (IDM) para gerencia
de acesso.
Figura 44. Arquitetura do o GE SelfServiceInterface
O User Portal [28] é especificado como uma implementação de uma interface gráfica do
usuário no modelo Web, seguindo o exemplo dos portais administrativos dos provedores nuvens
de infraestrutura mais utilizados atualmente, tais como, Amazon EC27, Eucalyptus8, Nuvem
Sigma9, Rackspace10, etc. O propósito do User Portal é permitir aos usuários da nuvem
executarem facilmente as operações sobre a infraestrutura. Isto inclui executar ações tais como:
criar usuário, gerenciar projetos, iniciar instâncias sobre uma base de imagens, criar imagens no
repositório de imagens, recuperar flavors, etc. Além disso, o User Portal facilitará o
gerenciamento de data centers virtuais (VDCs), oferecendo estatísticas das máquinas físicas e
7
https://aws.amazon.com/pt/ec2/
http://www8.hp.com/us/en/cloud/helion-eucalyptus-overview.html
9
https://www.cloudsigma.com/
10
https://www.rackspace.com/pt-br/cloud
8
virtuais. O Cloud Library [27] busca fornecer bibliotecas em Javascript que implementem a
comunicação e interação do User Portal e o Toolkit com outros GEs. O elemento Toolkit define
uma interface de linha de comando para acesso direto à infraestrutura da nuvem e destinada
usuários experientes. Este kit de ferramentas usa a biblioteca da nuvem, bem como, suas
diferentes APIs. A implementação de todos os elementos do SSI é concretizada via o GE Cloud
Portal.
4.2.4.1 Cloud Portal
O Cloud Portal (CP) é uma aplicação web implementada em JavaScript11 e se baseia
no componente Horizon do OpenStack12. O CP foi desenhado seguindo os preceitos do padrão
Model-View-Controller (MVC) e tem foco na melhoria da experiência do usuário com o uso
extensivo de AJAX. O uso do AJAX permite a renderização dinâmica das páginas. Aliado a
isso, o uso de CSS personalizável com um design responsivo torna as múltiplas telas adaptáveis
a vários dispositivos (computadores, smart phones, tablets, etc). Outro ponto de destaque é o
suporte multilíngue atingido por técnicas de internacionalização.
As principais funcionalidades ofertadas pelo CP são providas pela biblioteca
jstack[https://github.com/ging/jstack]. A jsstack é uma implementação em JavaScript das APIs
disponibilizadas pela nuvem OpentStack. A utilização do CP é bem intuitiva para qualquer
usuário habituado a sistemas web. Por exemplo, as ações necessárias para executar uma máquina
virtual pelo CP, a saber:
1 – Acessar o Cloud Portal,
2 – Criar uma KeyPair,
3 – selecionar uma Image e
4 – Executar a máquina virtual são facilmente realizáveis pelas telas disponibilizadas.
Um tutorial de como subir uma máquina virtual via CP é exibido na seção 4.3.
4.2.5 AppManagement
O GE AppManagment [29] define um serviço que permita a implantação de habilitadores
genéricos sobre a nuvem FIWARE de forma direta. Isto é, fornecer o suporte básico para a
gestão de configuração de hardware (servidores virtuais, redes virtuais, etc.) e gestão de
11
12
https://pt.wikipedia.org/wiki/JavaScript
O OpenStack Horizon é o dashboard web para gerencia da nuvem Openstack.
instalação do software. Passo que incluem tanto a fase de implantação de uma aplicação, bem
como, a gestão do ciclo de vida dela.
O AppManagment é baseado no componente OpenStack Murano. O OpenStack Murano[30]
é um catálogo de aplicações descritas utilizando-se a MuranoPL. A MuranoPL [30] é a
linguagem de programação do OpenStack Murano que se baseia na linguagem YAML.
Basicamente, a MuranoPL define variáveis e passo para instalação de uma aplicação. Através
de arquivos templates escritos em YAML é possível registrar uma aplicação passível de
instanciação e configuração na nuvem OpenStack. Por isso, o AppManagment introduz um
catálogo de aplicações, permitindo aos desenvolvedores e administradores da nuvem
rapidamente buscar, configurar e implantar suas aplicações de modo visual.
Os principais recursos fornecidos ao usuário nuvem através AppManagment são: o catálogo
de aplicações, a implantação e configuração de aplicações complexas através de modelos
blueprints, suporte a linguagens de configuração (como Puppet13 ou Chef14) para a instalação
de softwares e a gestão do ciclo de vida da aplicação implantada. A definição dos modelos
blueprints é muito importante para implantação de aplicações multicamada, isto é, aplicações
que utilizam uma camada para processamento web, outra camada para gerenciamento de dados
com utilização de sistemas gerenciadores de banco de dados.
A arquitetura do AppManagment (figura 45) define três elementos básicos: a API, o Engine
e o Application Agentque compõem o Aplication Managment Service. A API representa a
interface de programação utilizada pelo usuário e pelo componente dashboard (no caso do
FIWARE, o Cloud Portal) para definição dos modelos de implantação das aplicações. O Engine
promove o processamento das requisições feitas a API, interagindo com os outros elementos da
infraestrutura, tais como, o serviço de orquestração (OpenStack Heat) e o Application Agent. O
Application Agenté um agente para processamento das instruções de software dentro da máquina
virtual, geralmente, um agente do OpenStack Murano.
13
14
https://docs.puppet.com/guides/introduction.html
https://www.chef.io/chef/
Figura 45. Arquitetura do AppManagment.
4.2.6 PolicyManager
O Policy Manager (PM) GE [31] busca fornecer escalabilidade na gestão dos recursos
da nuvem com base na definição de regras e políticas delimitadoras. Para isso, o PM oferece a
gestão básica dos recursos de nuvem pela definição de fatos, ações e regras relacionadas ao
monitoramento dos recursos da infraestrutura e dos serviços. Tendo como base a linguagem
PyCLIPS15, o PM permite definir regras que auxiliam na construção de um sistema inteligente
e autogerenciável. A utilização da PyCLIPS permite melhorar o monitoramento e o atuamento
sobre o OpenStack, visto que a mesma é desenvolvida em Python o que favorece a interação
com os outros componentes da OpenStack. Dessa forma, as principais funcionalidades que o
PM fornece são:
I.
Gestão de Regras de Escalabilidade: É possível definir regras delimitadoras
relacionadas à escalabilidade na garantia da boa execução da funcionalidade principal
dos componentes e ou aplicações. Por exemplo, é possível iniciar uma nova instancia de
uma máquina virtual ou aplicação de acordo com parâmetros de uso de CPU, memória
e ou espaço em disco.
II.
Gestão de diferentes fatos relacionados a máquinas virtuais a fim de lançar ações
cujas condições definidas nas regras delimitadoras sejam atendidas.
Nesse proposito, foi definida a arquitetura do Policy Managment que é exibida na figura 46.
O componente API Agent disponibiliza uma interface a Policy Manager Interface. Através
dessa interface o usuário pode especificar regras e ações na composição de um sistema de
conhecimento, seguindo o formato da linguagem PyClips. A API Agent registra no Orion
15
http://pyclips.sourceforge.net/web/
Context Broker GE os produtores de informação sobre o monitoramento dos recursos da nuvem.
Os dados e métricas colhidos são enviados ao Fact-Gen via operação de notificação do Orion
Context Broker. Esses dados são encaminhados ao Rules Enginee são utilizados na dedução de
novos fatos com base nas regras ou na inferência de novas ações a serem tomadas.
Figura 46. Arquitetura do Policy Managment.
4.3 Exemplo de uso do Cloud Portal
A instanciação de uma máquina virtual é uma tarefa corriqueira na implantação de uma
aplicação da nuvem FIWARE. A rápida provisão de recursos com GEs, servidores web,
servidores de mensagens é possibilitada pela fácil configuração de máquinas virtuais pelo Cloud
Portal (veja seção 3.2.4). As ações necessárias para instanciação de uma máquina virtual são
relativamente simples:
1. Acessar o Cloud Portal: O acesso ao Cloud Portal se dá via o endereço
https://cloud.lab.fiware.org/. São exigidos o e-mail e a senha do usuário (Figura 47)
previamente cadastro para liberar o acesso.
2. Criar uma KeyPair: A KeyPair é um de par de chaves de segurança para acesso a
máquina virtual que será criada. A criação de uma KeyPair (Figura 48) exige apenas um
nome único para identificação da mesma. O usuário deve efetuar ao download do
arquivo gerado para sua guarda pessoal. Esse passo é opcional no caso de já existir uma
KeyPair cadastrada.
3. Selecionar uma Image: Através das cópias inicializáveis de sistemas operacionais ou
GEs, o usuário seleciona a configuração de software inicial de sua máquina virtual. O
menu do Cloud Portal e um exemplo do conjuntos de Images disponíveis na nuvem do
FIWARE Lab são exibidos na figura 49.
4. Executar uma máquina virtual: A execução de uma máquina virtual segue o modelo de
telas passo a passo onde os dados necessários são inseridos e clica-se no botão de
próximo (no caso “next”). A figura 50 exibe o primeiro passo (1.Details) para execução
de uma máquina virtual onde o usuário deve informar o nome da instância, selecionar o
Flavor (configuração de hardware) e a quantidade de instância que ele quer subir. O
segundo passo (2. Access & Security) permite a seleção da KeyPair que será vinculada
a máquina virtual e o(s) grupo(s) de segurança para configurar as portas liberadas e o
tipo de acesso a elas. O terceiro passo (Networking) define a rede a que a máquina será
ligada. O quarto passo (Post-Greation) permite que o usuário defina algum script para
execução assim que a máquina for instanciada. Por fim, o quinto passo exibe um resumo
das configurações escolhidas e finaliza o processo, criando e iniciando a execução da
máquina virtual.
Figura 47. Cloud Portal – página de Acesso.
Figura 48. Criação de KeyPair no Cloud Portal
Figura 49. Cloud Portal Menu – Listagem de Images.
Figura 50. Executando uma Máquina Virtual no Cloud Portal.
4.4 Considerações Relevantes
A utilização dos GEs do capitulo de Cloud Hosting exige um grande esforço e planejamento
para implantação da nuvem OpenStack de forma que se possa garantir os requisitos necessários
a execução de uma instância FIWARE. Em um primeiro momento, esse esforço tentou ser
diminuído pela utilização da OPS-Deploy(veja seção 9.2.1), entretanto, mesmo com essa
abordagem, a disponibilidade rápida dos GEs não foi prontamente alcançada. Dessa forma, os
WPs de Middleware e de Infraestrutura definiram que utilizaríamos o Docker GE para executar
alguns dos GEs da FIWARE, permitindo aos participantes do projeto Smart Metropolis o acesso
as tecnologias da FIWARE, mesmo que à nível de experimentação e desenvolvimento.
Para atingirmos esse objetivo, máquinas virtuais foram configuradas com o Docker e
alguns dos GEs da FIWARE executados como containers do Docker. Os GEs atualmente
instalados e configurados como containers Docker são listados na tabela 14.
Capitulo
GE
Host
Port
Data/Context
Orion
10.7.30.153
1026
Data/Context
CEP
10.7.31.31
8888
Data/Context
Aeon
10.7.31.32
8080
Data/Context
CKan
10.7.31.32
80
Data/Context
Spargo BI
10.7.31.28
8888
Data/Context
Cosmos
10.7.30.153
8081/5050
Data/Context
WireCloud
10.7.30.153
80
Data/Context
Kurento
10.7.30.153
8888
Iot
Iot-Discoverry
10.7.31.28
8080
Iot
Broker
10.7.31.28
80
Security
idm
10.7.31.29
8000
Security
idm-keystone
10.7.31.29
5000
Security
authzforce
10.7.31.29
8080
Security
pepwilma
10.7.31.29
80
Tabela 14. GEs executando como Docker Containers.
As experiências advindas da implantação desse modelo de infraestrutura revelaram que, de
fato, a utilização do Docker e consequente execução do GEs como Docker Containers é uma
opção para rápida provisão dos GEs da FIWARE. Os pontos negativos desse modelo são a
dificuldade da integração e customização da instalação dos GEs. Isto é, a utilização desse
modelo em um cenário de Produção deve ser cuidadosamente planejada para que se diminua a
necessidade de reconstrução de Docker Images e reexecução dos Docker Containers. Isto se
deve ao fato de que qualquer customização da configuração do GE onde o serviço necessite ser
reinicializado, provavelmente, implicará na parada de execução do Docker Container. Outro
ponto relevante é o acesso aos arquivos de logs dos GEs, atividade extremamente necessária no
cenário de desenvolvimento. Por padrão, o Docker disponibiliza um fluxo de dados de log
através do comando docker logs, entretanto esse fluxo é originado pela leitura de apenas um
arquivo fixo que deve ser configurado na Docker Image. Isto é, qualquer acesso à múltiplos
arquivos de logs se dará de forma manual. A maioria das Docker Images dos GEs
disponibilizadas no Docker Hub foi instalada corretamente. Apenas a Docker Image do IotDiscovery não executou prontamente. Para o Iot-Discovery foi executada uma Docker Image
do Servidor Tomcat aonde a aplicação do Iot-Discovery foi implantada. Como trabalhos futuros
buscaremos melhoras a integração entre os GEs em execução, assim como, pesquisar um
modelo mais gerenciável do ponto de vista de manutenção e modificação das configurações dos
GEs.
5 Data/Context Management
Esse capitulo apresentará habilitadores genéricos da plataforma FIWARE que facilitam o
desenvolvimento de aplicações inovadores que requerem gerenciamento, processamento e
exploração de informação contextual, bem como, fluxos de dados em tempo real e em grande
escala.
5.1. Cloud Messaging (AEON) GE
5.1.1. Objetivos
O Cloud Messaging, também conhecido como AEON, é um GE disponível no Data/Context
Management da plataforma FIWARE, com a finalidade de ajudar na criação de aplicações com
canais de comunicação em tempo real, facilitando a gestão e comunicação ilimitadas entre
entidades. Uma entidade pode ser qualquer coisa que possa participar comunicação de
informações.
Os benefícios da utilização do Cloud Messaging são:
● Comunicar aplicações e serviços através de uma rede em tempo real em escala global;
● Facilidade de uso e de integração no desenvolvimento de aplicações, fornece um SDK
para conectar seus serviços e dispositivos através de uma rede em tempo real;
● Alto desempenho para trocar grande quantidade de mensagens e dados entre processos
e dispositivos e entre dispositivos; e
● Capacidade de lidar com vários tipos de mensagens, sendo possível definir prioridades
para cada mensagem de modo confiável mesmo com grandes volumes de dados.
5.1.2. Descrição
AEON (http://aeon-platform.readthedocs.io/en/latest/) é um serviço de nuvem para criar
aplicações com canais de comunicação em tempo real. A sua arquitetura é baseada nas
necessidades de comunicação enfrentadas atualmente, com bilhões de dispositivos
interconectados e tempos curtos de resposta. Assim, as soluções tecnológicas utilizadas precisão
atender estas exigências: desempenho, resposta e escalabilidade. O AEON é capaz de processar
milhões de solicitação por segundo, e garantir comunicações com apenas alguns milissegundos
de atraso.
É utilizado o padrão de arquitetura Pub/Sub responsável pela troca assíncrona de mensagem,
onde os remetentes das mensagens (editores) enviam mensagens, através de canais, para os
receptores (assinantes) que manifestaram interesse em recebê-las. Como a comunicação não é
realizada diretamente para uma entidade, é possível adicionar facilmente novos editores e
assinantes. Nesse caso, o AEON é responsável por gerenciar os canais de comunicação entre as
entidades.
Figura 51. Ilustração da troca de mensagens utilizando AEON
Na figura 51 exemplifica o processo de comunicação de um barco (editor/Pub) com um
notebook (assinante/Sub) que está inscrito no canal onde o barco publica as suas mensagens.
Com o enfileiramento de mensagens em nuvem, o assinante de um serviço não precisa entender
o protocolo utilizado pelo prestador do serviço (editor), ou vice-versa, mas pode se concentrar
em solicitar uma funcionalidade necessária. Dessa forma, o AEON oferece um serviço de nuvem
PaaS (plataforma como serviço) para troca de mensagem baseada em fila que permite a
comunicação entre várias entidades que desejam trocar mensagens de forma confiável utilizando
protocolos neutros.
O AEON além de facilitar a comunicação entre as entidades, também da suporte em algumas
operações:
● Gestão das entidades:
○ Criar, remover, atualizar e excluir entidades
○ Criar, remover, atualizar e excluir canais associados a uma entidade
● Publicação / Assinatura:
○ Publicar informações através de um canal.
○ Inscrever em um canal. Pausar, continuar e parar a inscrição para obter um
melhor controle sobre suas operações.
4.1.3. Exemplo de uso
A seguir será apresentado o exemplo de uso do AEON (https://github.com/atos-ari-aeon/fiwarecloud-messaging-sdk/tree/master/SDK/java/src/example)
em
Java,
onde
será
criado
comunicação em tempo real entre entidades utilizando o serviço de nuvem AEON. Nosso
cenário é bastante simples. Temos somente duas entidades, uma que publica as informações e
outra que recebe as informações pulicadas, e um canal por onde as informações trafegam.
Criação das entidades e canais
O primeiro passo é criar uma nova entidade com a ajuda da interface gráfica (disponível em
http://{server}:{port}, no nosso caso http://10.7.31.32:8080). Para isso é necessário ter cadastro
e estar logado no AEON.
Fazendo uso da interface, o usuário desenvolvedor poderá cadastrar, na pagina principal (home),
novas entidades ao clicar no batão “New Entity. Após clicar nesse botão, é necessário preencher
algumas informações e clicar no botão “Save” segundo a imagem ilustrada na Figura 52.
Figura 52. Dados necessários para cadastro de entidades
Com o cadastro de uma nova entidade efetuado, é preciso criar um novo canal, já que as
entidades são criadas sem nenhum canal, para isso, basta clicar no botão “New Channel” e
preencher as informações do novo canal seguindo as informações apresentadas na Figura 53.
Figura 53. Dados necessários para cadastro de um canal
Depois de cadastrar esse novo canal, será possível selecioná-lo na entidade que o mesmo foi
cadastrado. Ao fazer isso, aparecerá os endereços (url) utilizados para publicar e receber dados
desse canal. A imagem da Figura 54 mostra onde são encontrados os endereços descritos
anteriormente:
Figura 54. Endereços gerados para Publication e Subscription
Criação da aplicação
Com esses endereços é possível executar um projeto exemplo em Java, disponível em:
https://github.com/atos-ari-aeon/fiware-cloud-messagingsdk/tree/master/SDK/java/src/example , que utiliza a SDK do AEON para criar aplicações que
trocam mensagem.
Esse projeto possuiu três classes, a primeira a classe (Config.java) possui as configuração onde
conter os endereços gerados anteriormente, segundo a imagem da Figura 55.
Figura 55. Configuração dos canais na aplicação
A classe SendNumbers.java é responsável por publicar no canal números, de zero a quinhentos,
no formato Json. O código é apresentado na Figura 56.
Figura 56. Código fonte da classe SendNumbers.java
A classe ReceiveNumbers.java é responsável por receber e imprimir no terminal as informações
que foram publicadas no canal pelo objeto da classe SendNumbers.java. Para mostrar que a
comunicação é feita de forma assíncrona, o subscriber sofre interrupção de tempos em tempos,
sem sofrer perda de mensagens, conforme ilustra a Figura 57.
Figura 57. Saída do terminal da classe ReceiveNumbers.java
5.2. Complex Event Processing (CEP) GE
5.2.1. Objetivos
O CEP (do inglês, Complex Event Processing) é um GE disponível no Data/Context
Management da plataforma FIWARE, e tem como objetivo dar suporte ao desenvolvimento,
implantação e manutenção de aplicações que envolvam o processamento de eventos
(acontecimentos de interesse em um sistema ou domínio) complexos, assim como proporcionar
meios para definir e manter a lógica de processamento desses eventos de forma flexível e
consistente. O CEP trabalha analisando, em tempo real, os dados dos diversos eventos das
aplicações, e, com isso, gerando uma visão imediata e permitindo tomada de decisões mais
rápidas com base nas novas condições. Basicamente, o CEP, projetado para atender tanto
requisitos funcionais como não funcionais, realiza o processamento de vários eventos a partir
de uma nuvem de eventos, objetivando a identificação dos eventos mais significativos dentro
desta nuvem, de maneira que não se tenha um alto custo no desempenho do aplicação.
4.2.2. Descrição
As funções que realizam o processamento dos eventos, no CEP, são implementadas com base
na forma e execução das EPNs (do inglês, Event Processing Networks), estas são compostas de
nós de processamento EPAs (do inglês, Event Processing Agents), que por sua vez são
compostos por agente de processamento. Através de uma rede EPN, pode-se descrever o fluxo
de eventos, originado nos produtores (fonte) de eventos, passando através de vários agentes de
processamento e ao fim atingindo os consumidores de eventos, que são o ponto de destino de
eventos. A figura 58 ilustra esse processo.
Figura 58. Ilustração de uma rede EPN.
Podemos observar que um único agente de processamento pode receber um ou vários eventos
de ou mais produtores. Percebemos também que o resultado (saída) do processamento de um
agente pode ser enviado diretamente ao consumidor ou pode ser processado por outros agentes
até que seja direcionado aos consumidores. Cada rede EPN poderá ter uma configuração
diferente, permitindo um fluxo de eventos diferente e adequado a aplicação. O processamento
feito pelos agentes é composto de várias funções e, muitas vezes a mesma função é aplicada a
diferentes eventos para fins diferentes em diferentes fases do processamento. Esta abordagem
permite, em tempo real, uma repartição flexível dos agentes nas EPAs, concedendo melhores
fatores de escalabilidade, desempenho, otimização e distribuir o poder de processamento.
Entidades de aplicação ou alguns outros GEs do FIWARE ligados ao CEP GE podem
desempenhar apenas o papel de produtor de eventos (e.g., sensores de comunicação), apenas o
papel de consumidor (e.g., Dashboard, processos de tratamento) ou ambos os papéis (e.g.,
Context Broker GE).
O comportamento de um agente de processamento de eventos é especificado usando uma
linguagem orientada a regra, o PCA (do inglês, Pattern-Condition-Action), que é composta de
três partes.
● A detecção de padrões que são associados ao contexto de processamento de eventos;
● Definição de condições (testes lógicos) formulado com base nos eventos; e
● Definição de ações a serem realizadas quando todas as condições estabelecidas forem
satisfeitas.
Os desenvolvedores da aplicação podem programar padrões a partir de eventos selecionados
dentro de um contexto de processamento (e.g., janela de tempo, segmentação) e, apenas se o
padrão satisfazer às condições da regra, há a detecção e a ação correspondente será executada.
Alguns exemplos de padrões utilizados:
● Sequence: os eventos precisam ocorrer em uma ordem específica para o padrão ser
correspondido;
● Aggregate: um conjunto de eventos de entrada é usado para calcular funções de
agregação e a partir destas funções identifica-se o padrão. Por exemplo, em um
determinado período de tempo, calcula-se a porcentagem de falha na leitura de diversos
sensores. É emitido alerta caso essa porcentagem seja maior do que 10%;
● Absent: nenhum evento atrelado a alguma condição chegou dentro da janela de tempo
para o padrão a ser correspondido; e
● All: todos os eventos especificados devem chegar para o padrão ser correspondido,
independentemente da ordem.
CEP fornece três interfaces principais: a primeira para receber eventos brutos de produtores de
eventos, a segunda para enviar eventos de saída para os consumidores de eventos e a terceira
para administrar o estado do CEP e o seu repositório de definições. Todas as operações a seguir
devem ser acessadas por meio do protocolo HTTP, através dos verbos GET, POST, PUT e
DELETE. Para as duas primeiras interfaces, o CEP GE oferece suporte às operações no formato
JSON, XML/NGSI ou delimitado por tag. As tabelas a seguir descrevem os modelos de uso
dessas APIs.
● API para receber eventos
Verbo HTTP
Exemplo URI
Descrição
POST
/{instance_name}/rest/events
Receber eventos externos
na instância especificada
Tabela 15 - Operações da API para receber eventos
Exemplo no formato JSON:
POST http://{server}:{port}/ProtonOnWebServer/rest/events
Content-Type: application/json
{"Name":"TrafficReport", "volume":"1000"}
● API para enviar eventos
Verbo HTTP
Exemplo URI
Descrição
POST
/application-
Enviar evento para um
name/consumer
consumidor
Tabela 16 - Operações da API para enviar eventos
Exemplo no formato JSON:
POST http://{server}:{port}/application-name/consumer
Content-type: application/json
{"Cost":"0.0","Certainty":"0.0","Name":"TrafficReport","EventSource":"","Duration":"0.0
","Annotation":"","volume":"1000","EventId":"e206b5e8-9f3a-4711-9f46d0e9431fe215","DetectionTime":"1350311378034"}
● API para gerenciamento do repositório de definições
Verbo
Exemplo URI
Descrição
/{CEP_Admin}/resources/definitions
Recuperar todas as
HTTP
GET
definições existentes
no repositório
POST
/{CEP_Admin}/resources/definitions
Adicionar uma nova
definição
GET
/{CEP_Admin}/resources/definitions/{de
Recuperar a definição
finition_name}
completa no formato
JSON
PUT
Substituir o conteúdo
finition_name
de uma definição
existente por novos
conteúdos
DELETE
Remover uma
finition_name}
definição do
repositório
Tabela 17 - Operações da API para gerenciar as definições
A seguir será apresentado o exemplo de uso do CEP, onde faremos um novo projeto (definição),
carregaremos no servidor CEP e simularemos o envio de alguns eventos para produzir uma saída
num arquivo txt. Nosso cenário é bastante simples. Temos alguns sensores de temperatura que
iremos monitorar e enviar alertas quando esta temperatura ultrapassar um limite inferior e
superior. Todas as requisições HTTP desde exemplo foram criadas utilizando curl, conforme
encontrado no fiware-tourguide. Além disso, utilizamos também apenas o formato JSON.
Criação da definição do projeto
O primeiro passo é criar um novo projeto com a ajuda da interface gráfica AuthoringTool
(disponível
em
http://{server}:{port}/AuthoringTool,
no
nosso
caso
http://10.7.31.32:8888/AuthoringTool/) ou através de solicitação HTTP POST na url base
http://{server}:{port}/{CEP_Admin}/resources/definitions/{definition_name}.
Fazendo uso da interface, o usuário desenvolvedor poderá construir a definição de seu projeto
através do preenchimento de formulários sem a necessidade de escrever código, conforme
ilustra a figura 59.
Figura 59. Interface Web - CEP AuthoringTool para definição do projeto
Neste exemplo, criamos nossa definição de projeto através da opção Import Project e
selecionando
o
arquivoTemperatureExample.json,
https://github.com/Fiware/tutorials.TourGuide-
disponível
em
App/blob/master/docker/images/tutorials.tourguide-app/TemperatureExample.json. A interface
também fornece outras funções como o Verify, para ver se o projeto de definição criado possui
algum erro e Save and Export, para salvar uma representação do projeto CEP em formato JSON
no repositório ou em um arquivo local e o Delete Project, para deletar uma definição.
Para que a aplicação CEP funcione, precisamos definir:
1. Producers: são utilizados para introduzir os eventos externos ao sistema e definir a
maneira como o CEP os recebem. Neste exemplo nós não definimos um produtor
explicitamente no projeto. Em vez disso, vamos usar os dados enviados via API através
de uma solicitação HTTP POST.
2. Events: são os diferentes eventos que se pretende processar. Uma definição de evento
inclui o nome do evento e uma lista de seus atributos. Neste exemplo, temos definidos
três eventos, no entanto o thingContextUpdate não será necessário, pois não utilizamos
o Orion Context Broker (CB) como produtor (para o envio de eventos), são eles:
● HighTemperatureAlert: este alerta vai ser gerado cada vez que a EPA
WarningHighTemperatureRule desencadear um evento. Definimos os atributos
de temperatura e entityId.
● LowTemperatureAlert: este alerta vai ser gerado cada vez que a EPA
WarningLowTemperatureRule desencadear um evento. Definimos os atributos
de temperatura e entityId.
3. EPAs: são utilizadas para processar e aplicar as regras dos eventos de entrada em um
contexto específico. Neste exemplo, as regras que irão acionar os alertas são as
seguintes:
● WarningHighTemperatureRule: Emitir um alerta quando a temperatura sobe
acima de um dado limiar (50 graus Celsius) durante 30 segundos.
● WarningLowTemperatureRule: Emitir um alerta quando a temperatura cai
abaixo de um determinado limiar (30 graus Celsius) durante 30 segundos.
4. Temporal Contexts: são janelas de tempo em que as EPAsestão ativos. Neste
exemplo, temos duas janelas temporais:
● WarningHighTempWindow: terá como finalidade definir a janela temporal
para a o WarningHighTemperatureRule, ou seja, quando a temperatura
ultrapassar os 50 graus Celsius em um intervalo de 30 segundos.
● WarningLowTempWindow: terá como finalidade definir a janela temporal
para a o WarningLowTemperatureRule , ou seja, quando a temperatura ficar
abaixo de 30 graus Celsius em um intervalo de 30 segundos.
5. SegmentationContexts: são usados para agrupar vários eventos a serem usados pelas
EPAs. Neste exemplo, temos:
● thingID: usado para definir o atributo (no caso entityID) usado para segmentar
os eventos.
6. Composite Contexts: utilizado para agrupar um ou mais contextos. Neste exemplo,
temos:
● WarningHighTempComp: irá combinar os contextos thingID e
WarningHighTempWindow para ser usado na EPA
WarningHighTemperatureRule.
● WarningLowTempComp: irá combinar os contextos thingID e
WarningLowTempWindow para ser usado na EPA
WarningLowTemperatureRule.
7. Consumers: responsável pelo consumo dos eventos e pelo envio para o mundo
exterior. Neste exemplo, temos:
● SensorTempConsumer: é o consumidor para os eventos
HighTemperatureAlert e LowTemperatureAlert. Ele irá criar o arquivo JSON
SensorTemp.txt, onde o CEP irá escrever os alertas.
Descoberta das definições criadas
É possível verificar todas definições que já foram criadas e que estão no repositório CEP. Para
isso foi utilizada a seguinte requisição:
http://10.7.31.32:8888/ProtonOnWebServerAdmin/resources/definitions/
Para verificar uma definição específica, basta seguir o modelo:
http://{server}:{port}/{CEP_Admin}/resources/definitions/{definition_name}
http://10.7.31.32:8888/ProtonOnWebServerAdmin/resources/definitions/TemperatureExample
Iniciando uma instância
Após a criação da definição do projeto, deve-se criar uma instância da mesma para que se
possa enviar os eventos. Para isso, foi utilizada a seguinte requisição HTTP PUT curl:
curl
http://10.7.31.32:8888/ProtonOnWebServerAdmin/resources/instances/ProtonOnWebServer \
-X PUT -s -S --header 'Content-Type: application/json' \
-d @- <<EOF
{
"action": "ChangeDefinitions",
"definitions-url": "/ProtonOnWebServerAdmin/resources/definitions/TemperatureExample"
}
EOF
Logo após mudamos o status da instância para start. Se o usuário desejar parar a instância,
troca-se por stop.
curl
http://10.7.31.32:8888/ProtonOnWebServerAdmin/resources/instances/ProtonOnWebServer \
-X PUT -s -S --header 'Content-Type: application/json' \
-d @- <<EOF
{"action":"ChangeState","state":"start"}
EOF
Descoberta das instâncias criadas
É possível verificar todas as instâncias que já foram criadas e que estão no repositório CEP.
Para isso foi utilizada a seguinte requisição:
http://10.7.31.32:8888/ProtonOnWebServerAdmin/resources/instances/ProtonOnWebServer
Enviando eventos externos para o CEP
Após a criação da instância do projeto, a aplicação já está funcionando e pronta para que se
possa enviar os eventos. Para isso, foram utilizados os seguintes exemplos de requisição
HTTP PUT curl:
● Temperatura baixa:
curl http://10.7.31.32:8888/ProtonOnWebServer/rest/events -X POST -s -S \
--header 'Content-Type: application/json' -d @- <<EOF
{"Name":"LowTemperatureAlert", "temperature":"25"}
EOF
● Temperatura alta:
curl http://10.7.31.32:8888/ProtonOnWebServer/rest/events -X POST -s -S \
--header 'Content-Type: application/json' -d @- <<EOF
{"Name":"HighTemperatureAlert", "temperature":"69"}
EOF
Verificar a saída
Uma vez que definimos e carregamos o projeto, executamos a instância e enviamos os
eventos, devemos ver os resultados no arquivo /tmp/SensorTemp.txt dentro do container onde
o CEP foi instalado. O arquivo de saída deverá ser como as seguinte:
● Temperatura baixa:
{"Cost":"0.0","Certainty":"0.0","Name":"LowTemperatureAlert","EventSource":"","Occurren
ceTime":"29\/02\/201619:10:45","Duration":"0.0","Annotation":"","entityId":"SENSOR_TEMP_ul20client_ACPI_0
_Thermal","EventId":"857e6f02-95ab-41e4-98448605c24bcf21","DetectionTime":"19\/07\/2016-19:10:45","temperature":"25"}
● Temperatura alta:
{"Cost":"0.0","Certainty":"0.0","Name":"HighTemperatureAlert","EventSource":"","Occurren
ceTime":"29\/02\/201619:13:31","Duration":"0.0","Annotation":"","entityId":"SENSOR_TEMP_ul20client_ACPI_1
_Thermal","EventId":"65367f5b-775a-4c01-8cb9c444fd84d66e","DetectionTime":"19\/07\/2016-19:13:31","temperature":"69"}
5.2.4. Problemas Encontrados
No exemplo realizado não foi possível obter acesso ao container onde o CEP foi instalado. Com
isso,também não tivemos acesso ao arquivo de saída /tmp/SensorTemp.txt do teste realizado.
5.2.5. Próximas atividades
Pretende-se utilizar o CEP GE em conjunto com o Orion, a fim de monitorar mudanças nos
valores de atributos de entidades de contexto para gerar eventos específicos. Além disso,
aprofundar mais o estudo da mesma no intuito de se trabalhar no desenvolvimento de aplicações
mais robustas.
5.3. Big Data Analysis (Cosmos) GE
5.3.1. Objetivos
O Cosmos, também chamado de Big Data Analysis, é um GE disponível no Data/Context
Management da plataforma FIWARE, e tem como objetivo a implantação de meios que
permitam a análise e processamento de dados através de um lote de tarefas (do inglês, batch)
e/ou através de um fluxo de dados estruturados ou não estruturados em um sistema
computacional (do inglês, data stream), a fim de se obter, posteriormente, uma melhor
compreensão sobre tais dados, os quais poderão revelar informações úteis e inteligentes, além
de oportunidades até então escondidas, podendo levar à tomada de melhores decisões e com
mais confiança. Além disso, melhores decisões podem significar maior eficiência operacional,
redução de risco e redução de custos, potencializando a apropriação da informação pelo
consumidor.
Os dados a serem analisados no contexto de Big Data podem sempre ser classificados em dois
grupos:
● Processamento batch (Lote de tarefas): processamento de dados que ocorre através de
um lote de tarefas enfileiradas, de modo que só se processa a próxima tarefa após o
término completo da tarefa anterior. Neste tipo de processamento, os dados são
armazenados com antecedência e o tempo de resposta não é de extrema importância. Por
exemplo, alimentação de um banco de dados local durante o dia e envio de um arquivo
sequencial contendo todos os registros para atualizações no período noturno nos sistemas
centrais.
● Processamento Data Stream (Fluxo de dados): os dados são recebidos e processados em
tempo quase real. Os resultados e tomadas e decisão precisam ser obtidos de maneira
rápida. Neste tipo de processamento, os dados não são previamente armazenados.
5.3.2. Descrição
O Cosmos GE também dá suporte à comunicação do padrão NGSI com outros tipos de GEs do
FIWARE como o Publish-Subscribe Context Broker GE e Open Data Portal GE, além de
permitir a implementação de computação privada em clusters baseados no ecossistema Hadoop,
proporcionando serviços tanto de computação como de armazenamento:
● Serviços de computação: permitem criar e configurar clusters de máquinas de forma
rápida, por meio de linha de comando ou através da API REST (do inglês,
Representational State Transfer). Além disso, permitem também selecionar um
subconjunto a partir de uma ampla gama de processamento em tecnologias préconfiguradas (e.g., Hadoop, Hive, Oozie, HBase, Sqoop, PIG);
● Serviços de armazenamento: permitem alimentar os clusters com uma enorme
quantidade e variedade de dados sem haver a necessidade de fazer adaptações ou
configurações prévias nos mesmos. Da mesma forma, os serviços de armazenamento
podem ser utilizados via linha de comando ou por meio da API REST.
O ecossistema Hadoop do Cosmos GE é composto de duas partes essenciais, o Hadoop
Distributed Filesystem (HDFS) e o Hadoop MapReduce, ambos são altamente confiáveis e
robustos para aplicações que envolvem grande quantidade de dados. O HDFS é um sistema de
armazenamento de dados que opera de forma distribuída (a informação é armazenada em mais
de um nó, onde cada um possui certa parte da informação original, podendo haver replicações
de dados afim de haver recuperação de dados quando um nó falhar), podendo ser utilizado via
linha de comando. O HDFS fornece interfaces para as aplicações com o objetivo de movê-los
para perto de onde estão localizados os dados. Ele possui 2 tipos de nós:
● Master (ou Namenode): armazena informações da distribuição de arquivos e
metadados. É necessário que esteja sempre disponível e para garantir a isso pode-se ter
um Master Secundário em um outro servidor para que, em caso de falha do primário, ele
possa assumir o controle rapidamente; e
● Worker (ou Datanode): armazena os dados propriamente ditos. Podem criar, excluir e
replicar blocos de dados de acordo com as instruções do Nó master dominante.
Dentre as principais características do HDFS, estão a tolerância, detecção e correção rápida de
falhas de maneira automática, portabilidade entre sistemas operacionais e hardware, economia
e eficiência através da distribuição de dados e por meio do processamento paralelo entre os
clusters, escalabilidade e confiabilidade no armazenamento, processamento e manutenção das
grandes quantidades de dados e lógica de processamento próxima aos dados.
Já o Hadoop MapReduce é um framework que possui um conjunto de bibliotecas que permite
realizar processamento e análise de grandes quantidades de dados em paralelo, usando todo o
hardware disponível no cluster Hadoop. O processamento é feito utilizando pares de valores de
chaves e é dividido em 2 etapas principais. A primeira é chamada de Map, onde ocorre o
mapeamento e validação dos dados. Os tipos de entrada e de saída do Map geralmente são
diferentes umas das outras. A segunda etapa é chamada de Reduce, onde cada resultado da
função Map é alocada para um redutor determinado pela função de partição, agregando e
sumarizando os resultados obtidos no mapeamento para gerar o resultado final, que é escrito no
sistema de arquivos distribuídos, através do Escritor de saída. A técnica de MapReduce é
bastante indicado para algoritmos que exigem um alto custo de processamento para ser
executado em uma única máquina A figura 60 ilustra esse processo.
Figura 60. Ilustração do paradigma MapReduce
Anteriormente à fase Map, o leitor de entrada divide o aglomerado de dados em 'blocos' de
tamanhos adequados à aplicação e o framework Hadoop atribui um bloco para cada nó de
processamento e armazenamento, através de função de mapeamento.
Ciclo de vida dos dados
A utilização dos dados no Cosmos GE pode ser dividida em 4 fases de vida distintas, são elas:
● Injeção: alimentação do banco do ambiente Big Data através das fontes que geram
uma grande quantidade de informação. Pode implicar em outros processos como a
normalização (reduzem a redundância de dados e as chances dos dados se tornarem
inconsistentes), criptografia (segurança e privacidade), filtragem e compressão dos
dados.
● Ingestão: Dentro desta fase deve ser garantida a capacidade necessária para absorver o
volume de dados vinda durante a injeção. É o processo que cobre o ajuste dos dados
(que podem ser de natureza muito diferente) obtidos ao formato apropriado que se irá
trabalhar e seu posterior armazenamento, caso a capacidade seja garantida.
● Processamento: análise propriamente dita dos dados. A arquitetura deve ser
facilmente escalável para atender um possível aumento das demandas de computação
durante a realização das tarefas.
● Consumo: os dados de saída (resultados do processamento) são consumidos e se
tornam novos dados de entrada para outra nova análise, ferramentas de visualização,
sistemas de consulta, etc. Os resultados podem ser armazenadas num repositório
externo diferente, a fim de assegurar a durabilidade e tempos de acesso maiores.
Ecossistema Cosmos
O Cosmos GE tem, em seu ecossistema, quatro principais ferramentas que irão auxiliar o usuário
desenvolvedor a implantar meios de análise Big Data. Essas ferramentas são:
● Cygnus: ferramenta que faz a conexão entre o Orion Context Broker e o sistema de
arquivos distribuídos do Cosmos, o HDFS, para alimentar (persistir dados) o cluster de
armazenamento permanente com dados de contextos que estão registrados no Orion
Context Broker. Permitindo assim a criação de uma base de dados que irá conter o
histórico dos dados de contexto, que poderão ser utilizados numa futura análise BigData.
Em outras palavras, o Orion armazena apenas o último valor em relação a um dado
atributo de uma entidade, e se caso algum valor passado for necessário, então será
preciso persisti-los, a cada mudança dessa variável (cada valor), no HDFS, usando o
Cygnus.
● Tidoop MR Library: biblioteca utilizada na criação de trabalhos MapReduce. Os
trabalhos MapReduce disponíveis dentro desta biblioteca podem ser combinados em
uma cadeia de execuções, ligando a saída de um trabalho à entrada de outro. Esse
encadeamento pode ser feito via linha de comando, manualmente executando as tarefas
sequencialmente, usando a API tidoop-mr-lib-api ou a Apache Oozie. Além disso, essa
ferramenta inclui meios que permitem a utilização de dados provinientes do CKAN
● Extensões Hadoop Tidoop: normalmente, nas aplicações MapReduce no Hadoop, os
dados são lidos e analisados a partir do HDFS, o Hadoop Distributed File System.
Porém, é possível que os dados a serem analisados não estejam no HDFS, mas numa
memória remota não-HDFS. Nesse caso, usando tidoop-hadoop-ext, será possível ler
esses dados ao apontar para essa memória remota. Os dados poderão ser armazenados
no CKAN ou no NGSI Short-Term Historic.
● Wilma PEP Proxy e Cosmos Auth: ferramenta para implementar a autenticação e
autorização baseada em OAuth2 em suas APIs REST. Através desses componentes, o
desenvolvedor poderá adicionar autenticação e segurança nos aplicativos de back-end.
Assim, apenas usuários FIWARE autorizados serão capazes de acessar seus GEs ou
serviços REST. Além disso, permite a gestão de permissões e políticas específicas para
os recursos, permitindo diferentes níveis de acesso para os usuários.
Inicialmente pensamos em um exemplo em que faríamos o download de algum arquivo .txt e
em seguida o upload do mesmo no sistema de armazenamento de arquivos distribuídos, o HDFS
Hadoop. Posteriormente, iríamos executar dois trabalhos MapReduce: o primeiro com o
objetivo de contar a ocorrência de cada palavra do texto e o segundo para ordenar, de forma
decrescente, a lista de palavras por quantidade de ocorrências das mesmas no texto. No entanto,
não foi possível executar este exemplo pois os recursos do Cosmos necessários para seu
desenvolvimento ainda não foram instalados. Das quatro principais ferramentas do ecossistema
Cosmos anteriormente citadas, apenas o Cygnus foi instalado no momento.
Pensamos então em outro exemplo que pudéssemos utilizar o Cygnus. O exemplo consiste em
utilizar a ferramenta Cygnus para fazer a conexão com o Orion Context Broker. Primeiramente
deve-se criar a entidade de contexto no Orion e seus respectivos atributos. Posteriormente, é
preciso criar a conexão Orion-Cygnus a partir do mecanismo de subscrição de notificação do
Orion CB. Através dessa subscrição, o Cygnus é notificado cada vez que determinados atributos
da entidade de contexto criada mudarem. Para fazer essa subscrição, o desenvolvedor pode usar
qualquer cliente REST ou uma requisição HTTP Curl com o seguinte modelo:
(curl localhost:1026/v1/subscribeContext -s -S --header 'Content-Type: application/json' -header 'Accept: application/json' --header 'Fiware-Service: vehicles' --header 'FiwareServicePath: /4wheels' -d @- | python -mjson.tool) <<EOF
{
"entities": [
{
"type": "car",
"isPattern": "false",
"id": "car1"
}
],
"attributes": [
"speed",
"oil_level"
],
"reference": "http://{Cygnus_SERVER}:{Cygnus_PORT}/notify",
"duration": "P1M",
"notifyConditions": [
{
"type": "ONCHANGE",
"condValues": [
"speed"
]
}
],
"throttling": "PT1S"
}
EOF
No modelo de subscrição acima citado, será enviada uma notificação cada vez que o
atributo speed, da entidade car1 e tipo car, muda o seu valor. A notificação será enviada para o
link contido em reference (http://{Cygnus_SERVER}:{Cygnus_PORT}/notify) e irá conter os
valores dos atributos speed e oil_level. Esta subscrição terá uma duração de um mês (P1M), e
só será possível o envio de uma notificação por segundo (PT1S).
Após a criação da subscrição, deve-se modificar, no Orion (através de outra requisição),
o(s) atributo(s) que estão sendo monitorados na mesma para testar se as notificações serão
enviadas ao Cygnus com sucesso.
No entanto, também não foi possível executar este exemplo, pois foi feita apenas a
instalação bruta do Cygnus e não conseguimos criar a subscrição com sucesso. Seria necessário
fazer a configuração prévia do chamado test agent (/usr/cygnus/conf/agent_test.conf) no local
onde foi instalado o Cygnus, para fazer a configuração da porta e do link em que se irá receber
as notificações, e como não temos acesso ao servidor onde foi instalado, não pudemos assim
fazê-lo.
A configuração do test agent pode ser encontrada no link: http://fiwarecygnus.readthedocs.io/en/release-0.13.0/quick_start_guide/
5.3.5. Próximos passos
Após concluída a instalação de todas as ferramentas do ecossistema Cosmos, pretendese dar continuidade ao desenvolvimento do exemplo da contagem e ordenamento de palavras
citado na seção anterior. Além disso, iremos aprofundar mais o estudo do Cosmos com o
objetivo de desenvolver uma aplicação mais robusta que abranja a comunicação com outras GEs
(CKAN, por exemplo).
5.4. Orion GE
5.4.1. Objetivos
O Orion Context Broker é uma implementação do Publish/Subscribe Context Broker
GE, que fornece interfaces NGSI9/10. Usando estas interfaces clientes podem realizar alguns
tipos de operações: registrar aplicações que produzem contexto, atualizar informação
contextual, receber notificações quando há mudanças na informação contextual, ou quando essa
mudança ocorre com uma determinada frequência e consultar informação contextual. [4]
5.4.2. Descrição
O desenvolvimento de aplicações inteligentes requer a coleta e o gerenciamento de
informações contextuais, esse termo se refere aos valores de atributos que caracterizam
entidades relevantes para a aplicação. No contexto de cidades inteligentes, esta informação
contextual pode vir de diferentes fontes (sistemas legados existentes, dispositivos móveis,
sensores) e variar ao longo do tempo [4]. Estas diferentes fontes trabalham como produtores de
contexto e provedores de contexto.
Neste cenário faz-se necessário implementar uma solução que seja não-intrusiva, ou seja,
capaz de se integrar aos sistemas existentes e a futuros sistemas que lidam com o gerenciamento
de serviços municipais, sem que suas arquiteturas sofram impacto. O Context Broker GE da
plataforma FIWARE implementa a NGSI9/10 REST API, que permite o gerenciamento de
informação contextual em conformidade com os requisitos de cidades inteligentes.
O Orion Context Broker, que é uma implementação de referência da Context Broker,
permite o gerenciamento de todo o ciclo de vida da informação contextual, incluindo
atualizações, consultas, registros e subscrições. Usando o Orion uma aplicação pode registrar
elementos de contexto e gerenciá-los através de operações de consulta e atualização. Além disso,
a aplicação pode fazer uma subscrição para alguma informação contextual específica, para
receber notificações do Orion, quando determinada condição ocorre.
A Figura 61 mostra uma visão geral da interação do Orion com aplicações que podem
ser produtoras ou provedoras de contexto. As aplicações produtoras de contexto enviam
informação contextual para o Orion através da operação update, esta informação é armazenada
pelo Orion em um banco de dados. Aplicações consumidoras podem consultar informações
contextuais através da operação query e outras aplicações podem fazer subscrições para serem
notificadas sobre mudanças em determinados atributos de uma entidade de contexto.
Figura 61. Visão Geral do Orion
Nesta seção será mostrado exemplos de utilização das operações da API NGSI para
interagir com o Orion Context Broker utilizando comandos CURL.
Contexto no Orion Context Broker é representado por meio de entidade NGSI. A Figura
62 o comando CURL para a criação da entidade Room2, que representa uma sala de um
determinado ambiente, com temperatura e pressão, como atributos. No exemplo, o atributo do
tipo Float, temperature da entidade Room2, foi setado com um valor 23 e o atributo do tipo
Integer, pressure, com o valor 720. Ao dar ENTER não há um retorno específico do Orion
quanto a criação da nova entidade, mas pode-se verificar que ela foi criada e armazenada
executando um GET <host>:<port>/v2/entities.
Figura 62. Criação de Entidades no Orion
Após a criação das entidades no Orion, pode-se realizar requisições de consulta, como
mostra a Figura 63. O primeiro comando CURL, é uma requisição GET que consulta a entidade
Room1. O Orion retorna a entidade no formado JSON, com seu id, tipo e atributos. O segundo
comando CURL da Figura 63 consulta apenas o atributo temperature da entidade Room1,
utilizando a palavra reservada “attrs” e indicando o nome do atributo explicitamente na
requisição. É possível recuperar os valores dos atributos fazendo requisições que utilizem o
formato <id da entidade>?options=keyvalues, como mostra a terceiro comando.
Figura 63. Consultas a Entidades no Orion
Pode-se também atualizar o valor de um determinado atributo. A Figura 64 mostra o
comando para fazer este tipo de alteração, que é uma requisição PUT, que utiliza a palavra
reservada “attrs” e o nome do atributo a ser atualizado e no corpo da requisição, é definido o
novo valor e o tipo.
Figura 64. Alteração de Atributo de Entidade
Além de criar uma nova entidade e atualizar seus atributos, é possível deletar uma
entidade criada anteriormente. A Figura 65 mostra este tipo de operação na NGSIv1 e o retorno
dado pelo Orion. A requisição é feita utilizando a operação updateContext, onde deve-se definir
a entidade a ser deletada e a updateAction como DELETE.
Figura 65. Remoção de Entidade no Orion
O Orion Context Broker permite que uma aplicação faça uma subscrição para ser
notificada quando uma determinada entidade é modificada de acordo com alguma condição. A
Figura 66 mostra a requisição de subscrição na NGSIv1 e a Figura 67 mostra como fazer esta
requisição utilizando a NGSIv2. Utilizando a NGSIv1 deve-se especificar a entidade para a qual
deseja-se subscrever, os atributos, uam URL de callback, através do atributo reference, para que
o Orion saiba para onde deve enviar a notificação, especificar as condições de notificação
através do atributo notifyCondition, neste exemplo foi definido que o Orion deve notificar a
aplicação quando o atributo speed da entidade car for modificado.
Figura 66. Subscrição com NGSIv1
Figura 67. Subscrição com NGSIv2
5.4.4. Próximos passos
-Desenvolver cliente, utilizando bibliotecas existentes, para interação de aplicações
mobile e desktop com o Orion
5.5. Stream Oriented (Kurento) GE
5.5.1. Objetivos
O desenvolvimento de aplicações multimédia interativas (stream) é uma tarefa complexa, que
geralmente requer conhecimentos específicos e investimentos enormes. O Stream Oriented GE
traz uma série de abstrações e facilitadores que possibilitam que qualquer desenvolvedor possa
criar aplicações que envolvem recursos avançados de tecnologias multimédia, tais como:
comunicações audiovisuais, visão do computador, realidade aumentada, reprodução flexível de
mídia, gravação, etc.
O
Kurento
(http://catalogue.fiware.org/enablers/stream-oriented-kurento)
é
uma
implementação da especificação do Stream Oriented (GE disponível no Data/Context
Management da plataforma FIWARE) que através de uma grande quantidade de APIs e
ferramentas fornecem aos desenvolvedores um conjunto robusto fim-a-fim de capacidades de
comunicação multimídia interoperáveis para lidar com a complexidade do transporte,
codificação/decodificação, processamento e tarefas de renderização de uma forma fácil e
eficiente.
5.5.2. Descrição
Kurento
(http://builds.kurento.org/dev/master/latest/docs/introducing_kurento.html)
é
composto por um servidor de mídia WebRTC (https://webrtc.org/) (navegador web com
comunicação em tempo real, que pode ser ponto-a-ponto ou utilizando um servidor de mídia) e
um conjunto de APIs clientes que tornam simples o desenvolvimento de aplicações de vídeo
avançadas para plataformas WWW e smartphones.
Figura 68. WebRTC ponto-a-ponto e WebRTC utilizando um servidor de mídia
A figura 68 compara os tipos de implementação do WebRTC, no primeiro retângulo é ilustrado
o WebRTC ponto-a-ponto já no segundo, mostra um WebRTC que utiliza de um servidor de
mídia.
Na parte central da arquitetura Kurento há um servidor de mídia chamado Kurento
Media Server (KMS) que é utilizado como servidor de mídia para o WebRTC. O KMS é
baseado na capacidade de processamento de mídia conectáveis. Isso significa que qualquer uma
de suas características fornecidas é um módulo conectável que pode ser ativada ou desativada
de acordo com a necessidade.
O KSM incluem características de comunicações de grupo, transcodificação, gravação,
mixagem, transmissão e encaminhamento dos fluxos audiovisuais. Seu diferencial é também
fornecer recursos de processamento de mídia avançados que envolvem visão computacional, a
indexação de vídeo, realidade aumentada e análise de discurso.
Ao ser utilizado como servidor de mídia para o WebRTC, faz com que a capacidade de
processamento do WebRTC aumente, ilustrado na figura 69 .
Figura 69. Aumento da capacidade de processamento de mídia utilizando o Kurento Media
Service em comparação com servidores de mídia comum.
Já a API do Kurento cliente é baseada no conceito de Elemento de mídia. Um elemento de
mídia é responsável por um tipo de mídia específico. Por exemplo, o elemento de mídia
chamado WebRtcEndpoint possui a capacidade de enviar e receber fluxos de mídia WebRTC,
já o FaceOverlayFilter detecta rostos em stream de vídeo trocados. Kurento possui grande
quantidade de elementos de mídia como parte de suas APIs. Mais exemplos de elementos de
mídias podem ser vistos na figura 70
Figura 70. Alguns elementos de mídias do Kurento
Os elementos de mídia podem ser ligados como peças de Lego para formar o chamado: Pipeline
de mídia. Para construir um Pipeline de mídia é preciso ter os elementos de mídia necessários
para uma aplicação e ligá-los seguindo a topologia desejada, onde a conectividade entre os
elementos de mídia é controlada através da conexão primitiva, presente em todas as APIs cliente
Kurento.
Figura 71. Exempo do uso do Pipeline de mídia.
A figura 71 ilustra o pedido de um video pelo cliente, através de um navegador
(browser), para um servidor de mídia Kurento (WebRTC), este possui um elemento de mídia
responsável por acessar um repositório de vídeos, encontrar o vídeo solicitado e devolvê-lo para
ser reproduzido pelo navegador do cliente.
Então, dessa forma, é utilizado o Kurento como base para o desenvolvimento de
aplicações multimédia interativas (stream).
A
seguir
será
apresentado
o
exemplo
de
uso
do
Kutento
(http://doc-
kurento.readthedocs.io/en/stable/tutorials/java/tutorial-helloworld.html) onde faremos uma
aplicação web, utilizando java, onde transmitirá vídeo via stream em loopback, conforme
mostrado na figura 72.
Figura72. Interface do exemplo em execução
A lógica dessa aplicação é bastante simples: o fluxo local (como capturado por uma webcam) é
enviada para o Kurento Media Server, que envia de volta para o cliente sem modificações. Para
implementar esse comportamento, é preciso criar um processo de mídia composto por um único
elemento de mídia, ou seja, criar um WebRtcEndpoint, que detém a capacidade de troca de
fluxos de mídia full-duplex (bidirecional). Este elemento de mídia está ligado a si próprio
(loopback), para que a comunicação recebida (a partir do navegador) seja enviado de volta (para
o
mesmo
navegador).
Este
processo
de
mídia
é
ilustrado
na
Figura
73.
Figura 73. Elementos de Mídia usado no exemplo.
Esta é uma aplicação web e, portanto, segue-se uma arquitetura cliente-servidor. No lado do
cliente, a lógica é implementada em JavaScript. No lado do servidor, usamos uma aplicação
servidor baseada em Spring-Boot que consome a API Cliente Kurento Java, para controlar
recursos de Kurento Media Server.
O diagrama de sequência da Figura 74 mostra as interações entre a a interface de aplicação para:
i) lógica JavaScript; ii) lógica do servidor de aplicativos (que utiliza o cliente Kurento Java); iii)
Kurento Media Server.
Figura 74 Diagrama de sequência apresenta as interações entre os componentes exemplo.
5.6. Comprehensive Knowledge Archive Network (CKAN) GE
5.6.1. Objetivos
O CKAN (http://docs.ckan.org/en/latest/contents.html), sigla para Comprehensive Knowledge
Archive Network, é uma aplicação web de código aberto que facilita a publicação e o
gerenciamento de dados abertos. Este portal é muito utilizado por Governos de vários países
(Estados Unidos, Austrália, Canadá etc.), além de instituições de pesquisa e outras organizações
que coletam dados com a finalidade de publica-los para que outros usuários possam utiliza-los.
Uma vez que os dados são publicados no CKAN, os usuários podem realizar pesquisas para
encontra-los conforme sua necessidade, e visualizá-los usando mapas, gráficos e tabelas - seja
ele um desenvolvedor, jornalista, pesquisador, membro de uma ONGs, ou até mesmo um
cidadão comum.
5.6.2. Descrição
A aplicação é altamente personalizável, visto que possibilita aos desenvolvedores a
customização da interface dos portais, bem como lhes permite escolher quais as características
são desejas para o seu portal de dados. Há mais de 60 diferentes extensões, as quais podem ser
adicionadas de forma independente em qualquer configuração que for escolhida. Qualquer um
pode construir novas extensões e contribuir.
O CKAN oferece uma interface intuitiva que permite o registro e login dos editores dos portais
no sistema (para os usuários que desejam somente encontrar dados, não é necessário registro
nem login); conjuntos de dados podem ser criados, editados ou removidos pelos usuários com
o permissões apropriadas; além disso, o CKAN permite criar grupos e organizações que
possuirão os conjuntos de dados.
Os dados são inseridos no portal, de forma pública ou privada, em unidades chamadas “datasets”
que podem conter, por exemplo, as estatísticas de criminalidade de uma região, os gastos de um
departamento do governo, ou leituras de temperatura de várias estações meteorológicas. Esses
“datasets” podem estar dentro de agrupamentos ou distribuídos entre organizações, e podem
conter tags que facilitem a sua busca.
Um dataset contém:
● Informações ou "metadados" sobre os dados (por exemplo, seu identificador único, o
título, descrição, data de sua criação, grupos, tags, organizações, em quais formatos ele
está disponível, sob qual licença ele é liberado, entre outras coisas);
● Uma série de "recursos" (planilha CSV ou Excel, arquivo XML, documentos PDF,
arquivo de imagem, dados vinculados no formato RDF etc), que mantém os dados em
si. Esses recursos podem estar armazenados internamente no CKAN, ou
disponibilizados simplesmente através de um link de uma página web que os contém.
Um conjunto de dados pode conter qualquer número de recursos, e diferentes recursos
pode conter os dados para anos diferentes, ou os mesmos dados em diferentes formatos;
● Histórico de inserção ou alterações de recursos e um mecanismo para mudança de
versão.
Para dar suporte na busca de dados, o CKAN fornece uma experiência de pesquisa rica que
permite buscas rápidas pelos metadados dos datasets, palavras-chave, textos completos dos
campos etc; também permite a filtragem por organizações, grupos, tags, formatos e licenças;
além disso, oferece um mecanismo de navegação entre conjuntos de dados relacionados. Os
resultados dessas buscas podem ser visualizados através de tabelas, gráficos e mapas
geográficos.
5.6.3. API do CKAN
As operações que são realizadas na interface web do CKAN e outras operações podem ser
realizadas também através de sua poderosa API (Application Programming Interface)
RESTFull. Para solicitar alguma informação sobre um dataset via API, é necessário realizar um
requisição HTTP passando informações desse dataset através da URL, o retorno é dado em
formato JSON.
Existem, atualmente, três versões da API do CKAN. Ao fazer uma requisição sem informar na
URL o número da versão, o CKAN vai escolher a versão mais recente da API. É recomendável
que se especifique a versão da API nas requisições, pois isso irá garantir que, quando houver
uma atualização da mesma, os clientes implementados em cima de suas outras versões irão
continuar funcionando.
A figura 75 mostra um exemplo de uma requisição de todos os datasets registrados no portal do
CKAN criado para testes.
Figura 75 requisição feita utilizando-se a versão 3 da API.
As Figuras 76a e 76b mostram a mesma busca da imagem anterior realizadas com as versões
anteriores da API.
Figura 76a: requisição com a versão 1 da API.Figura 76b: requisição com a versão 2 da API.
É possível observar nas imagens acima que o retorno de uma requisição com a versão 1 devolveu
o nome do objeto (por exemplo, "areasverdes"), enquanto que a versão 2 devolveu seu ID (por
exemplo, "ada09a14-2a54-4fcb-8f9e-3b2a1defbe85").
É importante salientar que algumas funções da API requer uma autorização. Para isso, a API
usa as mesmas funções e configuração de autorização que a interface web. Dessa forma, se um
usuário está autorizado a fazer algo na interface web também estará autorizado a fazê-lo por
meio da API.
5.6.4. Problemas Encontrados
O CKAN é uma excelente ferramenta para publicação de dados estáticos. Porém a ferramenta
não é muito boa para publicação e gerenciamento de dados dinâmicos. Para tentar contornar
esse problema e dinamizar o processo de inserção e atualização de dados no nos portais, podese utilizar a extensão DataStore que complementa o FileStore, mecanismo de upload de recursos
nos datasets.
O FileStore permite que os usuários façam o upload de imagens de logotipo para grupos e
organizações; além disso, permite fazer upload de arquivos para os datasets. Seu grande
problema é que ele só permite a inserção ou remoção de arquivos inteiros, não oferece nenhuma
forma de atualizar ou acessar partes de um arquivo.
A extensão DataStore fornece um banco de dados para o armazenamento de dados estruturados
a partir de recursos CKAN. Esse armazenamento é feito de forma assíncrona com o uso de um
serviço, o DataPusher, que extrai os dados dos arquivos inseridos no FileStore e os adiciona ao
DataStore num formato que ele possa manipular. Essa extensão fornece uma API para inserir
dados de forma incremental no banco, procurar, filtrar, remover e atualizar os dados, sem a
necessidade de download e upload de todo o arquivo de dados.
5.6.5. Pendências
Ainda não foi possível realizar testes com a extensão DataStore. Também ficou faltando testar
a comunicação entre o CKAN e outros GE’s.
5.6.6. Próximos Passos
Encontrar uma forma de tornar mais dinâmica a publicação e gerenciamento de dados no
CKAN. O plugin DataStore não supri totalmente as necessidades do projeto, pois, de certa
forma, ainda não automatiza esse processo. Nos estudos realizados até agora, pode-se perceber
que os dados só são persistidos no banco de dados do DataStore, se hover um recurso associado
no CKAN. Para isso, seria necessário a inserção manual desse recurso no CKAN. Caso não seja
encontrada uma solução, deve-se pensar em criar uma extensão para isso. O CKAN é altamente
flexível à criação de plugins desse tipo.
6 Advanced Middleware and Interfaces to Network and Devices
Esta seção apresenta uma visão geral dos objetivos e da descrição dos habilitadores genéricos
(do inglês, Generic Enablers – GEs) da plataforma FIWARE disponíveis no catálogo de GEs
sobre Advanced middleware and interfaces to Network and Devices. O restante da seção está
estruturada em duas subseções. A subseção 6.1 descreve o GE KIARA Advanced Middleware,
enquanto a subseção 6.2 detalha o GE OFNIC (OpenFlow Network Interface and Control).
6.1. KIARA Advanced Middleware
6.1.1. Objetivos
O KIARA Advanced Middleware é um GE que fornece uma comunicação flexível, eficiente,
escalável e segura entre aplicações distribuídas, assim como a outros GEs disponíveis no
catálogo do FIWARE. O KIARA abstrai os métodos de comunicação dos dispositivos presentes
na rede, como IEEE 802.11, 802.3, 802.15.4, entre outros (protocolos como 6LoWPAN, Coap
e ZigBeeIP também), e assim facilita que componentes completamente diferentes possam se
comunicar de forma eficiente, ou seja, que o receptor da mensagem compreenda perfeitamente
o que foi transmitido pela origem.
6.1.2. Descrição
Um middleware, em geral, é criado para estabelecer uma melhor comunicação entre serviços,
receber e codificar dados recebidos, enviar esses dados ao seu destino e possivelmente receber
resultados em troca [REF Mid]. Para isso, os middlewares se utilizam de padrões de
comunicação específicos, como Publish/Subscribe, Point-to-Point, e Request/Reply.
O GE KIARA usa o modelo de comunicação Publish/Subscribe para fornecer a troca de dados
entre as possíveis aplicações na rede e/ou GEs. No modelo de comunicação Publish/Subscribe,
uma entidade (e.g., dispositivo de medição de temperatura)publica, através de um protocolo
bem conhecido, um serviço (e.g., medições sensoriais) para que este seja acessado por entidades
que o subscrevam. O GE KIARA implementa métodos que permitem a troca de mensagens e
fornece serviço de comunicação entre os dispositivos de forma transparente, de modo que estes
nem mesmo se conheçam.
O Advanced Middleware KIARA tem suporte a QoS (Quality of Service - Qualidade de Serviço)
[REF QoS] onde os dispositivos declaram quais níveis de serviços precisam para seu pleno
funcionamento e middleware trata de prover essa funcionalidade para o mesmo.
O GE KIARA não é um serviço autônomo, mas um conjunto de ferramentas e uma biblioteca
de comunicação a ser integrado com a aplicação. Ele difere de outros middlewares por
apresentar:
●
Arquitetura de Serviço de Alto Nível: que provê funcionalidades para tratar a estrutura
de dados da aplicação, amenizando os esforços do desenvolvedor;
● Segurança: permitindo aos aplicativos definirem suas necessidades de segurança para
que o GE KIARA faça com que sejam cumpridos durante a sessão de comunicação;
● Suporte Dinâmico a Multiprotocolos: o middleware KIARA pode selecionar, em tempo
de execução, o melhor método de comunicação com o serviço remoto;
● QoS e SDN: sempre que possível, anotações de QoS podem ser utilizadas para melhorar
a rede utilizando uma rede SDN, como exemplo, reserva de largura de banda.
O FIWARE pode ser definidosobre uma SDN. Em ambientes assim, o módulo de QoS irá
interagir com o Netfloc GE para obter informações de rede adicional ou mesmo disposição dos
componentes de rede para fornecer uma qualidade de serviço solicitada.
O diagrama da Figura 77 mostra as funcionalidades principais da GE.
Figura 77: Diagrama Arquitetural KIARA
Na Figura 77 o trajeto de cima para baixo caracteriza o envio de dados, enquanto o inverso é o
recebimento de dados pelo KIARA. Como em uma transmissão em camadas, cada uma é
responsável pela implementação de uma determinada funcionalidade, não sendo necessária a
mesma implementação nas outras camadas.
As camadas do Middleware Kiara são:
● DataAccess, com principal função mapear o modelo de comunicação (como o padrão
Publish/Subscribe);
● Marchalling que, dependendo da configuração ou padrão de comunicação, os dados
serão serializados para o formato de transmissão requerido ao enviar e desserializados
ao recebê-los (exemplo JSON);
● Wire-Protocols também dependendo da configuração da comunicação, um tipo de
comunicação é estabelecido, como o protocolo Real Time Publish Subscribe (RTPS) que
é usado quando a comunicação for feita pelo padrão Publish/Subscribe;
● O KIARA tem suporte aos tipos padrões de Transport Protocols (TCP e UDP);
● Dispatching trabalha com operações single-threaded, multi-threaded e thread-pool
permitindo operações síncronas e assíncronas para o recebimento de dados das
aplicações remotas.
O módulo de negociação do GE é responsável por estabelecer o melhor método de transmissão
e os protocolos utilizados para uma melhor comunicação entre dispositivos e o middleware,
avaliando os paradigmas e os requisitos de QoS.
O módulo de segurança está presente em todo o processo do caminho dos dados, fornecendo um
caminho seguro por meio de autenticação entre o GE e as aplicações.
O FIWARE.OpenSpecification.I2ND.Middleware define a arquitetura completa do KIARA,
como também o design da sua API para criação de aplicativos.
6.1.3 Exemplo
Será apresentado um exemplo básico da utilização do KIARA Advanced Middleware, uma
calculadora de soma ou subtração de dois números. Comunicação em RPC.
Basicamente o servidor oferecerá duas funções:
● float add (float n1, fload n2) : Retorna a soma de dois números
● float subtract (float n1, float n2) : Retorna a subtração de dois números
Assim precisamos definir uma classe <IDL-ServiceName>ServantExample para prover essas
funções.
class CalculatorServantExample extends CalculatorServant {
public float add (/*in*/ float n1, /*in*/ float n2) {
return (float) n2 + n2;
}
public float substract (/*in*/ float n1, /*in*/ float n2) {
return (float) n1 - n2;
}
}
A IDL KIARA define o que cada classe deve conter para um perfeito funcionamento da
aplicação:
● <IDL-ServiceName> : Interface expondo as chamadas de operação de serviço síncrona
definidos.
public interface Calculator {
public float add (/*in*/ float n1, /*in*/ float n2);
public float subtract (/*in*/ float n1, /*in*/ float n2);
}
● <IDL-ServiceName>Async : Interface expondo as chamadas de operação assíncrona.
public interface CalculatorAsync {
public void add(/*in*/ float n1, /*in*/ float n2, AsyncCallback<Float>
callback);
public void subtract(/*in*/ float n1, /*in*/ float n2,
AsyncCallback<Float> callback);
}
● <IDL-ServiceName>Client : Interface para expor todas as chamadas do lado do cliente
(síncrona e assíncrona).
public interface CalculatorClient extends Calculator, CalculatorAsync {
}
● <IDL-ServiceName>Process : Classe que contém os métodos que serão executados
para processar chamadas dinâmicas.
public class CalculatorProcess {
public static void add_processAsync(final TransportMessage message,
final SerializerImpl ser, final AsyncCallback<Float> callback) {
try {
final BinaryInputStream bis =
BinaryInputStream.fromByteBuffer(message.getPayload());
// Deserialize message ID
final Object messageId = ser.deserializeMessageId(bis);
// Deserialize return code (0 = OK, anything else = WRONG)
int retCode = ser.deserializeUI32(bis, "");
if (retCode == 0) { // Function execution was OK.
int result = ser.deserializeI32(bis, "");
callback.onSuccess(result);
}
} catch (Exception ex) {
callback.onFailure(ex);
}
}
public static void subtract_processAsync(final TransportMessage
message, final SerializerImpl ser, final AsyncCallback<Integer> callback) {
try {
final BinaryInputStream bis =
BinaryInputStream.fromByteBuffer(message.getPayload());
// Deserialize message ID
final Object messageId = ser.deserializeMessageId(bis);
// Deserialize return code (0 = OK, anything else = WRONG)
int retCode = ser.deserializeUI32(bis, "");
if (retCode == 0) { // Function execution was OK.
int result = ser.deserializeI32(bis, "");
callback.onSuccess(result);
}
callback.onFailure(ex);
}
}
}
● <IDL-ServiceName>Proxy : Esta classe encapsula toda a lógica necessária para
chamar as operações remotas. (Cliente proxy → stub).
● <IDL-ServiceName>Servant : Esta classe abstrata fornece todos os mecanismos
(transporte, un/marshalling, etc.) que o servidor necessita para chamar as funções de
servidor.
● <IDL-ServiceName>ServantExample : Esta classe será estendido para implementar as
funções do lado do servidor.
● ClientExample : Esta classe contém o código necessário para executar um possível
exemplo de aplicação do lado do cliente.
● ServerExample : Esta classe contém o código necessário para executar um possível
exemplo de aplicação do lado do servidor.
Logo após podemos criar nosso servidor para executar os procedimentos remotos.
public class ServerExample {
public static void main (String [] args) throws Exception {
System.out.println("CalculatorServerExample");
Context context = Kiara.createContext();
Server server = context.createServer();
CalculatorServant Calculator_impl = new CalculatorServantExample();
Service service = context.createService();
service.register(Calculator_impl);
//Adiciona um service esperando uma conexãoTCP usando CDR serialization
server.addService(service, "tcp://0.0.0.0:9090", "cdr");
server.run();
}
}
Agora será criado a parte cliente do exemplo:
public class ClientExample {
public static void main (String [] args) throws Exception {
System.out.println("CalculatorClientExample");
float n1 = (float) 3.0;
float n2 = (float) 5.0;
float ret = (float) 0.0;
Context context = Kiara.createContext();
//Conecta ao servidor escutando em 127.0.0.1:9090 (TCP)
Connection connection =
context.connect("tcp://127.0.0.1:9090?serialization=cdr");
Calculator client = connection.getServiceProxy(CalculatorClient.class);
try {
ret = client.add(n1, n2);
System.out.println("Result: " + ret);
System.out.println("Exception: " + ex.getMessage());
return;
}
}
Kiara.shutdown();
}
Com isso temos uma aplicação que faz cálculos através do KIARA.
6.1.4 Próximos Passos
O KIARA ainda precisa ser estudado profundamente para o desenvolvimento de aplicações
mais robustas.
6.2. OpenFlow Network Interface and Control (OFNIC)
6.2.1. Objetivos
O OFNIC é um GE disponível no catálogo da plataforma FIWARE, e tem o objetivo principal
de suportar a abstração e a virtualização de recursos (e.g., caminhos, tabelas de fluxo, largura
de banda e etc.) e funcionalidades (e.g., encaminhamento de dados) das Redes Definidas por
Software (do inglês, Software Defined Networks – SDN). Esse GE expõe uma interface RESTful
que monitora e oferece informações próximas ao tempo real, para aplicações ou até mesmo
outros GEs do FIWARE, relacionadas a uma rede baseada no protocolo OpenFlow. As
informações de rede que podem ser acessadas via GE OFNIC incluem medições relacionadas à
topologia da rede (e.g., quantidade de switches OpenFlow, conexões físicas entre eles e etc.) e
estatísticas de mensagens (ao nível de fluxos, nós ou portas) OpenFlow e de dados nos switches.
Além disso, o OFNIC oferece a capacidade de interagir com o Controlador SDN para expor a
funcionalidade de controle do estabelecimento de caminhos fim-a-fim com garantias de
qualidade de serviço/experiência (QoS/QoE) requeridas pelas aplicações.
6.2.2. Descrição
O OFNIC é uma implementação de referência e de código aberto do GE NetIC (do inglês,
Network Information and Control). O GE NetIC provê a abstração da heterogeneidade (em
termos de tecnologias de comunicação, protocolos e etc.) dos dispositivos nas SDN, expondo
ainda informações sobre o estado da rede e permitindo a sua programabilidade. Os possíveis
usuários do NetIC incluem os provedores de serviços de rede ou outros componentes do
FIWARE, como o Cloud Hosting. Através das interfaces disponíveis, esses usuários podem
obter estatísticas (e.g., uso de largura de banda) e implementar políticas para as funcionalidades
da rede. Especificamente, o OFNIC expõe as seguintes informações relacionadas ao controle de
redes SDN baseadas em OpenFlow: o FIWARE.OpenSpecification.I2ND.NetIC, que detalha as
especificações do NetIC; e a FIWARE.OpenSpecification.I2ND.NetIC.RESTfulAPI, que
define as APIs do NetIC.
O conjunto de APIs RESTful oferecidas pelo OFNIC é acessado através de mensagens HTTP
que consideram o formato JSON para representar os dados na troca de informações com os
usuários. As APIs são expostas via uma Northbound Interface, que permite a comunicação entre
as aplicações e os Controladores SDN. O OFNIC é capaz de receber diferentes requisições
HTTP, e, para cada requisição recebida de uma aplicação interessada em dados, ele envia uma
mensagem com algum código de retorno. As requisições disponíveis no OFNIC estão listadas a
seguir:
● PUT, para criar recursos de rede;
● POST, atualizar informações sobre os recursos de rede;
● GET, para obter uma lista dos recursos de rede disponíveis; e
● DELETE, para remover um recurso de rede.
O OFNIC disponibiliza APIs que expõem um conjunto de comandos que permitem obter
informações e alguma programabilidade da rede SDN. Esses comandos manipulam diferentes
objetos, como Network, Node, Port, Link e VirtualPath. Tais objetos são manipulados através
de diferentes operações, as quais são divididas em grupos de funcionalidades chamados
Synchronize, Virtualpaths e Monitor. As operações do grupo Synchronize permitem que os
usuários (i.e., aplicações ou outros GEs do FIWARE) obtenham as informações sobre a
topologia da rede SDN, a configuração dos nós (e.g., endereços), situação das portas de switches,
dentre outras. Já as operações do grupo Virtualpaths permitem listar todos os caminhos virtuais
na rede e adicionar novos caminhos com base em informações, como endereços IP e MAC da
fonte e do destino, largura de banda disponível, protocolo de Nível de Rede, etc. Por fim, o
grupo de operações Monitor oferece APIs para obter estatísticas de rede coletadas sobre todas
as portas dos dispositivos de rede (e.g., switches). Os parâmetros coletados e expostos pela API
incluem a quantidade de bytes transmitidos por unidade de tempo e a quantidade de pacotes
transmitidos por unidade de tempo.
7Internet of Things (IoT) Services Enablement
O paradigma de Internet das Coisas (Internet of Things - IoT) tem ganhado cada vez mais
notoriedade nos últimos anos. Esse paradigma abrange uma infraestrutura de hardware, software
e serviços que conectam objetos físicos à rede de computadores, ele consiste em conectar
diversos dispositivos e/ou objetos do mundo real, denominados como coisas, de forma que eles
possam interagir com outros objetos e aplicações afim de colaborar entre si para a realização de
diversas tarefas ou para prover serviços e informações úteis às pessoas. Tais objetos e serviços
conectados tem o potencial de atuar ativamente em processos sociais e de negócios, podendo
reagir de forma autônoma a eventos do mundo físico influenciando ou modificando os processos
em que se encontram inseridos.
De acordo com [1] a arquitetura de IoT compreende usualmente três camadas: i)
Camada de sensoriamento, nesta camada estão incluídos os diversos objetos de IoT responsáveis
por aferir e prover informações sobre o ambiente (sensores) e por realizar tarefas (atuadores)
que em resposta aos dados sensoriados, irão alterar o ambiente em que estão inseridos; ii)
Camada de rede, responsável por gerenciar a comunicação entre os dispositivos e aplicações; e
iii) Camada de aplicações, nesta camada estão incluídas as aplicações que fazem uso dos dados
e/ou funcionalidades providas pelos dispositivos da camada se sensoriamento.
Embora a aplicação do paradigma de IoT seja interessante em diversos senários, conectar
tais dispositivos envolve superar uma série de desafios em diferentes camadas. Alguns desses
desafios segundo [2] são: i) padronização de dados, atualmente os dispositivos de IoT não
seguem nenhum tipo de padronização quanto à oferta de dados, eles fornecem seus dados em
diferentes formatos ou unidades, o que dificulta o consumo de suas informações; ii) Modelos
para virtualização de dispositivos, para facilitar o consumo e uso das funcionalidade providas
pelos dispositivos de IoT é necessário estabelecer interfaces que exponham os dados e
funcionalidades dos dispositivos através da internet, preferencialmente utilizando padrões Web
abertos; iii) Suporte ao desenvolvimento de aplicações, desenvolver aplicações que sejam úteis
ás pessoas e que façam uso de dispositivos de IoT não é uma tarefa trivial, isso envolve lidar
com questões relacionadas a rede, heterogeneidade de dados e dispositivos, descoberta de
dispositivos, etc. Algumas das soluções promissoras para estes desafios dizem respeito ao uso
de middlewares e/ou plataformas que facilitem o compartilhamento e consumo de dados
provenientes dos dispositivos de IoT, oferecendo diferentes níveis de abstrações para os
provedores de informações e desenvolvedores de aplicações, de modo que estes não precisem
lidar com os desafios inerentes às diferentes camadas para realizarem as suas tarefas.
Nesta seção serão apresentados os Habilitadores Genéricos oferecidos pelo Fiware para
suporte ao desenvolvimento de aplicações no domínio de IoT, a saber: Backend Device
Management, Protocol Adapter, IoT Template Handler, Backend Configuration Manager (IoT
Discovery), IoT Broker e Gateway Data Handling . Os Habilitadores Genéricos a serem
apresentados atuam em diversas camadas de IoT, oferecendo um conjunto de funcionalidades e
abstrações que facilitam o compartilhamento/consumo de dados e desenvolvimento de
aplicações, contribuindo assim para mitigar os desafios supracitados. Detalhes sobre as
funcionalidades oferecidas por cada um desses Habilitadores Genéricos e exemplos de uso serão
apresentados nas seções a seguir.
7.1 Backend Configuration Manager (IoT Discovery)
O Backend Configuration Manager (IoT Discovery) é um Habilitador Genérico
responsável por gerenciar e facilitar a descoberta e disponibilidade de agentes de IoT. Assim
como outros Habilitadores Genéricos oferecidos pelo FIWARE, o IoT Discovery utiliza o
conceito de entidades de contexto(ver seção 2.1), que são entidades genéricas descritas por meio
de atributos e metadados. Em IoT, entidades de contexto podem ser usadas para modelar
recursos e as variáveis associadas a eles, por exemplo, uma entidade de contexto pode ser usada
para representar um sensor de presença, um GPS, uma sala, uma pessoa, etc.
O IoT Discovery permite registrar, atualizar e realizar buscas acerca de entidades de
contexto. Ele também permite realizar subscrições que permitem a seus usuários serem
notificados em tempo real sobre a disponibilidade dessas entidades. Assim sendo, o IoT
Discovery atua como um ponto de acesso às entidades de contexto e seus atributos, facilitando
a descoberta de recursos e informações disponíveis para serem utilizadas por aplicativos.
7.1.1 Descrição
Em IoT a disponibilidade de dispositivos pode ser afetada por diversos fatores como:
mobilidade dos dispositivos, acesso à rede, disponibilidade energética, etc. Isso faz com que
dispositivos e serviços tornem-se indisponíveis em determinados momentos. De forma similar,
novos dispositivos podem surgir no ambiente tornando-se disponíveis para serem utilizados por
aplicações. Devido a essa dinamicidade do ambiente de IoT é extremamente importante o papel
dos serviços de descoberta de recursos.
Usando o serviço de descoberta oferecido pelo IoT Discovery o usuário pode registrar,
realizar descobertas e subscrições acerca de:
● informações sobre dispositivos de IoT e as variáveis que eles mensuram;
● informações sobre “coisas” e seus atributos;
● informações sobre associações entre entidades, quando os atributos de uma entidade
podem ser mensurados a partir de atributos de outras entidades.
Além das funcionalidades acima citadas, a especificação do IoT Discovery prevê ainda
outros tipos de mecanismos de descoberta, que são:
● Geográfico: as entidades podem ser descobertas com base em sua localização;
● Probabilístico: as entidades podem são descobertas por meio de semelhanças em sua
sintaxe;
● Semântico: As entidades são descobertas por meio de descrições semânticas baseadas
em ontologias.
A descoberta geográfica baseia-se nas coordenadas de latitude e longitude. Para que
possa ser realizada, os recursos a serem descobertos devem possuir um atributo de contexto no
qual sua localização geográfica (latitude e longitude) são especificadas. No entanto a sintaxe e
semântica desse atributo e de seus metadados ainda não foi definida, desse modo a descoberta
por localização geográfica ainda não está disponível na implementação atual do IoT Discovery.
A descoberta probabilística usa técnicas de aprendizado de máquina para analisar as
descrições dos recursos de IoT, que podem estar descritas em formato RDF (Resource
description Framework) ou não. As descrições são processadas por um algoritmo probabilístico
não supervisionado de aprendizado de máquina, que extrai “conceitos textuais” das descrições
de recursos e, com base na frequência desses conceitos, automaticamente agrupa as descrições
em clusters. A Figura 78 ilustra o processo de agrupamento das descrições de IoT.
Figura 78. Agrupamento das descrições de IoT [5]
Esta abordagem permite descoberta automática, ranqueamento e recomendação de
descrições de recursos de IoT.
Nesta abordagem, a descoberta dos recursos dar-se por meio de queries SPARQL [6]
passadas pelo usuário ao IoT Discovery.
A descoberta semântica tem por finalidade habilitar interoperabilidade semântica entre
os produtores de informações e os consumidores. Na abordagem tradicional onde os recursos
são representados por meio de entidades de contexto e descobertos através das operações
disponibilizadas através da interface NGSI-9 as buscas são baseadas nos nomes, atributos e tipos
das entidades de contexto. Na abordagem tradicional nomes, atributos e tipos são criados de
forma arbitraria pelos provedores de informações, deste modo é possível que conceitos
diferentes sejam utilizados para descrever um mesmo recurso. Na abordagem semântica, os
recursos de IoT são representados por meio de descrições semânticas compartilhadas, que
permitem que os diversos provedores de informações e usuários possam descrever seus recursos
e suas consultas utilizando os mesmo conceitos.
Nesta abordagem i) os provedores de informações precisam registrar seus recursos
utilizando descrições semânticas para IoT; ii) consumidores de informações usam queries
SPARQL para descobrirem recursos, e; iii) as descrições semânticas dos recursos de IoT devem
ser especificadas através da ontologia de referência IoT-A 16.
16
IoT-A - http://www.iot-a.eu/public
7.1.2 Exemplos de Uso
Nesta seção serão apresentados exemplos de uso do IoT Discovery utilizando para tal as
operações definidas na interface NGSI-9, os exemplos mostram como registrar, realizar
subscrições, cancelar subscrições e realizar descobertas acerca de entidades de contexto.
Registro de Entidades
O exemplo mostrado na figura 79 ilustra o registro de uma entidade de contexto com
identificador Laboratory of computers, do tipo Laboratory e contendo dois atributos:
temperature, do tipofloat, e; pressure, do tipo integer. Para registrar a disponibilidade de um
recurso no IoT Discovery, além de especificar o identificador, tipo e atributos da entidade é
necessário especificar a URI pela qual o recurso está acessível, no exemplo a seguir o recuso é
acessível através do endereço: http://imd.com/Rooms. Também deve ser especificado, através
do atributo duration, o tempo no qual a entidade de contexto estará disponível, no exemplo a
seguir foi especificado o valor “P1M” (permanence 1 month), indicando que a entidade estará
disponível para descoberta por um período de um mês a partir da data em que foi registrada.
A entidade foi registrada por meio da operação registerContext, disponível através da
interface NGSI-9.
Figura 79. Registro de uma entidade de contexto no IoT Discovery
Descoberta de Entidades
O exemplo da Figura 80 mostra a descoberta de entidades por meio da operação
discoverContextAvailabilitydisponibilizada através da interface NGSI-9. No exemplo foi
realizada uma pesquisa por entidades do tipo Laboratory e com identificador Laboratory of
computers. Como resposta, o IoT discovery retornou os dados referentes à entidade que satisfaz
os critérios da busca. Caso o usuário deseje pesquisar por todas as entidades do tipo Labratory,
bastaria, nesta consulta, substituir o id da entidade pesquisada por .* (pontos seguido de
asterisco), desta forma os dados referentes a todas as entidades do tipo Laboratory seriam
retornados.
Figura 80. Descoberta de entidades de contexto
Subscrição
O exemplo da Figura 81 ilustra a realização de uma subscrição realizada por meio da
operação subscriteContextAvaliability disponibilizada através da interface NGSI-9. Como pode
ser visto no corpo da mensagem HTTP foi realizada uma subscrição afim de ser notificado sobre
a disponibilidade do atributo temperature de entidades do tipoLaboratory, o valor “.*” passado
como identificador da entidade de interesse indica que o usuário não está interessado no em
atributos de uma entidade específica, mas sim em qualquer entidade do tipo Laboratory, não
importando qual seja o seu identificador. Caso o usuário deseje se subscrever em uma entidade
especifica deve-se passar o identificador da entidade de interesse. No corpo da mensagem HTTP
também deve ser passado o endereço para o qual as notificações acerca da disponibilidade das
entidades
devem
ser
enviadas,
no
exemplo
foi
passado
o
endereço:
http://imd.com/Admninistration. Também deve ser passado através do atributo duration a
duração da subscrição, no exemplo foi passado o valor P1M, indicando que a subscrição tem
validade de 1 mês contado a partir da data em que foi realizada, após esse período o usuário terá
que fazer uma nova subscrição caso deseje continuar a receber notificações.
Como resposta à requisição o IoT Discovery retornou o identificador da
subscrição (SubscriptionId).
Figura 81. Subscrição acerca da disponibilidade de uma entidade de contexto
Alteração de uma subscrição
A alteração de uma subscrição pode ser realizada por meio da operação
updateContextAvailabilitySubscriptiondisponibilizada através da da interface NGSI-9. No
exemplo a seguir (Figura 82) a subscrição realizada no exemplo anterior foi alterada, de forma
a incluir o atributo pressure na lista de atributos de interesse de entidades do tipo Laboratory.
Para alterar uma subscrição além de especificar a duração, entidade e atributos de interesse é
necessário enviar também o identificador (subscriptionId) da subscrição a ser alterada, assim
como mostra a figura 82.
Figura 82. Alteração de uma subscrição
Cancelamento de uma Subscrição
Uma
subscrição
pode
ser
cancelada
por
meio
da
operação
unsubscribeContextAvailability quando o usuário não está mais interessado em receber
notificações acerca da disponibilidade de uma entidade de contexto. A Figura 83 ilustra a
realização uma requisição de cancelamento de subscrição realizada ao IoT Discovery. Para
cancelar uma subscrição o usuário precisa informar apenas o identificador (SubscriptionId) da
subscrição.
Figura 83. Cancelamento de uma subscrição
7.2 IoT Broker
O IoT Broker atua como um mediador entre os dispositivos de IoT e os usuários que
consomem suas informações. Ele permite que os usuários façam consultas por dados
provenientes de dispositivos de IoT sem que os mesmos precisem necessariamente conhecer
quais dispositivos são capazes de provê os dados requisitados, a forma de acesso a esses
dispositivos ou onde eles estão localizados. Todo o processo de aquisição dos dados é abstraído
pelo IoT Broker. Além de consultas síncronas a dados provenientes de dispositivos, o IoT
Broker permite realizar consultas assíncronas a dados de IoT (representados por meio de
entidades de contexto), de modo que o usuário possa ser notificado sempre que um atributo de
uma ou mais entidades de contexto for alterado, quando um atributo ultrapassar determinado
valor, quando o mesmo estiver dentro de determinado intervalo, etc.
7.2.1 Descrição
Diversos autores [1] [2] [7] afirmam que um dos grandes desafios inerentes ao
desenvolvimento de aplicações que utilizam dados provenientes de dispositivos de IoT é a
enorme heterogeneidade de dispositivos e protocolos. Atualmente existem diversos dispositivos
capazes de se comunicar e prover dados via rede, no entanto, muitos desses dispositivos ainda
provém seus dados de forma não padronizada, utilizando protocolos e formatos de dados
diferentes entre si. Desse modo, para utilizar dados provenientes de diversos tipos de
dispositivos os desenvolvedores de aplicações necessitam, em muitos casos, lidar com diferentes
protocolos de comunicação e diferentes formatos de dados, isso acaba por dificultar o
desenvolvimento de aplicações.
Com o uso do IoT Broker os desenvolvedores não precisam lidar com diferentes
protocolos e formatos para representação de dados, ao invés disso eles utilizam a interface
NGSI-10 para consultar e consumir informações provenientes de dispositivos de IoT, e o IoT
Broker, por sua vez, recupera dos dispositivos as informações solicitadas e as retorna de forma
padronizada. Desse modo os desenvolvedores não necessitam conhecer os protocolos, API’s e
modelo de dados dos diversos dispositivos, precisam apenas conhecer a interface NGSI-10 para
solicitar os dados desejados ao IoT Broker, que se encarregará de recuperá-los.
O IoT Broker é stateless, ou seja, ele não possui estado, não guarda nenhuma informação
acerca da disponibilidade de dispositivos de IoT ou dos dados aferidos pelos mesmos. Sempre
que o usuário requisita um dado ele é consultado diretamente nos dispositivos e retornado pelo
IoT Broker. O fato de não guardar estado torna o IoT Broker bastante escalável, diversas
instancias do IoT Broker podem ser criadas e deletadas em resposta ao aumento ou diminuição
do número de usuários, sem que haja prejuízo de perca de dados pelos mesmos.
Tipicamente, o IoT Broker interage com o IoT Discovery (ver seção 6.1) afim de
recuperar informações sobre a disponibilidade dos dispositivos de IoT. Essas informações são
recuperadas via interface NGSI-9 quando um usuário solicita alguma informação. Quando isso
acontece, o IoT Broker realiza uma requisição ao IoT Discovery afim de identificar quais
dispositivos são capazes de provê os dados solicitados pelo usuário, uma vez que os dispositivos
são identificados as informações são recuperadas e retornadas ao interessado. A Figura 84
ilustra as operações, definidas na especificação NGSI, utilizadas para troca e consumo de dados
entre o IoT Broker, usuários, dispositivos de IoT e IoT Discovery.
Figura 84. Operações utilizadas para troca e consumo de dados entre o IoT
Broker, usuários, dispositivos de IoT e IoT Discovery
Os usuários podem enviar consultas síncronas ao IoT Broker usando a operação
QueryContext, consultas assíncronas podem ser realizadas por meio da operação
SubscribeContext. Caso o usuário realize uma subscrição ele deve implementar a operação
NotifyContext, afim de receber as notificações enviadas a ele pelo IoT Broker, conforme
determina a especificação NGSI-10.
Os provedores de informações devem utilizar a operação RegisterContext, definida na
especificação NGSI-9 para registrar a sua disponibilidade junto ao IoT Discovery. Uma vez
registrada a sua disponibilidade, o dispositivo poderá receber solicitações de dados do IoT
Broker, para isso o dispositivo deve implementar a operação QueryContext, definida na
especificação NGSI-10. O dispositivo também deve implementar a operação SubscribeContext,
afim de que quando solicitado pelo usuário o IoT Broker se subscreva para receber dados dos
dispositivos e os repasse ao usuário quando os dados forem alterados.
A Figura 85 ilustra uma consulta síncrona a dados realizada por um usuário ao IoT
Broker, a consulta envolve 4 passos.
Figura 85. Consulta síncrona a dados no IoT Broker
1. O usuário solicita um dado ao IoT Broker (operação QueryContext);
2. O IoT Broker verifica junto ao IoT Discovery quais dispositivos são capazes de
provê a informação solicitada (operação DiscoveryContextavaliability);
3. Uma vez que o IoT Broker conhece os dispostivos que possuem os dados
requisitados ele requisita os dados aos dispositivos (Operação QueryContext);
4. O IoT Broker agrupa os dados e os retorna ao usuário.
7.2.2 Exemplos de Uso
A seguir serão apresentados o exemplo de uso do IoT Broker em conjunto com o IoT
Discovery. O exemplo consiste em fazer o registro de uma entidade de contextono IoT discovery
e em seguida requisitar os dados da entidade através de IoT Broker. Conforme ilustra a figura
acima essa ação envolve 4 passos: i) requisição dos dados por parte do usuário; ii) descoberta
da entidade de contexto que oferece os dados; iii) recuperação dos dados junto ao provedor de
dados; e iv) retorno das informações recuperadas ao usuário.
Registro de uma entidade de contexto
O primeiro passo para a condução do nosso exemplo de uso é registrar uma entidade de
contexto no IoT Discovery, conforme mostra a figura a seguir (Figura 86). De acordo com a
especificação NGSI-9 o registro de uma entidade acontece por meio da operação
RegisterContext, que utiliza o método HTTP POST. No corpo da requisição devem ser incluídos
o identificador e tipo da entidade de contexto junto com seus atributos e o endereço por meio
do qual os dados (valores dos atributos) referentes à entidade cadastrada podem ser adquiridos.
No exemplo a seguir foi criada uma entidade do tipo Room, com identificador Room1 e
contendo os seguintes atributos de contexto: temperature, do tipo float; e pressure, do tipo
integer.
Os
valores
dos
atributos
podem
ser
acessados
através
do
endereço:
http://192.168.0.6:8080/NGSI10/Room.
Figura 86. Criação da entidade Room1 no IoT Discovery
Consulta a uma entidade de contexto
Uma vez registrada a sua disponibilidade no IoT Discovery os valores dos atributos da
entidade Room1 podem ser acessados através do IoT Broker. Uma das formas de se ter acesso
aos
valores
desses
atributos
é
através
da
seguinte
requisição,
GET
http://iot-
broker/ngsi10/contextEntities/Room1 , definida nas operações de conveniência alternativas à
NGSI-10.
Uma vez que essa requisição é realizada o IoT Broker recupera junto ao IoT
Discovery
os
dados
referentes
a
entidade
Room1
através
da
operação
DiscoveryContextavaliability, definida na especificação NGSI-9. A Figura 87 ilustra a
requisição enviada pelo IoT Broker ao IoT Discovery afim de recuperar as informações
referentes a entidade Room1.
Figura 87. Requisição enviada pelo IoT Broker ao IoT Dicovery
O IoT Dicovery recebe a solicitação e como resposta ao IoT Broker retorna as seguintes
informações, ilustradas na Figura 88, referentes a entidade Room1.
Figura 88. Resposta do IoT Discovery à requisição do IoT Broker
Após receber as respostas do IoT Discovery o IoT Broker toma conhecimento acerca
dos atributos oferecidos pela entidade Room1 e dos endereços por meio do qual eles podem ser
acessados. Tendo conhecimento dessas informações o IoT Broker realiza a requisição
QueryContext, definida na especificação NGSI-10, ao provedor dos dados referentes a entidade
Room1. A Figura 89 ilustra essa requisição.
Figura 89. Requisição enviada do IoT Broker ao provedor de dados referente à entidade
Room1
Apos recuperar os dados provenientes dos dispositivos de IoT o IoT Broker retorna os dados
ao usuário.
7.3 Backend Device Management IDAS:
7.3.1 Descrição:
Este componente realiza a conexão entre dispositivos ao FIWARE-based ecosystems,
traduz protocolos específicos de IoT para o protocolo de informação NGSI, que é o modelo de
troca padrão de dados do FIWARE.
Ele faz com que seus dispositivos sejam representados em uma plataforma FIWARE
como entidades NGSI em um ContextBroker. isto é, você pode consultar por trocas no status
dos parâmetros do dispositivo, consultando ou comentando aos atributos da entidade
correspondente da NGSI presentes no ContextBroker.
Além disso, ele possibilita acionar comandos para sua atuação nos dispositivos apenas
atualizando atributos de comandos específicos nas entidades NGSI representadas no Comand
Broker. Desta maneira, as interações dos desenvolvedores com seus dispositivos são suportadas
pelo Context Booker, proporcionando uma API homogênea e uma interface como para todos os
outros dados non-IoT em um FIWARE ecosystem.
Figura 90 - Como a IDAS funciona.
7.3.2 Objetivos:
Com o IDAS o usuário dispõe de diversos procedimentos, como:
● Codificar todos os IoT Agents com node.js, e com isso, processos de configuração e
novos desenvolvimentos vai ser simplificados e otimizados.
● Os IoT Agents não vão ser classificados por tecnologias de transporte como: (HTTP,
MQTT, COAP), mas distribuídos em diferentes repositórios GIT baseados no nível
superior de protocolo e que oferecem diferentes possibilidades de transporte. Isso
significa que tem um Agente da IoT Ultralight2.0 com diferentes opções de transporte
que poderá ser aprimorado no futuro. você selecionará e usará estes agentes únicos da
IoT (Ultralight 2.0) que suportam os protocolos de semântica e transporte que seus
dispositivos já usam atualmente.
● O IoT Agent Manager, que irá monitorar e administrar as instancias dos IoT Agents.
você só precisará desse componente para cenários complexos com múltiplas instâncias
de IoT Agents.
● Usar a Biblioteca para IoT Agents no node.js que é provida para estes integradores IoT
dispostos a implementar um novo protocolo padrão específico de IoT neles mesmos.
● Implementar Um componente IoT Edge Manager. inicialmente ele vai guardar e
aguentar as “comunicações” e/ou topologia e detalhes como as entidades NGSI. essa
implementação teste está sendo desenvolvida sendo parte do FIGWAY tool. No futuro
ele poderá endereçar mais funções além do armazenamento relacionado aos IoT
networks, IoT Gatewys e IoT end-nodes operations.
7.3.3 Exemplos de uso:
Abaixo temos um exemplo de uso do IDAS, implementado em Python e tem como
objetivo, criar entidades NGSI no Orion, IoT Broker, entre outros ContextBrokers.
Para obter o exemplo, é necessário fazer o download do arquivo, através do site abaixo,
seguindo as instruções passadas no slide do segundo link:
Python IDAS:
https://github.com/telefonicaid/fiware-figway/tree/master/python-IDAS4
Instruções de instalação e uso do Python IDAS:
http://pt.slideshare.net/FI-WARE/fiware-iotidasintroul20v2?qid=15d9416e-69a1-441b-a5faea6857725b52&v=&b=&from_search=1
Ao acessar as instruções dirija-se ao slide número 13, onde começam as instruções de
instalação. A figura 91 mostra como proceder no primeiro momento:
Figura 91 - Como configurar o Python IDAS.
Seguindo os Slides, teremos as configurações de entidade e de dispositivo, após
configurarmos todos eles, basta seguir as demais instruções que o IDAS já estará instalado na
sua máquina e traduzindo as informações do dispositivo, transformando-as em NGSI para que
ContextBrokers, como o IoT Broker, consigam utilizá-los, passando as informações para os
usuários interessados.
Obs.: a pasta que deverá ser usada é a pasta python, presente no documento para
download no link do github acima.
7.3.4 - Problemas encontrados:
No exemplo de uso acima, tudo funciona corretamente, porém, quando o usuário tenta
se comunicar com a entidade, esta não esta fornecendo os dados que possui (ainda não foi
resolvido, porem esta em andamento).
7.3.5 - Pendências:
Receber dados da entidade NGSI. (em andamento)
7.3.6 - Próximos passos:
Assim que o problema for resolvido, o proximo passo será unir o IDAS com o IoT
Broker e com o Cepheus.
7.4 Protocol Adapter (MR CoAP):
7.4.1 Descrição:
Este protocolo é capaz de suportar um dos protocolos IoT Devices que é aceito pelo FIWARE, ele é capaz de traduzir um protocolo especifico, chamado CoAP over 6LowPAN, para
ligações FI-WARE internas únicas. o Protocol Adapter foi designado para trabalhar com a
plataforma IBM Moterunner e comunicações via 6LoWPAN, e usar CoAP como aplicação de
protocolo em camadas.
7.4.2 Objetivos:
O usuário do MRCoAP poderá plugar dispositivos usando o protocolo CoAP over
6LowPAN dentro da Arquitetura IoT do FI-WARE. o Protocol Adapter foi designado para usar
o sistema operacional IBM Mote Runner, que proporciona uma maquina virtual para executar
códigos independentes de dispositivos, e proporciona também um suporte para programação
relativa por meio de delegates e suporta Java e C# como linguagens de programação de alto
nível.
7.4.3 - Problemas encontrados:
Devido à baixa documentação do MRCoAP, não foram encontrados nenhum exemplo
de uso deste até o momento.
7.4.4 - Pendências:
Encontrar exemplo(s) de uso para o MRCoAP.
7.4.5 - Próximos passos:
Assim que for encontrado algum(uns) exemplo(s) de uso do MRCoAP, o próximo passo
é buscar uma forma de interligá-lo ao IDAS, que estará sendo usado em conjuntos com as GEs:
IoTBroker(Jorge) e Cepheus(Claudio).
7.5 Gateway Data Handling - EspR4fastData
O Gateway Data Handling (EspR4FastData) é um habilitador genérico (GE) responsável
por promover o primeiro nível de inteligencia para o ambiente de IoT do FIWARE,
transformando dados em eventos a partir de geras inteligentes porém simples. Ou seja, o
Gateway Data Handling é o GE responsável por coletar dados brutos ou estruturados (NGSI)
oriundos de diferentes fontes (dispositivos, brokers, etc.), transformá-los (filtrando, combinando
e agregando) em eventos de maior valor agregado, e enviá-los para os seus interessados a partir
de regras predefinidas.
A partir da versão 4.4.1 o Gateway Data Handling passou a se chamar IoT Data Edge
Consolidation (IDEC)17 para atender a necessidade de se ter um nome mais genérico (usando
a convenção dos outros FIWARE Generic Enablers). Dessa forma, o projeto EspR4FastData
também sofreu mudança na nomenclatura, e passou a se chamar Cepheus 18.
7.5.1 Descrição
Em um ambiente de IoT, onde se tem um numero muito grande de dispositivos,
aplicações e rede de sensores, gerando um numero ainda maior de dados em tempo real. É
necessário que essa quantidade gigantesca de dados brutos seja processada, gerando
informações de maior valor agregado (informações relevantes para outras aplicações). O IoT
Data Edge Consolidation (IDEC) é o GE do FIWARE responsável atender essa necessidade de
processar os dados brutos gerados em tempo real, coletando (recebendo), filtrando, fundindo,
agregando e consolidando os dados a partir de fontes heterogêneos, e os enviando para seus
respectivos interessados.
O Cepheus é o projeto que faz parte do FIWARE no âmbito do projeto de IoT Data Edge
Consolidation. O Cepheus é composto por dois componentes principais componentes:
● Cepheus-CEP: Um processador de eventos (Complex Event Processing - CEP);
● Cepheus-Broker: Um broker NGSI simplificado;
Os componentes do Cepheus juntamente com o IoT Agent, proveem um Gateway NGSI
para os diversos dispositivos no ambiente de IoT do FIWARE.
17
18
http://catalogue.fiware.org/enablers/iot-data-edge-consolidation-ge-cepheus
https://github.com/Orange-OpenSource/fiware-cepheus
O Gateway NGSI tem como principal objetivo interligar os diversos dispositivos NGSI
e/ou Non-NGSI aos seus interessados. Ou seja, é componente responsável por receber, processar
e encaminhar os dados aos seus interessados. Onde os dispositivos Non-NGSI são os
dispositivos que utilizam de outros tipos de protocolos, como por exemplo, HTTP, MQTT,
COAP, etc.
O IoT Agent portanto, é componente responsável por traduzir os dados de diferentes
tipos de protocolos para o formato NSGI. Ou seja, o IoT Agente funciona como uma espécia de
proxy, traduzindo os dados de diferentes tipos (HTTP, MQTT, COAP, etc) para o formato
padrão NGSI. A figura 92 apresenta a arquitetura completa do Gateway NSGI.
Figura 92. Arquitetura do Gateway NSGI
Fonte: http://fiware-cepheus.readthedocs.io/en/latest/index.html
7.5.1.1 Cepheus-CEP
O Cepheus-CEP é um processador de eventos complexos (Complex Event Processing CEP) que tem como objetivo processar eventos básicos e gerar eventos com maior nível de
agregação. Ou seja, é um componente responsável por processar os dados em tempo real,
filtrando, agregando e combinando dados de diferentes fontes em tempo real.
O Cepheus-CEP utiliza a biblioteca java de código aberto Esper19 para realizar o
processamento dos eventos. Transformando os dados brutos em eventos de maior valor
agregado a partir de regras simples, porém inteligentes. As regras de processamento do CEP são
descritas em EPL (Event Processing Language). A linguagem EPL é uma extensão da
linguagem SQL, otimizada especificamente para lidar com dados de eventos de alta frequência.
A linguagem EPL permite realizar agrupamento, agregação, classificação, filtragem, fusão,
cisão e duplicação de fluxos de eventos, definindo hora e duração dos eventos, combinando
padrão dos eventos, e assim por diante. Como por exemplo, a expressão a seguir, permite
calcular a media de temperatura dos últimos 30 segundos da sala 1:
select avg(temperatura) from Room1.win:time(30 sec)
O Cepheus-CEP possui duas APIs HTTP. A primeira delas é a API Admin REST para
prover acesso as configurações do CEP, e a segunda é uma API NGSI para prover a
comunicação com os outros componentes NGSI (Provedores de contexto e Brokes de contexto).
7.5.1.1.1 API Admin
A API Admin é definida como uma simples API REST para definir as configurações do
CEP. O caminho para acesso as configurações do CEP é definido através de '/v1/admin/config',
e aceita verbos HTTP: GET, POST e DELETE. A tabela 18 a seguir apresenta a especificação
dos métodos.
Operação
Verbo HTTP
Descrição
GET
Consulta a configuração salva.
POST
Salva uma nova configuração.
DELETE
Remove a configuração atual.
/v1/admin/config
Tabela 18. Operações para configuração do CEP
O formato padrão para o arquivo de configuração é JSON. O conteúdo do arquivo é
definido conforme ilustrado na figura 93.
19
http://www.espertech.com/esper/
Figura 93. Exemplo de um arquivo de configuração do CEP
Os atributos do arquivo de configuração são especificados da seguinte maneira:
● HOST: Define o endereço e porta onde o Cepheus-CEP pode ser encontrado. É usado
para a subscrição do provedores de contexto;
● IN: Define a lista de eventos de entrada (entidades de contexto) que serão providas pelos
provedores de contexto;
○ ID: Define o identificador da entidade de contexto;
○ TYPE: Define o tipo da entidade de contexto;
○ ISPATTERN: Define se o ID deverá ser considerado durante uma consulta;
○ ATTRIBUTES: Define a lista de atributos;
■ NAME: Define o nome do atributo;
■ TYPE: Define o tipo do atributo (O tipo pode ser: string, double, float,
int e bool);
■ METADATA: Define a lista de metadados;
● NAME: Define o nome do metadado;
● TYPE: Define o tipo do metadado;
● JSONPATH: Define uma expressão para acessar os valores
dentro de objetos complexos;
■ JSONPATH: Define uma expressão para acessar os valores dentro de
objetos complexos;
○ PROVIDERS: Define a lista de URLs dos provedores de contexto da entidade;
● OUT: Define a lista de entidade de contexto que serão geradas nos eventos de saia;
○ ID: Define o identificador da entidade de contexto;
○ TYPE: Define o tipo da entidade de contexto;
○ ISPATTERN: Define se o ID deverá ser considerado durante uma consulta;
○ ATTRIBUTES: Define a lista de atributos;
■ NAME: Define o nome do atributo;
■ TYPE: Define o tipo do atributo;
■ METADATA: Define a lista de metadados;
● NAME: Define o nome do metadado;
● TYPE: Define o tipo do metadado;
○ BROKERS: Define a lista de brokers que serão notificados;
■ URL: Define a URL do broker;
■ SERVICENAME: Define o valor do atributo Fiware-Service passado
no cabeçalho do HTTP;
■ SERVICEPATH: Define o valor do atributo Fiware-ServicePath
passado no cabeçalho do HTTP;
■ AUTHTOKEN: Define o valor do atributo X-Auth-Token passado no
cabeçalho do HTTP (Requerido pelo PEP Proxy);
● STATEMENTS: Define a lista de regras (Esper EPL statements) que serão
processadas;
7.5.1.1.2 API NGSI
A API NGSI suporta apenas um subconjunto das operações padrão do NGSI necessárias
para permitir a comunicação com outros componentes NGSI.
Apesar do arquivo de configuração possuir o campo 'providers' para que sejam
informados os provedores de contexto que iram interagir com o Cepheus-CEP, o CEP permite
que informações de contexto possam ser enviadas diretamente (sem que seja especificada no
arquivo de configuração). A figura X mostra as duas formas possíveis para interação com o
Cepheus-CEP. A figura 94a apresenta a forma de publicação direta através de uma requisição
'updateContext' para o CEP. Já a figura 94b apresenta a forma de publicação na qual os
provedores de contexto são especificados pelo arquivo de configuração, dos quais o CEP irá se
inscrever nos mesmos através de requisições 'subsbriceContext', e dessa forma, poderá ser
atualizado (notificado) através de requisições 'notifyContext' sempre que houver atualização dos
provedores de contexto.
Figura 94. Formas de comunicação com CEP
Fonte: http://fiware-cepheus.readthedocs.io/en/latest/cep/configuration/index.html
As operações permitidas pela API NGSI são definidas conforme a tabela 19 a seguir:
Operação
Verbo HTTP
Descrição
/v1/updateContext
POST
Atualiza a informação de contexto.
/v1/subscribeContext
POST
Solicita inscrição para um informação de
contexto.
/v1/notifyContext
POST
Notifica sobre uma mudança de contexto.
Tabela 19. Operação disponíveis pela API NGSI do CEP
7.5.1.2 Cepheus-Broker
O Cepheus-Broker é o componente responsável por intermediar a comunicação
entre os provedores de contexto, como IoT Agent ou dispositivos NGSI (atuadores e sensores),
e os brokers remoto como, por exemplo, o Orion. E assim, podendo interceptar informações de
contexto que poderão ser enviadas para outros componentes NGSI, como o Cepheus-CEP, que
se inscreve no Cepheus-Broker para receber informações de contexto que serão processadas
pelo mesmo.
O Cepheus-Broker consiste de um broker reduzido que suporta apenas dois tipos
de operações:
● Requisições de Encaminhamento (Forwarding): Encaminhado as requisições entre
os dispositivos e os brokers;
● Requisições de Publicação e Inscrição (Pub/Sub): Inscrevendo-se e publicando
informações de contexto que serão processadas pelo CEP;
A figura 95 apresenta o fluxo de requisições que passam pelo Cepheus-Broker.
Figura 95. Requisições trocadas com Cepheus-Broker
Fonte: http://fiware-cepheus.readthedocs.io/en/latest/broker/index.html
7.5.1.2.1 Forwarding
A operação de encaminhamento consiste no repasse de uma requisição feita por
um dispositivos NSGI ou por um dispositivos não NGSI (por meio de um IoT Agente) ao
Cepheus-Broker, para os brokers remotos configurados. Ou seja, uma requisição feita por um
dispositivo ao Cepheus-Broker é encaminhada pelo mesmo para os brokers remotos
configurados de acordo com o arquivo de configuração. O encaminhamento das requisições
também ocorre no sentido contrário, quando os brokers remotos enviam atualizações ou
consultas ao Cepheus-Broker, o mesmo encaminha a requisição para os dispositivos
responsáveis.
A figura 96 apresenta o fluxo de requisições realizados entre os dispositivos, o
Cepheus-Broker e os brokers remotos. Onde no primeiro momento, uma requisição de registro
é feita pelo dispositivo ao Cepheus-Broker, que por sua vez encaminha essa requisição para o
Orion. No segundo momento, o Orion envia uma requisição para atualização no CepheusBroker, e o mesmo encaminha a requisição para o dispositivo. O mesmo corre para a requisição
de consulta. Num quarto momento, o dispositivo envia uma requisição para atualização de uma
informação de contexto, e o Cepheus-Broker encaminha para o Orion novamente.
Figura 96. Fluxo de Requisições de Encaminhamento do Cepheus-Broker
7.5.1.2.2 Pub/Sub
As operações de subscrição (inscrição) e publicação (notificação) entre o CepheusBroker e os demais componentes NGSI ocorre conforme o exemplo da figura 97. O endereço
do Cepheus-Broker é passado para o Cepheus-CEP através do campo 'provider' do arquivo de
configuração. O que faz com que o Cepheus-CEP realize uma requisição de subscrição ao
Cepheus-Broker. Uma vez inscrito, o Cepheus-CEP será notificado sempre que houver um
atualização no Cepheus-Broker. A figura 97 apresenta o fluxo de requisições trocadas entre os
dispositivos, o Cepheus-Broker, o Cepheus-CEP e o broker remoto (Orion). Onde, no primeiro
momento o Cepheus-CEP realiza um requisição subscrição ao Cepheus-Broker. No segundo
momento, o dispositivo envia uma requisição para atualização de um informação de contexto
para o Cepheus-Broker, que por sua vez encaminha a requisição para o Orion conforme
especificado na seção anterior. E em seguida, notifica o Cepheus-CEP, que por sua vez irá
processar as informações de contexto gerando nova informações de maior valor agregado.
Figura 97. Fluxo de Requisições de Inscrição e Notificação do Cepheus-Broker
7.5.2 Exemplo de Uso
A seguir será apresentado um exemplo de uma aplicação (regra) que calcula a
média da temperatura de todas as salas por cada andar de um prédio.
Para realização do exemplo, foi necessário a configuração de duas maquina
virtuais linux (CentOS 7) com 512mb. Uma maquina foi instalado o Orion Context Broker e
configurado o IP 192.168.0.1. E a outra maquina foi instalado o Cepheus-CEP e CepheusBroker, e configurado o IP 192.168.0.2.
A entidade de contexto que irá representar um sala é dada conforme ilustra a
figura 98, onde cada sala possui um identificador único e dois atributos, um atributo de
temperatura para informar a temperatura atual da sala e um atributo andar para especificar o
andar que a determinada sala se encontra:
Figura 98. JSON para criação e atualização das entidades salas
O arquivo de configuração do CEP foi definidor conforme ilustrado na figura 99,
onde o atributo host indica o endereço da maquina que está instalado o Cepheus-CEP. O atributo
in especifica as entidades de contexto que serão verificadas. Para esse caso, foi definido o valor
"Room" para o atributo type, o "Room.*" para o atributo id e o valor true para atributo isPattern,
dessa forma, permitindo selecionar todos as entidades de contexto do tipo Room e que possuem
o id com prefixo Room. Os atributos temperature e floor foram definidos conforme a entidade
de contexto definida previamente. O atributo providers, foi definido com o endereço da maquina
onde se encontra o Cepheus-Broker. Nesse caso, como o Cepheus-CEP e o Cepheus-Broker
estão instalados na mesma máquina, o campohost e providers podem ser ambos definidos como
localhost. Porém é preciso ainda especificar a porta de cada um dos serviços, onde a porta 8080
é definida para o CEP e a porta 8081 é definida para o Broker.
Como entidade de saída (resultado), o atributo out apresenta a entidade de contexto que
irá representar a temperatura média de cada andar do prédio. Para isso, a entidade de saída foi
definida com o atributo id igual a "FloorX", o type igual a "Floor" e os atributos da entidades
foram definidos com o name igual a temperature e o type igual a double. O atributo brokers foi
definido como o endereço da maquina onde está instalado o Orion Context Broker
(192.168.0.1). E, por fim, o campo statements foi definido conforme a regra para calcular a cada
10 segundos, a media da temperatura das salas nos últimos 10 minutos, para cada andar do
prédio.
Figura 99. JSON para configuração do CEP
A tabela 20 apresenta a ordem das requisições que foram executadas no exemplo:
Operação
Verbo HTTP
Endereço
Conteúdo/Descrição
/v1/updateContext
POST
192.168.0.2
Figura 99 (JSON para criação e atualização
das entidades salas). Para criação das
entidade de contexto no Cepheus-Broker.
/v1/admin/config
POST
192.168.0.2
Figura 99 (JSON para configuração do
CEP). Para configuração do Cepheus-CEP.
/v1/updateContext
POST
192.168.0.2
Idêntico ao da Figura 99, alterando apenas
os valores e o atributo updateAction para
UPDATE. Foram executadas varias
requisições iguais a esta alterando apenas
os valores de cada uma das entidades para
gerar os dados que serão processados.
/v1/queryContext
GET
192.168.0.1
{
"entities": [
{
"type": "Floor",
"isPattern": "true",
"id": "Floor.*"
}
]
}
Para consulta o resultado do processamento
enviado do Cepheus para o Orion Context
Broker.
Tabela 20. Tabela de sequencias de operações
8 Security
8.1 Objetivos
Sabemos que é altamente desejado que aplicativos, softwares ou informações sejam
acessados somente por aqueles autorizados para tal. Para isso, existem vários mecanismos que
lidam com diferentes aspectos de segurança da informação, tais como autenticação, políticas de
segurança, entre outros. A plataforma FIWARE foi projetada para considerar estes aspectos em
uma abordagem secure by design, onde atributos de segurança da plataforma em si, e das
aplicações que executem sobre ela, são considerados através de uma arquitetura de segurança
que engloba questões relacionadas a gestão de identidades, controle de acesso e monitoramento
de eventos de segurança. Isso é conseguido com um conjunto de Generic Enablers (GEs) que
podem ser integrados com outros GEs da plataforma.
Neste contexto, este capítulo apresenta um estudo sobre o Capítulo Técnico de
Segurança (Security) da plataforma FIWARE que oferece GEs responsáveis pela autenticação,
autorização e confiabilidade de informações. Para uma maior compreensão do estudo deste
capítulo, iniciaremos com uma introdução de alguns conceitos básicos da literatura (Seção 7.2).
Para demonstrar a aplicação desses conceitos, desenvolvemos uma aplicação de exemplo (Seção
7.3) que será explorada ao longo deste estudo. Em seguida, apresentamos uma visão geral da
arquitetura do Capítulo Técnico de Segurança, identificando seus componentes principais
(Seção 7.4), que serão explorados nas seções subsequentes. Mais especificamente, abordaremos
os seguintes GEs: Identity Management GE (Seção 7.5), Authorization PDP GE e PEP Proxy
GE (Seção 7.6), Cyber Security GE (Seção 7.7) e Trustworthy Factory GE (Seção 7.8).
Durante este estudo, maior ênfase foi dada aos GEs relacionados a controle de acesso,
mais especificamente Identity Management GE, Authorization PDP GE e PEP Proxy GE,
adotando um ponto de vista de desenvolvedor de aplicações que atuariam como clientes desses
GEs. É importante mencionar também que este estudo considera a versão 4 da plataforma
FIWARE (R4).
8.2 Conceitos Básicos e Definições
Esta seção apresenta alguns termos e definições utilizados na descrição do Capítulo
Técnico de Segurança da plataforma FIWARE, que é construído em torno de três áreas
temáticas: Gerenciamento de Identidade e Acesso (Identity and Access Management);
Segurança Cibernética (CyberSecurity); e Confiança e Gestão de Confiabilidade (Trust and
Trustworthiness Management). Desse modo, a terminologia será apresentada em torno desses
tópicos.
8.2.1 Gerenciamento de Identidade e Acesso (Identity and Access
Management)
● Identidade Digital (DigitalIdentity): Uma identidade digital é uma representação
digital de um conjunto de afirmações sobre um sujeito ou entidade. Essas afirmações,
também chamadas de atributos, podem ter sido feitas pelo próprio sujeito ou por
terceiros. Deve ser observado que para qualquer sujeito normalmente haverá múltiplas
identidades digitais.
● Autenticação (Authentication): O ato de verificar a identidade de uma entidade ou
sujeito. A autenticação permite confirmar que um determinado sujeito ou entidade é
quem ele afirma ser. Ao utilizar o termo entidade, permitimos que não somente humanos
possam ser autenticados, mas também entidades genéricas, como um sistema ou um
equipamento.
● Credencial (Credential): Um conjunto de dados apresentados como evidência de uma
identidade e/ou direitos reivindicados. Normalmente utilizado para autenticação (por
exemplo, senha).
● Provedor de Identidades (Identity Provider - IdP): Um provedor de identidade é uma
entidade que atua como um serviço de autenticação para usuários finais, e como fonte
de dados de autenticação para provedores de serviços. Pode ser entendido como uma
base de usuários.
● Participante confiável (Relying party - RP):Uma entidade que confia em uma
representação de identidade ou afirmação (por exemplo, token de segurança) emitido por
uma outra entidade (ex: IdP) dentro de um contexto de requisição.
● Single Sign-On (SSO): Da perspectiva de uma entidade cliente (usuário ou aplicação),
o SSO é a capacidade de autenticar-se com alguma entidade do sistema (um IdP), e ter
a autenticação respeitada por outras entidades, denominados provedores de serviços (um
RP). Em outras palavras, é a capacidade de um cliente se autenticar somente um vez e
ter acesso a múltiplos serviços.
● Gestão de Identidades de Federadas (Federated Identity Management - FIM):
Capacidades de gerenciamento de identidade que permitem que os usuários de um
ambiente (organização, ou domínio de segurança, também conhecido como realm) possa
acessar os serviços de outro, sem a necessidade de se registrar na base de usuários do
domínio que provê o serviço. Uma federação é uma parceria confiável entre diferentes
domínios em uma relação produtor-consumidor, onde todos os usuários de um domínio
tem acesso a todos os serviços oferecidos pelos outros domínios.
● Autorização (Authorization): Termo utilizado alternadamente para dois significados
próximos, mas distintos, dependendo do contexto:
○ Gestão de autorização (Authorization Management): Processo de atribuição
de permissões para entidades, também conhecida como user-permission
assignment. No FIWARE, isso é feito através do IDM GE, de forma que o termo
é utilizado com esse significado.
○ Aplicação de autorização (Authorization Enforcement): Processo de
determinar se uma entidade está autorizada a fazer algo quando do pedido de
acesso, seguido pela concessão ou não do acesso. No contexto da plataforma
FIWARE, esse processo é realizado por dois componentes: o Authorization PDP
GE determina se o acesso deve ser permitido, e com base nesta decisão, o PEP
Proxy GE concede ou nega o acesso solicitado à entidade requerente.
8.2.2 Segurança Cibernética (CyberSecurity)
● CyberSecurity: O processo de proteger informação através da prevenção, detecção e
resposta a ataques.
● Risco (Risk): Uma medida de quanto uma entidade é ameaçada por um evento ou
circunstancia potencial. Risco normalmente é calculado em função do impacto adverso
caso o evento ocorra, e a probabilidade/possibilidade do evento ocorrer.
● Gerenciamento e Correlação de Eventos de Segurança (SIEM - Security Information
and Event Managent): Sistema que permite a coleta, armazenamento e análise de
eventos de segurança gerados por diversos componentes de um rede, incluindo
aplicativos de segurança (como firewall e proxies), sistemas de detecção de intrusão, e
eventos de controle de acesso.
8.2.3 Confiança e Gestão de Confiabilidade (Trust and Trustworthiness
Management)
● Confiança na aplicação - Trust in an application (software): O estado de credibilidade
que a parte interessada em utilizar o sistema credita neste. Por exemplo, se um usuário
não confia em um determinado sistema, a tendência será não utilizá-lo.
● Confiabilidade (Trustworthiness): Uma propriedade objetivo do aplicativo, com base
na existência (ou inexistência) de contramedidas adequadas que reduzam a
probabilidade de resultados inaceitáveis. Em outras palavras, as partes interessadas
(stakeholder) apresentam objetivos de confiabilidade (trustworthiness objective) para o
aplicativo.
● Atributo de confiablidade (Trustworthiness attribute): Um atributo derivado de
atributos de qualidade de software, exemplo de tal atributo: segurança, capacidade de
reutilização, confiabilidade, escalabilidade, confidencialidade, entre outros, para o
contexto de confiança que podem ser quantificados por métodos de medição aplicados
para a aplicação.
● Objetivo de confiablidade (Trustworthiness objective): A definição de uma pontuação
mínima a ser atingida para um atributo de confiabilidade.
Perfil de confiabilidade (Trustworthiness profile): A lista de objetivos de confiabilidade
fornecida por qualquer das partes interessadas para o desenvolvedor do aplicativo.
8.3 Aplicação de Exemplo
Nesta seção apresentamos a aplicação desenvolvida como estudo de caso para a
apresentação dos GEs de segurança da plataforma FIWARE. A aplicação implementada é
formada por dois componentes: um componente back-end e um componente front-end. Sua
arquitetura é apresentada na Figura 100.
Figura 100 - Processo de chamada de operações no Web Service.
O componente back-end consiste em um Web service REST que apresenta dois serviços,
contendo em cada um dos dois métodos. Cada um desses serviços recebe uma chamada HTTP
GET e retorna como resultado da chamada um JSON contendo informações relevantes e
resultados da chamada.
Abaixo são apresentados os métodos que compõe os dois serviços implementados:
● Serviço 01:
○ helloWorld: ao ser chamado, o método retorna um JSON contendo uma
string simples de “Hello, World!”.
○ greeting: ao ser chamado, com parâmetro referente ao nome a ser exibido,
o método retorna um JSON contendo uma string formada pela junção das
strings “Hello, ” e o texto do parâmetro recebido.
● Serviço 02:
○ listNames: ao ser chamado o método retorna em um JSON uma lista
contendo os nomes que atualmente estão armazenados pelo servidor.
○ addName: ao ser chamado com um parâmetro, o parâmetro recebido é
salvo na lista de nomes armazenados pelo servidor. Como resultado da
sua chamada, nenhum JSON é retornado por esse método.
O componente de front-end corresponde a uma aplicação Web para interação com o
usuário que realiza chamadas aos serviços definidos. Essa aplicação foi desenvolvida em JSF
(Java Server Faces) e nela foi criada uma interface que permite ao usuário escolher qual das
chamadas realizar, com campos para definição das informações necessárias para as chamadas
do serviço, além de permitir também a exibição dos resultados das chamadas para o usuário.
A Figura 101 apresenta exemplos da interface Web, onde pode ser visualizado o
processo ocorrido durante uma chamada a uma das operações dos serviços pela aplicação JSF,
bem como a interface exibida ao usuário.
Figura 101 - Interface da aplicação JSF.
Nessa interface, uma vez inseridos os dados e selecionada a operação a ser realizada, é
realizada uma chamada REST ao serviço correspondente no webservice com os dados
necessários à sua execução. Após a chamada ter sido processada pelo servidor, e tendo sido
retornado o JSON resultante, a interface recebe o JSON e o processa, atualizando a interface
exibida ao usuário com os dados resultantes da chamada.
Esta aplicação será utilizada ao longo deste capítulo para exemplificar a utilização dos
diferentes GEs disponibilizados pelo Capítulo Técnico de Segurança da plataforma FIWARE.
Desse modo, a versão inicial da aplicação não utiliza nenhum dos mecanismos de segurança do
FIWARE, e sua evolução será detalhada ao longo do texto.
8.4 Visão arquitetural do Capítulo Técnico
Esta seção apresenta uma visão geral da arquitetura do Capítulo Técnico de Segurança
da plataforma FIWARE, identificando os diferentes GEs que implementam os recursos de
segurança da plataforma, tais como como gerenciamento de identidade, controle de acesso ou
monitoramento de segurança. A arquitetura de segurança do FIWARE, exibida na Figura 102 é
composta por cinco GEs que juntas fornecem um conjunto abrangente de serviços para
aplicações com o intuito de cumprir com os requisitos mais importantes de segurança, como
autenticação, autorização e confiabilidade. São estes Identity Management GE, Authorization
PDP GE, PEP Proxy GE, Cyber Security GE e Trustworthy Factory GE.
Figura 102 - Visão geral da arquitetura de segurança [3].
O Identity Management GE (IdM) é responsável pelo gerenciamento de identidades de
usuários, organizações e aplicações, assim como de suas respectivas credenciais, e da
autenticação dessas entidades. Este GE considera requisitos para a gestão de identidades de
“coisas” (IoT), e atende às especificações para o gerenciamento de identidades sobre diferentes
domínios. Ele também oferece uma API REST para o gerenciamento de identidades em
ambientes multi-tenant, permitindo ainda a gestão de autorização, com suporte a definição de
papéis e permissões específicas de uma organização ou de uma aplicação. Desenvolvedores
interagem com este componente para registrarem suas aplicações no IdM, e para gerenciar a
segurança de suas aplicações (credenciais, papéis e políticas de autorização). Usuário finais
usam o IdM GE para se registrarem, e gerenciar seus respectivos perfis e suas organizações,
enquanto que todas as entidades clientes de aplicações utilizam o IdM para fins de autenticação.
A implementação de referência deste GE é o Keyrock.
O Authorization PDP GE (PDP) é o componente responsável por gerenciar políticas de
autorização na plataforma FIWARE. Este componente utiliza a linguagem XACML para
representação de políticas, implementando a especificação XACML Core v3.0. As políticas
definidas pelos desenvolvedores por meio do IdM são gerenciadas pelo PDP, que é responsável
também por avaliar requisições de acesso, encaminhadas pelo PEP, para permitir ou negar o
acesso a serviços. A implementação de referência deste GE é o AuthZForce.
O PEP Proxy GE (PEP) atua como ponto de aplicação de políticas de segurança na forma
de um proxy-reverso HTTP, com o objetivo de proteger serviços REST. Este componente
intercepta as requisições para o serviço, interage com o IdM para autenticar a requisição e o
token da entidade cliente anexado à requisição, e em seguida interage com o PDP que autoriza
ou não o acesso ao serviço. Além de validar o token e a requisição por meio do IdM, o PEP
também recupera informações sobre o token, e seu usuário, deste mesmo componente. Para
tomar uma decisão de acesso, o PDP leva em consideração a política de segurança definida,
informações acerca da requisição do cliente, e informações acerca do token enviado (tais como
atributos do cliente obtidos do IdM). O PEP aplica a decisão do PDP, e em caso positivo,
encaminha a requisição ao serviço, e a resposta do serviço ao cliente. A implementação de
referência para este GE é o Wilma. A plataforma FIWARE suporta a utilização de outros PEPs,
como por exemplo PEPs que protejam serviços não-REST ou serviços que utilizem outros
protocolos além de HTTP.
O CyberSecurity GE é uma ferramenta para a detecção, análise e resposta a incidentes
de segurança. Este componente apresenta mecanismos que permitem calcular e quantificar
vetores de ataque, realizando uma análise de vulnerabilidades e riscos, e sugerir possíveis
remediações a partir de um catalogo de contra-medidas. O CyberSecurity GE depende de um
SIEM (não oferecido pela plataforma FIWARE) para a coleta de eventos e informações de
segurança. A implementação de referência para este GE está classificada como deprecated no
catálogo de GEs do FIWARE.
Além dos componentes apresentados na Figura 102, o Capítulo Técnico de Segurança
também contém um GE para questões de confiabilidade. O Trustworthy Factory GE oferece um
ambiente para o desenvolvimento de aplicações confiáveis, incluindo ferramentas (baseada em
análise estática e dinâmica de código-fonte) para a produção de evidências que objetivos de
confiabilidade foram alcançados, e uma plataforma de certificação de código fonte, permitindo
a assinatura digital de código entre outras funcionalidades. A implementação de referência para
este GE está classificada como deprecated no catálogo de GEs do FIWARE.
8.5 Descrição do Identity and Access Management GE
A gestão de identidades engloba alguns aspectos envolvidos com o acesso de usuários a
redes, serviços e aplicações, incluindo autenticação segura e privada de usuários para
dispositivos, redes e serviços, gestão de perfil de usuário e de autorização, Single Sign-On (SSO)
para domínios de serviço e federação de identidade para aplicações. Um sistema de gestão de
identidades visa realizar a tarefa complexa de lidar com as diversas tecnologias nos domínios
de segurança acima mencionados, e fornecer tecnologias de fácil utilização, colocando o usuário
final e suas necessidades diretamente no centro da arquitetura, enquanto protege sua
privacidade.
8.5.1 Visão Geral da Arquitetura do KeyRock
A Figura 103 apresenta a arquitetura de alto nível do KeyRock, a implementação de
referência do Identity Management GE. Este componente oferece dois portais de interação para
usuários. O Portal de Usuário Final (End User Portal) é utilizado pelos usuários finais para
registrarem sua conta pessoal no KeyRock, informando o endereço de e-mail, senha, etc. Isto é
implementado como uma interface de usuário Web. Os usuários finais podem modificar ou
configurar os seus dados da conta pessoal. Por outro lado, o Portal de Desenvolvedor de
Aplicações (Application Developer Portal) é utilizado pelos desenvolvedores para registar e
gerenciar as suas aplicações, especialmente as aplicações do cliente, incluindo as credenciais de
aplicação, permitindo o aplicativo autenticar-se no IdM ou ainda definir os papéis de acessos
específicos da aplicação.
Figura 103 - Identity Management GE - Arquitetura em alto-nível [13].
Além das interfaces de usuários, o KeyRock oferece um conjunto de APIs, sendo três
APIs para o gerenciamento de diversos aspectos, e uma API para fins de autenticação e
autorização.
● API de Gerenciamento de Usuário (User Management API): Fornece uma REST API
para criar contas de usuário, recuperar e modificar atributos de usuário, excluir contas
de usuário. A interface deve ser compatível com SCIM 2.0 REST API.
● API de Gerenciamento da Aplicação (Application Management API): Utiliza o REST
API para o gerenciamento de aplicações, tais como registro da aplicação, recuperar e
modificar dados da aplicação, por exemplo: credenciais e excluir a aplicação.
● API de Gerenciamento de Acesso (Access Management API): Utiliza também o REST
API para gerenciar papéis globalmente ou para uma aplicação específica, definindo as
permissões de papéis e atribuindo os papéis para os usuários. As permissões de papéis
formam uma política de autorização que pode ser empurrada para a Authorization PDP
GE através da sua PAP API.
● API de Autenticação e Autorização (Authentication & Authorization): As APIs de
autenticação e autorização do KeyRock seguem as especificações dos padrões SAML
2.020 e OAuth221, suportando cenário de SSO e de Federação de Identidades. A seguir
é possível visualizar uma descrição de algumas operações suportadas pelo conjunto de
APIs fornecida pela KeyRock:
Operação
Verbo
HTTP
Descrição
/users/:id
GET
Acessa uma usuário passando o id
como parâmetro
/user?access_token=12342134234023
437
GET
Acessa um usuário cadastrado
informando o access_token
/applications.json?actor_id=1&access
_token=2YotnFZFEjr1zCsicMWpAA
GET
Acessa aplicações de uma entidade
(usuário ou organização) passando
como parâmetro o actor_id e o
access_token
20
21
http://saml.xml.org/saml-specifications
http://oauth.net/2/
/v2/ServiceProviderConfigs
GET
Acessa as configurações do provedor de
serviços
Para uma visualização completa das operações pode-se consultar a documentação do
KeyRock no Apiary 22.
8.5.2 Descrição do Exemplo da Aplicação
A fim de exemplificar a realização da autenticação da aplicação anteriormente descrita
com o OAuth2, são descritas abaixo as modificações realizadas sobre a aplicação original,
inicialmente sem autenticação, a fim de ilustrar o seu uso. Para tais modificações, foi utilizada
a implementação do OAuth2 da Apache, o Apache Oltu 23.
8.5.2.1 Autenticando um usuário no KeyRock
A primeira modificação realizada na aplicação foi referente a inserção de elementos de
segurança que permitissem o acesso de informações de um usuário somente após a realização
do processo de autenticação, conforme ilustrado na Figura 104.
Figura 104 - Modelo de arquitetura para requisição do Web App [19]
No processo exibido na Figura 104, ao acessar uma funcionalidade da aplicação web que
requer autenticação, o usuário é inicialmente redirecionado à tela de login no IdM. Uma vez
feito o login com as informações de acesso cadastradas nesse, é solicitada a confirmação de
22
23
http://docs.keyrock.apiary.io/
https://oltu.apache.org/
autorização do usuário para a aplicação na qual ele deseja se autenticar. Uma vez que tenha
autorizado a aplicação, um access-code é gerado e retornado à aplicação. Em posse do access
code, a aplicação realiza uma nova requisição ao IdM para obter o access token, que o retorna,
fazendo com que possa ser inserido pela aplicação em chamadas posteriores.
O primeiro passo realizado a fim de implementar esse processo na aplicação foi realizar
o registrado da aplicação no IdM. Para realizar esse processo, ao acessar o endereço do IdM e
realizar o login é possível ver na tela inicial exibida uma listagem de aplicações cadastradas e a
opção para cadastro de uma nova aplicação. Para cadastrar uma nova aplicação deve-se clicar
em "Register" no canto superior direito da janela de aplicações.
Figura 105 - Opção de registro de uma nova aplicação.
Será exibida então uma nova página onde devem ser inseridas as informações básicas da
aplicação a ser registrada. Nessas informações estão o nome, descrição e URL da aplicação
criada, assim como a Callback URL, sendo essa última a URL para qual o IdM realiza o
redirecionamento quando o access code é gerado, retornando-o em um parâmetro HTTP do
redirecionamento realizado a essa URL.
Figura 106 - Informações para registro da aplicação.
Após preencher essas informações, é possível selecionar uma imagem de exibição para
a aplicação e, se necessário, cortá-la para melhor se adequar ao tamanho de exibição.
Figura 107 - Seleção da imagem de exibição da aplicação.
Por fim, podem ser modificados na página exibida os papéis e permissões associados a
aplicação sendo criada.
Figura 108 - Configuração de papéis e permissões da aplicação.
Depois desses passos, ao clicar em "Finish" a aplicação é criada e suas informações
(definidas pelo usuário e códigos gerados para acesso do IdM pela aplicação) podem ser
acessadas ao clicar na aplicação na tela inicial do IdM ou na sessão de aplicações.
Figura 109 - Informações da aplicação cadastrada.
Tendo sido registrada a aplicação, em seguida, no projeto da aplicação JSF responsável
pela interação com o usuário e comunicação com o webservice REST, foram implementados
alguns passos para o seu correto funcionamento.
O primeiro deles foi referente à inserção de um botão para realização da autenticação do
usuário na interface, assim como um para a chamada à uma nova operação que acessa e exibe
essa informações de um usuário autenticado.
Figura 110 - Interface JSF para autenticação e requisição de informações do usuário
Ao selecionar o botão de autenticar, um redirecionamento é realizado ao IdM para a
obtenção de um access_code. O trecho de código responsável por fazer esse redirecionamento
é exibido abaixo.
Figura 111 - Código para obtenção do access_code.
Nele é realizada uma requisição HTTP GET ao endereço do IdM, no caminho
/oauth2/authorize, com os parâmetros response_type, client_id e redirect_uri definidos. O
parâmetro response_type deve ter o seu valor definido como code e o valor dos demais
parâmetros podem ser obtidos nas informações da aplicação registrada no IdM (como mostrado
anteriormente). O access_code gerado será retornado como parâmetro GET em uma chamada
ao endereço definido no redirect_uri.
Para tratar esse redirecionamento que contém o access code gerado, foi necessário
definir um novo servlet na aplicação, sendo esse responsável pelo tratamento das chamadas
realizadas ao endereço /auth e obter, a partir do access_code gerado, o access_token que será
utilizado pela aplicação em cada requisição uma vez que essa esteja autenticada. O trecho de
código responsável pela obtenção do access_token no servlet definido é exibido a seguir.
Figura 112 - Código para obtenção do access_token.
No código inicialmente é obtido o access_code enviado como parâmetro pela etapa
anterior. Tendo sido obtido o código gerado, uma nova requisição HTTP POST é feita ao IdM,
no caminho /oauth2/token, passando como parâmetros o endereço do IdM para geração do token
(token_location), grant_type, access_code e redirect_uri. Além disso, também são definidos os
cabeçalhos Authorization (com o valor formado por "Basic " + base64(client_id:client_secret))
e Content-Type.
Tendo sido definida a requisição com seus parâmetros e cabeçalhos, uma conexão é
aberta com o IdM e realizada a requisição, obtendo o JSON de resposta que contém o
access_token. O token obtido é então acessado e armazenado na sessão da aplicação, juntamente
com o tempo para expiração do token, para que possam ser usados em requisições de operações
posteriores. Por fim, é realizado um redirecionamento à página inicial da aplicação.
Uma vez obtido o access_token, requisições podem ser realizadas ao IdM enviando
como parâmetro para confirmar a autenticação o token recebido, como a solicitação das
informações de um determinado usuário.
Figura 113 - Código para obtenção do access_token.
O trecho de código apresentado na Figura 113 é responsável pela obtenção de
informações do usuário autenticado após a obtenção do access token. Em posse do token, uma
requisição HTTP GET é realizada ao endereço /user, passando o access token obtido como
parâmetro da requisição, sendo retornado um JSON contendo as informações de acesso e
permissões do usuário autenticado com o token enviado.
8.5.2.2 Envio de Requisições a um Fiware GE
O processo para autenticação da aplicação e interação com um GE Fiware pode ser
ilustrado pela imagem abaixo, sendo a primeira etapa (do primeiro redirecionamento até a
obtenção do access_token) igual à descrita na seção anterior. Em seguida o token obtido é
enviado ao GE Fiware e inserido em chamadas posteriores realizadas por essa ao IdM, a fim de
confirmar a sua autenticação.
Figura 114 - Modelo de arquitetura para requisição do Web App com Serviço de GE FIWARE
[20].
O Repository RI é um GE Fiware, referente a uma implementação do Repostiory GE
(uma descrição mais detalhada sobre esse GE pode ser encontrado a partir da Seção 2.2), e que
foi escolhido como GE a ser utilizado na implementação da aplicação que segue o processo
apresentado.
Para possibilitar a interação entre a aplicação de teste e o Repository, inicialmente foi
necessário ajustar configurações de autenticação do Repository (conforme o guia 24 oficial de
instalação e administração), correspondentes aos parâmetros de acesso ao IdM (domínio do
IdM, chave e senha cadastrados, bem como o endereço de callback) localizados no arquivo
Repository-RI.properties, presente no diretório /etc/default/. O resultado
da configuração de exemplo pode ser visualizado na Figura 115, exibida a seguir:
Figura 115 - Configurações dos parâmetros de IdM do Repository GE.
24
https://repository-ri.readthedocs.io/en/latest/installation-guide.html#repository-configuration
Também foi necessário realizar mudanças no arquivo web.xml, presente no diretório
WEB-INF, localizado na pasta da aplicação FiwareRepository implantada no servidor
(localizado no diretório /usr/local/tomcat/webapps/FiwareRepository/WEB-INF no nosso
ambiente). Nesse arquivo é necessário indicar a habilitação da autenticação com o uso do
OAuth2. Para isso é necessário substituir o trecho noSecurity.xml inicialmente presente no
documento por securityOAuth2.xml, resultando na modificação do arquivo para o trecho de
código exibido abaixo na Figura 116.
Figura 116 - Configuração de ativação da segurança com OAuth2 no arquivo web.xml.
Após esses passos, tendo configurado corretamente a comunicação entre o IdM e o
repositório, foram realizados testes de autenticação no Repository com o serviço de IdM ativo.
Porém, embora os passos até a obtenção do access token tenha ocorrido normalmente, tivemos
insucesso no acesso dos recursos disponibilizados no repositório com a utilização da
autenticação. Uma vez que para a solução desse problema a fim de fazer com que posteriormente
a aplicação interaja com o GE Fiware, ainda são necessárias configurações adicionais no GE e
comunicação da aplicação com o repositório uma vez que o processo de autenticação esteja
inteiramente funcional.
8.6 Descrição dos Componentes de Autorização (PEP Proxy GE e Authorization PDP GE)
Nesta seção, trabalharemos apenas com as GEs responsáveis pela parte de autorização,
são PEP Proxy GE e Authorization PDP GE, já que estes habilitadores genéricos estão altamente
interligados em suas funcionalidades, por se preocuparem com o tratamento das solicitações e
permissões de acesso.
8.6.1. Conceitos Básicos sobre Controle de Acesso
A seguir, conceituaremos alguns termos fundamentais de controle de acesso, que
servirão como base para este estudo do capítulo de segurança do FIWARE de forma em geral,
e mais especificamente para as GEs desta seção.
Há uma relação de controle de acesso com outros serviços de segurança, como
autenticação, auditoria e administração.
● Auditoria (Auditing): Monitora e mantém um registro de atividades relevantes no
sistema.
● Administração (Administration): Políticas de autorizações são utilizadas para o
controle de acesso dos usuários pelos administradores de segurança.
O AuthZForce fornece um modelo de controle de acesso baseado em atributo (ABAC Attribute-Based Access Control), uma evolução do modelo de acesso baseado em papéis (RBAC
- Role-Based Access Control). Em seguida, conceituamos os elementos principais desses
modelos.
● Papel (Role):Estabelece permissões baseadas nos papéis funcionais na empresa,
atribuindo usuários para um papel ou conjunto de papéis. Pode representar tarefas ,
responsabilidades e qualificações associadas com uma empresa.
● Permissão (Permission): É uma aprovação de um modo particular de acesso para um
ou mais objetos no sistema.
● Sujeito (Subject):O sujeito é um ator representando um usuário de um recurso. O sujeito
pode ser uma pessoa, um programa, um dispositivo ou outro elemento que solicite acesso
a um recurso.
● Recurso (Resource): Entidade a ser protegida contra uso não autorizado. Ex.:
dispositivos, arquivos, registros, tabelas, processos, programas, redes ou domínios que
contenham ou recebam informações.
● Ação (Action): a execução de uma função para a solicitação de um sujeito sobre um
recurso. Ex.: ler, escrever, editar, apagar, copiar, executar e modificar.
● Atributos (Attributes): Características dos sujeito, recurso ou condições ambiente.
Atributos contêm informações dadas por um par “nome-valor”.
● Atributos do sujeito (Subject attributes): Os atributos de um sujeito corresponde à suas
propriedades, como por exemplo o ID de usuário, organização, papel, nível de acesso.
● Atributos de recurso (Resource attributes): O recurso é uma entidade passiva que o
sujeito solicita agir sobre este. Este recurso pode ser, por exemplo: dados, pessoa,
dispositivo ou aplicação. Atributos de recurso são ID de recurso, URL, classificação, por
exemplo.
● Atributos de ação (Action attributes): Uma ação representa a operação que um sujeito
solicita executar sobre um recurso. Ações podem ser criar, ler, escrever, deletar.
Atributos de ação são ID de ação, parâmetro A, parâmetro B e entre outros.
● Atributos de ambiente (Environment attributes): Contexto operacional ou situacional
em que ocorrem as solicitações de acesso. Ex.: a hora atual, dia da semana, a localização
de um usuário, a carga da CPU do PEP / PDP, o nível de ameaça atual e temperatura.
● Política (Policy): representação de regras ou relações que torna possível determinar se
um acesso solicitado deve ser permitido, tendo em conta os valores dos atributos do
sujeito, do recurso e das condições ambiente possivelmente.
● Controle de Acesso Baseado em Papel (Role Based Access Control - RBAC): Método
de controle de acesso baseado em papéis que restringe o acesso ao recurso somente aos
sujeitos autorizados, através da análise dos papéis que o sujeito exerce na organização
ou empresa. Permissões são atribuídas a papíes, enquanto que papéis são atribuídos a
sujeitos. As atribuições de papéis podem ser realizadas para um sujeito ou para grupos.
● Controle de Acesso Baseado em Atributo (Attribute Based Access Control - ABAC):
Método de controle de acesso onde o sujeito solicita a execução de operações em
recursos, que são concedido ou negado com base em atributos atribuídos ao sujeito,
atributos atribuídos ao recurso, condições ambientais e um conjunto de políticas que são
especificados no termos desses atributos e condições. O modelo ABAC define um
conjunto de componentes funcionais, que serão apresentados em seguida.
● Ponto de Decisão Política (Policy Decision Point - PDP): Calcula decisões de acesso
através da avaliação das políticas.
● Ponto de Aplicação de Política (Policy Enforcement Point - PEP): Aplica as decisões
de política em resposta a um pedido de um sujeito solicitante de acesso a um recurso
protegido. As decisões de controle de acesso são feitas pelo PDP.
● Ponto de Informação de Política (Policy Information Point - PIP): Serve como fonte
de recuperação de atributos ou os dados necessários para a avaliação das políticas para
fornecer a informação necessária para o PDP para tomar as decisões.
● Política de Administração de Ponto (Policy Administration Point - PAP) : fornece
uma interface de usuário para criar, gerenciar, testar e depurar as políticas.
Figura 117 - Exemplo de Pontos Funcionais de Autorização [14]
A relação entre os diversos componentes do modelo ABAC é apresentado na Figura 117,
onde temos um sujeito (subject) que solicita acesso a um recurso protegido (object). Para saber
se o sujeito terá acesso ou não, passa-se por várias etapas: primeiro, passa pelo PEP que
encaminhará uma solicitação com as informações do sujeito ao PDP, este calculará a decisão
de acesso, analisando as políticas aplicáveis. Para isso, o PDP comunica-se com o PIP para
recuperar os atributos e dados importantes para a avaliação das políticas, que são armazenadas
em um repositório. O PAP, permite a um administrdor gerenciar as políticas do repositório. A
partir disso, o PDP manda uma resposta ao PEP permitindo ou negando o acesso ao recurso, e
este, por último, irá autorizar ou negar o acesso ao sujeito como decidido pelo PDP.
8.6.2 Visão Geral da Arquitetura do Authorization PDP GE e PEP Proxy GE
Nesta seção detalhamos a arquitetura das GEs Authorization PDP e PEP Proxy, cuja
implementações de referência são, respectivamente, o AuthZForce e Wilma.
O AuthZForce fornece uma API para obter decisões de autorização com base em
políticas de autorização e os pedidos de autorização de PEPs, esta API segue o estilo de
arquitetura REST e está em conformidade com XACML na versão 3.0. Esta GE fornece duas
características principais:
1. Avaliação de decisão de políticas de autorização: Sua principal característica consiste
em avaliar as decisões de autorização com base em políticas XACML e atributos
relacionados a uma requisição de acesso dada, por exemplo, identidade do solicitante,
recurso solicitado e ação solicitada, seguindo a lógica de avaliação da política definida
no padrão XACML.
2. Administração de políticas de autorização: utilizado para a criação, recuperação,
atualização e remoção de políticas XACML. Este recurso é fornecido para clientes
externos através de uma API REST denominada PAP (Policy Administration Point).
Estas características são implementadas pelo AuthZForce através das APIs PDP e PAP,
baseado nos componentes do modelo ABAC. A API PDP oferece serviços para a tomada de
decisão de autorização computadas por um mecanismo de controle de acesso compatível com
XACML (XACML-compliant), enquanto que a API PAP permite o gerenciamento das políticas
XACML que serão consideradas pelos serviços da API PDP.
A API PDP pode ser utilizada por qualquer implementação de PEP que siga a
especificação XACML para solicitar uma decisão de autorização do mecanismo de avaliação de
políticas. O PEP envia uma solicitação HTTP POST para a API com uma requisição XACML
como corpo da solicitação. Este pedido deve conter todos os atributos de autorização
necessários, referidos na política aplicada, para o PDP para ser capaz de avaliar esta política. O
PDP retorna uma resposta XACML que contém a permissão ou negação da decisão. Ele também
pode retornar Indeterminate se ocorreu um erro durante a avaliação, por exemplo, se algum
atributo estava faltando. É possível também definir a política de forma que o PDP retorne Deny
em vez de Indeterminate se ocorrer um erro deste tipo, para evitar qualquer problema no lado
do PEP.
A API PAP é utilizada pela Identity Management GE para gerenciar as políticas de
acesso, definidas por desenvolvedores para suas aplicações através da interface Web do
KeyRock. Esta API também pode ser utilizada diretamente por qualquer cliente de
administração de política, que por ventura venha ser desenvolvido especificamente para tratar
de aspectos específicos da política de controle de acesso que o portal do IdM GE não atenda.
Por outro lado, o PEP Proxy Wilma, atua como ponto de aplicação de decisões. Este GE
é um componente de back-end, sem interface de front-end, que permite proteger o acesso a
serviços e aplicativos, adicionando filtros de autenticação e autorização para GEs do FIWARE
e para qualquer serviço de back-end. Em suma, o PEP Proxy é capaz de interceptar cada
solicitação de acesso para um serviço e executar o fluxo de trabalho de autenticação e
autorização. No PEP Proxy GE, o recurso protegido é um serviço REST, para o qual a GE
desempenha o papel de proxy reverso e é implantado como tal. Nesta configuração, é
fundamental que qualquer requisição de acesso passe através do PEP Proxy antes de chegar ao
serviço protegido.
Figura 118 - Authorization PDP -Visão geral da arquitetura [15]
A Figura 118 mostra como os componente AuthZForce e Wilma interagem para garantir
controle de acesso. Quando um usuário (Access Requester) deseja acessar um determinado
serviço, ele precisa se autenticar junto ao Identity Management GE, que retorna um token de
acesso (passo 1). Quando o PEP Proxy GE recebe uma requisição (passo 2), ele recupera o token
de autenticação do cabeçalho específico e valida-o com Identity Management GE (passo 3),
obtendo também informações acerca do usuário. Após a autenticação, o PEP Proxy interage
com o Authorization PDP GE para realizar a autorização (passo 4). O PEP Proxy envia ao
Authorization PDP as informações do usuário (ex: Id de usuário, papel, atributos) e da requisição
(ex: recurso a ser acessado, ação). Baseado nas políticas de segurança configuradas o
Authorization PDP toma uma decisão acerca de permitir ou negar o acesso. Caso o acesso seja
permitido, o PEP Proxy GE então encaminha a requisição para o serviço (passo 5).
8.6.3 Representando Políticas de Controle de Acesso usando XACML
Uma vez que o AuthZForce adota a linguagem XACML para a descrição de políticas de
autorização, se faz necessário uma breve introdução sobre esta linguagem. O XACML pode ser
sumarizado em 3 pontos principais:
● Linguagem para definição de politicas (Policy language): XACML (eXtensible
Access Control Markup Language) define um modelo de dados XML para a definição
de políticas de autorização, bem como a lógica a seguir para avaliá-las em um contexto
de solicitação de acesso. O XACML é estruturado principalmente nos seguintes
elemento: Regra, Política (conjunto de regras) e “PolicySet” (conjunto de elementos de
política). A Política, a “PolicySet”, combina várias regras ou políticas e, portanto, várias
decisões juntas de várias maneiras, que são definidas na norma, para tomar a decisão
final.
● Protocolo de Requisição-Resposta (Request-Response protocol): O padrão XACML
também define um modelo de dados XML para a solicitação de decisão de autorização
(XACML Request) que um PEP cria com todos os atributos solicitados de acesso
necessários e envia para o API PDP para avaliação e a resposta resultante (XACML
Response), que contém a decisão final (permitir ou negar).
● Framework Arquitetural (Architecture framework): O padrão XACML também
define uma arquitetura de alto nível, baseado na arquitetura conceitual do modelo
ABAC, incluindo os seguintes componentes principais:
○ Policy Decision Point (PDP): O PDP fornece decisões de autorização com base
em vários atributos dados em tempo de execução por PEPs sobre cada pedido de
acesso de entrada e políticas XACML que definem várias regras para verificar
se esses atributos satisfazem determinadas condições para se obter o acesso.
○ Policy Administration Point (PAP): O PAP fornece uma interface para os
administradores de política de gestão das políticas XACML a ser executada pelo
PDP. O IdM GE também fornece uma forma de interface gráfica para o PAP,
como parte de seu recurso de gerenciamento de acesso.
○ Policy Enforcement Point (PEP): O PEP protege um determinado recurso /
serviço API - tipicamente uma API REST no FIWARE - e reforça a decisão do
PDP se deve permitir ou negar um pedido de acesso especial à API.
Para a próxima seção, necessitaremos da definição do domínio:
● Domínio (Domain): A aplicação permite a criação de múltiplos domínios, estes são
instâncias para utilizar as políticas de autorização de forma independentes, permitindo a
definição de políticas para aplicações distintas, ou para uma organização.
Mais detalhes sobre a linguagem podem ser encontrada em sua especificação 25.
8.6.4. API para Administração de domínio de política
Nesta seção, detalharemos sobre a administração de domínio de política, definindo o
conceito de domínio de política, as operações em domínios e finalizar com testes de domínio.
A aplicação permite múltiplas instâncias/domínios, permitindo que os usuários ou
organizações utilizem as políticas de autorização de forma que estejam complemente isoladas.
Para ser um domínio de política, precisa possuir: vários metadados do domínio - ID atribuído
pela AuthZForce API, ID externo (atribuído para o cliente provisoriamente), descrição,
referência a política (root) ativa no domínio; Um repositório de políticas; E atributo de
configuração de Provedores - os provedores de atributos fornecerem atributos que o PEP Proxy
não fornece diretamente no XACML<Request>. Por exemplo, um provedor de atributo pode
obter valores de atributos a partir de um banco de dados externo.
No domínio de política existe quatro operações principais, são criação, listagem, edição
e remoção de domínios de administração de política. A API permite que os administradores de
aplicação ou de interfaces de administração de AuthZForce crie domínios para os usuários,
remova domínios quando não são mais usados, liste e edite domínios de administração de
política.
Verbo
HTTP
25
Descrição
Caminho
Cabeçalho
https://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html
Corpo
POST
Adiciona
domínio.
-
/domains
-
-
PUT
Atualiza
propriedades
do domínio.
-
/domains/{do
mainId}/prop
erties
-
-
GET
Obtém uma
lista dos
domínios
existentes.
DELETE Deleta
domínio.
Content-Type:
application/xml;
charset=UTF-8
Accept:
application/xml
Content-Type:
Novas
application/xml; propriedades.
charset=UTF-8
Accept:
application/xml;
charset=UTF-8
-
/domains/{do
mainId}/prop
erties
-
Accept:
application/xml;
charset=UTF-8
-
/domains/{do
main_ID}
-
Content-Type:
application/xml;
charset=UTF-8
Accept:
application/xml
-
Tabela 21 - Verbos HTTP para manipulação de domínio.
Exemplo da operação de Criação de Domínio
Para a criação de um domínio, necessita gerar uma solicitação HTTP POST com corpo
da requisição (payload) XMLpara a URL: http://${SERVER_NAME}:${PORT}/authzforcece/domains. Além disso, substitua ${SERVER_NAME} e ${PORT} com o hostname do servidor e a
porta para HTTP. Você pode fazer isso com a ferramenta curl:
$ export domainProperties="<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
\
<domainProperties
\
xmlns="http://authzforce.github.io/rest-api-model/xmlns/authz/5"
externalId="external0">
<description>This
is
my
domain</description>
</domainProperties>"
\
\
\
$
\
\
\
\
curl
--verbose
--request
POST
--header
"Content-Type:
application/xml;charset=UTF-8"
--data
"$domainProperties"
--header
"Accept:
application/xml"
http://${SERVER_NAME}:${PORT}/authzforce-ce/domains
...
>
POST
/authzforce-ce/domains
HTTP/1.1
>
Content-Type:
application/xml;charset=UTF-8
>
Accept:
application/xml
>
Content-Length:
227
>
...
<
HTTP/1.1
200
OK
<
Server:
Authorization
System
<
Date:
Mon,
04
Aug
2014
13:00:12
GMT
<
Content-Type:
application/xml
<
Transfer-Encoding:
chunked
<
<?xml
version="1.0"
encoding="UTF-8"
standalone="yes"?>
<link
xmlns="http://www.w3.org/2005/Atom"
rel="item"
href="h_D23LsDEeWFwqVFFMDLTQ"
title="h_D23LsDEeWFwqVFFMDLTQ"/>
Observe que o valor href na resposta acima dá-lhe o ID de domínio na forma de um
UUID codificado em Base64 atribuído pela API. Você precisa deste ID para qualquer outra
operação no domínio.
Exemplo da operação de Listagem de Domínio
Para listar os domínios existentes deve utiliza o método GET, assim, recupere as
propriedades de domínio atual utilizando os parâmetros como detalhado na Tabela 21.
Por
exemplo,
este
pedido
HTTP
recebe
as
propriedades
do
domínio
iMnxv7sDEeWFwqVFFMDLTQ. Neste caso, não existe qualquer propriedade específica, que é o caso
por padrão, veja a seguir:
GET
HTTP/1.1
Accept: application/xml; charset=UTF-8
/domains/iMnxv7sDEeWFwqVFFMDLTQ/properties
Resposta:
<?xml
version="1.0"
encoding="UTF-8"
standalone="yes"?>
<ns4:domainProperties
xmlns:ns4="http://authzforce.github.io/rest-api-model/xmlns/authz/5" />
Exemplo da operação de Edição/Atualização de Domínio
A API também permite aos usuários atualizar certas propriedades do domínio que lhes
é atribuído:
● Um ID externo (externalId) opcional para o domínio, que os usuários/clientes podem
modificar e mais facilmente usá-lo como referência, em oposição ao ID de domínio
único e de somente leitura designado pela API, uma vez por todas, quando o domínio é
criado;
● A descrição (description) do domínio (opcional).
Atualize as propriedades de domínio com o método PUT.
Por exemplo, este pedido define a propriedade externalId ao my-domain-123:
PUT
/domains/iMnxv7sDEeWFwqVFFMDLTQ/properties
HTTP/1.1
Accept:
application/xml;
Content-Type:
<?xml
application/xml;
version="1.0"
<domainProperties
encoding="UTF-8"
charset=UTF-8
charset=UTF-8
standalone="yes"?>
xmlns="http://authzforce.github.io/rest-api-model/xmlns/authz/5"
externalId="my-domain-123" />
Assim, obtendo a resposta com as novas propriedades.
Como resultado, o ID externo do domínio my-domain-123 aponta para o domínio
iMnxv7sDEeWFwqVFFMDLTQ. Os clientes só podem contar com a externalId sob seu controle para
recuperar o ID de domínio definido pelo API, antes de começar a usar outras operações de API
que exigem o ID de domínio definido pelo API, como citamos anteriormente. Com efeito, os
clientes podem procurar o ID definido pelo API correspondente a um determinado externalId
como se segue:
GET
/domains?externalId=my-domain-123
HTTP/1.1
A resposta gera o ID de domínio correspondente em um link de atributo href:
<?xml
version="1.0"
encoding="UTF-8"
standalone="yes"?>
<ns2:resources
xmlns:ns2="http://authzforce.github.io/rest-api-model/xmlns/authz/5"
xmlns:ns3="http://www.w3.org/2005/Atom">
<ns3:link rel="item" href="iMnxv7sDEeWFwqVFFMDLTQ" title="iMnxv7sDEeWFwqVFFMDLTQ"/>
</ns2:resources>
Exemplo da operação de Remoção de Domínio
Pode ser removido um domínio ao fazer uma solicitação HTTP DELETE com XML
payload para a URL: http://${SERVER_NAME}:${PORT}/authzforce-ce/domains/{domain_ID}.
Por exemplo, com a ferramenta curl:
$
curl
--header
--verbose
"Content-Type:
--request
DELETE
application/xml;charset=UTF-8"
\
\
--header
"Accept:
application/xml"
http://${SERVER_NAME}:${PORT}/authzforce-ce/domains/h_D23LsDEeWFwqVFFMDLTQ
\
8.6.5. API para Administração de Política
Esta etapa, tratará da API que é responsável pela administração de políticas no domínio,
comumente chamada de PAP.
O PAP API é usado por administradores de política para gerenciar o repositório de
políticas a partir da qual o PDP API carrega as políticas aplicadas, APIs estas definidas na seção
8.6.3. Também, importante saber que o PAP suporta múltiplas instâncias na forma de domínios
de administração genérico que são separados uns dos outros. Cada administrador de política,
exceto o super administrador, é de fato um administrador de domínio, na medida em que ele
está autorizado a administrar a política para um ou mais domínios específicos. E assim, os
domínios são normalmente utilizados para auxiliar no isolamento de instâncias, deixando um
domínio por instância.
As operações utilizadas para manipular as políticas de um domínio são chamadas de
Adding, Updating, Getting e Deleting no inglês, mas traduzindo-as ficariam: adicionando,
atualizando, listando e deletando.
Verbo
HTTP
Descrição
POST
Adiciona e
atualiza
políticas a um
domínio.
Caminho
-
/domains/{do
mainId}/pap/
policies
Cabeçalho
-
-
ContentType:
application/x
ml;
charset=UTF8
Accept:
application/x
ml;
charset=UTF8
Corpo
Conjunto de
Políticas
XACML como
definido no
esquema
XACML3.0
GET
Obtém uma ou
mais políticas,
ou, ainda, as
versões de
políticas de um
domínio.
-
-
-
DELETE Deleta
políticas ou
todas as
versões de uma
política de de
um domínio.
-
-
/domains/{do
mainId}/pap/
policies/{poli
cyId}
/domains/{do
mainId}/pap/
policies/{poli
cyId}/{versio
n}
/domains/{do
mainId}/pap/
policies
-
Accept:
application/x
ml;
charset=UTF8
/domains/{do
mainId}/pap/
policies/{poli
cyId}
/domains/{do
mainId}/pap/
policies/{poli
cyId}/{versio
n}
-
Accept:
application/x
ml;
charset=UTF8
Tabela 22 - Tabela de Verbos HTTP para manipulação de políticas de domínio.
Vejamos como proceder em cada caso:
Exemplo da operação de Adicionar e Atualizar Políticas
O PAP fornece uma RESTful API para adicionar e atualizar as políticas a um domínio
específico. Solicitações HTTP para esta API devem ter um formato padrão do verbo HTTP
POST como descrito na Tabela 22.
Mostraremos, agora, um exemplo de solicitação/pedido HTTP abaixo:
POST
/domains/iMnxv7sDEeWFwqVFFMDLTQ/pap/policies
HTTP/1.1
Accept:
application/xml;
Content-Type:
<?xml
charset=UTF-8
application/xml;
version="1.0"
encoding="UTF-8"
charset=UTF-8
standalone="yes"?>
<PolicySet
xmlns="urn:oasis:names:tc:xacml:3.0:core:schema:wd-17"
PolicySetId="P1"
Version="1.0"
PolicyCombiningAlgId="urn:oasis:names:tc:xacml:3.0:policy-combiningalgorithm:deny-unless-permit">
<Description>Sample
PolicySet</Description>
<Target
/>
<Policy
PolicyId="MissionManagementApp"
Version="1.0"
RuleCombiningAlgId="urn:oasis:names:tc:xacml:3.0:rule-combining-algorithm:denyunless-permit">
<Description>Policy
for
MissionManagementApp</Description>
<Target>
<AnyOf>
<AllOf>
<Match
MatchId="urn:oasis:names:tc:xacml:1.0:function:string-equal">
<AttributeValue
DataType="http://www.w3.org/2001/XMLSchema#string">MissionManagementApp</Attribute
Value>
<AttributeDesignator
Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"
AttributeId="urn:oasis:names:tc:xacml:1.0:resource:resource-id"
DataType="http://www.w3.org/2001/XMLSchema#string"
MustBePresent="true"
</Match>
</AllOf>
</AnyOf>
</Target>
/>
<Rule
RuleId="MissionManager_role_can_manage_team"
<Description>Only
MissionManager
role
authorized
to
Effect="Permit">
manage
the
mission
team</Description>
<Target>
<AnyOf>
<AllOf>
<Match
<AttributeValue
DataType="http://www.w3.org/2001/XMLSchema#string">Team</AttributeValue>
Category="urn:oasis:names:tc:xacml:3.0:attribute-category:resource"
AttributeId="urn:thales:xacml:2.0:resource:sub-resource-id"
/>
</Match>
</AllOf>
</AnyOf>
<AnyOf>
<AllOf>
<Match
<AttributeValue
DataType="http://www.w3.org/2001/XMLSchema#string">manage</AttributeValue>
Category="urn:oasis:names:tc:xacml:3.0:attribute-category:action"
AttributeId="urn:oasis:names:tc:xacml:1.0:action:action-id"
/>
</Match>
</AllOf>
</AnyOf>
</Target>
<Condition>
<Apply
<Function
FunctionId="urn:oasis:names:tc:xacml:3.0:function:any-of">
FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-equal"
/>
<AttributeValue
DataType="http://www.w3.org/2001/XMLSchema#string">MissionManager</AttributeValue>
AttributeId="urn:oasis:names:tc:xacml:2.0:subject:role"
MustBePresent="false"
Category="urn:oasis:names:tc:xacml:1.0:subject-category:access-subject"
/>
</Apply>
</Condition>
</Rule>
</Policy>
</PolicySet>
Veja como seria a resposta HTTP em seguida. Observe que o status de resposta HTTP é
200 com um link para gerenciar a nova política, caso a solicitação tenha sido bem-sucedida. A
ligação é feita do ID da política e da versão que está separada por '/'.
HTTP/1.1
200
Content-Type:
<?xml
OK
application/xml;
version="1.0"
encoding="UTF-8"
<ns3:link
charset=UTF-8
standalone="yes"?>
xmlns:ns3="http://www.w3.org/2005/Atom"
rel="item" href="P1/1.0" title="Policy 'P1' v1.0"/>
Para atualizar uma política, deve-se adicionar uma nova versão da política, isto é, devese enviar o mesmo pedido como acima, mas com um valor de versão superior.
Exemplo da operação de Listar Políticas
Para obter a política do domínio, depois desta já adicionada ao domínio (caso de dúvida,
consulte acima a Criação e Edição de Políticas), acesse-a pelo seu ID da forma descrita no
verbo HTTP GET da Tabela.
Exemplo:
GET
/domains/iMnxv7sDEeWFwqVFFMDLTQ/pap/policies/P1
HTTP/1.1
O resultado é uma resposta HTTP com a lista de links para as versões da política P1
disponível no domínioiMnxv7sDEeWFwqVFFMDLTQ:
HTTP/1.1
200
Content-Type:
<?xml
OK
application/xml;
version="1.0"
encoding="UTF-8"
charset=UTF-8
standalone="yes"?>
<ns2:resources
<ns3:link
rel="item"
href="1.0"/>
<ns3:link
rel="item"
href="1.1"/>
<ns3:link
rel="item"
href="2.0"/>
<ns3:link
rel="item"
href="2.1"/>
<ns3:link
rel="item"
href="2.2"/>
...
</ns2:resources>
Porém, existe outra maneira de consultar as políticas, requisitando uma versão específica
da política utilizando o segundo caminho da tabela do Verbo HTTP GET.
Exemplo:
GET
/domains/iMnxv7sDEeWFwqVFFMDLTQ/pap/policies/P1/1.0
HTTP/1.1
A resposta é o documento de política (XACML PolicySet - Conjunto de políticas
XACML) nesta versão. Mas se você desejar buscar a mais recente pode utilizar um caminho
como a URL /domains/iMnxv7sDEeWFwqVFFMDLTQ/pap/policies/P1/latest.
Ainda, pode ser listada todas as políticas de um domínio específico utilizando o terceiro
caminho deste Verbo:
Exemplo:
GET
/domains/iMnxv7sDEeWFwqVFFMDLTQ/pap/policies
HTTP/1.1
Accept:
<?xml
application/xml;
version="1.0"
encoding="UTF-8"
charset=UTF-8
standalone="yes"?>
<ns2:resources
<ns3:link
rel="item"
href="root"/>
<ns3:link
rel="item"
href="P1"/>
<ns3:link
rel="item"
href="P2"/>
...
</ns2:resources>
Exemplo da operação de Deletar Políticas
Uma operação fundamental é a remoção de políticas, operação necessária quando não
deseja mais se utilizar de alguma política. Você pode remover uma versão política do domínio
utilizando o Verbo HTTP DELETE com o segundo caminho desse Verbo da Tabela.
Exemplo:
DELETE
/domains/iMnxv7sDEeWFwqVFFMDLTQ/pap/policies/P1/1.0
HTTP/1.1
A resposta é o documento de política removido (XACML PolicySet - Conjunto de
políticas XACML) nesta versão.
Existe, ainda, uma maneira bastante útil de remoção de política, removendo todas as
versões de uma política a partir do domínio, usando o primeiro caminho deste Verbo HTTP.
Exemplo:
DELETE
/domains/iMnxv7sDEeWFwqVFFMDLTQ/pap/policies/P1
HTTP/1.1
Como resultado, obterá uma resposta HTTP com a lista de links para todas as versões
removidos da política, semelhante ao do pedido HTTP do método GET na mesma URL.
8.6.6 Cenários de Uso
Além destes detalhes, temos que, pode ser escolhido um nível de segurança pelo
administrador dentre os três níveis disponíveis, são estes: Autenticação, Autorização Básica e
Autorização Avançada. Abaixo descreveremos detalhadamente cada e suas representações por
meio de figuras.
Para configurar este ambiente precisa seguir 6 passos, são:
1) Registrar a aplicação no IdM GE;
2) Implantar o PEP Proxy sobre o serviço back-end; Observando que o endpoint do serviço
deve ser o endpoint do PEP Proxy, mas deve mudar o back-end para outro endpoint (ele
pode está localizado no mesmo servidor, mas em outra porta). Desta forma, o PEP
redirecionará as solicitações para o serviço.
3) Implementar um mecanismo OAuth2 na aplicação; Etapa esta que permitirá que os
usuários façam login na aplicação usando as contas FIWARE.
4) Após a autenticação do usuário na aplicação, através do login, o IdM gera um token
OAuth2 que representará o usuário. Este token será importante para incluí-lo nas
solicitações do serviço de back-end como um cabeçalho HTTP;
5) Enviar todas as solicitações do serviço de back-end para o endpoint no qual o PEP Proxy
está implantado.
6) Nesta última etapa, o PEP analisa se o token é válido, caso seja válido, redirecionará a
solicitação para o back-end. Caso contrário, gerará um código de não autorizado.
Este cenário de uso pode ser dividido em três níveis.
8.6.6.1 Autenticação com PEP
No primeiro nível, detalharemos o passo a passo somente da autenticação, utilizando
contas FIWARE para os usuários e aplicações, neste nível, trabalharemos com IdM GE e PEP
Proxy GE.
Figura 119 - PEP Proxy - Nível 1: Autenticação [16]
De acordo com a Figura 119 exibida acima, após a criação de usuário e aplicativo na
conta do FIWARE, neste nível, o PEP receberá do front-end (Web APP) uma solicitação REST
(request) de acesso ao serviço back-end (Back-end Apps) com um token OAuth2 (access-token)
do usuário. Quando o PEP Proxy recebe a solicitação, ele extrai o token do cabeçalho HTTP e
envia uma solicitação para o Servidor de Contas do FIWARE (IdM GE) para validá-lo, lembrese que a URL do servidor é definida no campo "account_host" do arquivo de configuração. Se
o token é válido, o PEP redireciona a solicitação para o serviço back-end configurado no
"app_host" e "app_port" do arquivo de configuração.
8.6.6.2 Autorização Básica com PEP e PDP
O segundo nível utilizará uma autorização básica, isto é, além de realizar a parte de
autenticação, trabalha com configuração dos papéis e das permissões para um usuário do
aplicativo, através do uso do IdM GE, PEP Proxy GE e Authorization PDP.
Figura 120 - PEP Proxy - Nível 2: Autorização Básica [16]
Na figura 120, observamos que o nível 2 ocorre de forma semelhante ao nível 1, mas
com a adição de alguns parâmetros que também serão analisados pela GE discutida. Logo, neste
nível 2, o primeiro passo é a criação de usuário e aplicativo na conta do FIWARE, mas além
disso, também configurar os papéis e permissões para esse usuário que terá no aplicativo.
O PEP Proxy irá verificar se o access_token é de um usuário autenticado numa conta
FIWARE, caso afirmativo, o PEP receberá uma resposta com as informações do usuário, nestas
informações está incluída a lista de papéis que o usuário tem para esta aplicação, Além disso, o
PEP Proxy interage com o Authorization PDP para saber se o usuário possui permissão ao
recurso (Back-end Apps) utilizando informações como os papéis do usuário, HTTP Verb e o
caminho do recurso.
8.6.6.3 Autorização avançada com PEP e PDP
O terceiro nível diz respeito a autorização avançada, responsável por configurar os
papéis e políticas no padrão XACML para um usuário que utilizará o aplicativo. Também utiliza
o IdM GE, PEP Proxy GE e Authorization PDP. Vejamos a seguir uma descrição detalhada
deste nível:
Figura 121 - PEP Proxy - Nível 3: Autorização Avançada [16]
A Figura 121 mostra a arquitetura desta configuração. Neste nível também deve-se criar
um usuário e aplicativo em conta do FIWARE como todos os outros níveis, mas também
configurar os papéis e políticas no padrão XACML para este usuário no aplicativo. Portanto,
neste nível serão verificados parâmetros avançados da solicitação, tais como, o corpo ou os
cabeçalhos personalizados. Para isso, o programador deve modificar o código fonte do PEP
Proxy, a fim de incluir os requisitos específicos. Com estes parâmetros definidos, será criado
um XACML e enviará uma solicitação ao Authorization PDP GE para validá-lo.
8.7 Descrição do CyberSecurity
O CyberSecurity GE é um componente com foco na detecção e resposta a incidentes de
segurança. Este componente oferece mecanismos que tratam desde a análise de riscos até a
sugestão de possíveis respostas que permitam mitigar esse risco, tendo como público-alvo
organizações que desejam detectar e gerenciar risco de segurança em sistemas e aplicações,
como por exemplo, mantenedores de infraestrutura FIWARE, e desenvolvedores de aplicações
baseada na plataforma FIWARE.
A proposta do Cyber Security GE engloba (1) Coletar vulnerabilidades e avaliar ameaças
potenciais; (2) Identificar ataques mais prováveis e de maior impacto; (3) Avaliar riscos e propor
soluções de remediação; (4) Entregar um serviço de visualização centralizado em nível de risco
e custo; e (5) Prover recursos de compartilhamento de dados críticos que preservem a
privacidade da organização. De forma a atingir esses objetivos, a arquitetura do CyberSecurity
GE engloba um conjunto de componentes que atuam em conjunto com um SIEM.
Figure 122 - Componentes de desenvolvimento e interações com Cyber Security GE [17].
O CyberSecurity GE trabalha em conjunto com outros componentes de segurança,
incluindo elementos de infraestrutura (tais como firewalls, roteadores e switches) e elementos
de controle de acesso (como o IdM KeyRock e o PDP AuthZForce do FIWARE). Esses
componentes são monitorados através de um SIEM, através de probes.
O Cyber Data Extraction é o componente responsável por extrair e processar os dados
relevantes fornecidos pelo usuário sobre seu sistema: topologia de rede, regras de firewall,
resultados de analisadores de vulnerabilidades, etc. A saída deste componente é utilizada como
entrada pelos componentes Scored Attack Path e Remediation. Dois tipos de dados são
utilizados: O relatório de um analisador de vulnerabilidades (como por exemplo o Nessus) e um
arquivo descrevendo a topologia do sistema. Este XML descreve computadores e suas interfaces
de rede, endereços IP, VLAN, serviços de rede, firewall e configuração de roteamento. Este
arquivo pode ser gerado automaticamente a partir de ferramentas de gerenciamento disponíveis.
Para dar informações sobre vulnerabilidades e a topologia para outros componentes, duas
formas de saída podem ser geradas. A primeira é a informação necessária para que o MulVAL
Attack Graph Engine gere o grafo de ataque. Esse arquivo contém tanto os dados sobre
vulnerabilidades quanto sobre a topologia. O segundo arquivo é gerado como um XML,
necessário para a aplicação de remediação.
O componente MulVAL Attack Graph Engine é um analisador topológico de
vulnerabilidades capaz de gerar, a partir da saída do Cyber Data Extraction, os possíveis
caminhos utilizados por ataques. Esta engine combina os conceitos de grafo de ataque 26 com
CVSS (Common Vulnerability Score System) para prover uma analise qualitativa e quantitativa
de vulnerabilidades individuais. As interações entre múltiplos elementos de redes devem ser
considerados para determinar o impacto na segurança que as vulnerabilidades em software
possuem para um determinada rede. Desse modo, o MulVAL analisa: Quais vulnerabilidades
foram reportadas e se elas existem em meus servidores; Quais softwares e serviços estão
rodando em meus servidores e como eles estão configurados; Como meus roteadores e firewalls
estão configurados; Quem são os usuários da minha rede; Como esses componentes interagem;
26
http://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/FIWARE.OpenSpecification.Security.C
yberSecurity
e Quais acessos eu devo permitir. O MulVAL cria grafos lógicos que apresentam os caminhos
de ataque, passando pelas regras de segurança, dispositivos e serviços de rede. Os
administradores de redes podem definir suas preferências de pontuação.
Baseado no grafo de ataque o componente Scored Attack Paths analisa as principais
vias de ataque e computa uma pontuação para cada um dos caminhos de acordo com seu impacto
no negócio e probabilidade de ocorrência. Basicamente, define o nível de risco associado com
cada caminho possível em um grafo de ataque.
O componente Remediation Engine ajuda a mitigar os riscos e toma ações efetivas de
acordo com as políticas de segurança, computando diferentes formas de quebrar as vias de
ataque, estimando o custo de cada uma. Desta forma, o administrador de rede pode selecionar o
caminho de rede e verificar as alternativas de remediação. Para computar remediações, um
banco de remediações é necessário. Este banco faz a conexão entre as vulnerabilidades e uma
possível remediação. Diversos tipos de remediação podem ser utilizados, tais como correções
de configuração, e aplicação de patches em software. Outros tipos de remediações não podem
ser armazenados em um banco de dados, pois elas dependem de remediações em nível de rede,
como regras de firewall, mudança de regra de roteamento. Para isso, o Remediation Engine
necessita de uma simulação da topologia da rede. A lista de remediações apresenta o custo
estimado, operacional e impacto. Existe também a possibilita de remediação automática,
utilizando aprendizagem de máquina. Utilizando respostas análogas as tomadas por
administradores em caminhos de ataques parecidos.
O componente Visualization interface provê uma interface Web para o administrador
de rede para que ele possa interagir com os componentes, analisando dinamicamente os riscos
do sistema. O administrador pode utilizar a ferramenta para visualizar os possíveis caminhos de
ataques, ver o nível do risco e as opções de remediações para resolvê-las.
O componente Privacy-Presenting Data Sharing possibilita que uma organização
possa compartilhar dados relativos a um ataque bem sucedido com grande impacto de negócio
com outros, sem expor informações confidenciais. As funcionalidades do Cyber Security
possibilita que a organização compreenda sua situação e reaja de forma apropriada,
particularmente durante fases críticas. Nessas fases pode ser crucial compartilhar informações
com instituições privadas ou companhias de consultoria. Privacy-Preserving Data Sharing
possibilita que essas informações sejam compartilhadas sem expor dados confidenciais e críticos
da organização. Isso é conseguido através dos princípios de Multi-Party Computation, uma
tecnica baseada em criptografia onde entidades diferentes são capazes de operar em um conjunto
de informações com garantias de privacidade.
A implementação de referência do Cyber Security GE pode ser encontrada no catálogo
de GEs FIWARE. Entretanto, a mesma está classificada como deprecated, tendo sua última
atualização em 02/02/2016.
8.8 Descrição do Trustworthy Factory GE
Há muita vulnerabilidade em sistemas disponibilizados na internet devido a malware,
spyware, hackers e falhas de segurança todos os dias, mas a maioria dessas vulnerabilidades
hoje são as vulnerabilidades dos aplicativos. Embora a confiança de um sistema seja algo
subjetivo, confiabilidade de um sistema pode ser medido de acordo com indicadores
quantificados. Portanto, foi desenvolvida a Trustworthy Factory GE para fornecer um ambiente
para desenvolver aplicativos confiáveis e para ajudar a sua certificação com base na avaliação
dos atributos de qualidade de software (baseado na ISO 25010). O ponto de partida para esta
GE é uma lista de objetivos de confiabilidade (trustworthiness profile).
A maioria dos habilitadores genéricos do FIWARE fornece funções comuns que podem
ser integradas dentro de novas aplicações e efetivamente utilizadas em tempo de execução, ou
seja, quando o aplicativo é executado. Já a Trustworthy Factory GE não presta este tipo de
função comum no momento de execução do aplicativo, mas sim uma função comum para o
desenvolvimento de novas aplicações Java confiáveis e, portanto, utilizada principalmente
durante a fase de desenvolvimento.
A Trustworthy Factory GE consiste em duas características principais:
● Static and Dynamic Application Trustworthiness Assessment: Este recurso
oferece um ambiente de desenvolvimento que auxilia um desenvolvedor a
escrever código-fonte Java com melhor qualidade, considerando aspectos de
projeto e melhores práticas. Além disso, outras ferramentas podem ser utilizadas
de forma a oferecer uma avaliação intermediária da confiabilidade para os
desenvolvedores. Com isso, desenvolvedores são capazes de consultar o objetivo
de confiabilidade dado como entrada pelo provedor de software e compará-lo
com uma avaliação atual.
● Semi-automated Workflow for Application Trustworthiness Certification:
Este recurso é usada pelo avaliador para preparar a fase de certificação. Ele
possui como entrada o código fonte da aplicação e diferentes informações
fornecidas pelo desenvolvedor de software, tais como contexto da aplicação e o
objetivo de confiabilidade). Um conjunto de ferramentas, integradas de acordo
com um workflow, auxiliam o avaliador a compreender o contexto da aplicação,
re-definir ou adicionar novos objetivos de confiabilidade, além de avaliar os
atributos de confiabilidade de uma aplicação em relação a estes objetivos. Com
isso, o avaliador é capaz de quantificar o nível de confiabilidade de um
aplicativo. Os resultados deste trabalho são armazenadas em um arquivo XML,
assinado pelo avaliador, chamado "Digital Trustworthiness Certificate (DTwC)"
e este arquivo será usado pela certificadora para certificar a aplicação.
Figura 123 - Contexto de fabricação de confiança [18].
Uma visão geral deste processo é apresentado na Figura 123. O ambiente de
desenvolvimento consiste na IDE Eclipse com um conjunto de plugins, apresentando visões
diferentes para o desenvolvedor e o avaliador. Um conjunto de plugins foram adicionados a fim
de combinar, agregar, fundir e transformar os resultados gerados por diversas ferramentas de
avaliação de código-fonte com um ponto de vista de confiabilidade. Uma vez pronta, a aplicação
passa por uma ferramenta de certificação, onde um avaliador verificar se o aplicativo é
compatível com os requisitos de confiabilidade especificadas como entrada.
O processo de certificação consiste em cinco etapas:
1. System description: Esta etapa consiste em declarar os diferentes componentes do
sistema e identificar qual componente está sob avaliação.
2. Trustworthiness Problem definition: Esta segunda etapa, define os problemas que
poderiam impactar um componente da aplicação. A lista de problemas é uma lista
predefinida, classificados por tipo. O avaliador seleciona um componente e verifica os
possíveis problemas que podem ocorrer neste recurso.
3. Trustworthiness Property Specification: Além do perfil de confiabilidade, ou seja, a
lista de objetivos, inicialmente passado para o desenvolvedor, o avaliador pode associar
atributos de confiabilidade extra para componentes específicos do aplicativo e definir
métricas diferentes para cada um.
4. Evidence collection: Esta etapa permite ao avaliador recolher as provas para calcular as
diferentes métricas e o valor para cada atributo de confiabilidade. A coleção pode ser
feito automaticamente usando ferramentas diferentes, exemplo análise estática e em
tempo de execução, ou podem ser recolhidos manualmente, no caso de algumas provas
serem fornecidas manualmente, por exemplo, os resultados de testes.
5. DTwC (Digital Trustworthiness Certificate) creation and editing: Este passo é usado
para validar a geração do certificado. Todos os dados necessários são verificados e
validados, a fim de gerar um certificado completo. Esta visão mostra o caminho em que
o certificado está e onde componente deve ter sido gerado, isto é, o seu caminho físico
ou URL de mercado.
A implementação de referência do Trustworthy Factory GE pode ser encontrada no
catálogo de GEs FIWARE. Semelhantemente a CyberSecurity GE, está classificada como
deprecated, tendo sua última atualização em 02/02/2016.
8.9 Considerações Finais
Neste capítulo de Segurança desenvolvemos um estudo detalhado da sua arquitetura,
trabalhando com os cinco habilitadores genéricos: Identity Management GE, Authorization PDP
GE, PEP Proxy GE, Cyber Security GE e Trustworthy Factory GE. Apesar de ter trabalhado
com todos eles, uma maior ênfase foi dada à área temática de Gerenciamento de Identidade e
Acesso, tendo um maior detalhamento sobre estes três primeiros GEs com suas respectivas
implementações de referência: KeyRock, AuthZForce e Wilma. Vale salientar que os outros
dois GEs estão classificadas como deprecated desde fevereiro do ano presente.
Também apresentamos uma aplicação como estudo de caso para a apresentação dos GEs
de Segurança, sendo esta formada por um componente back-end (definindo um webservice
REST) e um componente front-end (correspondente a uma aplicação Web para interação com o
usuário que realiza chamadas aos serviços definidos) que puderam ser utilizados de forma a
experimentar a integração dos GEs apresentados com seus componentes.
8.9.1 Problemas Encontrados
Surgiram diversos problemas durante o estudo do Capítulo de Segurança da plataforma
FIWARE. Um dos problemas diz respeito ao acesso a um GE utilizado um token de
autenticação. Foi desenvolvido um cliente Web para acessar o Repository GE após autenticação
do usuário junto ao Keyrock. Entretanto, embora o token de autenticação tenha sido obtido com
sucesso, o mesmo não era aceito pelo GE. Uma tentativa de identificar a causa do problema foi
iniciada, mas não tivemos tempo hábil para um estudo aprofundado do Repository GE e seus
mecanismos de autenticação junto ao Keyrock.
Outro problema encontrado diz respeito a interação com o componente de autorização
AuthZForce implantado no IMD. Este componente oferece serviços para o gerenciamento de
políticas de controle de acesso, que por sua vez podem ser agrupadas em diferentes domínios.
Seguindo a documentação oficial de administração do AuthZForce 27 para criação de
domínio, ao executar a instrução CURL (configurado conforme foi especificado na seção 7.6.4)
27
https://github.com/authzforce/fiware/blob/master/doc/InstallationAndAdministrationGuide.rst
é retornado um erro de código HTTP 400 Bad Request. Desta forma não conseguimos prosseguir
nos testes posteriores com outras operações de domínio e, de forma semelhante, com a
administração de políticas de domínios. Observe mais detalhadamente o erro na Figura 124
abaixo:
Figura 124 - Erro HTTP 400 Bad Request em criação de domínio.
8.9.2 Pendências
Devido às dificuldades enfrentadas no desenvolvimento das aplicações e com o fim do
prazo para a conclusão do relatório antes de ser possível realizar as correções necessárias, a
finalização dessas aplicações é uma pendência atualmente, estando inserida nas metas para o
trimestre seguinte, a fim de fazer com que todas as formas de autenticação e interação entre
IdM, GEs e Proxies consigam ser experimentadas e documentadas a partir desses exemplos.
Também é apresentada como pendência a finalização do gerenciamento de domínios de
políticas e do gerenciamento das políticas nos domínios.
8.9.3 Próximos passos
Como próximos passos está a finalização das aplicações de exemplo restantes e a
realização de testes com a administração de domínios e de políticas em domínios. Além disso,
recomendamos também um estudo mais aprofundado acerca dos componente keyrock, Wilma
e AuthZForce, as implementações das GEs IDM, PEP e PDP. Tal estudo visa a produção de
material didático acerca da utilização das GEs mencionadas para proteger aplicações que rodem
em cima de uma infraestrutura FIWARE.
9 FIWARE Ops
A utilização de FIWARE tem como ponto inicial a configuração da infraestrutura de
suporte as tecnologias providas pela plataforma. Dentro do ecossistema FIWARE, os
provedores de instâncias FIWARE são definidos como organizações privadas ou públicas que
buscam implantar essa infraestrutura no fomento da disseminação da FIWARE como padrão
tecnológico para construção de aplicações de cidades inteligentes. O esforço e custo dessa
implantação são altos, dependendo de vários recursos de hardware (servidores, equipamentos
de rede) e software (sistema OpenStack) que devem seguir requisitos de performance,
escalabilidade e redundância. No intuito de facilitar esse processo foi definido o capítulo técnico
FIWARE Operations.
9.1 Objetivos
O objetivo principal do FIWARE Operations (FI-Ops) [32] é prover um conjunto de
ferramentas que facilitem a implantação, configuração e operação de instâncias FIWARE. Deve,
ainda, auxiliar na expansão da infraestrutura associada a uma determinada instância FIWARE
através da federação de nós adicionais (data centers) ao longo do tempo, alavancando, assim, a
cooperação de múltiplos provedores FIWARE.
9.2 Descrição
O capítulo técnico do FIWARE Ops constitui-se de uma coleção de ferramentas para
implantação, configuração e gerenciamento de instâncias FIWARE. Atualmente, essas
ferramentas auxiliam na administração do FIWARE LAB. O FIWARE LAB é uma rede
federada de instâncias FIWARE [33] onde desenvolvedores podem experimentar a utilização
dos recursos disponibilizados pela plataforma FIWARE. As operações de inclusão de novos nós
ou de federação de novas instâncias ao FIWARE LAB são realizadas utilizando o FIWARE
Ops.
A arquitetura definida pelo FIWARE Ops (Figura 125) apresenta elementos que podem
ser agrupados em quatro grupos de atividades, a saber: OPS-Deploy, OPS-Dash, OPS-Health e
OPS-Toolkit.
Figura 125. Arquitetura do FIWARE-Ops.
9.2.1 OPS-Deploy
A OPS-Deploy [34] é um complexo sistema de software composto por um conjunto de
scripts Puppets, um organizador de tarefas (NailGun28), um executor de tarefas (Astute29) e
uma interface do usuário web. A utilização da OPS-Deploy garante que a instalação do
Openstack esteja dentro dos padrões necessário à Federação ao FIWARE LAB. A arquitetura
da OPS-Deploy é exibida na Figura 126 e foi baseada na ferramenta FUEL da Mirantis30. A
implementação da OPS-Deploy partiu do projeto original da ferramenta FUEL, tendo sido feitas
algumas personalizações ou melhorias, como adaptar a interface do usuário para um estilo
similar ao utilizado pela FIWARE ou criar elementos que permitisse a instalação de
componentes de monitoramento, bem como para desenvolver os scripts de instalação para cada
componente FIWARE integrado. Os componentes Cobbler, Puppet, Mcollective são
ferramentas de terceiros que já faziam parte da arquitetura da Fuel. Completam a arquitetura os
componentes específicos da FUEL: Astute e Nailgun, em conjunto com os elementos FIWARE
disponibilizados por plugins.
28
https://docs.fuel-infra.org/fuel-dev/develop/nailgun.html
https://docs.fuel-infra.org/fuel-dev/develop/env.html#astute
30
https://www.mirantis.com/products/mirantis-openstack-software/
29
Figura 126. Arquitetura do OPS-Deploy.
A partir da versão 3.0, a OPS-Deploy passou a suportar uma arquitetura compatível com
plugins, solução herdada da versão da FUEL 6.1. Isso, permite aos usuários instalar e configurar
recursos adicionais para seus ambientes de uma forma flexível, repetível e confiável. De acordo
com esta nova abordagem, todos os componentes desenvolvidos anteriormente, foram
refatorados como um plugin. Os plugins só podem ser instalados antes de configurar e
implementar o ambiente da nuvem Openstack. Caso contrário, os usuários deveram implantar
novamente o ambiente para ativar o plugin.
Os usuários são capazes de interagir com OPS-Deploy usando tanto interface do usuário,
quanto a interface CLI, baseada em comandos BASH. Essas interfaces interagem com Nailgun
que implementa uma API no modelo REST, permitindo o gerenciamento de dados de
implantação. O Nailgun gerencia dados de configuração, volumes de disco, dados de
configuração de redes e quaisquer dados específicos do ambiente que são necessários para
finalizar uma implantação. O Astute é responsável pela composição de agentes capazes de
executar as ações e configurações solicitadas ao Nailgun. Nailgun usa banco de dados SQL para
armazenar seus dados e serviço AMQP para interagir com os agentes do Astute, enquanto o
Cobbler é usado como serviço de provisionamento de sistemas operacionais e prestador de
serviços de DHCP. Por fim, o Puppet é o serviço de implantação e através de agentes
MCollective são realizadas tarefas específicas, como partição de discos rígidos de,
conectividade de rede e sondagem de nós a serem descobertos.
9.2.2 OPS-Dash
O OPS-Dash [35] define um dashboard para gerenciamento e administração do
FIWARE LAB. Atualamente é composto por três elementos: FIDASH, Sevice Level Agreement
Manager e Maintenance Calendar.
9.2.2.1 FIDASH
O FIDASH é um painel para administração e gestão dos nós participantes do FIWARE
Lab. Ele tem como foco principal a administração de infraestuturas propriétarias, fornecendo
um controle eficaz e configurável na executação de operações sobre a infraestrutura e no
monitoramento do status dos nós vinculados ao FIWARE LAB.
Tecnicamente, o FIDASH é uma versão adaptada de GE WireCloud, garantindo um
ambiente de mashup, altamente personalizável, onde os widgets podem ser desenvolvidos e
organizados em painéis. O usuário do FIDASH pode facilmente definir a funcionalidade e
comportamento do painel através da escolha dos widgets utilizados e a configurar do layout,
exemplo na Figura 127. As funcionalidades expostas pelo FIDASH estão relacionadas às
atividades pertinentes ao FIWARE Ops. Por isso, o FIDASH busca atender as funcionalidades
oferecidas pelos serviços OpenStack, pelo Service Level Agreement Manager, monitoramento
(FI-Health) e os outros serviços disponibiveis no OPS-Toolkit. Atualmente o FI-Dash é
composto um conjunto de 10 widgets exibidos na tabela 23.
Widget
Descrição
List Images
Lista as Images do nó FIWARE monitorado.
List Flavors
Lista os Flavors do nó FIWARE monitorado.
List Instances
List Volumes
Detail Image
Detalha as informações sobre uma Image.
Detail Instance
Detalha as informações sobre uma Instâcia de máquina
virtual.
Detail Volume
Detalha as informações sobre um Volume.
Resources Usage
Exibe gráficos de uso de recursos do nó FIWARE
monitorado.
Embedded SLA MANAGER
Exibe informações sobre o gerenciador dos contratos de
serviço.
Tabela 23. Widgets do FIDASH
Figura 127. Painel do FIDASH.
9.2.2.2 Service Level Agreement Manager
O Service Level Agreement Manager [36] busca prover mecanimos de suporte ao
controle dos contratos de níveis de serviços, do inglês Service Level Agreements (SLA). Os
contratos de níveis de serviços são regras definidas para monitorar o nível de eficiência dos
serviços disponibilizados. Por exemplo, um serviço de armazenamento de objetos pode definir
valores de atributos pertinentes ao controle de qualidade dos serviços, tais como, espaço em
disco, velocidade mínima de download, etc. Esses valores e seus monitoramentos constituem
um contrato do nível de qualidade do serviço ofertado, isto é, compõem o SLA do serviço de
armazenamento.
Atualmente, a implementação do SLA Manager permite gerir o ciclo de vida de contratos
de nível de serviço que se inicia na criação do modelo para detecção de violações, passando pelo
monitoramento dos valores definidos e finaliza com a notificação das violações. As
funcionalidades suportadas atualmente pelo SLA Manager são:
1. Criar/Consultar modelos de SLA.
2. Criar/Consultar acordos de SLA de modelos definidos.
3. Visualizar informações sobre violações e falhas.
Figura 128. Arquitetura do SLA Manager.
O SLA Manager está dividido em dois componentes principais: o SLA-Framework e o
SLA-Dashboard. O SLA-Framework é uma aplicação web multi-plataforma que permite gerir
todo o ciclo de vida de contratos de nível de serviço. Ele monitora a qualidade nos serviços
prestados e estabelece os acordos de nível de serviço, assim como, registra as violações dos
termos dos contratos. Sua atuação abrange os níveis de host, de máquinas virtuais e serviços
web. O SLA-Dashboard expõe ao usuário as ações providas pelo SLA-Framework através de
uma interface gráfica web. A arquitetura do SLA Manager (Figura wse) apresenta duas camadas
distintas que delimitam esses componentes. A camada Graphical User Interface compreende os
elementos do SLA-Dashboard (SLA-GUI, SLA-Manager-Client e Authentication Backend). A
camada Federation Layer, por sua vez, compreende os elementos do SLA-Framework (SLAService, SLA-Enforcement, SLA-Repository, SLA-Personalization). Essas camadas interagem
através da API Rest do SLA-Framework o que permite a reutilização deste em outras aplicações.
Outros habilitadores genéricos da FIWARE estão presentes para suporte a funcionalidades
conjuntas, tais como o IDM GE, o Context Broker GE e o BIG DATA GE.
A utilização do SLA-Manager é facilitada pelo uso do SLA-Dashboard que permite a
configuração via páginas web. Por exemplo, a Figura 129 exibe o registro de um contrato que
monitora as propriedades: percentagem de uso de CPU e percentagem de uso de disco
relacionado a um serviço. Através dessa página é possível facilmente definir as propriedades
que seram monitoradas e os valores que serão garantidos. Uma vez que os contratos são
registrados o usuário pode visualizar a página de monitoramento (Figura 130) que indica
visualmente as notificações de quebra de garantias.
Figura 129. Página de registro de Contrato.
Figura 130. Página de monitoramento de Contratos.
9.2.2.3 Maintenance Calendar
O Maintenance Calendar [37] permite que os administradores da infraestrutura criem
eventos de manutenção a fim de que os usuários e outros componentes da FIWARE fiquem
cientes da manutenção. Sua arquitetura (Figura 131) é uma intercessão entre os componentes
OPS-Dash e OPS-Toolkit. Dessa forma, o componente de interação com os usuários faz parte
do FI-Dash e as ferramentas de background para manutenção da infraestrutura fazem parte do
FI-Toolkit.
Figura 131. Arquitetura do Maintenance Calendar.
O componente do FI-Dash é um widget que expõe as funcionalidades da API REST do
componente do FI-Toolkit, permitindo a definição dos períodos de manutenção para as
diferentes regiões FIWARE Lab. O componente FI-Toolkit expõe uma API REST que permite
aos administradores de infraestrutura do FIWARE LAB criar eventos para os períodos de
manutenção, bem como, aos usuários criarem eventos para períodos de não manutenção. Além
disso, esse componente inclui um sistema de notificação, permitindo que os consumidores
(usuários e outros serviços da FIWARE) receberem notificações de quando um evento é criado,
modificado ou excluído. O sistema de notificação se baseia no Orion Context Broker GE.
O cadastro de eventos é armazenado e gerenciado em um servidor de calendário o
Radicale. O Radicale 31é um sistema servidor de calendário leve que implementa as operações
básicas tais como: armazenar, atualizar e servir eventos de calendário. O tipo de eventos que
podem ser cadastrados é:
1. Os eventos de manutenção associados a um nó específico: são aqueles
gerenciados pelo próprio nó. Por exemplo, a Organização do nó de Trento possui
um usuário com os privilégios para gerir os eventos do nó de Trento (criar e
excluir).
2. Os eventos de períodos sem manutenção referentes a todos os nós. Esses
eventos indicam que durante este período deve ser proibido fazer manutenção
em todos os nós. Somente os usuários com os privilégios específicos podem
gerenciar este tipo de eventos aqueles que estão relacionados ao papel de
“uptime requester”.
9.2.3 OPS-Health
O OPS-Heatth especifica a construção de ferramentas de monitoramento da
infraestrutura da plataforma FIWARE. Atualmente, o OPS-Health é implementado através do
FI-Health. O FI-Health[38] é um conjunto de ferramentas de teste de ponta a ponta que garante
que a integração dos componentes OpenStack estão funcionando como esperado. Por exemplo,
cada nó do FIWARE Lab é testado em um cenário do mundo real usando a API REST do
OpenStack através dos endpoints fornecidos pelos terminais de serviços federados. O intuito
por trás desses testes é garantir que o fluxo do GE Cloud Portal está funcionando como projetado
do início ao fim. Isto é, o conjunto de testes do FI-Health possibilitam identificar os serviços
OpenStack que apresentam falhas antes ou ao mesmo tempo em que os usuários podem relatar
esses problemas.
O FI-Health é, portanto, um conjunto de ferramentas para Openstack que verificam o
status dos nós do FIWARE LAB. A arquitetura do FI-Health (Figura 132) apresenta quatro
31
http://radicale.org/
componentes principais, a saber: Sanity Check, FI-Health Dashboard, Infographics e Federation
Monitoring.
Figura 132. Arquitetura do FI-Health.
O Sanity Check executa os testes de sanidade nos nós federados ao FIWARE LAB a fim
de validar suas capacidades. Para isso, o Sanity Check utiliza um sistema de testes
automatizados o Jenkins32. O Infographic mostra a capacidade de infraestutura dos nós
FIWARE. O Federation Monitoring provê monitoramento de falhas e performance de nós
FIWARE, sendo baseado nos componentes Ceilometer33 e Monasca34 do Openstack. Por fim,
o FI-Health Dashboard permite a visualização dos resultados dos testes.
9.2.4 OPS-Toolkit
O OPS-Toolkit [39], atualmente denominado FI-Toolkit, fornece um conjunto
variado de ferramentas. Essas ferramentas ampliam as funcionalidades das ferramentas padrões
do OpenStack, assim como podem adicionar novos componentes de middleware para garantir
as funcionalidades necessárias às operações do nó FIWARE. A maioria das ferramentas do FIToolkit expõem interfaces que serão exploradas pelo FI-DASH para executar as tarefas a partir
da interface do usuário. A versão atual do FI-Toolkit, release 4, é composta pelos seguintes
32
https://jenkins.io/index.html
https://wiki.openstack.org/wiki/Telemetry
34
https://wiki.openstack.org/wiki/Monasca
33
componentes: Flavor Synchronization tool, Glance Sync, User management tool, Public keys
management tool.
A gerência de Flavors em um ambiente multiplataforma (FIWARE LAB) no qual várias
nuvens OpenStack estão sendo executadas é um trabalho complexo devido ao o uso de vários
tipos de Flavors, onde Flavors com nomes diferentes podem oferecer configurações similares.
A Flavor Synchronization tool resolve esse problema, permitindo a sincronização de Flavors
entre nós federados do FIWARE LAB.
Problema similar ao exposto anteriormente ocorre com as Images. Isto é, nesse conjunto
de nuvens várias Images estão disponibilizadas, aumentando a probabilidade de Images
similares ou iguais já estarem disponíveis em outras plataformas. A resolução desse novo
desafio é realizada pela ferramenta Glance Sync. A Glance Sync permite a sincronização de
Images entre nós federados do FIWARE LAB.
Outro desafio na administração do FIWARE LAB é a gerencia das contas de usuários
trial. Basicamente, existem três tipos de usuários do FIWARE LAB, o usuário basic, o usuário
trial e o usuário comunity. O usuário basic tem acesso a FIWARE LAB, mas não acessa os
recursos relacionados aos nós FIWARE, isto é, não acessa os recursos da nuvem OpenStack. O
usuário trial possui um período limitado, geralmente 15 dias, no qual lhe é permitido acessar os
recursos de um nó FIWARE. Qualquer desenvolvedor ou usuário que queria se cadastrar no
FIWARE LAB tem direito a uma conta basic podendo solicitar um período como usuário trial
para efetivar testes. Posteriormente o usuário trial pode conseguir se tornar um comunity. O
usuário comunity está vinculado a um nó FIWARE tendo acesso a um conjunto limitado de
recursos sem período de tempo determinado para liberá-los. Os usuários comunity devem
requisitar sua vinculação ao nó FIWARE aos administradores do nó. Dessa forma, quando um
usuário trial tem o seu período de testes expirado, os recursos alocados a ele devem ser liberados
e sua conta deve ser modificada para o tipo basic. A ferramenta que automatiza o processo de
atualização dos usuários trial após sua expiração de praso é a User management tool. A última
ferramenta disponibilizada pelo FI-Toolkit é a Public keys management tool a qual permite o
armazenamento seguro de chaves publicas para acesso as máquinas virtuais nos nós FIWARE.
9.3 Exemplo
A utilização das ferramentas FI-DASH, FI-Toolkit ou FI-Health exigem uma estrutura
de nuvem OpenStack configurada como uma instância da FIWARE. Dessa forma, a primeira
ferramenta a ser avaliada no capítulo FIWARE Ops foi a OPS-Deploy. A implantação e
configuração da nuvem OpenStack que servirá de base a instância da FIWARE é de interesse
de todos os Work Packs do projeto Smart Metrópolis. Por isso, os coordenadores dos Work
Packs de Infraestrutura e Middleware definiram que seria executada a implantação inicial de
uma nuvem OpenStack utilizando unicamente OPS-Deploy. Essa abordagem inicial serviria a
dois propósitos:
1. Garantir que apenas com a OPS-Deploy seria possível implantar completamente uma
nuvem OpenStack para execução da instância FIWARE, garantido, assim, os requisitos
necessários para a mesma.
2. Verificar se a plataforma implantada forneceria minimamente os serviços e recursos
necessários para utilização do projeto Smart Metropolis em um cenário de
desenvolvimento e testes exploratórios.
Nesse caminho uma nuvem OpenStack, release Kilo, foi implantada utilizando-se a
OPS-Deploy em um servidor HP ProliantML350 G635 que executa o VMWare vSphere36
como hypervisor em sua versão 5.1.0. Esse servidor atualmente encontra-se no Laboratório de
Concepção de Sistemas (ConSiste37) localizado no Departamento de Informática e Matemática
Aplicada da Universidade Federal do Rio Grande do Norte. A instalação de uma nuvem
OpenStack com o OPS-Deploy é um processo que segue um fluxo de atividades bem definidas,
a saber:
1. Configurar as máquinas para execução da nuvem e do servidor da OPS-Deploy.
2. Instalar e colocar em execução o servidor da OPS-Deploy;
3. Criar e configurar o ambiente na interface web da OPS-Deploy;
4. Efetuar o Deploy do Ambiente.
A infraestutura configurada para a execução da nuvem OpenStack e o servidor OPSDeploy consistiu em 4 máquinas virtuais criadas no servidor HP Proliant, seguindo os
parâmetros especificados na tabela 24. A máquina FI-Ops foi criada para executar o servidos
OPS-Deploy. A FI-Open-Controller serve como controlador da nuvem OpenStack e as
máquinas FI-Open-Compute e a FI-Open-Storage correspondem ao nó de computação das
35
http://h10032.www1.hp.com/ctg/Manual/c01711840
https://www.vmware.com/br/products/vsphere-hypervisor.html
37
http://consiste.dimap.ufrn.br/
36
máquinas virtuais e o nó de armazenamento de objetos, respectivamente. Essas máquinas são
executadas seguindo a arquitetura exposta na Figura 133.
Máquinas
CPU
RAM
DISK
REDE
FI-Ops
6 vCPU
6 GB
55 GB
2 Portas de 1 GB
FI-Open-Controller
4 vCPU
5 GB
65 GB
4 Portas de 1 GB
FI-Open-Compute
6 vCPU
6 GB
50 GB
3 Portas de 1 GB
FI-Open-Storage
3 vCPU
4 GB
35 GB
3 Portas de 1 GB
Tabela 24. Máquinas para execução da OpenStack com OPS-Deploy.
Figura 133. Arquitetura da OpenStack com OPS-Deploy no ConSiste.
Além da configuração da infraestrutura de hardware, também é necessário configurar as
conexões de rede das máquinas seguindo um padrão especifico de conexões, privacidade e
funcionalidades dedicadas. Isto é, a implantação da nuvem OpenStack com o OPS-Deploy
exige:
1. Uma rede dedicada para administração dos nós da nuvem pelo servidor da OPS-Deploy,
habitualmente denominada Admin PXE;
2. Uma rede dedicada para gerenciamento da nuvem pelo nó controlador da OpenStack,
geralmente denominada Manager OPS.
3. Uma rede dedicada para comunicação relativa ao armazenamento de objetos,
normalmente chamada de Storage OPS.
4. Uma rede dedicada para comunicação privativa entre as máquinas virtuais da nuvem,
costumeiramente denominada Private OPS.
Outra exigência é que o Servidor do OPS-Deploy possua acesso à internet por uma rede
física diferente da Admin PXE. A configuração de rede na implantação do ConSiste (Figura
134) seguiu esse parâmetros balizadores e incluiu uma rede para acesso externo a nuvem a
PUPLIC OPS. As exigências físicas são que ao menos as redes Admin PXE e Public OPS
estejam em conexões físicas distintas. As redes Manager OPS, Storage OPS, Private OPS podem
ser configuradas como VLANs que utilizam essas conexões físicas.
Figura 134. Configuração de Rede OPS-Deploy e OpenStack no ConSiste.
Após a configuração da estrutura descrita anteriormente, deve-se proceder com a
instalação do servidor OPS-Deploy. A implantação do servidor OPS-Deploy é facilitada e
auxiliada por uma imagem de máquina disponibilizada em formato ISO, disponível em [34]. A
imagem deve ser utilizada como ponto de inicialização (boot) para o servidor OPS-Deploy em
sua primeira execução. Através de esquema de “passo à passo” é possível concluir a instalação
facilmente. Posteriormente, as máquinas que forem compor a nuvem devem ser inicializadas
com boot via rede o qual será gerenciado pelo servidor da OPS-Deploy. A cada máquina iniciada
corretamente pelo servidor OPS-Deploy, a interface web de administração do OPS-Deploy
disponibiliza os recursos da máquina para serem adicionados ao ambiente de nuvem que se está
configurando. A criação do ambiente é relativamente simples quando feita pela interface web
do administrador. Novamente, segue um modelo de passo a passo, sendo a primeira tela (Figura
135) a de definição do nome descritivo do ambiente. A próxima tela exibe seleção de
hypervisors (KVM, qEmu, etc) disponíveis para configuração da nuvem OpenStack.
Posteriormente, podem-se configurar parâmetros relacionados ao armazenamento e a rede da
nuvem.
Figura 135. Tela para criação do Ambiente no OPS-Deploy.
Após criação do ambiente da nuvem a ser instalado, se faz necessário adicionar as
máquinas (nós) participantes e configurá-las em seus papeis adequadamente. Como visto
anteriormente foram utilizadas três máquinas para compor a nuvem OpenStack, a saber: a FIOpen-Controller, a FI-Open-Compute e a FI-Open-Storage. Cada um desses nós deve ser
configurados pela interface web do OPS-Deploy. A configuração de cada nó exige três ações
básicas (Figuras 136, 137, 138): atribuir um papel ao nó (Controller, Compute, Storage, etc),
configurar o disco (ajustar o espaço destinado a log, banco de dados, etc.) e configurar as
interfaces de rede (qual interface será usada para qual rede). Uma vez que os nós estejam
corretamente configurados (Figura 135), pode se dar inicio ao processo de deployment da
nuvem. Nesse processo a interface web do OPS-Deploy exibe alertas e realiza modificações
visuais como modificar a cor de background para notificar uma operação inadequada. Por
exemplo, caso queira se instalar um nó Compute com pouco espaço em disco para os serviços
serem executados corretamente, o deployment do ambiente não ocorre. Ao final de todo o
processo de implantação da nuvem é exibida a tela da Figura 139, evidenciando ao usuário o
sucesso da operação.
Figura 136. Nós configurados da Nuvem OpenStack no ConSiste.
Figura 137. Configuração de Disco nos Nós OpenStack.
Figura 138. Configurando a Rede nos Nós OpenStack.
Figura 139. Tela de Sucesso para implantação da Nuvem OpenStack com OPS-Deploy.
9.4 Considerações Relevantes
A instalação da nuvem OpenStack Kilo no laboratório ConSiste utilizando a
OPS-Deploy foi executada corretamente, embora muito tempo tenha sido gasto na correta
configuração do ambiente. Isto é, ocorreram várias tentativas de deployment nas quais
mensagens com falhas referentes à configurações de rede ou espaço em disco insuficiente ou
falta de acesso à internet foram apontadas. Outro ponto relevante, foi a necessidade de
configurar um Firewall para acesso externo à Nuvem OpenStack, bem como, para o controlador
da Nuvem ter acesso a internet. O acesso da internet pelo controlador da nuvem deve ser
realizado por um Firewall para isolar a rede da Nuvem.
Após a instalação com sucesso da Nuvem OpenStack não foi possível acessar
inicialmente o componente Horizon do OpenStack. Tal comportamento deveu-se a configuração
de segurança imposta pelo OPS-Deploy que utiliza um servidor de proxy virtualizado no nó
controlador. Dessa forma, o endereço de acesso ao componente Horizon deve ser configurado
nos servidores DNS da rede em que a Nuvem está inserida, assim como, deve ser realizado um
proxy reverso para acesso a este componente via o Firewall.
Como trabalhos futuros, se busca uma melhor documentação dos procedimentos
realizados para um completa implantação da Nuvem OpenStack com o OPS-Deploy. Assim
como, configurar máquinas virtuais na nuvem com os GEs da FIWARE instalados. A instalação
do GEs poderá ocorrer utilizando Images Docker para um rápido provisionamento ou via
instalação e configuração manual para melhor customização.
Referências
[1]
Aazam, Mohammad, Pham Phuoc Hung, and Eui-Nam Huh. "Smart gateway based
communication for cloud of things." Intelligent Sensors, Sensor Networks and
Information Processing (ISSNIP), 2014 IEEE Ninth International Conference on. IEEE,
2014. p. 1- 6.
[2]
Cavalcante, Everton, et al. "On the interplay of Internet of Things and Cloud Computing:
A systematic mapping study." Computer Communications (2016).
[3]
Security
Architecture.
Disponível
em
https://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/Security_Architecture.
Acesso em 20 de maio de 2016.
[4]
FIWARE.OpenSpecification.Data.ContextBroker.
Disponível
em
:
https://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/FIWARE.OpenSpecifi
cation.Data.ContextBroker. Acessado em 06 de junho de 2016.
[5]
FIWARE.OpenSpecification.IoT.Backend.IoTDiscovery.
Disponível
em:
http://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/FIWARE.OpenSpecific
ation.IoT.Backend.IoTDiscovery Acessado em 08 de junho de 2016.
[6]
SPARQL Query Language for RDF. Disponível em: https://www.w3.org/TR/rdf-sparqlquery/ Acessado em 08 de junho de 2016.
[7]
F. C. Delicato, P. F. Pires, T. Batista, Middleware solutions for the In-ternet of Things,
Springer London, United Kingdom, 2013. doi:10.1007/978-1-4471-5481-5.
[8]
Cloud Hosting Architecture. FIWARE WIKI. Disponível em https://forge.fiware.org
/plugins/mediawiki/wiki/fiware/index.php/Cloud_Hosting_Architecture. Acessado em 20
de julho de 2016.
[9]
Openstack Kilo Documentation. Openstack Docs. Disponível em http://docs.openstack
.org/kilo/. Acessado em 20 de julho de 2016.
[10] Jha, A., D, j., Murari, K., Raju, M., et al (2012). “OpenStack Beginner's Guide”.
http://cssoss.files.wordpress.com/2012/05/openstackbookv3-0_csscorp2.pdf. Acesso em
20 julho de 2016.
[11] Openstack Admin Guide. Disponivel em http://docs.openstack.org/admin-guide/.
Acesado em 20 de julho de 2016.
[12] Openstack API. Disponível em http://developer.openstack.org/api-ref.html. Acessado em
20 de julho de 2016.
[13] Identity
Management
GE.
Disponível
em
https://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/FIWARE.Architecture
Description.Security.IdentityManagement. Acessado em 21 de julho de 2016.
[14] Vincent C. Hu, David Ferraiolo, Rick Kuhn, Adam Schnitzer, Kenneth Sandlin, Robert
Miller e Karen Scarfone, NIST Guide to Attribute Based Access Control (ABAC)
Definition and Considerations, National Institute of Standards and Technology Special
Publication 800-162, Janeiro 2014.
[15] Authorization
PDP
GE.
Disponível
em
Description.Security.AuthorizationPDP. Acessado em 21 de julho de 2016.
[16] PEP Proxy. Disponível em http://fiware-pep-proxy.readthedocs.io/en/latest/user_guide/.
Acessado em 21 de julho de 2016.
[17] CyberSecurity
GE.
Disponível
em
Description.Security.CyberSecurity. Acessado em 21 de julho de 2016.
[18] Trustworthy
Factory
GE.
Disponível
em
Description.Security.TrustworthyFactory. Acessado em 21 de julho de 2016.
[19] How
to
implement
oauth2
in
your
applications.
Disponível
em
https://testfiwaretour.readthedocs.io/en/feature-add_deep_dive/handling-authorizationand-access-control-to-apis/how-to-implement-oauth2-in-your-applications/.
Acessado
em 21 de julho de 2016.
[20] How
to
send
requests
to
a
fiware
ge.
Disponível
em
https://testfiwaretour.readthedocs.io/en/feature-add_deep_dive/handling-authorizationand-access-control-to-apis/how-to-send-requests-to-a-fiware-ge/. Acessado em 21 de
julho de 2016.
[21] AuthzForce. Disponível em http://authzforce-ce-fiware.readthedocs.io/en/release-5.3.0a/.
[22] User
And
Programmers
Guide.
Disponível
em
https://github.com/authzforce/fiware/blob/master/doc/UserAndProgrammersGuide.rst.
[23] Installation
And
Administration
Guide.
Disponível
em
https://github.com/authzforce/fiware/blob/master/doc/InstallationAndAdministrationGui
de.rst. Acessado em 05 de julho de 2016.
[24] Course:
PEP
Proxy
Wilma
GE.
Disponível
https://edu.fiware.org/course/view.php?id=131. Acessado em 21 de julho de 2016.
em
[25] Course:
Authorization
PDP.
Disponível
https://edu.fiware.org/course/view.php?id=144. Acessado em 21 de julho de 2016.
em
[26] Handling authorization and access control to apis: Introduction. Disponível em
https://testfiwaretour.readthedocs.io/en/feature-add_deep_dive/handling-authorizationand-access-control-to-apis/introduction/. Acessado em 21 de julho de 2016.
[27] FIWARE SelfServiceInsterfaces. Disponível em http://forge.fiware.org/plugins/
mediawiki/wiki/fiware/index.php/FIWARE.ArchitectureDescription.Cloud.SelfServiceI
nterfaces. Acessado em 25/07/2016.
[28] FIWARE Cloud Architecture. Disponível em https://forge.fiware.org/docman/view.php/
7/5266/D.12.1.1+FIWARE+Architecture%28Cloud%29.pdf. Acessado em 25/07/2016.
[29] FIWARE App Managment. Disponível em https://forge.fiware.org/plugins/mediawiki
/wiki/fiware/index.php/FIWARE.ArchitectureDescription.Cloud.ApplicationManagemnt
. Acessado em 25/07/2016.
[30] OpenStack Murano Docs. Disponível em http://murano.readthedocs.io/en/stable-kilo/.
Acessado em 25/07/2016.
[31] FIWARE Policy Managment. Disponível em https://forge.fiware.org/plugins/mediawiki/
wiki/fiware/index.php/FIWARE.ArchitectureDescription.Cloud.PolicyManager.
Acessado em 25/07/2016.
[32] FIWARE Operations. Disponível em https://www.fiware.org/fiware-operations/. Acesso
em 27/07/2016.
[33] FIWARE LAB. Disponível em https://account.lab.fiware.org/. Acesso em 27/07/2016.
[34]
OPS-Deploy.
Diponpivel
em
https://github.com/SmartInfrastructures/fuel-main-dev/blob/si
/4.0/README.md. Acesso em 27/07/2016.
[35]
OPS-Dash. Disponível em http://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php
/FIWARE_OPS_Tools. Acesso em 27/07/2016.
[36] SLA Manager. Disponível em https://github.com/Atos-FiwareOps/sla-dashboard. Acesso
em 27/07/2016,
[37] MainTenance Calendar. Disponível em https://github.com/Atos-FiwareOps/fiwaremaintenance-calendar-api, Acesso em 27/07/2016.
[38] FI-Health. Disponível em http://forge.fiware.org/plugins/mediawiki/wiki/fiware/
index.php/FI-Health. Acesso em 27/07/2016.
[39] FIWARE OPS Tool. Disponível em https://forge.fiware.org/plugins/mediawiki/wiki
/fiware/index.php/FIWARE_OPS_Tools#Support_Tools_-_OPS-Toolkit. Acessado em
27/07/2016.
[40] Authorization PDP - AuthZForce: Installation and Administration Guide. Disponível em
https://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/Authorization_PDP__AuthZForce_-_Installation_and_Administration_Guide_(R4.2.0). Acessado em 28 de
julho de 2016.
[41] SpagoBI
Documentation.
Disponível
em
http://www.spagobi.org/homepage/services/documentation/. Acessado em 30 de julho de
2016.
[42] RSS
Documentation.
Disponível
em
Description.Apps.RSS. Acessado em 30 de julho de 2016.
[43] Store
Documentation.
Disponível
em
Description.Apps.Store. Acessado em 30 de julho de 2016.
[44] Application
Mashup
Documentation.
Disponível
em
https://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/Architecture_of_Appli
cations,_Services_and_Data_Delivery_R4. Acessado em 30 de julho de 2016.
[45] User
Guide
Wirecloud.
Disponível
em
https://wirecloud.readthedocs.io/en/latest/user_guide/. Acessado em 30 de julho de 2016.
[46] Marketplace
Documentation.
Disponível
em
Description.Apps.Marketplace. Acessado em 30 de julho de 2016.
[REF SDN] D. Kreutz, F. M. Ramos, P. Esteves Verissimo, C. Esteve Rothenberg, S.
Azodolmolky, S. Uhlig. Software-defined networking: A comprehensive survey. Proceedings
of the IEEE, 103(1), 14-76, 2015.
[REF ONF specification] OpenFlow Switch Specification (Version 1.5.0). Open Networking
Foundation
(ONF).
Technical
Specification.
https://www.opennetworking.org/images/stories/downloads/sdn-resources/onfspecifications/openflow/openflow-spec-v1.5.0.pdf.
[REF Mid] Middleware, Disponível em: https://pt.wikipedia.org/wiki/Middleware, Acesso em:
25 de maio de 2016.
[REF QoS] QoS - Qualidade de Serviço, Disponivel em: http://br.ccm.net/contents/278-qosqualidade-de-servico . Acesso em: 31 de maio de 2016.

WP-Middleware - Projeto SmartMetropolis | IMD-UFRN

Transcrição

Documentos relacionados

Slides

Ficha técnica

Ericsson e Verizon planejam milhões de dispositivos de IoT

baixar o PDF - Giuliano Bertoti

Goulds 3620 - Goulds Pumps

F5 Networks garante a segurança e a performance das

RE/MAX Philippines

Juntas RTJ - Control Seals Vedações Industriais

havoline® é mais proteção para o seu carro

Investigador de Coimbra lidera novo estudo europeu sobre