Summary
– Hyperledger Composer is an open‑source, JavaScript‑based application development framework that was built to accelerate creation of business blockchain applications on Hyperledger Fabric. It provided high‑level modeling (assets, participants, transactions), reusable components, a web “Playground” for testing, and generators (APIs and REST) to expose business networks to client apps.
– Important: Hyperledger Composer was deprecated (status deprecated August 2019). It is no longer actively developed or supported; its concepts were folded into later Hyperledger Fabric releases. Composer is useful for learning, prototyping, or maintaining legacy Composer networks, but it is not recommended for new production projects. (Sources: Investopedia; The Linux Foundation) [Links at end]
1) Key concepts and architecture (plain language)
– Purpose: Composer simplified building business logic and common models for permissioned blockchain solutions so business users and developers could collaborate without writing low‑level chaincode from scratch.
– Primary entities:
• Asset: an item that has value in the business network (e.g., a shipment, invoice, certificate).
• Participant: an organization or person who interacts with the network (e.g., farmer, shipper).
• Transaction: an operation that changes assets or state and triggers logic.
• Transaction processor scripts: JavaScript functions that execute business logic when transactions are submitted.
• Access Control Lists (ACL): rules that control who can read/submit/update/delete network resources.
• Business Network Archive (BNA): a packaged file that contains the model, scripts, ACLs, queries and metadata for a business network.
– Runtime & integration:
• Composer ran on top of Hyperledger Fabric; Composer translated the high‑level models and logic into Fabric chaincode for execution.
• Composer provided a composer-rest-server that could auto‑generate REST APIs for a deployed business network, and a LoopBack connector for integration with external systems.
• Developer tooling included composer-cli (CLI), composer-playground (web UI), and Yeoman generators.
2) Why teams used Composer (advantages)
– Faster prototyping: high‑level modeling (.cto files) and JavaScript transaction logic sped development compared with hand‑coding Fabric chaincode.
– Business‑friendly: domain modeling allowed business stakeholders to capture requirements without deep knowledge of chaincode or Fabric internals.
– Reusability: packaged business networks could be reused across organizations and environments.
– Built‑in testing and Playground: web‑based Playground permitted interactive modeling and testing without full local Fabric setup.
– Auto APIs: composer‑rest‑server quickly produced REST interfaces to the deployed network for client apps.
3) Limitations and deprecation — what you must know
– Deprecated: Composer entered deprecated status in Aug 2019. Maintainers aren’t adding new features or support. Composer’s concepts remain useful, but production systems should migrate to Fabric‑native approaches.
– Compatibility risks: Composer historically depended on specific Fabric and Node.js versions; using it with newer stacks can be problematic.
– Migration cost: Networks built with Composer must be reimplemented as Fabric chaincode (e.g., Node, Go, or Java chaincode) or replaced with Fabric SDK/API layers to continue in supported environments.
(References: Investopedia; The Linux Foundation)
4) Typical Composer project structure (what you would author)
– A minimal business network contains:
• models/ (file extension .cto): asset/participant/transaction definitions
• lib/ (JavaScript): transaction processor scripts
• permissions.acl: access control rules
• queries.qry (optional): named queries
• package.json: metadata and dependencies
• README.md and other documentation
– All of this is packaged into a Business Network Archive (BNA) for deployment.
5) Practical steps — building a simple “Perishable Goods” proof‑of‑concept (for learning or legacy maintenance)
Note: Because Composer is deprecated, only attempt this in an isolated learning environment (e.g., a VM or container with historically compatible Node/Docker versions), or use Composer Docker images if available.
High‑level workflow
1. Prepare environment (learning only)
• Install prerequisites: Docker and Docker Compose, Git, and a Node.js version known to work with Composer (historically Node 8.x or 10.x depending on Composer release). Use caution: current Node versions may be incompatible.
• Optionally use a prebuilt Composer development VM/container to avoid environment mismatch.
2. Install Composer tools (historical commands — may require specific Node version)
• npm install -g composer-cli composer-rest-server generator-hyperledger-composer composer-playground
• (If using local Playground: npm install -g composer-playground, and start it)
• Verify with composer –version or composer-cli commands.
3. Model your business network
• Create a project folder. Add a model file (models/perishables.cto) with assets and participants. Example model snippet:
namespace org.example.perishables
asset Shipment identified by shipmentId {
o String shipmentId
o String description
o String status
o Double temperature
• > Participant owner
}
participant Farmer identified by farmerId {
o String farmerId
o String name
}
transaction UpdateTemperature {
o String shipmentId
o Double temperature
}
• Add JavaScript transaction processor in lib/logic.js:
/**
* Sample transaction processor
* @param {org.example.perishables.UpdateTemperature} tx
* @transaction
*/
async function updateTemperature(tx) {
const ns = ‘org.example.perishables’;
const shipmentRegistry = await getAssetRegistry(ns + ‘.Shipment’);
const shipment = await shipmentRegistry.get(tx.shipmentId);
shipment.temperature = tx.temperature;
if (tx.temperature > 10) { shipment.status = ‘AT_RISK’; }
await shipmentRegistry.update(shipment);
}
4. Define access controls (permissions.acl)
• Example: give Farmers permission to submit UpdateTemperature transactions on shipments they own.
rule FarmerCanUpdateTemp {
description: “Farmers can update temp on their shipments”
participant(p): “org.example.perishables.Farmer”
operation: CREATE
resource(r): “org.example.perishables.UpdateTemperature”
condition: (some condition if needed)
action: ALLOW
}
5. Create package.json and metadata, then build BNA
• composer archive create -t dir -n .
• This produces a .bna file representing the business network.
6. Deploy to a Fabric test network
• Start a Fabric test network compatible with the Composer release.
• Install and start the .bna using composer network install and composer network start commands (historical).
• Create identities for participants (composer participant add or issuing identities) and import cards (composer card import) for use with REST or Playground.
7. Test using Playground or composer-rest-server
• composer-playground (web UI) allows you to import the BNA, instantiate network, create participants/assets, and submit transactions interactively.
• composer-rest-server will publish REST endpoints for assets, participants, and transactions so client apps can call them.
8. Iterate: add queries, improve ACLs, add events and historian access.
Caveats:
– Exact CLI commands and required versions vary; consult archived Composer docs if you must run these steps.
– Use Composer only for learning or maintaining legacy Composer networks. Do not start new production systems with Composer.
6) Migrating away from Composer (recommended approach for production)
If you have an existing Composer BNA and want to move to a supported Fabric architecture, follow a migration strategy:
– Export the Business Network Archive (BNA) and extract model, scripts, and ACL files to understand the business logic and data model.
– Choose target chaincode approach:
• Implement chaincode (smart contracts) directly in a supported language (Go, Node.js, or Java) using Fabric chaincode APIs. Recreate assets, participants, transactions, and business logic there.
• Alternatively, build a microservice layer using Fabric SDKs (Node/Java) that enforces the same business rules and interacts with Fabric via the Fabric Gateway.
– Reimplement access control: Fabric does not use Composer ACLs; enforce permissions via certificate‑based MSP identities, endorsement policies, channel/org level access, or application middleware.
– Recreate REST endpoints: replace composer-rest-server by creating your own REST API that interacts with Fabric via Fabric SDK (recommended).
– Test thoroughly: unit test chaincode, integration test through SDK, and run performance/security testing.
7) Alternatives and modern Hyperledger tooling
– Hyperledger Fabric (current): build chaincode in supported languages; use Fabric Gateway and Fabric SDKs to integrate.
– Hyperledger Cello, Hyperledger Explorer: deployment and monitoring tools.
– Commercial BaaS offerings: IBM, AWS, Azure previously offered Fabric‑based BaaS (ideally use Fabric native SDKs).
– For rapid prototyping, consider off‑chain prototyping tools or specialty frameworks that are actively maintained.
8) Best practices and governance (when maintaining Composer artifacts)
– Treat Composer artifacts (BNA, models, scripts) as source of truth; maintain them in version control.
– Keep identities and private keys secure. Composer used identity cards; safeguard them.
– Record migration plans and map Composer ACLs and roles to Fabric MSP identities and chaincode logic when planning to migrate.
9) Further reading and sources
– Investopedia — “Hyperledger Composer” (overview and deprecation note):
– The Linux Foundation — About Hyperledger:
– The Linux Foundation — Hyperledger Composer project (archived)
Final recommendation
– Use the explanation above to learn the high‑level model Composer introduced and to document any legacy Composer deployments.
– For new production blockchain work, plan to use Hyperledger Fabric native tools and SDKs and migrate Composer business logic into Fabric chaincode and application layers.
– Inspect a sample BNA (if you provide it) and outline a migration plan to Fabric chaincode.
– Produce exact example files (model, script, ACL) for the Perishable Goods example.
– Provide a step‑by‑step migration checklist tailored to your existing Composer artifacts.