Hyperledger Composer部署过程解析：模型转换及与Fabric Invoke映射问询

Great question! Let me break down how Hyperledger Composer handles deployment and maps its transaction logic to Hyperledger Fabric's core mechanisms:

First, let's clarify what happens when you deploy a Composer Business Network Definition (BND)—the bundle of your CTO model, JavaScript transaction functions, ACL rules, and queries:

• You package your BND into a .bna file using composer archive create.
• When you deploy this archive to a Fabric network via composer network deploy (or newer equivalent CLI commands), Composer converts the entire BND into a Node.js-based Fabric chaincode.
• Unlike Go-based Fabric chaincode (which compiles to native binary bytecode), Composer's generated chaincode stays in JavaScript. It runs inside a Fabric chaincode container using the Node.js runtime—so there’s no compilation to machine-level bytecode here. The chaincode is installed onto Fabric peer nodes as-is, and instantiated with the BND's content embedded within it.
• During instantiation, Composer sets up state structures matching your CTO entities in Fabric's world state, and activates ACL rules as runtime permission checks.

The connection between Composer's transaction logic and Fabric's core Invoke flow is handled by the generated Node.js chaincode and Composer's SDK:

• When you define a transaction function in your script.js (e.g., async function transferVehicle(tx) { ... }), Composer registers this function with a unique identifier tied to your transaction’s namespace and type (from the CTO model).
• When a client uses the Composer SDK to submit a transaction (via transaction.submit()), the SDK constructs a Fabric transaction proposal targeting your deployed Composer chaincode, with:
  • The fcn (function name) set to invoke (Fabric chaincode’s standard entry point)
  • Args containing serialized metadata about the transaction (namespace, type) and its payload data
• The Fabric peer receives this proposal and triggers the chaincode’s Invoke method. Inside the generated Composer chaincode, this Invoke method acts as a router:
  • It deserializes incoming args to identify which Composer transaction function needs to run
  • It first enforces applicable ACL rules to verify the submitting identity has permission to execute the transaction
  • If permissions check out, it runs your custom JavaScript transaction function, handling state updates (like modifying assets/participants) by interacting with Fabric's world state API
• After execution, the chaincode returns a response to the peer, which goes through Fabric’s standard endorsement, ordering, and commit flow to write the updated state to the ledger.

A key takeaway: Composer abstracts most of Fabric’s low-level chaincode details, so you don’t have to write raw Fabric chaincode yourself—but under the hood, every transaction you define is routed through Fabric’s core Invoke pipeline via the generated chaincode layer.

内容的提问来源于stack exchange，提问作者ulu