SERVIÇOS WEB

A camada de Serviços de suporte foi implementada a partir da disponibilização de uma API web seguindo os princípios de uma arquitetura orientada à serviços no modelo RESTful, a qual utiliza o protocolo HTTP na comunicação na porta 4200. Esta API implementa os fluxos de comunicação propostos no modelo, alguns dos requisitos básicos pertinentes ao ambiente simulado, incluindo requisitos relativos a segurança.

Para implementação de mecanismos de segurança e privacidade no servidor HTTP, através do uso de tokens, foi utilizado o formato JSON Web Token. Sendo que em toda autenticação de sucesso no servidor, um novo token é gerado e neste pode conter diversas informações, como exemplo, os recursos em que o usuário e/ou dispositivo IoT que executou login está autorizado a acessar, bem como, informações sobre URL de conexão para envio de dados.

O formato JSON é o padrão definido para todos os serviços implementados neste servidor. E para cada recurso (URI) disponibilizado, o token gerado deve ser enviado junto na requisição, somente assim os serviços permitirão a execução da ação solicitada, caso contrário, o mecanismo de segurança implementado com Passport.JS irá identificar a falta de permissão necessária para acesso ao recurso e irá realizar o bloqueio da chamada, retornando detalhes do problema ocorrido. Exceto os serviços web de registro e o de autenticação, estes devem ser requisitados em um processo anterior a geração do token, devido à necessidade prévia de identificação e autorização do dispositivo ao ambiente desenvolvido.

Contudo, na processo de codificação e decodificação do token é necessário que uma senha seja definida para realizar tal procedimento, para este ambiente a senha é “iotSimulatorPlataformKey”, conforme é possível ver em maiores detalhes no APÊNDICE C. Os serviços web desenvolvidos e disponibilizados no servidor HTTP estão detalhados no Quadro 5.

Quadro 5 – Detalhamento dos serviços web desenvolvidos URI Método HTTP Descrição Resposta /api/register POST registra o dispositivo armazenando seu código e realizando anotações

semânticas dos metadados do dispositivo.

usuário e senha são retornados na resposta da chamada, para que o dispositivo possa realizar a autenticação no ambiente IoT desenvolvido.

/api/authentication/login POST autentica dispositivo IoT e fornece as autorizações de acesso e configurações. recebe usuário e senha e valida na base de dados

Positiva: Retorna o token e a URL em que o dispositivo deve enviar seus dados, para que fique dinâmico o destino dos dados a cada

autenticação.

Negativa: Retorna mensagem de erro. /api/device-data POST salva dados recebidos do

dispositivo IoT: realiza

anotações semântica e publicar dados na base de conhecimento (triple store).

Positiva: Retorna mensagem de sucesso

Negativa: Retorna mensagem de erro com detalhes sobre o problema.

/api/device-data/:código GET obtém dados mais atuais de um sensor via consulta SPARQL na base de conhecimento

Retorna objeto JSON com os resultados da consulta

O serviço web de registro do dispositivo IoT tem por objetivo “conectar” o dispositivo ao ambiente IoT desenvolvido. O registro é efetivado a partir do envio dos metadados do dispositivo, em formato JSON previamente definido, conforme apresentado na Figura 30.

Fonte: O autor (2019)

Uma vez que o dispositivo realizar o registro, será gerado um código de identificação que é retornado na resposta da requisição, juntamente com as credenciais (usuário e senha) de acesso, para que seja possível a realização da autenticação e obtenção do token que possibilitará a comunicação com o serviço de envio de dados.

O serviço web de autenticação tem por objetivo atender tanto a camada de Dispositivo IoT quanto a camada de Apresentação. Sendo que os dispositivos necessitam da autenticação para enviar os dados de sensores e informações relativas aos recursos disponíveis, e também usuários poderão estar autenticando para acessar informações da camada de serviços de suporte. Ambas as comunicações devem ocorrer através do envio de token gerado pelo serviço de autenticação.

Na requisição da autenticação é necessário o envio dos parâmetros de usuário e senha, para que sejam validados pelo servidor HTTP. Em caso de sucesso na validação, um token no formato Bearer é repassado na resposta à requisição deste serviço, e caso as credenciais fornecidas não sejam válidas, uma mensagem de erro é retornada. Um exemplo da mensagem JSON de resposta com o token gerado e com a URL para envio dos dados, no caso de sucesso na autenticação, é demonstrado na Figura 31.

Fonte: O autor (2019)

Somente após o recebimento do token que é possível requisitar o demais serviços web disponíveis como o de envio de dados, por exemplo. Contudo, sempre deve ser enviado o token juntamente nestas requisições, através do parâmetro “Authorization” do cabeçalho de HTTP, contendo o valor valor composto do texto “Bearer”, um caracter de espaço, e mais o token recebido na resposta da autenticação, conforme desmonstrado na Figura 32.

Fonte: O autor (2019)

Caso o token não seja recebido nos demais serviços, é retornada uma mensagem comunicando o problema relativo a autorização de acesso. Este mecanismo se aplica a qualquer novo serviço a ser implementado na solução que exija verificação e validação de acesso.

Sobre o serviço web de envio de dados do dispositivo para o ambiente IoT, este além da validação do token de segurança, também exige que os dados sejam enviados no formato JSON, seguindo a estrutura definida previamente e apresentada na Figura 33.

Figura 31 - Exemplo de JSON recebido na resposta sucesso na autenticação

Figura 33 - Estrutura JSON de envio ao serviço web de inserção de dados

Fonte: O autor (2019)

O serviço de obtenção dos dados mais atuais dos sensores foi desenvolvido para funcionar de forma dinâmica de acordo com o parâmetro recebido na URI da requisição. Este parâmetro trata-se do código de identificação do dispositivo IoT, sendo utilizado na consulta SPARQL realizada na base de conhecimento.

Os serviços de envio e obtenção de dados foram implementados no mesmo arquivo, em funções separadas, conforme é possível visualizar estes métodos no APÊNDICE D.