In this series of blog posts, I will take you through the steps involved in the design, architecture, and implementation of a fully functional Enterprise Blockchain Application. I will do so by sharing content from various stages of developing a sample application for Loan Origination and Payment on Blockchain. If you follow through the end of this series, you will have a better understanding of the internal workings of a blockchain application.
We (OFS) are building this application in IBM Blockchain Platform 2.0 Beta. Please check out my previous post — Demystifying the Fabric Chaincode with an Example for better continuity.
In this post, I will cover the nitty-gritty of invoking a fabric chaincode from your application with code samples. This post will get fairly technical quickly.
Going back to the design and architecture of our sample application, you can see that any calls to the Hyperledger Fabric are delegated to Hyperledger Gateway Services:
The Hyperledger Gateway Service is composed of the following components:
Asynch Service Invocation Handler — a set of REST APIs that acts as a gateway for downstream fabric calls. The calls are asynchronous and return immediately after invocations.
Hyperledger (Fabric) Invoker — a core component that uses fabric SDK for chaincode invocations.
Event Hub — a component that listens for chaincode events and pushes the event details to subscribers.
Let us review these components in detail:
Async Service Invocation Handler
It is important to embrace async programming when developing a blockchain application, due to the numerous steps between building and proposing a transaction and adding a transaction to a blockchain.
Hyperledger (Fabric) Invoker
The job that is submitted to the executor service in the step above implements the downstream fabric calls. Conceptually the steps look like this:
Step #1 Build a Transaction Proposal request
Step #2 Send the Transaction Proposal to endorsing peers
This is a synchronous process, and the execution waits here.
Step #3 Collect and verify the Proposal responses
Step #4 Send the Proposal responses to the Orderer
Observe the CompletableFuture, then wait for the promises to resolve and take domain specific actions. Resolved promises mean successful submission to Orderer.
The fabric SDK takes care of the next two steps internally:
- Step #5 Orderer broadcasts the blocks to all Leader peers
- Step #6 Leader peer broadcasts the blocks to other peers in the group
Given the async nature of the transaction with the blockchain, we took an event-driven approach to react to the events emitted from chaincode. The events could be a new borrower application added to the blockchain, alender adding a new proposal to the blockchain, etc.
These events are baked into the chaincode and will be emitted when the related transactions are added to the blockchain.
Listening to these chaincode events from your client is fairly straightforward.
I hope this post helped you to get some insights into how to develop a fabric chaincode client using Java Fabric client SDK. Stay tuned for more.
About the Author
Ganeshram Ramamurthy is ObjectFrontier’s technical director and heads technology for presales. For many years, Ganesh has been designing and developing enterprise applications across various domains. He has a keen interest in emerging technologies and is now spearheading blockchain initiatives at OFS.