|
1 | 1 | --- |
2 | | -title: Azure Blockchain Workbench architecture |
3 | | -description: Overview of Azure Blockchain Workbench architecture and its components. |
4 | | -services: azure-blockchain |
5 | | -keywords: |
6 | | -author: PatAltimore |
7 | | -ms.author: patricka |
8 | | -ms.date: 4/20/2018 |
9 | | -ms.topic: article |
10 | | -ms.service: azure-blockchain |
11 | | -ms.reviewer: zeyadr |
12 | | -manager: femila |
13 | | -#Customer intent: As a developer, I want to understand the architecture and components of Azure Blockchain Workbench. |
| 2 | +redirect_url: /azure/blockchain/workbench/architecture |
| 3 | +redirect_document_id: true |
14 | 4 | --- |
15 | | -# Azure Blockchain Workbench architecture |
16 | | - |
17 | | -Azure Blockchain Workbench simplifies blockchain application development by providing a solution using several Azure components. Blockchain Workbench can be deployed using a solution template in the Azure Marketplace. The template allows users to pick the modules and components to deploy with Blockchain Workbench, such as blockchain stack, type of client application, and support for IoT integration. Once deployed, Blockchain Workbench provides access to a web app, iOS app, and Android app. |
18 | | - |
19 | | - |
20 | | - |
21 | | -## Identity and authentication |
22 | | - |
23 | | -Using Blockchain Workbench, a consortium can federate their enterprise identities using Azure Active Directory (Azure AD). Workbench generates new user accounts for on-chain identities with the enterprise identities stored in Azure AD. The identity mapping facilitates authenticated login to client APIs and applications and uses the authentication policies of organizations. Workbench also provides the ability to associate enterprise identities to specific roles within a given smart contract. In addition, Workbench also provides a mechanism to identify the actions those roles can take and at what time. |
24 | | - |
25 | | -After Blockchain Workbench is deployed, users interact with Blockchain Workbench either via the client applications, REST-based client API, or Messaging API. In all cases, interactions must be authenticated, either via Azure Active Directory (Azure AD) or device-specific credentials. |
26 | | - |
27 | | -Users federate their identities to a consortium Azure AD by sending an email invitation to participants at their email address. When logging in, these users are authenticated using the name, password, and policies. For example, two-factor authentication of their organization. |
28 | | - |
29 | | -Azure AD is used to manage all users who have access to Blockchain Workbench. Each device connecting to a smart contract is also associated with Azure AD. |
30 | | - |
31 | | -Azure AD is also used to assign users to a special administrator group. Users associated with the administrator group gain administrator |
32 | | -rights/actions within Blockchain Workbench, such as deploying contracts and giving permissions to a user to access a contract. Users outside this group do |
33 | | -not have access to administrator actions. |
34 | | - |
35 | | -## Client applications |
36 | | - |
37 | | -Workbench provides automatically generated client applications for web and mobile (iOS, Android), which can be used to validate, test, and view blockchain applications. The application interface is dynamically generated based on smart contract metadata and can accommodate any use case. The client applications deliver a user-facing front end to the complete blockchain applications generated by Blockchain Workbench. Client applications authenticate users via Azure Active Directory (Azure AD) and then present a user experience tailored to the business context of the smart contract. The user experience enables the creation of new smart contract instances by authorized individuals and then presents the ability to execute certain types of transactions at appropriate points in the business process the smart contract represents. |
38 | | - |
39 | | -In the web application, authorized users can access the Administrator Console. The console is available to users in the Administrator group in Azure AD and provides access to the following functionality: |
40 | | - |
41 | | -* Deploy Microsoft provided smart contracts for popular scenarios. For example, an asset transfer scenario. |
42 | | -* Upload and deploy their own smart contracts. |
43 | | -* Assign a user access to the smart contract in the context of a specific role. |
44 | | - |
45 | | -## Gateway service API |
46 | | - |
47 | | -Blockchain Workbench includes a REST-based gateway service API. When writing to a blockchain, the API generates and delivers messages to an event broker. When data is requested by the API, queries are sent to the off-chain SQL database. The SQL database contains a replica of on-chain data and metadata that provides context and configuration information for supported smart contracts. Queries return the required data from the off-chain replica in a format informed by the metadata for the contract. |
48 | | - |
49 | | -Developers can access the gateway service API to build or integrate blockchain solutions without relying on Blockchain Workbench client apps. |
50 | | - |
51 | | -> [!NOTE] |
52 | | -> To enable authenticated access to the API, two client applications are registered in Azure Active Directory. Azure Active Directory requires distinct application registrations each application type (native and web). |
53 | | -
|
54 | | -## Message broker for incoming messages |
55 | | - |
56 | | -Developers who want to send messages directly to Blockchain Workbench can send messages directly to Service Bus. For example, messages API could be used for system-to-system integration or IoT devices. |
57 | | - |
58 | | -## Message broker for downstream consumers |
59 | | - |
60 | | -During the lifecycle of the application, events occur. Events can be triggered by the Gateway API or on the ledger. Event notifications can initiate downstream code based on the event. |
61 | | - |
62 | | -Blockchain Workbench automatically deploys two types of event consumers. One is triggered by blockchain events to populate the off-chain SQL store. The other is to capture metadata for events generated by the API related to the upload and storage of documents. |
63 | | - |
64 | | -## Message consumers |
65 | | - |
66 | | - Message consumers take messages from Service Bus. The underlying eventing model for message consumers allows for extensions of additional services and systems. For example, you could add support to populate CosmosDB or evaluate messages using Azure Streaming Analytics. The following sections describe the message consumers included in Blockchain Workbench. |
67 | | - |
68 | | -### Distributed ledger consumer |
69 | | - |
70 | | -Distributed ledger technology (DLT) messages contain the metadata for transactions to be written to the blockchain. The consumer retrieves the messages and pushes the data to a transaction builder, signer, and router. |
71 | | - |
72 | | -### Database consumer |
73 | | - |
74 | | -The database consumer takes messages from Service Bus and pushes the data to an attached database, such as SQL database. |
75 | | - |
76 | | -### Storage consumer |
77 | | - |
78 | | -The storage consumer takes messages from Service Bus and pushes data to an attached storage. For example, storing hashed documents in Azure Storage. |
79 | | - |
80 | | -## Transaction builder and signer |
81 | | - |
82 | | -If a message on the inbound message broker needs to be written to the blockchain, it will be processed by the DLT consumer. The DLT consumer is a service, which retrieves the message containing metadata for a desired transaction to execute and then sends the information to the *transaction builder and signer*. The *transaction builder and signer* assembles a blockchain transaction based on the data and the desired blockchain destination. Once assembled, the transaction is signed. Private keys are stored in Azure Key Vault. |
83 | | - |
84 | | - Blockchain Workbench retrieves the appropriate private key from Key Vault and signs the transaction outside of Key Vault. Once signed, the transaction is sent to transaction routers and ledgers. |
85 | | - |
86 | | -## Transaction routers and ledgers |
87 | | - |
88 | | -Transaction routers and ledgers take signed transactions and route them to the appropriate blockchain. Currently, Blockchain Workbench supports Ethereum as its target blockchain. |
89 | | - |
90 | | -## DLT watcher |
91 | | - |
92 | | -A distributed ledger technology (DLT) watcher monitors events occurring on block chains attached to Blockchain Workbench. |
93 | | -Events reflect information relevant to individuals and systems. For example, the creation of new contract instances, execution of transactions, and changes of state. The events are captured and sent to the outbound message broker, so they can be consumed by downstream consumers. |
94 | | - |
95 | | -For example, the SQL consumer monitors events, consumes them, and |
96 | | -populates the SQL database with the included values. The copy enables recreation of a replica of on-chain data in an off-chain store. |
97 | | - |
98 | | -## Azure SQL database |
99 | | - |
100 | | -The Azure SQL database attached to Blockchain Workbench stores contract definitions, configuration metadata, and a SQL-accessible replica of data stored in the blockchain. This data can easily be queried, visualized, or analyzed by directly |
101 | | -accessing the database. Developers and other users can use |
102 | | -the database for reporting, analytics, or other data-centric |
103 | | -integrations. For example, users can visualize transaction data using Power BI. |
104 | | - |
105 | | -This off-chain storage provides the ability for enterprise organizations to query data in SQL rather than in a blockchain ledger. Also, by standardizing on a standard schema that's agnostic of blockchain technology stacks, the off-chain storage enables the reuse of reports and other artifacts across projects, scenarios, and organizations. |
106 | | - |
107 | | -## Azure Storage |
108 | | - |
109 | | -Azure Storage is used to store contracts and metadata associated with contracts. |
110 | | - |
111 | | -From purchase orders and bills of lading, to images used in the news and medical imagery, to video originating from a continuum including police body cameras and major motion pictures, documents play a role in many blockchain-centric scenarios. Documents are not appropriate to place directly on the blockchain. |
112 | | - |
113 | | -Blockchain Workbench supports the ability to add documents or other media content with blockchain business logic. A hash of the document or media content is stored in the blockchain and the actual document or media content is stored in Azure Storage. The associated transaction information is delivered to the inbound message broker, packaged up, signed, and routed to the blockchain. This process triggers events, which are shared via |
114 | | -the outbound message broker. The SQL DB consumes this information and sends it to the DB for later querying. Downstream systems could also consume these events to act as appropriate. |
115 | | - |
116 | | -## Monitoring |
117 | | - |
118 | | -Workbench provides application logging using Application Insights and Azure Monitor. Application Insights is used to store all logged information from Blockchain Workbench and includes errors, warnings, and successful operations. Application Insights can be used by developers to debug issues with Blockchain Workbench. |
119 | | - |
120 | | -Azure Monitor provides information on the health of the blockchain network. |
121 | | - |
122 | | -## Next steps |
123 | | - |
124 | | -> [!div class="nextstepaction"] |
125 | | -> [Deploy Azure Blockchain Workbench](blockchain-workbench-deploy.md) |
0 commit comments