Habilitadores Genéricos da Plataforma FIWARE -...

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_0-20120529-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.

updateContextAvailabilitySubscription

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 Verbo HTTP

Descrição

contextEntities/{EntityID}

GET Recupera informações sobre uma entidade de contexto

POST Realiza o registro sobre a disponibilidade de uma entidade de contexto

contextEntities/{EntityID}/attributes

GET Recupera o valor dos atributos de uma entidade de contexto

POST Regrista informações sobre atributos de uma entidade de contexto

contextEntities/{EntityID}/attributes/{attributeName}

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

contextEntities/{EntityID}/attributeDomains/{attributeDomainName}

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

/contextEntityTypes/{typeName}

GET Recupera informações sobre entidades de contexto pertencentes a determinado tipo.

POST Registra informações sobre entidades de contexto pertencentes a determinado tipo

/contextEntityTypes/{typeName}/attributes

GET Recupera informações sobre entidades de contexto que pertencem a determinado tipo

POST Registra informações sobre entidades de contexto que pertencem a determinado tipo

contextEntityTypes/{typeName}/attributes/{attributeName}

GET Recupera informações sobre atributos que pertencem a determinado domínio e cujas entidades pertencem a determinado tipo

POST Registra informações sobre atributos que pertencentes a determinado domínio e cuja entidade pertence a determinado tipo

/contextEntityTypes/{typeName}/attributeDomains/{attributeDomainName}

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

contextAvailabilitySubscriptions

POST Realiza uma subscrição pra ser notificado a respeito da disponibilidade de entidades de contexto

/contextAvailabilitySubscriptions/{subscriptionID}

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.

{notificationURI}/QueryContext

Operação a ser implementada pelo usuário que deseja realizar subscrições afim de receber notificações acerca de informações contextuais de entidades de contexto. As notificações são enviadas para a URI informada 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.


Descrição

contextEntities/{EntityID}

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.

contextEntities/{EntityID}/attributes

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

contextEntities/{EntityID}/attributes/{attributeName}

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

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

contextEntities/{EntityID}/attributes/{attributeName}/{attributeID}

GET Recupera o valo de um atributo de contexto específico

PUT Atualiza o valor de um atributo de determinada entidade de contexto

DELETE Deleta um atributo específico de uma entidade de contexto

contextEntities/{EntityID}/attributeDomains/{attribute

GET Recupera todos os atributos pertencentes a uma domínio específico.

DomainName}

contextEntityTypes/{typeName}

GET Recupera todas as informações referentes à entidades de contexto pertencentes a determinado tipo

contextEntityTypes/{typeName}/attributes

GET Recupera todos os atributos de contexto associados à entidades de contexto pertencentes a determinado tipo

contextEntityTypes/{typeName}/attributes/{attributeName}

GET Recupera todos os valores dos atributos cujo nome do atributo é igual ao informado e cujas entidades de contexto pertencem a determinado tipo

contextEntityTypes/{typeName}/attributeDomains/{attributeDomainName}

GET Recupera as informações de todos os atributos pertencentes a determinado domínio e cujas entidades pertencem a determinado tipo

contextSubscriptions POST Registra o interesse em receber informações sobre entidades de contexto de forma assíncrona

contextSubscriptions/{subscriptionID}

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 Linked-

USDL. 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.


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).


POST Cria metadados de Recurso informando o id da coleção (collection) e o name do recurso (recurso).


PUT Atualiza metadados de Recurso informando o id da coleção (collection) e o nomedo recurso (resource).


DELETE Deleta Recurso informando o id da coleção (collection) e o name do recurso (recurso).

/FiwareRepository/v2/collec/collection/resource

GET Busca conteúdo de Recurso informando o id da coleção (collection) e o nomedo recurso (resource).

/FiwareRepository/v2/collec/collection/resource

POST Insere ou atualiza conteúdo de Recurso informando o id da coleção (collection) e o nomedo recurso (resource).

/FiwareRepository/v2/service/query?query={ShortQuerySPARQL}

GET Consulta diretamente a base de dados em RDF passando como parâmetro uma Query String em SPARQL.

/FiwareRepository/v2/service/query POST Consulta diretamente a base de dados em RDF. Passando como corpo da mensagem a Query String longa em SPARQL.

/FiwareRepository/v2/service/query/contentURL

GET Consulta diretamente a base de dados 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 GitHub2 é 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 2https://github.com/Fiware/apps.Repository-RI

https://github.com/conwetlab/Repository-RI.git

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.

2.5.3. Exemplo de uso e Problemas Encontrados 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:

https://hub.docker.com/

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

3http://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/{server_id}

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.


DELETE Deleta a máquina virtual.

/v2.1/{tenant_id}/servers/{server_id}/diagnostics

GET Lista alguns dados básicos sobre o uso da máquina virtual. Por exemplo, uso de CPU e memória.

/v2.1/{tenant_id}/servers/{server_id}/ips

GET Lista os endereços IPs vinculados a máquina virtual.

/v2.1/{tenant_id}/servers/{server_id}/metadata

GET Lista os itens de meta dados associados à máquina virtual.

/v2.1/{tenant_id}/servers/{server_id}/os-instance-actions

GET Lista um breve histórico de ações efetuadas sobre a máquina virtual.

/v2.1/{tenant_id}/servers/{server_id}/os-volume_attachments

POST Vincula um volume à uma máquina virtual. O volume fornece um armazenamento persistente e funciona como um disco rígido externo.

/v2.1/{tenant_id}/servers/{server_id}/os-volume_attachments/{attachment_id}

DELETE Desvincula um volume de uma máquina virtual.

/v2.1/{tenant_id}/servers/{server_id}/os-volume_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 Deleta o “flavor”

/v2.1/{tenant_id}/os-keypairs

GET Lista as pares de chaves disponíveis para o tenant especificado.

/v2.1/{tenant_id}/os-keypairs

POST Cria ou importa um par de chaves.

/v2.1/{tenant_id}/os-keypairs/{keypair_name}

DELETE Delata o par de chaves.

/v2.1/{tenant_id}/images GET Listas as “Images” (veja seção 3.2.1.2).

/v2.1/{tenant_id}/images/{image_id}

GET Lista os detalhes da Images.

/v2.1/{tenant_id}/images/{image_id}

DELETE Deleta a Image.

/v2.1/{tenant_id}/os-fixed-ips/{fixed_ip}

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.

/v2.1/{tenant_id}/os-fixed-ips/{fixed_ip}/action

POST Reserva ou libera um IP fixo.

/v2.1/{tenant_id}/os-floating-ips

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.

/v2.1/{tenant_id}/os-floating-ips

POST Cria ou aloca um IP flutuante a um projeto.

/v2.1/{tenant_id}/os-floating-ips/{floating_ip_id}

DELETE Deleta ou desaloca um IP flutuante.

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.

/v1/images/{image_id} HEAD Exibe meta dados relacionados a uma Image.

/v1/images/{image_id} PUT Faz a atualização de uma Image através do upload de um novo arquivo ou atualiza os respectivos meta dados.

/v1/images/{image_id}

DELETE 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

/v2/{tenant_id}/volumes 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.

/v2/{tenant_id}/volumes/{volume_id} DELETE Deleta um Volume.

/v2/{tenant_id}/volumes/{volume_id}/metadata

POST Salva os meta dados do Volume.


GET Exibe os meta dados do Volume.


PUT Atualiza os meta dados do Volume.

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

/v2/{tenant_id}/volumes POST Cria um Volume

/v2/{tenant_id}/volumes 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.

/v2/{tenant_id}/volumes/{volume_id} DELETE Deleta um Volume.


POST Salva os meta dados do Volume.


GET Exibe os meta dados do Volume.


PUT Atualiza os meta dados do Volume.

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

4https://pt.wikipedia.org/wiki/YAML 5 https://www.python.org/ 6 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

HTTP

Descrição

/v1/{tenant_id}/stacks POST Cria um Stack.

/v1/{tenant_id}/stacks GET Lista os dados do Stack.

/v1/{tenant_id}/stacks/{stack_name}/{stack_id}

GET Exibe os detalhes do Stack.


PUT Atualiza um Stack.


DELETE Deleta um Stack.

/v1/{tenant_id}/stacks/{stack_name}/{stack_id}/snapshots POST Cria uma imagem temporal (Snap

Shot) do Stack. Similar ao conceito de cópia de segurança.

/v1/{tenant_id}/stacks/{stack_name}/{stack_id}/snapshots GET Lista os snapshots do Stack.

/v1/{tenant_id}/stacks/{stack_name}/{stack_id}/snapshots/{snapshot_id}

DELETE Deleta o snapshot.

/v1/{tenant_id}/stacks/{stack_name}/{stack_id}/snapshots/{snapshot_id}/restore

POST Restaura o Stack ao estado salvo no snapshot.

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}/{container}

GET Exibe detalhes sobre o Container e lista os objetos armazenados ordenados pelo atributo “name”.


PUT Cria um Container.


DELETE Deleta um Container.

/v1/{account}/{container}/{object}

GET Efetua o download do Object.


PUT Cria ou atualiza o Object.


COPY Copia o Object.


DELETE Deleta o Object.


HEAD Exibe os meta dados vinculados ao Object.


POST Cria ou atualiza objetos de meta dados relacionados ao 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

7https://aws.amazon.com/pt/ec2/ 8http://www8.hp.com/us/en/cloud/helion-eucalyptus-overview.html 9https://www.cloudsigma.com/ 10https://www.rackspace.com/pt-br/cloud

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

11https://pt.wikipedia.org/wiki/JavaScript 12 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.

13https://docs.puppet.com/guides/introduction.html 14https://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

15http://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.

https://cloud.lab.fiware.org/

https://cloud.lab.fiware.org/

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 Iot-

Discovery 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.

http://aeon-platform.readthedocs.io/en/latest/

É 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/fiware-

cloud-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.

https://github.com/atos-ari-aeon/fiware-cloud-messaging-sdk/tree/master/SDK/java/src/example

https://github.com/atos-ari-aeon/fiware-cloud-messaging-sdk/tree/master/SDK/java/src/example

http://10.7.31.32:8080/

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-messaging-

sdk/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-

name/consumer

Enviar evento para um

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-9f46-

d0e9431fe215","DetectionTime":"1350311378034"}

● API para gerenciamento do repositório de definições

Verbo

HTTP

Exemplo URI Descrição

GET /{CEP_Admin}/resources/definitions Recuperar todas as

definições existentes

no repositório

POST /{CEP_Admin}/resources/definitions Adicionar uma nova

definição

GET /{CEP_Admin}/resources/definitions/{de

finition_name}

Recuperar a definição

completa no formato

JSON

PUT /{CEP_Admin}/resources/definitions/{de

finition_name

Substituir o conteúdo

de uma definição

existente por novos

conteúdos

DELETE /{CEP_Admin}/resources/definitions/{de

finition_name}

Remover uma

definição do

repositório

Tabela 17 - Operações da API para gerenciar as definições

5.2.3. Exemplo de uso

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, disponível em

https://github.com/Fiware/tutorials.TourGuide-

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\/2016-

19:10:45","Duration":"0.0","Annotation":"","entityId":"SENSOR_TEMP_ul20client_ACPI_0

_Thermal","EventId":"857e6f02-95ab-41e4-9844-

8605c24bcf21","DetectionTime":"19\/07\/2016-19:10:45","temperature":"25"}

● Temperatura alta:

{"Cost":"0.0","Certainty":"0.0","Name":"HighTemperatureAlert","EventSource":"","Occurren

ceTime":"29\/02\/2016-

19:13:31","Duration":"0.0","Annotation":"","entityId":"SENSOR_TEMP_ul20client_ACPI_1

_Thermal","EventId":"65367f5b-775a-4c01-8cb9-

c444fd84d66e","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.

5.3.3. Exemplo de uso e Problemas Encontrados

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 'Fiware-ServicePath: /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://fiware-

cygnus.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, pretende-

se 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

5.4.3. Exemplo de uso e Problemas Encontrados 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

http://catalogue.fiware.org/enablers/stream-oriented-kurento

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 .

http://builds.kurento.org/dev/master/latest/docs/introducing_kurento.html

https://webrtc.org/

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).

5.5.3. Exemplo de uso

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.

http://doc-kurento.readthedocs.io/en/stable/tutorials/java/tutorial-helloworld.html

http://doc-kurento.readthedocs.io/en/stable/tutorials/java/tutorial-helloworld.html

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

https://translate.googleusercontent.com/translate_c?act=url&depth=1&hl=pt-BR&ie=UTF8&prev=_t&rurl=translate.google.com.br&sl=en&tl=pt-BR&u=http://doc-kurento.readthedocs.io/en/stable/glossary.html&usg=ALkJrhj-4HB_2uUv8JQu65RY4qT3jV60qg#term-media-pipeline

https://translate.googleusercontent.com/translate_c?act=url&depth=1&hl=pt-BR&ie=UTF8&prev=_t&rurl=translate.google.com.br&sl=en&tl=pt-BR&u=http://doc-kurento.readthedocs.io/en/stable/glossary.html&usg=ALkJrhj-4HB_2uUv8JQu65RY4qT3jV60qg#term-media-element



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.

http://docs.ckan.org/en/latest/contents.html

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, pode-

se 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); } } catch (Exception ex) { 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); } catch (Exception ex) { 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-A16.

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.

http://imd.com/Rooms

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).

http://imd.com/Admninistration

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-

http://iot-broker/ngsi10/contextEntities/Room1

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.

http://iot-broker/ngsi10/contextEntities/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-a5fa-ea6857725b52&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:

https://github.com/telefonicaid/fiware-figway/tree/master/python-IDAS4

http://pt.slideshare.net/FI-WARE/fiware-iotidasintroul20v2?qid=15d9416e-69a1-441b-a5fa-ea6857725b52&v=&b=&from_search=1

http://pt.slideshare.net/FI-WARE/fiware-iotidasintroul20v2?qid=15d9416e-69a1-441b-a5fa-ea6857725b52&v=&b=&from_search=1

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 FI-

WARE, 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 Cepheus18.

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 http://catalogue.fiware.org/enablers/iot-data-edge-consolidation-ge-cepheus 18 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

/v1/admin/config

GET Consulta a configuração salva.

POST Salva uma nova configuração.

DELETE Remove a configuração atual.

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 Cepheus-

Broker, 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

Fonte: http://fiware-cepheus.readthedocs.io/en/latest/broker/index.html 7.5.1.2.2 Pub/Sub

As operações de subscrição (inscrição) e publicação (notificação) entre o Cepheus-

Broker 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

Fonte: http://fiware-cepheus.readthedocs.io/en/latest/broker/index.html 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 Cepheus-

Broker, 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:


Descrição

/users/:id

GET Acessa uma usuário passando o id como parâmetro

/user?access_token=12342134234023437

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

20http://saml.xml.org/saml-specifications 21 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 Apiary22.

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 Oltu23.

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 http://docs.keyrock.apiary.io/ 23 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 guia24 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ção25.

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

Descrição Caminho Cabeçalho Corpo

25 https://docs.oasis-open.org/xacml/3.0/xacml-3.0-core-spec-os-en.html

POST Adiciona domínio.

- /domains - Content-Type: application/xml; charset=UTF-8

- Accept: application/xml

PUT Atualiza propriedades do domínio.

- /domains/{domainId}/properties

- Content-Type: application/xml; charset=UTF-8

- Accept: application/xml; charset=UTF-8

Novas propriedades.

GET Obtém uma lista dos domínios existentes.

- /domains/{domainId}/properties


DELETE Deleta domínio.

- /domains/{domain_ID}


- 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}/authzforce-

ce/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 /domains/iMnxv7sDEeWFwqVFFMDLTQ/properties HTTP/1.1 Accept: application/xml; charset=UTF-8

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; charset=UTF-8

Content-Type: application/xml; charset=UTF-8


<domainProperties

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:


<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 --verbose --request DELETE \ --header "Content-Type: 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 Caminho Cabeçalho Corpo

POST Adiciona e atualiza políticas a um domínio.

- /domains/{domainId}/pap/policies



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.

- /domains/{domainId}/pap/policies/{policyId}

- /domains/{domainId}/pap/policies/{policyId}/{version}

- /domains/{domainId}/pap/policies


DELETE Deleta políticas ou todas as versões de uma política de de um domínio.

- /domains/{domainId}/pap/policies/{policyId}

- /domains/{domainId}/pap/policies/{policyId}/{version}


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




<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-combining-

algorithm: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:deny-

unless-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" Effect="Permit">

<Description>Only MissionManager role authorized to manage the mission

team</Description>

<Target>

<AnyOf>

<AllOf>


<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>


<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 FunctionId="urn:oasis:names:tc:xacml:3.0:function:any-of">

<Function FunctionId="urn:oasis:names:tc:xacml:1.0:function:string-equal" />

<AttributeValue

DataType="http://www.w3.org/2001/XMLSchema#string">MissionManager</AttributeValue>

<AttributeDesignator AttributeId="urn:oasis:names:tc:xacml:2.0:subject:role"

DataType="http://www.w3.org/2001/XMLSchema#string" 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 OK



<ns3:link 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 é, deve-

se 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 OK



<ns2:resources



<ns3:link rel="item" href="1.0"/>





...

</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



<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, lembre-

se 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 ataque26 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;

26http://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/FIWARE.OpenSpecification.Security.CyberSecurity

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 AuthZForce27 para criação de

domínio, ao executar a instrução CURL (configurado conforme foi especificado na seção 7.6.4)

27https://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.

28https://docs.fuel-infra.org/fuel-dev/develop/nailgun.html 29https://docs.fuel-infra.org/fuel-dev/develop/env.html#astute 30https://www.mirantis.com/products/mirantis-openstack-software/

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 Lista os Flavors do nó FIWARE monitorado.

List Volumes Lista os Flavors do nó FIWARE monitorado.

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 (SLA-

Service, 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 Radicale31é 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

31http://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 FI-

Toolkit 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 33 https://wiki.openstack.org/wiki/Telemetry 34 https://wiki.openstack.org/wiki/Monasca

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 OPS-

Deploy 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

35http://h10032.www1.hp.com/ctg/Manual/c01711840 36https://www.vmware.com/br/products/vsphere-hypervisor.html 37 http://consiste.dimap.ufrn.br/

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 FI-

Open-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.OpenSpecification.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.OpenSpecification.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-sparql-query/ 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.

https://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/FIWARE.OpenSpecification.Data.ContextBroker

https://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/FIWARE.OpenSpecification.Data.ContextBroker

http://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/FIWARE.OpenSpecification.IoT.Backend.IoTDiscovery

http://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/FIWARE.OpenSpecification.IoT.Backend.IoTDiscovery

https://www.w3.org/TR/rdf-sparql-query/

https://www.w3.org/TR/rdf-sparql-query/

https://forge.fiware.org/



http://docs.openstack/

http://cssoss.files.wordpress.com/2012/05/openstackbookv3-0_csscorp2.pdf

http://docs.openstack.org/admin-guide/

http://developer.openstack.org/api-ref.html

[13] Identity Management GE. Disponível em https://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/FIWARE.ArchitectureDescription.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 https://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/FIWARE.ArchitectureDescription.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 https://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/FIWARE.ArchitectureDescription.Security.CyberSecurity. Acessado em 21 de julho de 2016.

[18] Trustworthy Factory GE. Disponível em https://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/FIWARE.ArchitectureDescription.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-authorization-and-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-authorization-and-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/. Acessado em 05 de julho de 2016.

[22] User And Programmers Guide. Disponível em https://github.com/authzforce/fiware/blob/master/doc/UserAndProgrammersGuide.rst. Acessado em 05 de julho de 2016.

[23] Installation And Administration Guide. Disponível em https://github.com/authzforce/fiware/blob/master/doc/InstallationAndAdministrationGuide.rst. Acessado em 05 de julho de 2016.

[24] Course: PEP Proxy - Wilma GE. Disponível em https://edu.fiware.org/course/view.php?id=131. Acessado em 21 de julho de 2016.

[25] Course: Authorization PDP. Disponível em https://edu.fiware.org/course/view.php?id=144. Acessado em 21 de julho de 2016.

https://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/FIWARE.ArchitectureDescription.Security.IdentityManagement

https://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/FIWARE.ArchitectureDescription.Security.IdentityManagement

https://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/FIWARE.ArchitectureDescription.Security.AuthorizationPDP

https://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/FIWARE.ArchitectureDescription.Security.AuthorizationPDP

http://fiware-pep-proxy.readthedocs.io/en/latest/user_guide/

https://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/FIWARE.ArchitectureDescription.Security.CyberSecurity

https://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/FIWARE.ArchitectureDescription.Security.CyberSecurity

https://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/FIWARE.ArchitectureDescription.Security.TrustworthyFactory

https://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/FIWARE.ArchitectureDescription.Security.TrustworthyFactory

https://testfiwaretour.readthedocs.io/en/feature-add_deep_dive/handling-authorization-and-access-control-to-apis/how-to-implement-oauth2-in-your-applications/

https://testfiwaretour.readthedocs.io/en/feature-add_deep_dive/handling-authorization-and-access-control-to-apis/how-to-implement-oauth2-in-your-applications/

https://testfiwaretour.readthedocs.io/en/feature-add_deep_dive/handling-authorization-and-access-control-to-apis/how-to-send-requests-to-a-fiware-ge/

https://testfiwaretour.readthedocs.io/en/feature-add_deep_dive/handling-authorization-and-access-control-to-apis/how-to-send-requests-to-a-fiware-ge/

http://authzforce-ce-fiware.readthedocs.io/en/release-5.3.0a/

https://github.com/authzforce/fiware/blob/master/doc/UserAndProgrammersGuide.rst

https://github.com/authzforce/fiware/blob/master/doc/InstallationAndAdministrationGuide.rst

https://github.com/authzforce/fiware/blob/master/doc/InstallationAndAdministrationGuide.rst

https://edu.fiware.org/course/view.php?id=131

https://edu.fiware.org/course/view.php?id=144

[26] Handling authorization and access control to apis: Introduction. Disponível em https://testfiwaretour.readthedocs.io/en/feature-add_deep_dive/handling-authorization-and-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.SelfServiceInterfaces. 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/fiware- maintenance-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.

https://testfiwaretour.readthedocs.io/en/feature-add_deep_dive/handling-authorization-and-access-control-to-apis/introduction/

https://testfiwaretour.readthedocs.io/en/feature-add_deep_dive/handling-authorization-and-access-control-to-apis/introduction/

http://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/FIWARE.ArchitectureDescription.Cloud.SelfServiceInterfaces




https://forge.fiware.org/docman/view.php/

https://forge.fiware.org/plugins/mediawiki

http://murano.readthedocs.io/en/stable-kilo/

https://forge.fiware.org/plugins/mediawiki/

https://www.fiware.org/fiware-operations/

https://account.lab.fiware.org/

https://github.com/SmartInfrastructures/fuel-main-dev/blob/si/4.0/README.md

https://github.com/SmartInfrastructures/fuel-main-dev/blob/si/4.0/README.md

http://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php

https://github.com/Atos-FiwareOps/sla-dashboard

https://github.com/Atos-FiwareOps/fiware-

http://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/FI-Health

http://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/FI-Health

https://forge.fiware.org/plugins/mediawiki/wiki

https://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/Authorization_PDP_-_AuthZForce_-_Installation_and_Administration_Guide_(R4.2.0)

https://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/Authorization_PDP_-_AuthZForce_-_Installation_and_Administration_Guide_(R4.2.0)

[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 https://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/FIWARE.ArchitectureDescription.Apps.RSS. Acessado em 30 de julho de 2016.

[43] Store Documentation. Disponível em https://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/FIWARE.ArchitectureDescription.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_Applications,_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 https://forge.fiware.org/plugins/mediawiki/wiki/fiware/index.php/FIWARE.ArchitectureDescription.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/onf-

specifications/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-qos-

qualidade-de-servico . Acesso em: 31 de maio de 2016.

https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow-spec-v1.5.0.pdf

https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-specifications/openflow/openflow-spec-v1.5.0.pdf

https://pt.wikipedia.org/wiki/Middleware

Habilitadores Genéricos da Plataforma FIWARE -...

Documents

Transcript of Habilitadores Genéricos da Plataforma FIWARE -...