Settembre 2018

Volume 33 numero 9

Il presente articolo è stato tradotto automaticamente.

Microservizi - Architect applicazioni Blockchain come Microservizi

Dal Stefano Tempesta | Settembre 2018

I Microservizi e blockchain smart Contract hanno molto in comune. Vanno entrambi considerati Esegui in isolamento (nella catena) e comunicare con l'esterno (fuori dalla catena) tramite un canale basato su messaggi. Essi devono essere di piccole dimensioni, sviluppata per l'esecuzione in modo autonomo e indipendente sia offrono prestazioni migliori quando vengono implementate in una rete decentralizzata.

Questo articolo vengono presentati i principi di progettazione, gli elementi e gli esempi di codice per la compilazione di applicazioni blockchain usando uno stile di architettura di microservizi e distribuirli nella piattaforma Microsoft Azure Blockchain.

I Microservizi perfettamente ai sensi spirito della filosofia di Unix: Un aspetto e le ben (tcrn.ch/2vnq5Pb). Un microservizio è un componente distribuibile indipendente dell'ambito limitato che supporta l'interoperabilità tramite la comunicazione basata su messaggi. Data questa premessa, un'architettura di microservizi è uno stile di progettazione che consente di creare sistemi software estremamente automatizzato, evolversi costituiti da microservizi con capacità singolo.

Che cosa le applicazioni hanno in comune con i microservizi e quali principi di progettazione possono essere applicati dalle architetture di microservizi per tutto il mondo decentralizzato blockchain? La tabella in figura 1mette a confronto i microservizi e smart Contract contro gli attributi di progettazione specifica.

Figura 1 Microservizi e i principi di progettazione di Blockchain

Principio di progettazione Microservizio Contratto intelligente
Singola responsabilità In genere fornisce un'interfaccia CRUD su una singola entità. Definisce i ruoli, stato e la logica rilevante per un flusso di lavoro di convalida in un singolo oggetto, usando l'approccio GRANCHIO (più avanti in questo articolo).
Contesto delimitato Senza dipendenza da altri servizi, è il proprietario al modello di dati per l'archiviazione permanente. Non ha dipendenze su altri smart Contract e sfrutta il modello di dati nella catena (vale a dire, blockchain stessa) come modello di dati preferito.
Messaggistica abilitata Possono sfruttare un gateway API per la comunicazione tra servizio e un bus di servizio per le comunicazioni interne al servizio. Può sfruttare "scaricarle" o "cryptlets" per l'accesso ai dati fuori dalla catena o strumenti come Azure Blockchain Workbench che espongono un'API REST.
Sviluppato in modo autonomo Più linguaggi di programmazione e Framework. Più piattaforme di blockchain disponibile, anche se non esiste attualmente alcuna comunicazione multipiattaforma.
Distribuibili in modo indipendente Con la progettazione adeguata (evento sourcing, CQRS) può ridurre o rimuovere completamente la dipendenza. Modelli di progettazione simili si applicano (descritto nel presente articolo).
Distribuito e decentralizzato Architettura distribuita invece di una centralizzato "monolite." Incorporati distribuito e decentralizzato ledger digitali per impostazione predefinita.

 

Progettazione di applicazioni blockchain come microservizi può offrire i vantaggi seguenti alla soluzione:

  • Consentire a molti le iniziative di ingegneria del software per l'esecuzione in parallelo.
  • Ridurre le dipendenze tra i team di sviluppo e test di software.
  • Supporta più le tecnologie, linguaggi e Framework.
  • Alzare di livello la facilità di innovazione tramite codice eliminabile.

I Microservizi in genere parlano al mondo esterno tramite un'interfaccia di programmazione dell'applicazione (API) che condivide un linguaggio comune, ad esempio JSON o SOAP, con il client, fornendo una lingua franca del sistemi abilitati per la messaggistica tra diverse tecnologie (.NET, Java, Node. js e così via) e le piattaforme (Windows, Linux). Questo vale anche per le API esposte da Azure Blockchain Workbench, blockchain, come si vedrà più avanti in questo articolo.

Da Microservizi alle applicazioni decentralizzate

Se si ha familiarità con il sentiment di DevOps del trattamento dei server, ad esempio capi di bestiame e non di animali domestici (bit.ly/2vrdM4p), è possibile applicare lo stesso approccio al codice sorgente. Codice facilmente eliminabili possa ridurre il debito tecnico, alzare di livello di modernizzazione dei processi di progettazione e ridurre i costi operativi tramite l'ottimizzazione dell'infrastruttura (ad esempio, in contenitori o completamente senza configurazioni).

Progettazione di applicazioni blockchain con i principi di architettura di microservizi può offrire i vantaggi aziendali. Miglioramento dell'efficienza del sistema software consente di ridurre i costi di infrastruttura e il rischio di interruzioni dei servizi correlati alla capacità. Questi aspetti sono di particolare valore per la blockchain privata, in cui l'efficacia dei costi e la continuità del servizio sono requisiti fondamentali per le aziende.

Le entità di architettura di Microservizi possono supportare uso dei componenti sostituibili, ridurre il debito tecnico che può provocare gli ambienti del periodo di permanenza e inaffidabili. Solidity, il linguaggio di programmazione per smart Contract in Ethereum, include un meccanismo per specificare la versione runtime esatta in cui viene eseguito ogni contratto. Nel corso del tempo, il numero di versione del contratto intelligente è utilizzabile per identificare il codice archiviato blockchain obsoleto che può essere un candidato per la sostituzione. Tenere semplicemente presente che in una blockchain, smart contratti che sono già stati elaborati (vale a dire, fanno parte di un blocco "determinato") non può essere eliminato, ovvero una nuova versione di un contratto deve essere pubblicata per le transazioni future.

Un altro vantaggio è migliore scalabilità del runtime, che consente a un sistema software aumentare o ridurre la domanda. Smart Contract implementato come i microservizi garantiscono blockchain con autorizzazione in un ambiente di business o consortium privata per distribuire carichi di lavoro per transazioni e i nodi di data mining in modo più flessibile.

Al livello più elementare, un'architettura di microservizi è sull'interruzione di un'applicazione o un sistema in parti più piccole e ottenendo sfruttano la configurazione distribuita. Di conseguenza, smart Contract eseguiti in una blockchain trarre vantaggio dalla natura distribuita della rete peer-to-peer. Con una progettazione orientata ai servizi di architettura basata su microservizi, smart Contract può offrire un miglioramento dell'efficienza, scalabilità e gestibilità, ovvero tutti gli attributi che sono essenziali per la corretta implementazione di soluzioni blockchain nell'organizzazione.

 

Decentralizzata Domain-Driven Design

Scrivere un'applicazione per un ledger digitale blockchain decentralizzati e si lavora con i requisiti di infrastruttura e software tipici di un sistema distribuito, ad esempio spazio di memorizzazione isolato, messaggistica asincrona e le transazioni distribuite. Applicazioni Blockchain richiedono anche l'autenticazione di utenti e dispositivi e l'autorizzazione per eseguire azioni specifiche all'interno di un contratto intelligente. Riprendendo l'approccio Domain-Driven Design (DDD) più diffusi, consultare la pratica di prendere in considerazione le entità, i processi e le proprietà di un sistema di blockchain come "Decentralizzato Domain-Driven Design" o DDDD.

È possibile iniziare la definizione di dominio o il contesto dell'esecuzione di smart Contract all'interno di un ledger digitale. Smart Contract rappresentano la logica di business dell'applicazione blockchain come flussi di lavoro, in cui ciascuna fase del flusso di lavoro identificato da un mittente del messaggio (un utente o dispositivo che esegue una funzione del contratto) e uno stato (parametri del contratto, rappresentati come un messaggio inviato a una funzione e il relativo stato interno). Altre parti (anche in questo caso, gli utenti o dispositivi) può dipendere dall'esecuzione di una funzione di un contratto intelligente.

In questo contesto, è fare riferimento a tutte le parti interessate come i ruoli applicazione. Il primo ruolo applicazione che crea il contratto è denominato initiator. In caso di modifica dello stato interno di un contratto, potrebbe essere generato un evento per segnalare la modifica ad altre parti del contratto smart o alle applicazioni esterne. Questo è un modello tipico, ad esempio, per il popolamento dei dati fuori dalla catena, tramite un bus di servizio per l'elaborazione di eventi generati da un contratto intelligente e pubblicazione dei messaggi di listener di traccia pertinenti. Figura 2 identifica le entità coinvolte in un flusso di lavoro all'interno di un contratto intelligente.

Entità del flusso di lavoro in un contratto intelligente
Figura 2 entità del flusso di lavoro in un contratto intelligente

Ethereum Usa Solidity come linguaggio di programmazione per la scrittura logica di business self-l'applicazione per smart Contract. Smart Contract in Solidity sono simili alle classi nei linguaggi orientate a oggetti. Ogni contratto contiene i ruoli, stato e le funzioni per implementare gli attori, fasi e le azioni di un processo di business.

Il frammento di codice nel figura 3 illustra i diversi tipi di dichiarazione di variabile in Solidity per i ruoli, stato e sulle proprietà che possono essere usate in un contratto intelligente per un'applicazione scommesse. I ruoli (il gambler e il bookmaker) vengono definiti come indirizzo, che è l'identificatore univoco di un utente o un contratto in Ethereum. Lo stato è un'enumerazione delle etichette che identifica lo stato corrente di una maggiore rilevanza inserito tramite il contratto intelligente. Le funzioni, come vedrà in seguito, definiscono una modifica dello stato. La quantità maggiore rilevanza viene espresso come un numero senza segno (Solidity, attualmente non supporta valori decimali).

Figura 3 dichiarazione dei ruoli, stato e le proprietà nel contratto di Smart scommesse

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;

Si noti l'indicazione della versione di Solidity cui piattaforma di destinazione per questo contratto intelligente. È consigliabile indicare questa istruzione pragma per evitare problemi di incompatibilità con le versioni future del linguaggio di programmazione Solidity e del compilatore. Ciò consente inoltre di identificare il codice precedente in un contratto intelligente, che debba essere sostituiti con una nuova versione per supportare codice aggiornato. Il processo di rimozione di un contratto smart esistente da una blockchain è denominato "autodistruzione".

Un contratto smart deve avere una singola responsabilità e contenere un minimo per la logica di business possibili, in modo ottimale solo la logica di convalida necessaria per lo ritiene di un contratto valido o non. Nella mia applicazione scommesse, un contratto intelligente può esporre le funzioni per l'inserimento di una maggiore rilevanza per il gambler e riconoscimento di rischio della perdita di bookmaker o win. Valuta può essere scambiato tra i due ruoli, come parte del flusso di lavoro maggiore rilevanza. Il modello abituale per transazioni monetarie che richiede la convalida di un contratto vede il trasferimento di quantità in corso in due fasi, come indicato nella figura 4. Per un certo importo, che viene quindi archiviato nel contratto di smart gambler (iniziatore del contratto) inserito una maggiore rilevanza. Se la maggiore rilevanza va a buon fine, la quantità vinti, indicata da bookmaker, l'ha viene trasferita al gambler. In caso contrario, il bookmaker cashes la quantità maggiore rilevanza.

Mettendo del flusso di lavoro
Figura 4 scommettere flusso di lavoro

Come illustrato nella figura 5, l'implementazione di questo contratto smart in Solidity è necessario definire diverse funzioni per ogni azione del flusso di lavoro, come indicato di seguito:

  • Il costruttore archivia il mittente del messaggio come gambler; si tratta del ruolo che avvia il contratto intelligente.
  • La funzione di maggiore rilevanza accetta una quantità come input, esegue alcune convalide (questa funzione può essere chiamata solo dal gambler e la quantità deve essere maggiore di zero), quindi trasferisce la quantità maggiore rilevanza per il contratto. Per consentire i trasferimenti di tipo valuta nella catena, è necessario contrassegnare una funzione come contabilità fornitori.
  • La funzione di opportunità vinte, dopo aver verificato che l'invoker non gambler, trasferisce la quantità acquisita al gambler e chiude la maggiore rilevanza come "Ha vinto."
  • La funzione persi, che anche in questo caso può essere chiamato solo dal bookmaker, trasferimenti quantità inizialmente scommettere e ora perso da gambler, con la bookmaker e chiude la maggiore rilevanza come "Persi".
  • Chiudendo una maggiore rilevanza, viene rimosso il gambler (l'indirizzo è impostato su 0x0) e la quantità impostata su zero, sono pronti per un'altra soluzione.

Figura 5 funzioni nel contratto di Smart scommesse

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

Anche se semplice nell'implementazione, questo scenario identifica un modello tipico per la gestione delle spese in un'applicazione di blockchain. Altri scenari potrebbe essere necessario incorporare attestable file, ad esempio documenti, fogli di calcolo, i certificati e immagini. Per diversi motivi, principalmente relativi a limiti di archiviazione, non è opportuno inserire i file in una blockchain. Un approccio comune è di eseguire un hash di crittografia (ad esempio, SHA-256) rispetto a un file e di condividere tale hash su un libro mastro distribuito. Il sistema esterno invece rende persistente il file in un meccanismo di archiviazione, ad esempio archiviazione di Azure o di pagina non valida (ipfs.io).

Esegue l'hash con lo stesso algoritmo hash in qualsiasi momento futuro restituirà lo stesso risultato, a meno che non è stato modificato il file persistente, anche se un solo pixel viene modificato in un'immagine. Questo processo concede la prova dell'esistenza di un oggetto di informazioni, ad esempio un messaggio di posta elettronica, file, documenti, chiamata telefonica o video presenti in un determinato punto nel tempo. Concede inoltre come prova dell'autenticità, ovvero si conosce un asset digitale non è stato modificato perché vengono archiviati il ledger digitale modificabile e indipendenti, verificabile record di tutte le transazioni. Per altre informazioni sul valore della blockchain in Gestione dei contenuti dell'organizzazione, leggere il post è pubblicata nel bit.ly/2OC2Ycp.

Event Sourcing e CQRS

Come descritto nella sezione precedente, è consigliabile creare smart Contract la responsabilità di solo una funzionalità. Mentre e orientati alle funzionalità di progettazione è una tecnica fondamentale per l'isolamento di smart Contract, non è sufficiente a garantire deployability indipendenti. Smart Contract può operare su un modello di dati comune all'interno del dominio del sistema, nonostante restando comunque isolate in esecuzione. Ad esempio, in un'applicazione potrebbe esserci un contratto per la gestione di rilevanza e l'altro per la gestione di eventi sportivi in cui a scommettere intelligente. Il contratto intelligente per scommettere può fare riferimento a un evento sportivo, creazione di una dipendenza tra i due contratti intelligenti (scommettere non può verificarsi se un evento non esiste). È disponibile un modo per modellare i dati che consentono di evitare la condivisione tra smart Contract dei dati?

Qualsiasi formato e archiviazione (SQL, NoSQL, JSON) viene usato, i database in base a oggetti e creazione, lettura, aggiornamento, le operazioni di eliminazione (CRUD) è in genere modello. Invece di archiviare le strutture che lo stato del dominio, modello permetterci di archiviare gli eventi che conducono allo stato corrente del mondo. Questo approccio alla modellazione viene chiamato origine evento (bit.ly/2O68nrt).

Origine evento riguarda l'archiviazione dei fatti. Un fact è un valore rappresentativo dell'occorrenza di un evento. Solo come nella vita, Microsoft non è possibile tornare indietro nel tempo e modificare passato, ovvero è solo possibile fare qualcosa in quella attuale per compensare le azioni precedenti. Dati non sono modificabili; quindi, abbiamo sempre rilasciato un nuovo comando o un evento per compensare, anziché aggiornare, lo stato di un'entità. Questo approccio viene eseguito con l'acronimo di GRANCHI, ovvero creare, recuperare, accodare e Burn (bit.ly/2MbpUOb), che è esattamente ciò che consente di eseguire una blockchain: nessun aggiornamenti dei dati o le eliminazioni, viene aggiunto solo alla catena. Eliminazione di un elemento da una blockchain è in conflitto con la non modificabilità, ma è possibile arrestare il trasferimento di asset "masterizzazione" l'indirizzo del destinatario.

Un problema immediato di questo approccio è delle prestazioni. Se qualsiasi valore di stato è una funzione di eventi, si potrebbe supporre che ogni accesso al valore richiede la ricalcolo dello stato corrente dagli eventi di origine. Ovviamente, sarebbe molto lenta. In schema event sourcing, è possibile evitare tali operazioni dispendiose utilizzando uno snapshot in sequenza le cosiddette: una proiezione dello stato dell'entità in un determinato punto nel tempo. Ad esempio, le banche pre-calcolano il saldo del conto bancario l'ultimo giorno del mese, in modo che non è necessario eseguire la somma di tutti i debiti e operazioni di crediti dal giorno è stato aperto il conto bancario per ottenere il saldo corrente.

Figura 6 Mostra il modello di dati strutturale per l'applicazione scommesse. Si tratta in alcuni casi il modello con schema snowflake, perché ogni entità (una tabella di database) è diverso da qualsiasi altro.

Modello di dati strutturali
Figura 6 modello a struttura dei dati

Il modello di dati strutturale Salva solo lo stato corrente del sistema, mentre l'approccio evento-sourcing Salva singoli dati. In schema event sourcing, lo stato è una funzione di tutti i fatti pertinenti che si sono verificati. Non solo questo assegnare automatizzata completa, ma anche ci consente di compilare le proiezioni di stato verso qualsiasi momento nel passato.

Per eseguire il push in questo ulteriore in termini di isolamento di responsabilità, comando Query Responsibility Segregation (CQRS) si integra con origine eventi come un modello di progettazione per l'archiviazione dei dati. CQRS incoraggia efficace singola responsabilità e deployability dei microservizi e dall'estensione per smart Contract. Afferma che è possibile ed è consigliabile, separare l'aggiornamento dei dati dalle funzionalità di query di dati in modelli distinti.

Quando si usa il modello CQRS, può essere eliminata la necessità di accedere ai dati in più contesti. Un contratto di smart può proprietari e incapsula tutti gli aggiornamenti dello stato del modello e generare eventi in caso di modifica dello stato. Tramite la sottoscrizione a notifiche di questi eventi, un contratto separato intelligente può compilare un modello completamente indipendente e ottimizzate per la query che non deve necessariamente essere condivisi con qualsiasi altro contratto o servizio esterno. Altre informazioni su CQRS dall'inserimento di Fowler bit.ly/2Awoz33.

Figura 7 descrive il modello di dati che ho progettato per l'applicazione scommesse usando l'origine evento. Questo modello semplice Usa una struttura simile indipendentemente dal fatto l'evento come gestito. Non è necessario conoscere lo stato corrente della finestra di maggiore rilevanza per leggere la sequenza di eventi. Struttura dei dati dell'evento varia a seconda dell'evento stesso. Anche se è presente una sequenza degli stati come definito nel flusso di lavoro, è irrilevante dal punto di vista del modello di dati. Pensare più grande: In uno scenario della supply chain, più flussi di lavoro e gli eventi presenti, con diverse entità e attributi. Il modello di dati strutturale può raggiungere complesso, mentre il modello basato su eventi, a barre alcuni attributi diversi per ogni evento, rimane costante.

Modello di dati di origine eventi
Figura 7-Sourcing di eventi del modello di dati

Transazioni distribuite

Un modello di dati condiviso non è il solo caso d'uso che possono introdurre accoppiamento stretto fra smart Contract. Un'altra minaccia importante è flussi di lavoro. Molti processi reale non possono essere rappresentato con una singola operazione atomica. Con tali flussi di lavoro, il risultato ha senso solo se tutti i passaggi possono essere eseguiti. Se un passaggio della sequenza non riesce, lo stato risultante del relativa al sistema diventa non valido. Nel mondo RDBMS, questi processi sono definiti "transazioni". Le transazioni di database sono in genere locali, inclusi entro i confini di un singolo database e si basano sui blocchi sulle tabelle prima degli aggiornamenti. Se un passaggio non riesce, è possibile ripristinare i passaggi già tentati prima un commit finale.

Per i microservizi senza stato, un'implementazione di transazioni tradizionale con blocchi di dati e atomicità, consistenza, isolamento, la conformità di durabilità (ACID) e flussi di lavoro distribuite (en.wikipedia.org/wiki/ACID) è poco pratico. Sagas (bit.ly/2AzdKNR) sono di lunga durata delle transazioni distribuite che consentono l'esecuzione di flussi di lavoro negli ambienti di accoppiamento, senza effettuare alcun presupposto sull'affidabilità di ciascun componente del sistema complesso.

In sagas, ogni passaggio nel flusso di lavoro esegue la parte del lavoro, registra una chiamata a una transazione di compensazione in un messaggio denominato "lista di distribuzione" e passa il messaggio aggiornato lungo la catena di attività. Se un passaggio a valle non riesce, questo passaggio esamina la lista di distribuzione e richiama transazione di compensazione del passaggio più recente, passare nuovamente alla lista di distribuzione. Il passaggio precedente esegue la stessa operazione, la chiamata di transazione di compensazione del suo predecessore e così via fino a quando non vengono compensate tutte le transazioni già eseguite. Questo modello comporta la coerenza finale dei dati in una transazione distribuita (bit.ly/2v8T360). Grazie alla sua natura distribuita, elevata e tolleranza di errore, sagas sono molto particolarmente adatti per un'architettura di microservizi, nonché sulla blockchain smart Contract.

È possibile implementare una sorta di lista di distribuzione con le funzioni di fallback in Solidity. Una funzione di fallback è una funzione non denominata definita con nessun argomento di input e restituisce alcun valore. Se nessuna delle altre funzioni di corrispondere all'identificatore di funzione specificata o ogni volta che il contratto riceve etere (nel caso Ethereum) viene eseguito in una chiamata al contratto. Inoltre, per ricevere etere, la funzione di fallback deve essere contrassegnata da pagare. Se WeekOfTheMonth non esiste, il contratto non può ricevere etere tramite normali (indirizzo-a-address) transazioni.

Vale la pena ricordare che un contratto senza una funzione di fallback debito può ricevere etere come un destinatario di una transazione coinbase, ad esempio un premio di blocco miner. Un contratto non può rispondere a tali trasferimenti etere e, di conseguenza, anche non è possibile rifiutarli. Questa è una scelta di progettazione di Ethereum e solidità non è possibile risolvere il problema. Un contratto può avere esattamente una funzione senza nome, come illustrato di seguito:

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

Nella Ethereum, sono necessari per un contratto intelligente consentire il trasferimento diretto di account-account-per funzioni di fallback. Questo avviene perché l'account del trasferimento dei potrebbe essere necessario eseguire i trasferimenti per entrambi esternamente proprietà dell'account (EOAs) e per altri smart Contract. Come EOAs può accettare solo i trasferimenti diretti, è l'unico modo per un account per il trasferimento di valore a un altro account per il contratto di esecuzione implementare una funzione di fallback. Ciò significa che qualsiasi contratto che deve accettare che tali trasferimenti devono essere preparati per il trasferimento diretto facendo in modo che una funzione di fallback. Senza tale funzione, il trasferimento potrebbe non riuscire e sarebbe impossibile per il contratto accettare etere dal contratto di altri.

Una procedura consigliata è di non usare alcuna logica nella funzione di fallback. È possibile inserire il codice nel corpo di questa funzione, ma è preferibile evitare nient'altro che la registrazione molto breve e semplice. Il motivo è importante e smart Contract univoco: Questa funzione viene eseguita perché è in esecuzione all'esterno di gas non si desidera. Come regola generale, si avrà sufficiente gas per generare un evento, ma non sufficienti per scrivere dati in archiviazione.

Messaggistica asincrona

Messaggistica asincrona svolge un ruolo fondamentale nel mantenere la trattazione regime di controllo in un'architettura di microservizi. Ad esempio, è possibile usare un broker di messaggi per recapitare le notifiche degli eventi in modo asincrono, che impedisce le connessioni da punto a punto che crea una dipendenza in ogni formato di disponibilità e il messaggio dell'endpoint. Con lo stesso token, smart Contract possono trarre vantaggio dall'integrazione abilitati per la messaggistica per traffico in ingresso (da esterno a interno blockchain) e in uscita (da blockchain verso le applicazioni esterne) comunicazione.

Oltre a fornire un'API REST, Azure Blockchain Workbench fornisce integrazione basato sulla messaggistica basata su eventi sugli elementi ledger. Gli eventi vengono pubblicati in una griglia di eventi di Azure e i consumer possono inserire i dati o eseguire azioni sulla base di questi eventi. Per i client che richiedono messaggistica affidabile, Azure Blockchain Workbench recapita i messaggi a un endpoint del Bus di servizio di Azure, nonché. È possibile generare eventi, ad esempio, per avvisare utenti e i sistemi di transazioni o le modifiche dello stato di un contratto intelligente. Le notifiche degli eventi possono essere utilizzate direttamente nel codice o utilizzati con gli strumenti, ad esempio App per la logica (bit.ly/2n4EgoP) per attivare il flusso di dati nei sistemi a valle.

Smart Contract versioni rappresentano spesso un flusso di lavoro di business che si integra con i dispositivi e sistemi esterni. Di conseguenza, le transazioni devono essere in grado di avviare un libro mastro distribuito che include i dati da un dispositivo o un sistema esterno. È anche possibile avere sistemi esterni di reagire agli eventi provenienti da smart Contract su un libro mastro distribuito. L'API REST e integrazione di messaggistica consentono di inviare le transazioni provenienti da sistemi esterni a smart Contract inclusi in un'applicazione Azure Blockchain Workbench e inviare le notifiche degli eventi a sistemi esterni in base alle modifiche che si verificano all'interno di un'applicazione. Esaminiamo ora gli schemi identificati per ciascuno di questi tipi di integrazioni nelle soluzioni end-to-end:

  • Recapito di eventi unidirezionale da un contratto intelligente al consumer di eventi.
  • Unidirezionale recapito di eventi di un messaggio da un sistema esterno a un contratto intelligente.

Contratto intelligente da un Consumer di eventi

Nel primo scenario, si verifica un evento all'interno di un contratto intelligente; ad esempio, una modifica dello stato o l'esecuzione di un tipo specifico della transazione. Questo evento viene trasmesso tramite griglia di eventi per i consumer downstream e i consumer quindi intraprendere le azioni appropriate. Un esempio di questo scenario è che quando si verifica una transazione, un consumer potrebbe ricevere un avviso e può agire, ad esempio le informazioni di registrazione in un database. Questo è lo stesso modello di Azure Blockchain Workbench seguito per popolare il database SQL fuori dalla catena. Un altro sarebbe se un contratto smart passa a uno stato specifico. ad esempio, quando un contratto passa in uno stato "Out of conformità". Quando si verifica questo cambiamento di stato, potrebbe attivare un avviso da inviare all'amministratore. In questo caso usando la procedura illustrata nel figura 8, dove:

  1. Il contratto smart esegue la transizione a un nuovo stato e invia un evento per la contabilità.
  2. Il libro mastro riceve e recapita l'evento Azure Blockchain Workbench.
  3. Azure Blockchain Workbench ha sottoscritto gli eventi della contabilità e riceve l'evento.
  4. Azure Blockchain Workbench pubblica l'evento ai sottoscrittori in griglia di eventi.
  5. I sistemi esterni hanno effettuato l'iscrizione di griglia di eventi, usare il messaggio e intraprendere l'azione appropriata.

Propagazione di un evento generato in un contratto intelligente a un sistema esterno
Figura 8 propagazione di un evento generato in un contratto intelligente a un sistema esterno

Sistema esterno a un contratto intelligente

È inoltre disponibile uno scenario con flusso da direzione opposta. In questo caso, viene generato un evento da un sensore o un sistema esterno e i dati da tale evento devono essere inviati a un contratto intelligente. Un esempio comune è il recapito dei dati da mercati finanziari, ad esempio i prezzi di merci, quotazioni di borsa o obbligazioni, a un contratto intelligente. In questo caso usando la procedura illustrata nel figura 9, dove:

  1. Si verifica un evento in un sistema esterno che attiva la creazione di un messaggio per Azure Blockchain Workbench.
  2. Il sistema esterno ha codice scritto per creare il messaggio in un formato noto e si invia direttamente al Bus di servizio.
  3. Azure Blockchain Workbench ha sottoscritto gli eventi del bus di servizio e recupera il messaggio.
  4. Azure Blockchain Workbench avvia una chiamata per la contabilità, l'invio di dati dal sistema esterno a un contratto specifico.
  5. Al momento della ricezione del messaggio, le transizioni di contratto a un nuovo stato possibili.

Propagazione di un evento generato da un sistema esterno a un contratto intelligente
Figura 9 propagazione di un evento generato da un sistema esterno a un contratto intelligente

L'implementazione di una soluzione end-to-end per uno scenario di integrazione esula dall'ambito di questo articolo. Ottimi esempi di integrazione in entrambe le direzioni reperibili bit.ly/2M8yflL.

In sintesi, i modelli di integrazione simili è reperibile in architetture di microservizi e smart Contract blockchain. La natura distribuita di entrambe le architetture incoraggia la messaggistica asincrona e l'utilizzo di un broker di messaggi, sotto forma di un bus di servizio o di griglia di eventi, per trasmettere informazioni tra servizi e smart Contract. Modelli di progettazione, ad esempio schema event sourcing, corrispondono in definitiva, la natura non modificabile di un ledger digitale e l'approccio basato sugli eventi per la comunicazione fuori dalla catena.

Esplorare l'API di Azure Blockchain Workbench

Azure Blockchain Workbench (aka.ms/abcworkbench) è un servizio che, in minuti, crea un ledger digitale blockchain (attualmente, Ethereum). Fornisce inoltre risorse ospitate in Azure per lo sviluppo rapido di smart Contract, riducendo al minimo l'infrastruttura sottostante necessari per eseguire Ethereum o piattaforma blockchain simile una preoccupazione.

Se si ha familiarità con Azure Blockchain Workbench, vedere l'introduzione a esso nel numero di giugno di MSDN Magazine (msdn.com/magazine/mt846726). Azure Blockchain Workbench fornisce agli sviluppatori con un'API REST come gateway per l'integrazione di applicazioni desktop, Web e per dispositivi mobili per applicazioni blockchain. Ad esempio, uno sviluppatore può usare l'API per consentire ai dispositivi IoT inviare dati a un contratto smart. O l'API può essere utilizzata da Power BI per creare la visualizzazione dei dati di blockchain. L'API espone un ampio set di funzionalità di Azure Blockchain Workbench, organizzati in gruppi di operazioni, come indicato nella figura Ae può essere usato per automatizzare le operazioni seguenti:

  • Creazione e la gestione dei flussi di lavoro all'interno di un consorzio di blockchain.
  • Associazione di utenti e organizzazioni con un consorzio, applicazioni blockchain o del flusso di lavoro dell'applicazione.
  • Esecuzione di transazioni su una blockchain.
  • Il recupero delle transazioni e del contratto dati da una blockchain.

 

Operazione di gruppo Descrizione
Applicazioni Gestione delle applicazioni blockchain Blockchain Workbench.
Funzionalità Elenco delle funzionalità di che un utente può eseguire all'interno di Blockchain Workbench.
Controlli Strumenti di sviluppo usati per convalidare i contratti intelligenti di configurazione e la blockchain Workbench.
Connessioni Connessione alle reti di blockchain.
Contratti Istanze di contratto intelligenti, tra cui capacità di agire sulle smart Contract.
Proxy di Graph Rappresenta un metodo del proxy per l'API di Graph di Azure Active Directory per gli utenti.
Integrità Stato di integrità dell'API di Blockchain Workbench.
Ledger Le reti di blockchain è supportata.
Utenti Gestione degli utenti all'interno di Blockchain Workbench.

Figura A gruppi di operazione API REST di Azure Blockchain Workbench

Le richieste HTTP all'API REST sono protette con Azure Active Directory (Azure AD). Per eseguire una richiesta autenticata a un'API REST, è necessario essere autenticati con credenziali valide prima di poter chiamare l'API client. L'autenticazione è coordinata tra i vari attori da Azure AD e offre il client con un token di accesso come prova dell'autenticazione. Il token viene quindi inviato nell'intestazione dell'autorizzazione HTTP di ogni richiesta dell'API REST. Vedere i seguenti esempi su GitHub per informazioni su come eseguire l'autenticazione di un'applicazione client per l'API REST di Azure Blockchain Workbench al bit.ly/2vxzlAC.

Repository GitHub contiene altri esempi di come richiamare i diversi servizi per l'elenco delle applicazioni, i flussi di lavoro e i contratti in una blockchain. Anche se l'implementazione corrente di Azure Blockchain Workbench supporta solo Ethereum, nelle versioni future verranno estesi il supporto per altri libri mastri digitale. Al termine, l'API fornirà un accesso comune per qualsiasi piattaforma supportata blockchain con una singola applicazione interfaccia, indipendentemente dalla tecnologia di programmazione e la programmazione di linguaggio in uso.


Stefano Tempestaè un Microsoft Regional Director e double MVP su intelligenza artificiale e applicazioni aziendali, nonché leader capitolo per la community di Microsoft Dynamics 365 in Svizzera. Tempesta è un insegnante di corsi su Dynamics 365, blockchain e machine learning e partecipa regolarmente come oratore a conferenze IT internazionali, tra cui Microsoft Ignite e Tech Summit. Ha fondato Blogchain spazio (blogchain.space), un blog sulle tecnologie della blockchain, scrive per MSDN Magazine e MS Dynamics e pubblica esperimenti di machine learning in Azure AI Gallery (Gallery.Azure.ai).

Un ringraziamento al seguente esperto tecnico: Jonathan Waldman


Discutere di questo articolo nel forum di MSDN Magazine