Technology trends for the world of tomorrow

Introduction

Are you evaluating blockchains and wondering how to get started? In this technical article I will compare and contrast two approaches that fall under the Hyperledger umbrella: Hyperledger Fabric and Hyperledger Composer.

As their names indicate, both Hyperledger Composer (Composer) and Hyperledger Fabric (Fabric) are top-level projects under the Linux Foundation’s Hyperledger umbrella blockchain project; however, they serve very different purposes:

Hyperledger Fabric is a pluggable blockchain implementation. It provides a set of peers with permissioned access to a distributed ledger.

Hyperledger Composer is a set of abstractions, tools and APIs to model, build, integrate and deploy a blockchain solution (a business network archive). Composer business network archives may be deployed to Hyperledger Fabric for execution.

So, Composer RUNS ON Fabric. Either can be used to implement a blockchain solution, however the level of abstraction, tools and languages used are quite different. Internally the Composer APIs map down to the underlying Fabric APIs – this access is managed by the Composer runtime however, which can provide a range of services that ease application development (described in more detail below).

Let’s take a look at the differences between the abstractions for Fabric and Composer.

Coding for Fabric

The chaincode for a Fabric solution is written in the Go programming language. The Hello World style example for Fabric is Marbles.

A chaincode Go file must implement two functions:

The Init function is called when the chaincode is initialized by the Fabric. It gives the chaincode an opportunity to create initialization data in the world state.

A typical pattern is to use an if statement to dispatch from the Invoke function to a private function, based on calling stub.GetFunctionAndParameters().

Step 1) Data Model

Fundamentally blockchain solutions need to store data on a distributed ledger. The format/shape/schema of the data is therefore critical, particularly if the data will be persisted on the ledger for years, or decades, to come.

The data model for the Go chaincode is defined as a Go struct, with field tags used to specify how the fields in the struct are persisted as JSON.

type marble struct {
ObjectType string `json:"docType"` //docType is used to distinguish the various types of objects in state database
Name string `json:"name"` //the fieldtags are needed to keep case from bouncing around
Color string `json:"color"`
Size int `json:"size"`
Owner string `json:"owner"`
}

Step 2) Dispatch Incoming Calls

When client submit transactions for processing to the blockchain (typically via the Fabric Node-SDK), they use an async RPC style interface. The RPC calls are then dispatched to individual Go functions for processing. The dispatch logic for Go chaincode is typically a large if statement, that switches on the name of the function that is being invoked.

Once inside a function, the Go code calls methods on the shim to read and write to the world-state. The shim defines the programmatic interface between the chaincode and the underlying Fabric platform: put/get/delete state, execute queries, emit events etc.

Step 9) Emitting Events

When something of significance has happened to the data on the blockchain an event can be emitted. Fabric places the data for the event on its Event Bus, so that client applications can pick it up for client-side processing.

Coding for Composer

Step 1) Data Model

The data model for a Composer business network is defined in a CTO file. The Composer Modeling Language defines the structure (schema) for the assets, participants and transactions in a business network.

Step 2) Dispatch Incoming Calls

Composer dispatches incoming transactions to JavaScript functions by introspecting the decorations (annotations) on the functions themselves. There is therefore no need to explicitly code a dispatch function.

For example, the marble-network contains a single JS function, and the @param and @transaction decorations indicate to the Composer runtime that this function should be called with an instance of org.hyperledger_composer.marbles.TradeMarble is submitted.

Step 3) Validate arguments

Composer automatically validates that transactions conform to the data model defined in the CTO file, both within the client API as well as within the runtime. This happens transparent to user code, meaning that functions written by the end user can be sure that the data they are processing conforms to the Composer data model for the business network.

Prior to emitting event data it will be validated against the Composer model, ensuring that invalid data cannot be emitted to clients.

Testing

Both Go and JavaScript have sophisticated unit testing capabilities. However, Composer has a secret weapon in that it actually supports 4 different runtimes, two of which are particularly useful for testing:

A Node.js runtime that simulates a blockchain

A Web runtime that executes within a web browser (used by the Composer Playground)

Hyperledger Fabric v0.6 runtime

Hyperledger Fabric v1.0 runtime

Runtime (1) is ideal for unit testing, because a unit test can run in a single Node.js process making it extremely quick to unit test transaction processor logic, perform step-by-step debugging, or code coverage analysis. Runtime (2) is great for interactive testing of solutions, right from the web-browser. Runtimes (2) and (3) are uses for integration, system and performance testing.

I cannot over-emphasize how import testing is when developing blockchain solutions. They involve testing fairly complex state-machine logic running on a distributed network, accessed by different parties, with different levels of access. Choosing a framework and runtime that makes testing easy is critical to success.

Summary

It isn’t possible to make a complete apples-to-apples comparison, because the Go version of Marbles includes queries, whereas the Composer version does not, however it is clear that the Composer version is far shorter and includes much less boilerplate code:

This ±10x reduction in the number of lines of code when Go and Composer solutions are compared is fairly consistent across several samples.

Composer includes several other major features and productivity enhancements:

business networks are automatically exposed as OpenAPI (Swagger) REST APIs via the composer-rest-server. The composer-rest-server uses passport.js to support pluggable end-user authentication schemes.

Composer includes a declarative Access Control Language, allowing developers to define which participants have access to which assets and under which circumstances. Composer ACLs drastically reduce the amount of procedural access control checks required in business logic.

Use the Composer Node-RED nodes to integrate Composer with IoT, analytics, dashboards etc.

VSCode extension to validate Composer model, ACL and query files

Integrate Composer with industry leading BPM and Integration tools, via OpenAPI and the LoopBack connector

Develop and test on the web interactively using the Composer Playground, simulating the blockchain in the browser, or connected to a Fabric.

Generate skeleton Angular web application from a business network definition

Publish and reuse models across business networks

There are of course some advantages to coding in Go to the Fabric APIs directly:

follow the absolute latest evolutions in the Fabric APIs and capabilities

possibly better raw performance, although for most application chaincode performance is unlikely to be the determining factor

type-safety

single language for both business logic and model

can incorporate third-party C and Go libraries easily

In summary I believe that for 90% of business developers Hyperledger Composer is the right choice to get started with blockchain development. It allows them to focus on the business logic, and avoids a lot of error-prone boilerplate code. They will also benefit from many of the higher-level tools and abstractions that Composer has to offer.

7 thoughts on “Getting Started with Blockchain Development”

Great article, thank you! I have seen a lot of information online about IBM Bluemix/Blockchain for Fabric development. Do you happen to know what role IBM Bluemix/Blockchain play in the application development process? Do they work with Fabric composer, or are these mutually exclusive?

Question is that while people will be using blockchain apps between multiple organizations; Is writing a Composer app secure? As far as I could understand Composer apps are being run as a chaincode app in a single channel. So this means a competitor organization will be keeping ledger data in its peer nodes without any encryption. So everybody even though they won’t be able to read, write to blockchain through composer transaction functions they can easily reach the data by reading the ledger directly.

Does it mean that composer is only suitable where there are no competitors and no privacy required in a blockchain? Does this reduce composer to a private ethereum like network where all participants can see everything but is easier to develop.

The purpose of a shared ledger in a permissioned network is to share data. You raise good points, but they are not Composer specific. Any Fabric based application will have to address the same issues around data sharing, privacy and security.