From 3808c0031e77a654e61d57b7fb5fa62ddfaa14c4 Mon Sep 17 00:00:00 2001 From: Shingo Fujimoto Date: Thu, 5 Nov 2020 15:03:19 +0900 Subject: [PATCH] docs(whitepaper): updates on architecture diagram and terminology Signed-off-by: Shingo Fujimoto --- whitepaper/cactus_arch.svg | 2015 ++++++++++++++++++++++++++++++++++++ whitepaper/whitepaper.md | 16 +- 2 files changed, 2026 insertions(+), 5 deletions(-) create mode 100644 whitepaper/cactus_arch.svg diff --git a/whitepaper/cactus_arch.svg b/whitepaper/cactus_arch.svg new file mode 100644 index 0000000000..5315fb73e0 --- /dev/null +++ b/whitepaper/cactus_arch.svg @@ -0,0 +1,2015 @@ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + image/svg+xml + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Synchronous Req. + Synchronous Res. + Async Message + + + + + + + + + + + + + + + + + + Admin API + + Service API + + + Verifier + + Verifierfactory + + + LedgerEventListener + Business Logic Pluginimplementation + + ValidatorAPI + + Ledgerconnectorimpl. + + Servercontroller + + + ValidatorAPI + + Ledgerconnectorimpl. + + + + + + + + + + + + + + + + + + + Trade Context + End UserApplication + Service ProviderApplication + + + CACTUS Node Server + + + validator server(s) + + interface + + plugin-1 + + plugin-N + + + + Legend + Validator'sKey + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Validator'sKey DB + Validatorregistory + + + + + + + + Async comm. + Synchronous comm. + + + diff --git a/whitepaper/whitepaper.md b/whitepaper/whitepaper.md index 408c4caf4c..26fdf74a31 100644 --- a/whitepaper/whitepaper.md +++ b/whitepaper/whitepaper.md @@ -747,19 +747,25 @@ Once an API call to Hyperledger Cactus framework is requested by a User, Busines Following diagram shows the architecture of Hyperledger Cactus based on the discussion made at Hyperledger Cactus project calls. The overall architecture is as the following figure. - + ### 5.2.1 Definition of key components in system architecture Key components are defined as follows: -- **Application user**: The entity submits API calls to "Cactus Routing Interface". Note: this component is exist outside of Cactus service system. +- ~~**Application user**: The entity submits API calls to "Cactus Routing Interface". Note: this component is exist outside of Cactus service system.~~ - **Business Logic Plugin**: The entity executes business logic and provide integration services that are connected with multiple blockchains. The entity is composed by web application or smart contract on a blockchain. The entity is a single plugin and required for executing Hyperledger Cactus applications. +- **CACTUS Node Server**: The server accepts a request from an End-user Application, and return a response depending on the status of the targeted trade. Trade ID will be assigned when a new trade is accepted. +- **End-user Application**: The entity submits API calls to request a trade, which invokes a set of transactions on Ledger by the Business Logic Plugin. +- **Ledger Event Listener**: The standard interface to handle various kinds of events(LedgerEvent) regarding asynchronous Ledger operations. The LedgerEvent will be notified to appropriate business logic to handle it. - **Ledger Plugin**: The entity communicates Business Logic Plugin with each ledger. The entity is composed by a validator and a verifier as follows. The entity(s) is(are) chosen from multiple plugins on configuration. +- **Service Provider Application**: The entity submits API calls to control the cmd-api-server when it is enabling/disabling Ledger plugins, or shutting down the server. Additional commands may be available on Admin API since **Server controller** is implementation-dependent. - **Validator**: The entity monitors transaction records of Ledger operation, and it determines the result(success, failed, timeouted) from the transaction records. Validator ensure the determined result with attaching digital signature with "Validator key" which can be verified by "Verifier". -- **Verifier**: The entity accepts only sucussfully verified operation results by verifying the digital signature of the validator. Note that "Validator" is apart from "Verifier" over a bi-directional channel. -- **Cactus Routing Interface**: The entity is a routing service between "Business Logic Plugin" and "Ledger Plugin(s)". The entity is also a routing service between Business Logic Plugin and API calls from "Application user(s)". -- **Ledger-n**: DLT platforms(e.g. Ethereum, Quorum, Hyperledger Fabric, ...) +- **Validator Server**: The server accepts a connection from Verifier, and it provides Validator API, which can be used for issuing signed transactions and monitoring Ledger behind it. The LedgerConnector will be implemented for interacting with the Ledger nodes. +- **Verifier**: The entity accepts only sucussfully verified operation results by verifying the digital signature of the validator. Verifier will be instantiated by calling the VerifierFactory#create method with associated with the Validator to connect. Each Verifier may be temporarily enabled or disabled. Note that "Validator" is apart from "Verifier" over a bi-directional channel. +- **Verifier Registry**: The information about active Verifier. The VerifierFactory uses this information to instantiate Verifier for the Business Logic Plugin. +- ~~**Cactus Routing Interface**: The entity is a routing service between "Business Logic Plugin" and "Ledger Plugin(s)". The entity is also a routing service between Business Logic Plugin and API calls from "Application user(s)".~~ +- ~~**Ledger-n**: DLT platforms(e.g. Ethereum, Quorum, Hyperledger Fabric, ...)~~ ### 5.2.2 Bootstrapping Cactus application