Conhecendo o MQTT

Por que o MQTT é um dos melhores protocolos de rede para a Internet das Coisas?

Para os dispositivos de Internet das Coisas (IoT), a conexão com a Internet é um requisito. A conexão com a Internet permite que os dispositivos trabalhem entre si e com serviços de backend. O protocolo de rede subjacente da Internet é o TCP/IP. Desenvolvido com base na pilha TCP/IP, o MQTT (Message Queue Telemetry Transport) tornou-se o padrão para comunicações de IoT.

O MQTT foi inventado e desenvolvido inicialmente pela IBM no final dos anos 90. Sua aplicação original era vincular sensores em pipelines de petróleo a satélites. Como seu nome sugere, ele é um protocolo de mensagem com suporte para a comunicação assíncrona entre as partes. Um protocolo de sistema de mensagens assíncrono desacopla o emissor e o receptor da mensagem tanto no espaço quanto no tempo e, portanto, é escalável em ambientes de rede que não são confiáveis. Apesar de seu nome, ele não tem nada a ver com filas de mensagens, na verdade, ele usa um modelo de publicação e assinatura. No final de 2014, ele se tornou oficialmente um padrão aberto OASIS, com suporte nas linguagens de programação populares, usando diversas implementações de software livre.

Por que o MQTT

O MQTT é um protocolo de rede leve e flexível que oferece o equilíbrio ideal para os desenvolvedores de IoT:

  • O protocolo leve permite a implementação em hardware de dispositivo altamente restringido e em redes de largura da banda limitada e de alta latência.
  • Sua flexibilidade possibilita o suporte a diversos cenários de aplicativo para dispositivos e serviços de IoT.

Para entender por que o MQTT é tão adequado para desenvolvedores de IoT, vamos analisar por que outros protocolos de rede populares falharam em IoT.

Por que não usar algum dos outros inúmeros protocolos de rede

A maioria dos desenvolvedores já se acostumou aos serviços da Web HTTP. Então, por que não conectar os dispositivos de IoT aos serviços da web? O dispositivo poderia enviar seus dados como uma solicitação de HTTP e receber atualizações do sistema como uma resposta de HTTP. Esse padrão de solicitação e resposta tem algumas limitações graves:

  • O HTTP é um protocolo síncrono. O cliente espera que o servidor responda. Os navegadores da web têm esse requisito, mas o custo é a baixa escalabilidade. No mundo da IoT, a comunicação síncrona tem sido um problema devido ao grande número de dispositivos e à rede, muitas vezes não confiável e de alta latência. Um protocolo de mensagem assíncrono é muito mais adequado para aplicativos de IoT. Os sensores podem enviar leituras e permitir que a rede descubra o caminho e a sincronização ideais para entregar aos dispositivos e serviços de destino.
  • HTTP é unidirecional. O cliente precisa iniciar a conexão. Em um aplicativo de IoT, os dispositivos e sensores geralmente são clientes, o que significa que eles não podem receber comandos da rede passivamente.
  • HTTP é um protocolo de um para um. O cliente faz uma solicitação e o servidor responde. É difícil e caro transmitir uma mensagem a todos os dispositivos na rede, o que é um caso de uso comum em aplicativos de IoT.
  • HTTP é um protocolo pesado com muitos cabeçalhos e regras. Ele não é adequado para redes restringidas.

Pelos motivos citados acima, a maioria dos sistemas escaláveis de alto desempenho usam um barramento do sistema de mensagens assíncrono, em vez de serviços da web, para trocas de dados internas. Na verdade, o protocolo de sistema de mensagens mais popular que é usado em sistemas de middleware corporativos é chamado AMQP (Advanced Message Queuing Protocol). No entanto, no ambiente de alto desempenho, a capacidade de computação e a latência da rede geralmente não são uma preocupação. O AMQP foi criado para assegurar a confiabilidade e a interoperabilidade em aplicativos corporativos. Ele possui um rico conjunto de recursos, mas não é adequado para aplicativos de IoT com restrição de recursos.

Além do AMQP, existem outros protocolos populares de sistema de mensagens. Por exemplo, o XMPP (Extensible Messaging and Presence Protocol) é um protocolo de mensagem instantânea (IM) ponto a ponto. Ele é pesado em recursos com suporte para casos de uso de IM, como presença e anexos de mídia. Em comparação com o MQTT, ele requer muito mais recursos no dispositivo e na rede.

Então, como o MQTT consegue ser tão leve e flexível? Um importante recurso do protocolo MQTT é o modelo de publicação e assinatura. Como em todos os protocolos de sistema de mensagens, ele desacopla o publicador e o consumidor de dados.

O modelo de publicação e assinatura

O protocolo MQTT define dois tipos de entidades na rede: um message broker e inúmeros clientes. O broker é um servidor que recebe todas as mensagens dos clientes e, em seguida, roteia essas mensagens para os clientes de destino relevantes. Um cliente é qualquer coisa que possa interagir com o broker e receber mensagens. Um cliente pode ser um sensor de IoT em campo ou um aplicativo em um data center que processa dados de IoT.

  1. O cliente conecta-se ao broker. Ele pode assinar qualquer “tópico” de mensagem no broker. Essa conexão pode ser uma conexão TCP/IP simples ou uma conexão TLS criptografada para mensagens sensíveis.
  2. O cliente publica as mensagens em um tópico, enviando a mensagem e o tópico ao broker.
  3. Em seguida, o broker encaminha a mensagem a todos os clientes que assinam esse tópico.

Como as mensagens do MQTT são organizadas por tópicos, o desenvolvedor de aplicativos tem a flexibilidade de especificar que determinados clientes somente podem interagir com determinadas mensagens. Por exemplo, os sensores publicarão suas leituras no tópico “sensor_data” e assinarão o tópico “config_change”. Os aplicativos de processamento de dados que salvam os dados do sensor em um banco de dados de backend assinarão o tópico “sensor_data”. Um aplicativo de console administrativo poderia receber comandos do administrador do sistema para ajustar as configurações dos sensores, como a sensibilidade e a frequência de amostragem, e publicar essas mudanças no tópico “config_change”. (Consulte Figura 1.)

Figura 1. O modelo de publicação e assinatura do MQTT para sensores de IoT

Ao mesmo tempo, o MQTT é leve. Ele tem um cabeçalho simples para especificar o tipo de mensagem, um tópico baseado em texto e, em seguida, uma carga útil binária arbitrária. O aplicativo pode usar qualquer formato de dados para a carga útil como JSON, XML, binário criptografado ou Base64, desde que os clientes de destino possam analisar a carga útil.

Introdução ao desenvolvimento com MQTT

A ferramenta mais fácil para começar o desenvolvimento com MQTT é o módulo Python mosquitto, que faz parte do projeto Eclipse Paho e fornece SDKs e bibliotecas do MQTT em várias linguagens de programação. Ele contém um broker do MQTT que pode ser executado no computador local e ferramentas de linha de comandos que podem interagir com o broker usando mensagens. É possível fazer download e instalar o módulo mosquitto no website do mosquitto.

O comando mosquitto executa o broker do MQTT no computador local. Opcionalmente, é possível usar a opção -d para executá-lo em segundo plano.

$ mosquitto -d

Em seguida, em outra janela do terminal, é possível usar o comando mosquitto_sub para conectar-se ao broker local e assinar um tópico. Após a execução do comando, ele vai esperar e imprimir todas as mensagens que receber da assinatura, à medida que elas forem chegando.

$ mosquitto_sub -t "dw/demo"

Em uma outra janela do terminal, é possível usar o comando mosquitto_pub para conectar-se ao broker local e, em seguida, publicar uma mensagem em um tópico.

$ mosquitto_pub -t "dw/demo" -m "hello world!"

Agora, o terminal que executa o mosquitto_sub deverá exibir “hello world!” na tela. Você acabou de enviar e receber uma mensagem usando um broker do MQTT!

É claro que em um sistema de produção, não é possível usar um computador local como o broker. Nesse caso, é possível usar o Serviço da plataforma Internet das Coisas do IBM Bluemix, que é um serviço sob demanda e confiável que funciona como um broker do MQTT. (Leia mais sobre como esse serviço do Bluemix se integra e usa o MQTT como seu protocolo para comunicar-se com dispositivos e aplicativos na documentação do serviço.)

O nó Serviço da plataforma Internet das Coisas do IBM Bluemix funciona da seguinte forma.

  • No console do Bluemix, é possível criar uma instância do serviço da plataforma Internet das Coisas sob demanda.
  • Em seguida, é possível incluir dispositivos que possam conectar a instância de serviço usando o MQTT. Cada dispositivo terá um ID e um nome. Somente os dispositivos listados podem acessar o serviço, e o painel da plataforma Watson IoT relatará informações sobre tráfego e uso desses serviços, nos respectivos dispositivos.
  • Para cada cliente do dispositivo, o Bluemix designará um nome do host, um nome de usuário e uma senha para a conexão com a instância de serviço (o broker do MQTT). (No Bluemix, o nome de usuário sempre é use-token-auth e a senha é o token que é mostrado na Figura 2 para cada dispositivo conectado.)
Figura 2. Criando uma instância de serviço da plataforma Internet das Coisas no IBM Bluemix

Ao usar um broker remoto do MQTT, será necessário passar pela aprovação das credenciais de autenticação e de nome do host do broker para os comandos mosquitto_sub e mosquitto_pub. Por exemplo, o comando a seguir assina o tópico de demonstração no nosso serviço da plataforma Internet das Coisas com o nome de usuário e senha fornecidos pelo Bluemix:

$ mosquitto_sub -t "demo" -h host.iotp.mqtt.bluemix.com -u username -P password

Para conhecer mais opções de como usar as ferramentas do mosquitto e também de como usar a API do mosquitto para criar seus próprios aplicativos clientes do MQTT, consulte a documentação no website do mosquitto.

Agora que você já tem as ferramentas necessárias, vamos nos aprofundar no protocolo MQTT.

Entendendo o protocolo MQTT

O MQTT é um protocolo de ligação que especifica como os bytes de dados são organizados e transmitidos pela rede TCP/IP. Mas por motivos práticos, os desenvolvedores não precisam entender o protocolo de ligação. Basta saber que cada mensagem tem uma carga útil de comando e dados. O comando define o tipo de mensagem (por exemplo, uma mensagem CONNECT ou uma mensagem SUBSCRIBE). Todas as bibliotecas e ferramentas do MQTT oferecem maneiras simples de manipular essas mensagens diretamente e podem preencher automaticamente alguns campos necessários, como os IDs da mensagem e do cliente.

Primeiro, o cliente conecta-se ao broker enviando uma mensagem CONNECT. A mensagem CONNECT pede para estabelecer uma conexão do cliente com o broker. A mensagem CONNECT tem os parâmetros de conteúdo a seguir.

Tablela 1. Parâmetros da mensagem CONNECT
Parâmetro Descrição
cleanSession Esta sinalização especifica se a conexão é persistente ou não. Uma sessão persistente armazena todas as assinaturas e as mensagens possivelmente perdidas (dependendo do QoS) no broker. (Consulte Tablela 3 para obter uma descrição do QoS).
username As credenciais de autenticação e autorização do broker.
password As credenciais de autenticação e autorização do broker.
lastWillTopic Quando a conexão for encerrada inesperadamente, o broker publicará automaticamente uma mensagem de “último desejo” em um tópico.
lastWillQos O QoS da mensagem de “último desejo”. (Consulte Tablela 3 para obter uma descrição do QoS).
lastWillMessage A própria mensagem de “último desejo”.
keepAlive Este é o intervalo de tempo em que o cliente precisa efetuar ping no broker para manter a conexão ativa.

O cliente receberá uma mensagem CONNACK do broker. A mensagem CONNACK tem os parâmetros de conteúdo a seguir.

Tablela 2. Parâmetros da mensagem CONNACK
Parâmetro Descrição
sessionPresent Indica se a conexão já tem uma sessão persistente. Ou seja, a conexão já tem tópicos assinados e receberá a entrega de mensagens ausentes.
returnCode 0 indica sucesso. Outros valores identificam a causa da falha.

Depois que uma conexão for estabelecida, o cliente poderá enviar uma ou mais mensagens SUBSCRIBE ao broker para indicar que ele receberá mensagens do broker de determinados tópicos. A mensagem pode ter uma ou várias repetições dos parâmetros a seguir.

Tablela 3. Parâmetros da mensagem SUBSCRIBE
Parâmetro Descrição
qos A sinalização qos (qualidade de serviço ou QoS) indica com que consistência as mensagens neste tópico precisam ser entregues aos clientes.

  • Valor 0: não confiável, a mensagem é entregue no máximo uma única vez, se o cliente estiver indisponível no momento, ele perderá a mensagem.
  • Valor 1: a mensagem deve ser entregue pelo menos uma vez.
  • Valor 2: a mensagem deve ser entregue exatamente uma vez.
tópico Um tópico para assinar. Um tópico pode ter vários níveis separados pelo caractere barra. Por exemplo, “dw/demo” e “ibm/bluemix/mqtt” são tópicos válidos.

Depois que o cliente tiver assinado um tópico com sucesso, o broker retornará uma mensagem SUBACK com um ou mais parâmetros returnCode.

Tablela 4. Parâmetros da mensagem SUBACK
Parâmetro Descrição
returnCode Existe um código de retorno para cada um dos tópicos no comando SUBSCRIBE. Os valores de retorno são os seguintes.

  • Valores 0 a 2: sucesso como nível de QoS correspondente. (Consulte Tablela 3 para saber mais sobre QoS.)
  • Valor 128: falha.

Correspondendo à mensagem SUBSCRIBE, o cliente também poderá UNSUBSCRIBE (cancelar a assinatura) de um tópico ou de vários tópicos.

Tablela 5. Parâmetros da mensagem UNSUBSCRIBE
Parâmetro Descrição
tópico Este parâmetro pode se repetir para vários tópicos.

O cliente pode enviar mensagens PUBLISH ao broker. A mensagem contém um tópico e uma carga útil de dados. Em seguida, o broker encaminha a mensagem a todos os clientes que assinam esse tópico.

Tablela 6. Parâmetros da mensagem PUBLISH
Parâmetro Descrição
topicName O tópico no qual a mensagem é publicada.
qos O nível de qualidade de serviço da entrega da mensagem. (Consulte Tablela 3 para obter uma descrição do QoS).
retainFlag Esta sinalização indica se o broker reterá a mensagem como a última mensagem conhecida deste tópica.
carga útil Os dados reais na mensagem. Pode ser uma sequência de texto ou um blob binário de dados.

Dicas e soluções alternativas

O poder do MQTT é a simplicidade. Não há restrições quanto ao tipo de tópico ou de carga útil de mensagem que se pode usar. Isso permite alguns casos de uso interessantes. Por exemplo, considere estas questões:

Como executar mensagens de um para um com o MQTT? Ambas as partes podem concordar em usar um tópico que seja exclusivo para elas. Por exemplo, o nome do tópico pode conter os IDs dos dois clientes para garantir sua exclusividade.

Como um cliente transmite seu status de presença? O sistema pode concordar com uma convenção de nomenclatura para tópicos de “presença”. Por exemplo, o tópico “presence/client-id” pode conter as informações de presença do cliente. O cliente define a mensagem como true quando se conecta e false quando se desconecta. O cliente também pode configurar uma mensagem de last will como false para ser definida quando a conexão for encerrada. A mensagem pode ser retida pelo broker para que novos clientes possam ler o tópico e descobrir o status de presença.

Como proteger as comunicações? A conexão do cliente com o broker pode ser uma conexão TLS criptografada para proteger os dados em trânsito. Além disso, como o protocolo MQTT não impõe restrições quanto ao formato de dados da carga útil, o sistema pode concordar com um método de criptografia e um mecanismo de atualização de chave. Depois disso, todo o conteúdo na carga útil pode ser dados binários criptografados das mensagens JSON ou XML reais.

Conclusão

Neste artigo eu ofereci uma introdução técnica ao protocolo MQTT. Você aprendeu o que é o MQTT, por que ele é adequado para aplicativos de IoT e como começar a desenvolver aplicativos que usam o MQTT.

Em um de meus próximos artigos, vou mostrar como desenvolver uma solução de sensor de IoT completa com serviços de MQTT de backend e usando uma placa NodeMCU.

Recursos

Recursos para download

Temas relacionados

Fonte:  https://www.ibm.com/developerworks/br/library/iot-mqtt-why-good-for-iot/index.html

Mosquitto e paho-mqtt-python

Mosquitto e paho-mqtt-python

Melhore a segurança do mosquito no Ubuntu 16.04 LTS

Instalar mosquito
> sudo apt-adicionar-repositório ppa: mosquitto-dev / mosquitto-ppa
> sudo apt-get atualizar
> sudo apt-get instalar mosquitto mosquitto-clients

Instalar o paho-mqtt-python
> pip install paho-mqtt

Configurar mosquito
> sudo vi /etc/mosquitto/mosquitto.conf
> wget https://github.com/eclipse/mosquitto/blob/master/mosquitto.conf

persistência true 
persistence_location / var / lib / mosquitto / 
allow_anonymous falso 
arquivo log_dest /var/log/mosquitto/mosquitto.log 
include_dir /etc/mosquitto/conf.d

Adicione a confoguração do mosquito
> sudo vi /etc/mosquitto/conf.d/default.conf

password_file / etc / mosquitto / passwd
ouvinte 1883 localhost
listener 8883 
certfile /etc/letsencrypt/live/[hostname]/fullchain.pem 
cafile /etc/letsencrypt/live/[hostname]/chain.pem 
keyfile /etc/letsencrypt/live/[hostname]/privkey.pem

Adicionar nome de usuário e senha do
mosquitto> mosquitto_passwd -c / etc / mosquitto / passwd [nome de usuário]
Senha: [senha]
Redigite a senha: [senha]

Teste com o assinante do mosquitto
> mosquitto_sub -h [hostname] -p 8883 –capath /etc/ssl/certs-t [topic] -q [qos] -c -i [clientid] -u [username] -P [senha]

Teste com o editor de mosquitos
> mosquitto_pub -h [hostname] -p 8883 –capath /etc/ssl/certs-t [topic] -m [message] -q [qos] -i [clientid] -u [username] -P [senha]

assinante paho-mqtt

 

import ssl
import sys

import paho.mqtt.client

def on_connect(client, userdata, flags, rc):
	print('connected (%s)' % client._client_id)
	client.subscribe(topic='[topic]', qos=2)

def on_message(client, userdata, message):
	print('------------------------------')
	print('topic: %s' % message.topic)
	print('payload: %s' % message.payload)
	print('qos: %d' % message.qos)

def main():
	client = paho.mqtt.client.Client(client_id='[clientid]', clean_session=False)
	client.username_pw_set('[username]', '[password]')
	client.on_connect = on_connect
	client.on_message = on_message
	client.tls_set('/etc/ssl/certs/DST_Root_CA_X3.pem', tls_version=ssl.PROTOCOL_TLSv1_2)
	client.connect(host='[hostname]', port=8883)
	client.loop_forever()

if __name__ == '__main__':
	main()
	sys.exit(0)

 

Configurar mosquito

>sudo vi /etc/mosquitto/mosquitto.conf
> wget https://github.com/eclipse/mosquitto/blob/master/mosquitto.conf

persistence true
persistence_location /var/lib/mosquitto/
allow_anonymous false
log_dest file /var/log/mosquitto/mosquitto.log
include_dir /etc/mosquitto/conf.d

Adicione a configuração do mosquito

password_file /etc/mosquitto/passwd
listener 1883 localhost
listener 8883
certfile /etc/letsencrypt/live/[hostname]/fullchain.pem
cafile /etc/letsencrypt/live/[hostname]/chain.pem
keyfile /etc/letsencrypt/live/[hostname]/privkey.pem
include_dir /etc/mosquitto/conf.d

Adicionar nome de usuário e senha do

> mosquitto_passwd -c /etc/mosquitto/passwd [username]
Password: [password]
Reenter password: [password]

 

Teste com o assinante do mosquitto

> mosquitto_sub -h [hostname] -p 8883 –capath /etc/ssl/certs -t [topic] -q [qos] -c -i [clientid] -u [username] -P [password]

 

Teste com o editor de mosquitos

> mosquitto_pub -h [hostname] -p 8883 –capath /etc/ssl/certs -t [topic] -m [message] -q [qos] -i [clientid] -u [username] -P [password]

Assinante paho-mqtt

import ssl
import sys

import paho.mqtt.client

def on_connect(client, userdata, flags, rc):
	print('connected (%s)' % client._client_id)
	client.subscribe(topic='[topic]', qos=2)

def on_message(client, userdata, message):
	print('------------------------------')
	print('topic: %s' % message.topic)
	print('payload: %s' % message.payload)
	print('qos: %d' % message.qos)

def main():
	client = paho.mqtt.client.Client(client_id='[clientid]', clean_session=False)
	client.username_pw_set('[username]', '[password]')
	client.on_connect = on_connect
	client.on_message = on_message
	client.tls_set('/etc/ssl/certs/DST_Root_CA_X3.pem', tls_version=ssl.PROTOCOL_TLSv1_2)
	client.connect(host='[hostname]', port=8883)
	client.loop_forever()

if __name__ == '__main__':
	main()
	sys.exit(0)

Editor paho-mqtt

import ssl
import sys

import paho.mqtt.client
import paho.mqtt.publish

def on_connect(client, userdata, flags, rc):
	print('connected')

def main():
	paho.mqtt.publish.single(
		topic='[topic]',
		payload='[message]',
		qos=2,
		hostname='[hostname]',
		port=8883,
		client_id='[clientid]',
		auth={
			'username': '[username]',
			'password': '[password]'
		},
		tls={
			'ca_certs': '/etc/ssl/certs/DST_Root_CA_X3.pem',
			'tls_version': ssl.PROTOCOL_TLSv1_2
		}
	)

if __name__ == '__main__':
	main()
	sys.exit(0)

 

erinus diz:

Se o seu assinante quiser receber todas as mensagens não lidas em um tópico após o início, você deverá concluir estas etapas:

Use o mesmo ID de cliente quando você inicia o assinante.
Use clean_session = False quando você inicia o assinante.
Use qos> 0 quando você assina um tópico.
Use qos> 0 quando você publicar uma mensagem.

Para tornar suas comunicações mais seguras, você deve concluir estas etapas:

Usar TLS 1.2
Set allow_anonymous = False
Habilitar autenticação com nome de usuário e senha

Se você quer mais métodos de autenticação, tente este plugin mosquitto:

https://github.com/jpmens/mosquitto-auth-plug

 

Fonte:  https://medium.com/@erinus/mosquitto-paho-mqtt-python-29cadb6f8f5c

 

 

 

 

Hyperledger

 

Hyperledger (ou o “Projeto Hyperledger”) é um projeto colaborativo envolvendo várias indústrias, iniciado em dezembro de 2015 pela Linux Foundation,[1] seu objetivo é suportar livros razão distribuídos com base na Blockchain. O seu foco é livros razão feitos para suportar transações de indústrias globais, incluindo as principais empresas de tecnologia, financeiras e logísticas, com o objetivo de melhorar vários aspectos da performance e robustez.[2] O projeto aspira unir um número de tentativas independentes para desenvolver protocolos e padrões abertos, provendo um framework modular que suporta componentes diferentes para usuários diferentes. Isso inclui uma variedade de blockchains, cada uma com seu consenso, modelos de persistência, e serviços para identidade, controle de acesso e contratos.

Histórico

Em Dezembro de 2015, a Linux Foundation anunciou a criação do projeto Hyperledger. Os primeiros fundadores do projeto foram anunciados em Fevereiro de 2016, e mais 10 membros que compõem o conselho de administração foram anunciados em 29 de Março.[3] Em 19 de Maio, Brian Behlendorf foi apontado como diretor executivo do projeto.[4]

No inicio de 2016, o projeto começou a aceitar propostas para bases de código e outras tecnologias a serem incubadas, para potencial inclusão como componentes centrais do Hyperledger. Uma das primeiras propostas foi para uma base de código que combina trabalhos prévios feitos pela Digital Asset Holdings (Blockstream’s libconsensus) e a OpenBlockchain da IBM.[5]Posteriormente, esse projeto foi renomeado para Fabric.[6] Em maio, o livro razão distribuído da Intel (Sawtooth) também foi incubado.[7]

Membros

Os primeiros membros da iniciativa incluem empresas que trabalham com blockchain (Blockchain, ConsenSysR3), outras empresas tecnológicas (CiscoDigital Asset HoldingsFujitsuHitachiIBMIntelNECNTT DATARed HatVMware), empresas financeiras (ABN AMROANZ BankBNY MellonCLS Group, CME GroupThe Depository Trust & Clearing Corporation (DTCC), Deutsche Börse GroupJ.P. MorganState StreetSWIFTWells Fargo), e outras (AccentureCalastone, Credits, GuardtimeIntellectEUSymbiont).

Motivação do projeto

Os primeiros membros da iniciativa incluem empresas que trabalham com blockchain (Blockchain, ConsenSysR3), outras empresas tecnológicas (CiscoDigital Asset HoldingsFujitsuHitachiIBMIntelNECNTT DATARed HatVMware), empresas financeiras (ABN AMROANZ BankBNY MellonCLS Group, CME GroupThe Depository Trust & Clearing Corporation (DTCC), Deutsche Börse GroupJ.P. MorganState StreetSWIFTWells Fargo), e outras (AccentureCalastone, Credits, GuardtimeIntellectEUSymbiont).

Motivação do projeto

De acordo com o Whitepaper do Hyperledger [8]:

As a fledgling technology, existing blockchain implementations have fallen short of meeting the multitude of requirements inherent in the complex world of business transactions. Scalability challenges, and the lack of support for confidential and private transactions, among other limitations, make its use unworkable for many business-critical applications. […] To meet the varied demands of the modern marketplace, Hyperledger has been designed for a broad array of industry-focused use cases, thereby extending the work of the pioneers in the field by addressing the existing shortcomings.

Em outras palavras, baseado no cenário atual de requisitos da indústria, foi identificado que as implementações atuais de blockchain não são suficientes. Problemas de escalabilidade, falta de suporte para transações privadas e outras limitações são citados como os principais culpados. A proposta do Hyperledger é justamente suprir esses requisitos a partir de uma série de casos de uso. A ideia também consiste de estender trabalhos existentes com o objetivo de mitigar as suas limitações. Vale destacar que o Hyperledger tem o foco na indústria, mais especificamente nas relações B2B e B2C.[8]

Objetivos

O objetivo principal do Hyperledger é criar uma plataforma útil, fácil de usar e robusta onde qualquer individuo interessado em construir um software baseado em blockchain pode usa-lá como base. Por motivos práticos, o Hyperledger pode nunca alcançar esse ideal que cobre todos os casos possíveis, mas o objetivo do time é chegar o mais perto possível.[8]

De maneira mais tangível, o projeto também define objetivos mais específicos como: modularidade, extensibilidade, facilidade de uso, variedade de métodos criptográficos. Cada um desses objetivos contribui para a visão geral do Hyperledger. Por exemplo, a modularidade contribui para a interoperabilidade entre sistemas que, por sua vez, potencializa a flexibilidade do projeto, e aumenta a cobertura de casos. A extensibilidade também contribui para aumentar a cobertura de novos casos, já que funcionalidades novas podem ser adicionadas.[8]

A conceito da modularidade é importante porque incentiva o desenvolvimento externo. Uma empresa não relacionada pode desenvolver novos módulos e contribuir para a melhora de módulos existentes. Generalizando, deve ser possível construir uma blockchain que não usa nenhum componente central do Hyperledger, mas ainda assim, se encaixar no seu framework. A troca de componentes a fim de satisfazer requisitos específicos também é um conceito central do Hyperledger. Por exemplo, alguns casos pedem um algoritmo rápido de consenso que requer alguma confiança, enquanto outros casos podem pedir menos velocidade com mais confiança.[8]

A extensibilidade e modularidade se provam como requisito central do projeto porque é inviável prever todos os usos futuros do Hyperledger e de tecnologias blockchain de uma maneira geral. Facilitar as contribuições externas pode incentivar o envolvimento de pessoas que contribuirão e usarão o Hyperledger.[8]

Requisitos propostos

Transações privadas e contratos confidenciais

O Hyperledger pretende suportar uma variedade de ferramentas criptográficas que devem garantir a presença de confidencialidade e privacidade. Essas ferramentas não devem prejudicar as propriedades de privacidade. Alguns casos de uso requerem confidencialidade mais básicas e otimizadas para performance que não são adequadas para o uso financeiro. O objetivo é suportar tanto o caso otimizado par performance quanto os casos mais sofisticados que pedem algoritmos criptográficos mais complexos.[8]

Identidade e auditabilidade

Em adição as transações privadas e confidenciais, o conceito de identidade baseado numa infraestrutura de chave pública completa os algoritmos criptográficos provendo a confidenciabilidade do Hyperledger. Além da infraestrutura de chave pública, o Hyperledger também deve prover suporte a uma documentação compreensível e imutável sobre essas identidades – incluindo os requisitos de confidenciabilidade associada a elas. O objetivo da documentação é suportar os casos que envolvem troca de identidade e auditoria. É importante notar que sempre deverá ser respeito o contrato inicial sobre a anonimidade da identidade. Por exemplo, se é previso que certa entidade é totalmente anonima, a documentação não incluirá nada que quebre esse acordo.[8]

Interoperabilidade

Como o Hyperledger propõe a utilização de vários componentes independentes, a interoperabilidade é proposta para que a interação entre esses elementos ocorra apesar de possíveis implementações fundamentalmente diferentes. Por exemplo, é esperado que haja a cooperação entre mais de um tipo de blockchain. Dessa forma, é dito que existe interação quando informação é trocada e utilizada por esses componentes. Para prover esse caso de uso, é definido um protocolo que permite a comunicação entre 2 ou mais blockchains.[8]

Portabilidade

A portabilidade em um nível de infraestrutura garante que o projeto Hyperledger funcione da mesma maneira em ambientes computacionais heterogêneos. O valor da portabilidade é explicitado ao ressaltar que o projeto deverá rodar com base numa grande combinação de blockchains, falhar em prover a portabilidade fere um principio geral do Hyperledger. A portabilidade em um nível de arquitetura tem significado parecido com o de modularidade: significa abstrair as interfaces dos componentes centrais para que não haja acoplamento de ambientes. Por exemplo, o componente de contratos inteligentes pode ser movido para uma unidade diferente de produção sem que haja necessidade de mudança a esse componente. [8]

Arquitetura

A arquitetura geral do Hyperledger consiste de 4 categorias:

  • Identidade (Identity)
  • Política (Policy)
  • Blockchain e contratos inteligentes (Smart Contracts)

De uma forma geral, essas categorias possuem responsabilidades específicas: a identidade é responsável por identificar as entidades participantes, a policy é responsável por regular o acesso e responsabilidades dessas entidades e o blockchain provê o serviço p2p que guarda o estado do sistema. Vale destacar que essas categorias são divisões lógicas do software e não necessariamente significam serviços fisicamente separados.[8]

Serviços de identidade

O requisito deste componente é identificar os componentes participantes da rede. Esses componentes incluem organizações participantes, validadores e transactors; Objetos contidos no livro razão e componentes mais tangíveis como: redes, servidores e ambiente de execuções.[8]

Serviços de política 

Os serviços de política permitem o gerenciamento das políticas de acesso ao sistema. Algumas dessas políticas incluem o gerenciamento do registro de novos membros e o controle de suas entradas e saídas. Esse serviço também é responsável pelo níveis de privacidade e as políticas de confiabilidade, responsabilidade e consenso. [8]

Blockchain

Os serviços de blockchain consistem de 3 partes:

  • Protocolo P2P.
  • Livro razão distribuído.
  • Gerenciador de Consenso.

O protocolo P2P funciona em cima da infraestrutura atual da internet e provê as capacidades de intercomunicação do sistema. O livro razão distribuído é a parte central do sistema e tem características parecidas com a de outros sistemas de criptomoedas. Por exemplo, o livro razão é responsável por manter e processar o estado do sistema e isso também é comum a bitcoin. Outras responsabilidades do livro razão distribuído sob o contexto do Hyperledger incluem: validar transações; calcular o hash de toda a base de dados de forma eficiente após cada bloco; minimizar a quantidade de dados necessários necessários para uma participante operar.[8]

Por fim, o gerenciador de consenso provê uma abstração para que outras partes do sistema utilizem os algoritmos de consenso de forma transparente. A ideia central é facilitar o uso e ao mesmo tempo prover um sistema flexível o suficiente para que novos procedimentos de consenso também possam ser adicionados.[8]

Incubação de projetos

Como um dos objetivos do Hyperledger é agregar contribuições externas, é adotada uma política de incubação para o gerenciamento dessas contribuições. Unidades de trabalhos são chamados de Projetos, e esses Projetos possuem um ciclo de vida [9]:

  • Proposta
  • Incubação
  • Maturidade
  • Depreciado
  • Fim de vida

Metodologias de gerenciamento similares são comuns a outros projetos open source, como o eclispe,[10] apache [11] e o OSGEO.[12] Até Julho de 2016, o Hyperledger possui dois projetos em fase de incubação, o Fabric e o Sawtooth.[13]

Sawtooth

O projeto Sawtooth, consiste na implementação de uma plataforma para construir e rodar livros razões distribuídos. O seu objetivo de modularidade é alinhado ao Hyperledger e é um dos motivos pela sua incubação. Diferente do Bitcoin, a proposta do Sawtooth é oferecer flexibilidade, desde transferências internacionais até aplicações de internet das coisas.[14]

Fabric

O fabric também é um projeto de tecnologias blockchain que oferece a possibilidade de encaixar várias implementações para certas funcionalidades. A versão de preview disponível em Julho de 2016 possui as seguintes features[15]:

  • Blockchain permissiva com finalidade imediata
  • Ambientes para a execução de contratos inteligentes
  • Módulos de consenso PBFT, NOOPS e SIEVE
  • Framework de eventos que suporta eventos predefinidos e customizados
  • SDK Client e API REST Básicas e Ferramentas CLI

Nessa mesma versão, estão presentes alguns BUGs e limitações, como [15]:

  • Alto tempo de resposta depois de testes de estresse.
  • Não possui eventos para peers no SDK.
  • Atributos no TCert não estão encriptados.

Referências

  1.  «Linux Foundation Unites Industry Leaders to Advance Blockchain Technology». 17 de dezembro de 2015
  2. Ir para cima «Linux Foundation’s Hyperledger Project Announces 30 Founding Members and Code Proposals To Advance Blockchain Technology». 9 de fevereiro de 2016. Consultado em 17 de fevereiro de 2016
  3. Ir para cima «Open Source Blockchain Effort for the Enterprise Elects Leadership Positions and Gains New Investments». 29 de março de 2016
  4. Ir para cima «Founder of the Apache Software Foundation Joins Linux Foundation to Lead Hyperledger Project». 19 de maio de 2016
  5. Ir para cima «Incubating Project Proposal: Joint DAH/IBM proposal». Tamas Blummer, Christopher Ferris. 29 de março de 2016. Consultado em 21 de junho de 2016
  6. Ir para cima «hyperledger/fabric»GitHub. Consultado em 23 de junho de 2016
  7. Ir para cima «Sawtooth Lake Hyperledger Incubation Proposal». Mic Bowman, Richard Brown. 14 de abril de 2016. Consultado em 21 de junho de 2016
  8. ↑ Ir para:a b c d e f g h i j k l m n o «Hyperledger Whitepaper». Consultado em 5 de julho de 2016
  9. Ir para cima «Hyperledger Project Lifecicle». Consultado em 6 de julho de 2016
  10. Ir para cima «Eclipse Development Process 2015». Consultado em 6 de julho de 2016
  11. Ir para cima «Apache Incubator». Consultado em 6 de julho de 2016
  12. Ir para cima «OSGEO Incubation Process». Consultado em 6 de julho de 2016
  13. Ir para cima «Hyperledger github». Consultado em 6 de julho de 2016
  14. Ir para cima «Sawtooth introduction». Consultado em 6 de julho de 2016
  15. ↑ Ir para:a b «Fabric Releases». Consultado em 6 de julho de 2016

Desenvolvendo APIs para Back-Ends Com o IBM API Connect

 

strong-framework

IBM API Connect é uma solução completa que aborda todos os aspectos do ciclo de vida da API. Oferece recursos abrangentes para criar, executar, gerenciar, proteger e monetizar APIs e microservices. Proporcionando uma experiência de utilizador incomparável, integrada, permite uma rápida implantação e administração simplificada de APIs.

Usando ferramentas baseadas em modelos automatizados, a IBM API Connect Deleoper pode facilmente descobrir APIs existentes e back-end fontes de dados e criar novas APIs e microservices baseado no popular open-source quadros Node.js Express e LoopBack® -tudo gerido a partir de um único console unificado.

Com o IBM API Connect, você pode ter uma API ao vivo instalado e funcionando em apenas alguns minutos.

Basta seguir estes passos!

Antes de começar, certifique-se de ter o seguinte:

Instale API Ligação

Para chegar API Connect a partir NPM, execute o seguinte na linha de comando:

$ npm install -g apiconnect

 

Crie seu projeto Conectar API

Para começar a criar seu projeto API de conexão, execute o seguinte e siga as instruções. Isto irá criar um diretório que contém um projeto Conectar API básico chamado ‘apic-getting-started’:

 

$ apic loopback

 

Agora siga os passos:

 

   _-----_
    |       |    .--------------------------.
    |--(o)--|    |  Let's create a LoopBack |
   `---------´   |       application!       |
    ( _´U`_ )    '--------------------------'
    /___A___
     |  ~  |
   __'.___.'__
 ´   `  |° ´ Y `


[?] What's the name of your application? apic-getting-started
[?] Enter name of the directory to contain the project: apic-getting-started


[?] What kind of application do you have in mind?
empty-server (An empty LoopBack API, without any configured models or datasources)
hello-world

 

Execute o Designer API

Em seguida, navegue até o diretório do projeto e abra o Designer API para começar a trabalhar com o nosso projeto:

$ cd apic-getting-started
$ apic edit

Express server listening on http://127.0.0.1:9000

 

O Designer API vai começar localmente, em seguida, abra a interface do usuário no navegador padrão. Se você não estiver conectado ao IBM Bluemix, você será solicitado a efetuar login com uma conta existente, ou para se inscrever para uma nova conta.

Uma vez que você está logado, o Designer API irá apresentar o separador ‘APIs’. Você verá uma API já foi criado para você.

 

strong2

Criar um novo modelo de dados

modelos de dados representam recursos que podem ser consumidos e expostos por suas APIs. Estes modelos estão ligados a fontes de dados, tais como bancos de dados, serviços externos, como e-mail, e até mesmo outras APIs.

Vamos definir um novo modelo de dados.

  1. Clique ‘modelos’ no top navbar
  2. Clique no botão “+ Adicionar”.
  3. Quando solicitado, digite o nome do ‘cliente’ para o novo modelo de dados.

 

strong3

 

  1. Clique no botão “Novo”. As configurações do modelo de dados será exibida.

Personalize o seu modelo de dados

Observe o padrão Modelo de Base é ‘PersistedModel’.Isso significa que esse modelo de dados representa um registro de banco de dados. Ele também tem uma fonte de dados chamada ‘db’. Este é o banco de dados padrão na memória.

Neste exemplo, estamos criando registros de clientes, portanto, quaisquer operações realizadas no modelo de dados “cliente” vai agir sobre registros armazenados no ‘db’ Fonte de Dados.

Vamos fazer algumas modificações no seu modelo de dados:

 

stron4

  1. Se ele não estiver selecionado, escolha a opção ‘Público’.
    Isso cria automaticamente um ponto final API de acesso público chamado “/ clientes ‘com CRUD padrão (criar, ler, atualizar, excluir) operações. Por exemplo, uma solicitação GET para ‘/ clientes’ irá retornar um conjunto de registros de clientes de ‘db’.
  2. Em “Propriedades”, clique no botão ‘+’ para adicionar uma nova propriedade para o modelo de dados.
    • Defina o campo “Nome da propriedade ‘para’ nome ‘.
    • Selecione «necessária». Isso vai exigir todas as instâncias para ter esse conjunto de propriedades.
    • Escolha ‘Tipo’ de ‘string’.
  3. Clique no ícone Salvar. Este é um ícone de disquete no canto superior direito da tela.

Comece o seu API

API Ligue o torna fácil de executar e testar as alterações à sua API localmente. Basta fazer o seguinte:

  1. Clique em “Todos os modelos ‘para retornar para a página de’ modelos ‘.
  2. Clique no botão “Executar”.
  3. Clique no botão “Iniciar”. Uma vez que a API foi iniciado, o endereço local onde ele está sendo executado será exibido.

strong5

Explore a sua API

Agora você pode enviar pedidos diretamente a esta API, ou usar a API Ligação Explorer. O Explorador de oferecer uma interface de usuário para uso fácil que permite visualizar todas as operações e endpoints de sua API.

Para abrir o Explorer, clique no botão “Explorar”.

 

strong6

 

Características do Explorador incluem:

  • lista navegável de todos os terminais de API e operações.
  • A documentação completa
  • solicitações de amostras, incluindo cURL e API Ligação SDKs.
  • Possíveis respostas

Para testar os terminais REST diretamente no seu navegador web, role para baixo no painel direito e em Parâmetros clique em Gerar para gerar dados fictícios.Você pode editar os valores na seção de dados instância do modelo. Em seguida, clique em chamada de Operação. A primeira vez que você fizer isso, você pode ver um erro devido a um certificado não confiável.Quando isso ocorre, clique no link fornecido na mensagem de erro na API Explorer para aceitar o certificado; em seguida, você pode continuar a chamar as operações no seu navegador web.

 

Experimente!

Uma vez que sua API está funcionando, você pode testá-lo usando as amostras de código fornecidas, ou testá-lo direito dentro do Explorer. Para testar um ponto final com o Explorer, basta navegar até o ponto final que você quer tentar, defina os parâmetros do pedido, e clique no botão ‘operação de call’.

 

strong7

Publique sua API

Agora que você já tentou executar o seu API localmente, é hora de publicá-lo. API Connect suporta a publicação de seu API para serviços que suporta um tempo de execução Node.js, e em breve irá incluir IBM Bluemix também.

Para obter instruções completas sobre como publicar seu API, consulte a documentação IBM:

A publicação do CLI

Publishing e estadiamento do GUI API Designer

 

Gerando Hash do Facebok

Em determinado  momento do processo, você precisará gerar um hash, para criar uma relação de confiança entre a sua aplicação e o login do facebook. Então segue o melhor e mais simples tutorial que encontrei na internet:

Para saber mais: Clique aqui