2018-11-08

Septembre 2018

Volume 33, numéro 9

Cet article a fait l'objet d'une traduction automatique.

Microservices - architecte des Applications Blockchain en tant que Microservices

Par Stefano Tempesta | Septembre 2018

Microservices et blockchain contrats intelligents ont beaucoup en commun. Elles sont attendues à la fois pour exécuter de manière isolée (chaîne) et de communiquer avec l’extérieur (hors chaîne) via un canal basé sur le message. Ils doivent à la fois être de petite taille, développée pour s’exécuter de manière autonome et indépendante et plus performants quand ils sont déployés sur un réseau décentralisé.

Cet article présente les principes de conception, les artefacts et les exemples de code pour générer des applications blockchain à l’aide d’un style d’architecture de microservice et leur déploiement sur la plateforme Microsoft Azure Blockchain.

Microservices génèrent parfaitement l’esprit de la philosophie Unix : Une chose et la barre d’outils (tcrn.ch/2vnq5Pb). Un microservice est un composant indépendant, pouvant être déployé de portée limitée qui prend en charge l’interopérabilité via la communication basée sur message. Étant donné ce site, architecture de microservices est un style d’ingénierie qui vous aide à créer des systèmes logiciels hautement automatisée, évolutive composés de microservices de fonctionnalités unique.

Que faire des applications ont en commun avec les microservices et les principes de conception peuvent être appliqués à partir d’architectures de microservice au monde décentralisé de blockchain ? Le tableau dans Figure 1compare des microservices et des contrats intelligents sur les attributs de conception spécifiques.

Figure 1 Microservices et des principes de conception de la Blockchain

Principe de conception	Microservice	Contrat intelligente
Responsabilité unique	Fournit généralement une interface CRUD dans une seule entité.	Définit les rôles, état et la logique pertinentes pour un workflow de validation sur un seul objet, à l’aide de l’approche de mer (plus loin dans cet article).
Contexte délimité	Aucune dépendance sur d’autres services, est propriétaire de son modèle de données pour le stockage persistant.	N’a pas de dépendance sur d’autres contrats intelligents et s’appuie sur le modèle de données on-chain (autrement dit, la fonctionnalité « blockchain » lui-même) en tant que le modèle de données par défaut.
Messagerie activée	Peuvent exploiter une passerelle d’API pour la communication interservices et un bus de service pour la communication intra-service.	Peut tirer parti « oracles » ou « cryptlets » pour l’accès aux données de hors chaîne ou des outils comme Azure Blockchain Workbench qui exposent une API REST.
Développé de façon autonome	Plusieurs langages de programmation et infrastructures.	Plusieurs plateformes blockchain disponibles, bien qu’il existe actuellement aucune communication inter-plateformes.
Peuvent être déployés indépendamment	Avec une bonne conception (événement d’approvisionnement, CQRS) peuvent réduire ou supprimer complètement de dépendance.	Les modèles de conception similaires s’appliquent (décrit dans cet article).
Distribué et décentralisé	Architecture distribuée par opposition à un centralisé « MONOLITHE. »	Intégré distribué et décentralisé livre numérique par sa conception.

Conception d’applications de blockchain en tant que microservices peut apporter les avantages suivants à votre solution :

Autoriser les nombreuses initiatives d’ingénierie logicielle pour s’exécuter en parallèle.
Réduire les dépendances entre les équipes de développement et de test de logiciel.
Prend en charge plusieurs technologies, langages et infrastructures.
Améliorer la facilité d’innovation dans le code pouvant être supprimé.

Microservices parlent généralement au monde extérieur via une interface de programmation d’application (API) qui partage un langage commun, par exemple JSON ou SOAP, avec le client, en fournissant un lingua franca de systèmes de messagerie entre les différentes technologies (.NET, Java, Node.js et ainsi de suite) et les plateformes (Windows, Linux). Cela vaut également pour le blockchain API exposée par Azure Blockchain Workbench, comme vous le verrez plus loin dans cet article.

À partir de Microservices pour des Applications décentralisées

Si vous êtes familiarisé avec le sentiment de DevOps de traitement de vos serveurs comme bétail et pas les pets (bit.ly/2vrdM4p), vous pouvez appliquer la même approche à votre code source. Code facilement JETABLE peut réduire la dette technique, promouvoir la modernisation des processus d’ingénierie et réduire les coûts opérationnels grâce à l’optimisation d’infrastructure (par exemple, dans des conteneurs ou des configurations entièrement sans serveur).

Conception d’applications de blockchain avec les principes d’architecture de microservice peut également générer les avantages professionnels. Améliorer l’efficacité dans le système de logiciels réduit les coûts d’infrastructure et les risques de pannes de service liés à la capacité. Ces aspects sont une valeur particulière pour les chaînes de blocs privé, où la rentabilité et la continuité de service sont des exigences principales pour les entreprises.

Principaux d’architecture de Microservice peut prendre en charge l’utilisation de composants remplaçables, en réduisant la dette technique pouvant conduire à des environnements chronologiques et non fiables. Uniformité, le langage de programmation pour les contrats intelligents dans Ethereum, dispose d’un mécanisme permettant de spécifier la version exacte du runtime sur lequel est exécutée chaque contrat. Au fil du temps, le numéro de version d’un contrat smart peut servir à identifier obsolète code stockées de blockchain qui peut être un candidat pour le remplacement. N’oubliez pas que dans une blockchain, à puce des contrats qui ont déjà été traités (autrement dit, font partie d’un bloc « extraction ») ne peut pas être supprimé, une nouvelle version d’un contrat doit être publiée pour de futures transactions.

Un autre avantage est une meilleure évolutivité du runtime, ce qui permet un système logiciel agrandir ou réduire la demande. Implémenté comme les microservices permettent les chaînes de blocs autorisé dans un environnement d’entreprise ou consortium privé pour distribuer les charges de travail pour la transaction et les nœuds d’exploration de données de manière plus souple des contrats intelligents.

Au niveau plus élémentaire, architecture de microservices concerne la rupture d’une application ou un système en éléments plus petits et en obtenant des avantages à partir de la configuration distribuée. Dans la même veine, des contrats intelligents qui s’exécutent sur une blockchain bénéficient de la nature distribuée du réseau peer-to-peer. Grâce à une conception orientée sur l’architecture de microservices, contrats intelligents peuvent offrir une efficacité accrue, l’évolutivité et la facilité de gestion, tous les attributs qui sont essentielles pour la bonne exécution des solutions de blockchain dans l’entreprise.

Décentralisée Domain-Driven Design

Écrire une application pour un fichier de comptabilité blockchain décentralisée numérique et que vous travaillez aux exigences d’infrastructure et de logiciels classiques d’un système distribué, telles que l’isolation du stockage, la messagerie asynchrone et les transactions distribuées. Applications Blockchain requièrent également l’authentification des utilisateurs et appareils et l’autorisation pour exécuter des actions spécifiques au sein d’un contrat active. En développant l’approche de conception pilotée par le domaine (DDD) populaires, reportez-vous à la pratique de prendre en compte les entités, les processus et les propriétés d’un système de blockchain en tant que « Décentralisé Domain-Driven Design » ou DDDD.

Nous allons commencer à définir le contexte, de l’exécution de contrats intelligents dans un fichier de comptabilité numérique ou le domaine. La logique métier de l’application de blockchain en tant que flux de travail, avec chaque étape d’un flux de travail identifié par un expéditeur de message (utilisateur ou périphérique qui exécute une fonction du contrat) et un état (les paramètres du contrat, représentés représentent des contrats intelligents en tant qu’un message envoyé à une fonction et son état interne). Autres parties (là encore, les utilisateurs ou périphériques) peuvent être affectées par l’exécution d’une fonction d’un contrat active.

Dans ce contexte, nous faisons référence à toutes les parties concernées en tant que rôles d’application. Le tout premier rôle d’application qui crée le contrat est appelé l’initiateur. Sur le changement d’état interne d’un contrat, un événement peut être déclenché pour signaler cette modification à d’autres parties du contrat actif ou dans des applications externes. Voici un modèle typique, par exemple, pour le remplissage des données hors chaîne, à l’aide d’un bus de service pour le traitement des événements déclenchés par un contrat actif et de publication de messages dans les écouteurs appropriés. Figure 2 identifie les entités impliquées dans un flux de travail au sein d’un contrat actif.

Figure 2 entités de flux de travail dans un contrat intelligente

Ethereum utilise uniformité comme son langage de programmation pour l’écriture d’une logique métier automatique de l’application pour les contrats intelligents. Contrats intelligents dans uniformité sont semblables aux classes dans les langages orientés objet. Chaque contrat contient des rôles, état et des fonctions pour implémenter des intervenants, les étapes et les actions d’un processus d’entreprise.

L’extrait de code dans Figure 3 montre les différents types de déclaration de variable dans l’uniformité pour les rôles, état et les propriétés qui peuvent être utilisées dans un contrat intelligent pour une application de parie. Rôles (le gambler et les Paris) sont définis en tant qu’adresse, ce qui est l’identificateur unique d’un utilisateur ou d’un contrat dans Ethereum. L’état est une énumération des étiquettes qui identifie l’état actuel d’un pari placé via le contrat actif. Les fonctions, comme vous le verrez plus tard, définissent un changement d’état. La quantité de résultat est exprimée sous la forme d’un nombre non signé (actuellement, uniformité ne prend en charge les valeurs décimales).

Déclaration de la figure 3 de rôles, état et propriétés dans le contrat Smart PARI

pragma solidity ^0.4.20;
contract Betting
{
  // Roles
  address public Gambler;
  address public Bookmaker;
  // State
  enum BetType { Placed, Won, Lost }
  BetType public State;
  // Properties
  uint public BetAmount;

Veuillez noter que l’indication de la version d’uniformité vous ciblez pour ce contrat actif. Il est recommandé d’indiquer cette instruction pragma afin d’éviter des incompatibilités avec les futures versions du langage de programmation de solidité et du compilateur. Cela permet également d’identifier le code ancien dans un contrat intelligent, qui peut être remplacée par une nouvelle version pour prendre en charge le code mis à jour. Le processus de suppression d’un contrat actif existant à partir d’une fonctionnalité « blockchain » est appelé « AUTODESTRUCTION. »

Un contrat intelligent doit avoir une seule responsabilité et contiennent une logique métier aussi peu que possible, optimale uniquement la logique de validation nécessaire pour l’estimer comme un contrat valide ou non. Dans mon application parie, un contrat intelligent peut exposer des fonctions pour placer un pari par le gambler et accuser réception win ou perte par les Paris. Devise peut-être être échangée entre les deux rôles, dans le cadre du flux de travail de meilleurs résultats. Le modèle habituel pour les transactions monétaires nécessitant une validation par un contrat voit le transfert de quantité qui passe en deux phases, comme indiqué dans Figure 4. Le gambler (initiateur du contrat) place un pari pour un montant donné, qui est ensuite stocké dans le contrat actif. Si le résultat est/gagné, le montant gagné /, indiqué par le Paris, est transféré vers le gambler. Sinon, les Paris cashes la quantité de meilleurs résultats.

Fait le pari du flux de travail
Figure 4 fait le pari le flux de travail

Comme indiqué dans Figure 5, l’implémentation de ce contrat active dans uniformité requiert que plusieurs fonctions définis pour chaque action du flux de travail, comme suit :

Le constructeur stocke l’expéditeur du message en tant que le gambler ; C’est le rôle qui initie le contrat actif.
La fonction PARI accepte un montant en tant qu’entrée, effectue une validation (cette fonction peut être appelée uniquement par le gambler et le montant doit être supérieure à zéro), puis transfère la quantité de meilleurs résultats pour le contrat. Pour permettre les transferts sur chaîne monétaire, il est nécessaire marquer une fonction en tant que fournisseurs.
La fonction Won, après avoir vérifié que le demandeur n’est pas le gambler, transfère le montant gagné / sur le gambler et ferme le pari comme « Succès ».
La fonction perdure, à nouveau peut uniquement être appelée par les Paris, les transferts la quantité initialement parie que, maintenant perdu à la gambler, avec les Paris et ferme la solution en tant que « Perdu ».
En fermant un pari, le gambler est supprimé (son adresse est définie sur 0 x 0) et la quantité définie sur zéro, prêt pour une autre solution.

Figure 5 fonctions dans le contrat Smart PARI

constructor() public {
  Gambler = msg.sender;
}
function Bet(uint amount) public payable {
  require(msg.sender == Gambler, "Only a gambler can place a bet.");
  require(amount > 0, "Amount should be greater than zero.");
  BetAmount = amount;
  address(this).transfer(amount);
  State = BetType.Placed;
}
function Won(uint amount) public payable {
  require(msg.sender != Gambler, "Only the bookmaker can mark a bet as won.");
  require(amount > 0, "Amount should be greater than zero.");
  Gambler.transfer(amount);
  Close(BetType.Won);
}
function Lost() public payable {
  require(msg.sender != Gambler, "Only the bookmaker can mark a bet as won.");
  Bookmaker = msg.sender;
  Bookmaker.transfer(BetAmount);
  Close(BetType.Lost);
}
function Close(BetType state) internal {
  Gambler = 0x0;
  BetAmount = 0;
  State = state;
}

Bien que simple dans l’implémentation, ce scénario identifie un modèle standard pour la gestion des dépenses monétaire dans une application blockchain. Autres scénarios d’avoir besoin d’incorporer des fichiers attestable, tels que des documents, des feuilles de calcul, des certificats et des images. Pour plusieurs raisons, principalement concernant limitation du stockage, il est inapproprié de placer les fichiers sur une fonctionnalité « blockchain ». Une approche courante consiste à effectuer un hachage de chiffrement (par exemple, SHA-256) par rapport à un fichier et le partager sur un Registre distribué de hachage. Le système externe au lieu de cela conserve le fichier dans un mécanisme de stockage, comme le stockage Azure ou des erreurs de page (ipfs.io).

Effectuer le hachage en utilisant le même algorithme de hachage à tout moment futures retournera le même résultat, à moins que le fichier persistant a été modifié, même si un pixel est modifié dans une image. Ce processus accorde à prouver l’existence qu’il existait un objet d’information comme une messagerie, fichier, document, appel téléphonique ou une vidéo à un certain point dans le temps. Elle autorise également la preuve d’authenticité, vous connaissez une ressource numérique n’a pas changé, car le livre numérique stocke immuable et indépendante, enregistrements vérifiables de toutes les transactions. Pour plus d’informations sur la valeur de la fonctionnalité « blockchain » dans la gestion de contenu d’entreprise, lisez le billet que j’ai publié à bit.ly/2OC2Ycp.

Event Sourcing et CQRS

Comme indiqué dans la section précédente, je vous recommande de génération de contrats intelligents avec responsabilité pour une fonctionnalité uniquement. Alors que la conception orientée sur la fonctionnalité est une technique essentielle pour l’isolation des contrats intelligents, il n’est pas suffisant pour garantir la simplicité de déploiement indépendante. Contrats intelligents peuvent agir sur un modèle de données commun au sein du domaine du système, en dépit d’en étant isolées dans l’exécution. Par exemple, dans une application peut être un contrat actif pour la gestion de meilleurs résultats et l’autre pour la gestion des événements sportifs sur lequel à parier. Le contrat intelligent pour fait le pari peut faire référence à un événement sportif, création d’une dépendance entre les deux contrats intelligents (fait le pari ne peut pas se produire si un événement n’existe pas). Existe-t-il un moyen pour modéliser les données qui peuvent aider à éviter le partage des données entre des contrats intelligents ?

Quelle que soit format et le stockage (SQL, NoSQL, JSON), nous utilisons, nous modèle généralement des bases de données en fonction des objets et de création, lecture, mise à jour, les opérations de suppression (CRUD). Au lieu de stocker des structures de ce modèle, l’état du domaine, nous pouvons stocker des événements qui mènent à l’état actuel de notre monde. Cette approche de modélisation est appelée approvisionnement en événements (bit.ly/2O68nrt).

Approvisionnement en événements consiste à stocker les faits. Un fait est une valeur représentative d’une occurrence d’événement. Comme dans la vie, nous ne pouvons pas revenir en arrière et modifier le passé, nous pouvons uniquement faire quelque chose dans le présent pour compenser les actions antérieures. Données sont immuables ; Par conséquent, nous avons toujours émis une nouvelle commande ou un événement à compenser, plutôt que de mettre à jour, l’état d’une entité. Cette approche fonctionne sous l’acronyme de mer, créer, récupérer, ajouter et Burn (bit.ly/2MbpUOb), ce qui est exactement ce qui permet une blockchain à exécuter : mises à jour de données ou les suppressions, il ajoute à la chaîne. Quelque chose si vous supprimez une blockchain est en conflit avec son immuabilité, mais vous pouvez arrêter transfert d’actifs par « graver » à l’adresse du destinataire.

Un problème immédiat de cette approche est les performances. Si n’importe quelle valeur d’état est une fonction d’événements, vous pouvez considérer que chaque accès à la valeur requiert le recalcul de l’état actuel à partir des événements de source. Évidemment, cela serait très lente. Dans l’approvisionnement en événements, vous pouvez éviter ces opérations coûteuses à l’aide d’un instantané propagé ce que l'on appelle : une projection de l’état d’entité à un moment donné dans le temps. Par exemple, les banques précalculer le solde de votre compte bancaire sur le dernier jour de chaque mois, afin que vous n’avez pas besoin de la somme de tous les débits et les opérations de crédits depuis le jour que vous avez ouvert votre compte bancaire pour obtenir votre solde actuel.

Figure 6 présente le modèle de structure des données pour l’application de pari. Cela est parfois appelé le modèle en flocon, car chaque entité (une table de base de données) est différente de n’importe quel autre.

Modèle de données structurelle
Figure 6 modèle de structure des données

Le modèle de données structurelle enregistre uniquement l’état actuel du système, tandis que l’approche event sourcing enregistre les faits individuelles. État, dans l’approvisionnement en événements, est une fonction de tous les faits pertinentes qui s’est produite. Non seulement cela donne-t-il contrôle total de vos, mais il permet également de générer des projections d’état vers un point dans le passé.

Pour transmettre les supplémentaire en termes d’isolation des responsabilités, commande requête répartition (CQRS) complète d’approvisionnement en événements comme un modèle de conception pour le stockage de données. CQRS encourage la responsabilité unique efficace et simplicité de déploiement de microservices et par extension, contrats intelligents. Elle indique que vous pouvez et doit, séparer les données-mise à jour des fonctionnalités de requête de données dans des modèles distincts.

Lorsque vous utilisez CQRS, vous pouvez supprimer la nécessité d’accéder aux données dans plusieurs contextes. Un contrat intelligent peut posséder et encapsuler toute mise à jour l’état du modèle et déclencher des événements de modification de cet état. En vous abonnant aux notifications de ces événements, un contrat distinct smart puisse générer un modèle de complètement indépendant et optimisé de requête qui n’a pas besoin d’être partagées avec tout autre contrat ou service externe. Vous pouvez en savoir plus sur CQRS à partir de la publication de Martin Fowler à bit.ly/2Awoz33.

Figure 7 décrit le modèle de données que j’ai conçu pour l’application de parie l’approvisionnement en événements. Ce modèle simple emploie une structure similaire, quel que soit l’événement géré. Il n’est pas nécessaire de connaître l’état actuel de la solution pour lire la séquence d’événements. Structure de données de l’événement varie selon l’événement lui-même. Bien qu’il existe une séquence d’états tel que défini dans le flux de travail, il est sans importance du point de vue du modèle de données. Pensez à plus grande : Dans un scénario de chaîne d’approvisionnement, plusieurs flux de travail et les événements existent, avec des attributs et des entités différentes. Votre modèle de structure des données peut devenir complexe, tandis que le modèle basé sur les événements, quelques attributs différents pour chaque événement, la barre reste constant.

Figure 7 Event Sourcing un modèle de données

Transactions distribuées

Un modèle de données partagée n’est pas le seul cas d’utilisation qui peuvent introduire un couplage étroit entre les contrats intelligents. Une autre menace importante est le flux de travail. Un grand nombre de processus de la vie réelle ne peut pas être représenté avec une seule opération atomique. Avec ces flux de travail, le résultat est pertinente uniquement si toutes les étapes peuvent être exécutées. Si une étape dans la séquence échoue, l’état du système pertinents résultant devient non valide. Dans le monde SGBDR, ces processus sont appelés « transactions ». Transactions de base de données sont généralement locales, contenues au sein d’une base de données et s’appuient sur les verrous sur les tables avant les mises à jour. Si une étape échoue, vous pouvez restaurer les étapes déjà tentés avant une validation finale.

Pour les flux de travail distribuées et les microservices sans état, une implémentation de transaction traditionnel avec des verrous de données et atomicité, cohérence, Isolation, la conformité de durabilité (ACID) (en.wikipedia.org/wiki/ACID) est peu pratique. Sagas (bit.ly/2AzdKNR) sont des transactions distribuées à long terme qui autorise l’exécution de flux de travail dans les environnements faiblement couplés, sans effectuer d’hypothèse de la fiabilité de chaque composant du système complex.

Dans sagas, chaque étape dans le flux de travail exécute sa partie du travail, inscrit un appel à une transaction de compensation dans un message appelé « bordereau de routage » et transmet le message mis à jour la chaîne de l’activité. Si une étape en aval échoue, cette étape examine le bordereau de routage et appelle transaction de compensation l’étape de la dernière retransmettre le bordereau de routage. L’étape précédente effectue la même chose, appel de transaction de compensation de son prédécesseur et ainsi de suite jusqu'à ce que toutes les transactions déjà exécutées sont compensées. Ce modèle entraîne la cohérence éventuelle de données dans une transaction distribuée (bit.ly/2v8T360). En raison de sa nature distribuée, hautement tolérant aux pannes, les sagas sont très bien adaptées à une architecture de microservices quant à des contrats intelligents blockchain.

Vous pouvez implémenter une sorte de bordereau de routage par le biais de fonctions de secours dans uniformité. Une fonction de secours est une fonction sans nom est définie avec aucun argument d’entrée et aucune valeur de retour. Si aucune des autres fonctions correspond à l’identificateur de la fonction donnée ou chaque fois que le contrat reçoit Ether (dans le cas Ethereum), il est exécuté sur un appel au contrat. En outre, afin de recevoir Ether, la fonction de secours doit être marquée à payer. Si aucune fonction n’existe, le contrat ne peut pas recevoir Ether via des transactions (adresse-adresse) régulières.

Il est important de mentionner qu’un contrat sans une fonction de secours à payer peut recevoir Ether en tant que destinataire d’une transaction coinbase, par exemple une récompense de bloc miner. Un contrat ne peut pas réagir à ces transferts Ether et, par conséquent, aussi ne peuvent pas rejeter les. Il s’agit d’un choix de conception de Ethereum et uniformité ne peut pas contourner. Un contrat peut avoir exactement une fonction sans nom, comme illustré ici :

// Fallback function
function() public payable {
  emit AmountTransfered(msg.sender);
}
event AmountTransfered(address sender);

Dans Ethereum, les fonctions de secours sont nécessaires pour un contrat intelligent autoriser le transfert direct de compte à ce compte. Il s’agit, car le compte de transfert peut avoir besoin effectuer les transferts pour les deux en externe appartenant à des comptes (EOAs) et à d’autres contrats intelligents. Comme EOAs accepte uniquement les transferts directs, la seule façon pour un compte pour transférer la valeur à un autre compte est pour le contrat en cours d’exécution implémenter une fonction de secours. Cela signifie que n’importe quel contrat qui souhaite accepter que ce transfert doit être préparé pour les transferts directs en ayant une fonction de secours. Sans cette fonction, le transfert échoue, et il serait impossible pour le contrat accepter Ether à partir de l’autre contrat.

Une bonne pratique est ne pas avoir une logique dans la fonction de secours. Il est possible de placer le code dans le corps de cette fonction, mais il est préférable d’éviter tout élément au-delà de journalisation très courte et simple. La raison est importante et unique contrats intelligents : Vous ne voulez pas cette fonction échouer, car il s’exécute en dehors de gaz. En règle générale, vous aurez juste assez gaz pour déclencher un événement, mais pas assez pour écrire des données dans le stockage.

Messagerie asynchrone

Messagerie asynchrone joue un rôle essentiel dans favoriser faiblement couplé dans une architecture de microservices. Par exemple, nous pouvons utiliser un répartiteur de messages pour fournir des notifications d’événements de manière asynchrone, empêche les connexions point à point qui créent une dépendance sur chaque format de message et de la disponibilité du point de terminaison. Par le même jeton, les contrats intelligents peuvent bénéficier d’une intégration à extension messagerie pour entrante (à partir d’extérieur vers l’intérieur de la fonctionnalité « blockchain ») et sortant (à partir de la blockchain vers des applications externes) communication.

En plus de fournir une API REST, Azure Blockchain Workbench fournit une intégration basée sur la messagerie basée sur des événements centré sur le livre. Événements sont publiés dans une grille d’événements Azure et les consommateurs peuvent recevoir les données ou entreprendre une action basée sur ces événements. Pour les clients qui requièrent une messagerie fiable, Azure Blockchain Workbench remet les messages à un point de terminaison Azure Service Bus, également. Vous pouvez déclencher des événements, par exemple, pour avertir les utilisateurs et les systèmes de transactions ou des changements d’état dans un contrat actif. Notifications d’événements pouvant être consommées directement dans le code ou avec des outils tels que Logic Apps (bit.ly/2n4EgoP) pour déclencher un flux de données en aval.

Contrats intelligents représentent souvent un flux d’entreprise qui s’intègre avec les appareils et systèmes externes. Par conséquent, les transactions doivent être en mesure de lancer sur un Registre distribué qui inclut des données à partir d’un appareil ou un système externe. Vous souhaiterez également avoir des systèmes externes de réagir aux événements provenant des contrats intelligents sur un Registre distribué. L’API REST et l’intégration de messagerie permettent à la fois en envoyant des transactions à partir de systèmes externes à des contrats intelligents inclus dans une application Azure Blockchain Workbench et envoyer des notifications d’événements à des systèmes externes selon les modifications qui se produisent dans une application. Examinons maintenant les modèles identifiés pour chacun de ces types d’intégrations dans vos solutions de bout en bout :

Remise d’événement à sens unique à partir d’un contrat actif à un consommateur d’événements.
Événement unidirectionnel remise d’un message à partir d’un système externe à un contrat actif.

Contrat active à un consommateur d’événements

Dans le premier scénario, un événement se produit au sein d’un contrat actif ; par exemple, un changement d’état ou l’exécution d’un type spécifique de transaction. Cet événement est diffusée via une grille d’événements aux consommateurs en aval et ces consommateurs ensuite prendre les mesures appropriées. Un exemple de ce scénario est que, lorsqu’une transaction se produit, un consommateur serions averti et peut prendre des mesures, telles que l’enregistrement des informations dans une base de données. Il s’agit du même modèle Azure Blockchain Workbench suit pour remplir sa base de données hors chaîne SQL. Une autre serait si un contrat smart passe à un état particulier ; par exemple, quand un contrat s’affiche dans un état « hors de la conformité ». Lorsque ce changement d’état se produit, il risque de déclencher une alerte soit envoyée à un administrateur. Cela se produit en suivant la procédure décrite dans Figure 8, où :

Le contrat smart effectue la transition vers un nouvel état et envoie un événement à la comptabilité.
Le livre reçoit et remet l’événement Azure Blockchain Workbench.
Azure Blockchain Workbench est abonné aux événements à partir de la comptabilité et reçoit l’événement.
Azure Blockchain Workbench publie l’événement aux abonnés sur la grille d’événements.
Les systèmes externes sont abonnés à la grille d’événements, consommer le message et prenez les mesures appropriées.

Figure 8 la Propagation d’un événement déclenché dans un contrat actif à un système externe

Système externe à un contrat intelligent

Il existe également un scénario qui circulent à partir de la direction opposée. Dans ce cas, un événement est généré par un capteur ou un système externe et les données à partir de cet événement doivent être envoyées à un contrat actif. Un exemple courant est la livraison de données en provenance des marchés financiers, tels que les prix des produits de base, des actions ou des obligations à un contrat active. Cela se produit en suivant la procédure décrite dans Figure 9, où :

Un événement se produit dans un système externe qui déclenche la création d’un message pour Azure Blockchain Workbench.
Le système externe a du code écrit pour créer ce message dans un format connu et l’envoie directement au Bus de Service.
Azure Blockchain Workbench est abonné aux événements de Service Bus et récupère le message.
Azure Blockchain Workbench lance un appel à la comptabilité, d’envoyer des données depuis le système externe à un contrat spécifique.
Lors de la réception du message, le contrat effectue la transition vers un nouvel état possible.

Figure 9 la Propagation d’un événement déclenché par un système externe à un contrat intelligent

L’implémentation d’une solution de bout en bout pour un scénario d’intégration est abordée dans cet article. Trouverez de bons exemples d’intégration dans les deux sens bit.ly/2M8yflL.

En résumé, les modèles d’intégration similaire accessibles dans les architectures de microservice et contrats intelligents blockchain. La nature distribuée de ces deux architectures encourage une messagerie asynchrone et l’utilisation d’un répartiteur de messages sous la forme d’une grille ou service bus d’événements pour transmettre des informations entre les services et contrats intelligents. Modèles de conception tels que l’approvisionnement en événements, correspondent au final, la nature immuable d’un fichier de comptabilité numérique et l’approche pilotée par événements communication chaîne.

Exploration de l’API Azure Blockchain Workbench

Azure Blockchain Workbench (aka.ms/abcworkbench) est un service qui crée un fichier de comptabilité blockchain numérique (actuellement, Ethereum) en quelques minutes. Il fournit également des ressources hébergées dans Azure pour le développement rapide de contrats intelligents, tout en réduisant les préoccupations de l’infrastructure sous-jacente nécessaires pour exécuter Ethereum ou plateforme blockchain similaire.

Si vous débutez avec Azure Blockchain Workbench, consultez ma présentation dans le numéro de juin de MSDN Magazine (msdn.com/magazine/mt846726). Azure Blockchain Workbench fournit aux développeurs une API REST en tant que passerelle à intégrer des applications de bureau, Web et mobiles pour des applications blockchain. Par exemple, un développeur peut utiliser l’API pour permettre aux appareils IoT envoyer des données à un contrat actif. Ou l’API peut être consommée par Power BI pour créer la visualisation des données de la fonctionnalité « blockchain ». L’API expose un large éventail de fonctionnalités d’Azure Blockchain Workbench, organisées en groupes de l’opération, comme indiqué dans Figure Aet peuvent être utilisés pour automatiser les éléments suivants :

Création et la gestion de flux de travail au sein d’un consortium de blockchain.
Association d’utilisateurs et des organisations avec un consortium, application de la blockchain ou workflow de l’application.
Exécution de transactions sur une fonctionnalité « blockchain ».
Récupération des transactions et les données de contrat à partir d’une fonctionnalité « blockchain ».

Groupe de l’opération	Description
applications,	Gestion des applications de blockchain Blockchain Workbench.
Capacités	Liste de fonctionnalités qu'un utilisateur peut effectuer dans Azure Blockchain Workbench.
Vérificateurs	Outils de développement utilisés pour valider des contrats intelligents Workbench configuration et blockchain.
Connexions	Connexion aux réseaux de blockchain.
Contrats	Instances de contrat actives, notamment la possibilité d’effectuer des actions sur les contrats intelligents.
Proxy de graphique	Représente une méthode de proxy à l’API Graph Azure Active Directory pour les utilisateurs.
Contrôle d’intégrité	État d’intégrité de Blockchain Workbench API.
Registres distribués	Prise en charge des réseaux de blockchain.
Utilisateurs	Gestion des utilisateurs dans Azure Blockchain Workbench.

Figure A les groupes d’opération Azure Blockchain Workbench REST API

Les requêtes HTTP à l’API REST sont protégés avec Azure Active Directory (Azure AD). Pour faire une demande authentifiée à une API REST, les clients doivent être authentifiées avec les informations d’identification valides avant de pouvoir appeler l’API. L’authentification est coordonnée entre les différents acteurs par Azure AD, ainsi que votre client avec un jeton d’accès en tant que preuve de l’authentification. Le jeton est ensuite envoyé dans l’en-tête d’autorisation HTTP de chaque demande d’API REST. Consultez ces exemples sur GitHub pour savoir comment authentifier une application cliente à l’API REST de Azure Blockchain Workbench à bit.ly/2vxzlAC.

Ce référentiel GitHub contient des exemples supplémentaires illustrant comment appeler les différents services pour répertorier les applications, les flux de travail et les contrats sur une fonctionnalité « blockchain ». Bien que l’implémentation actuelle d’Azure Blockchain Workbench prend en charge uniquement les Ethereum, les versions futures étendra la prise en charge pour les autres livres numériques. Au final, l’API fournit un accès à n’importe quelle plateforme blockchain pris en charge à l’aide d’une seule application programming interface, quelle que soit la technologie et le langage en cours d’utilisation de programmation commun.

Stefano Tempestaconcerne un directeur régional Microsoft et les MVP double sur l’intelligence artificielle et les Applications métier, ainsi que responsable de chapitre de la Communauté Microsoft Dynamics 365 en Suisse. Tempesta est un formateur de cours sur Dynamics 365, blockchain et machine learning et orateur régulier aux conférences informatiques internationales, y compris Microsoft Ignite et Tech Summit. Il a fondé Blogchain espace (blogchain.space), un blog sur les technologies blockchain, écrit pour MSDN Magazine et MS Dynamics World et publie les expériences d’apprentissage automatique sur la galerie Azure AI (Gallery.Azure.ai).

Je remercie l’expert technique suivant : Jonathan Waldman

Discuter de cet article sur le forum MSDN Magazine

Partager via