This document provides an overview of the architecture and workflow of Hyperledger Composer transactions. It describes how a Composer client submits a transaction which is validated and executed by Composer chaincode on a Fabric peer. It also discusses how the Composer REST server exposes a REST API for the business network model and handles authentication using Passport.js.

1. Hyperledger Composer
Architecture Deep Dive
Dan Selman
2017-07-25 (v0.10.0)

3. A day in the life of a Composer transaction…
Composer
Client
Fabric
Client
Composer
Chaincode
(Go)
Composer
Runtime (JS)
End-User
User
Code
(JS)
Fabric
Shim
(Go)
Duktape JS VM
Peer
Composer
REST
Server
Events

4. Business Network Definition
(Programming Model)

5. Connect and Deploy
• Load the BusinessNetworkDefinition
• BusinessNetworkDefinition.fromArchive or fromDirectory
• Deploy a business network
• AdminConnection.connect(connectionProfileName)
• Connection profiles are loaded from disk. They are JSON documents that include all the
information required to connect to a channel on a Fabric (or other runtimes)
• AdminConnection.deploy(businessNetworkDefinition, options)
• Options can include the endorsement policy
• Deployment is currently an install followed by an instantiate. We are breaking these
steps apart.
• Install Composer chaincode (Go), instantiate Composer chaincode (Go), send a HLF
transaction with the business network archive payload to the chaincode.
• BusinessNetworkDefinition archive is stored in the world-state on the blockchain

6. Submit Transaction
• Create a BusinessNetworkClient connection
• BusinessNetworkClient.connect(connectionProfileName)
• BusinessNetworkClient.submitTransaction(tx)
• TX is validated against the model
• TX is serialized to JSON
• Use Node-SDK to submit the JSON payload to the Composer system
chaincode

8. Handle Transaction (on peer)
• Validate the JSON for the transaction against the model
• Attempt to resolve the relationships in the transaction
• Call the Access Control Engine to determine whether the current participant has
permission to execute this transaction
• Find all Transaction Processor functions that are subscribed to the
type of the transaction
• For each:
• Invoke the function
• All access to assets, participants and transactions are filtered through the
declarative Access Control Engine

11. Composer “Current Participant”
• Fabric access is authenticated using the standard certificate based
authentication mechanism
• Composer system chaincode maps the fingerprint for certificate used
to submit the transaction to a Composer participant. A Participant is a
modelled entity in a business network, which could represent a
user/org/system, with arbitrarily complex metadata and relationships
• Composer includes APIs and CLIs to manage the mapping from a
certificate to a Participant instance.
• Issue identity, revoke, bind
• A single participant could have multiple identities (certificates)

12. Composer REST Server
• Based on Open Source LoopBack technology
• Connect to a Business Network
• Introspect the model (assets, participants, transaction, queries)
• System types: identities, ping etc
• Automatically generate strongly-typed REST routes based on the model for
the business network definition
• Uses the Open Source passport.js framework for authentication
• Supports 100+ authentication provides, Twitter, GitHub, LDAP, OAuth,IBM ID etc.
• Wallet REST APIs map from an external ID (e.g. GitHub) to a PKI certificate
• Wallet persistence is delegated to LoopBack (so supports 20+ relational and
non-relational back-ends