Building an enterprise blockchain application (part 3): invoking Fabric chaincode from your application
In this series of blog posts, we will take you through the steps involved in the design, architecture, and implementation of a fully functional enterprise blockchain application. We will do that by sharing content from the various development stages of a sample application that we (OFS) built 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 the blockchain application.
For better continuity, please check out our previous post, Building an enterprise blockchain application (part 2): demystifying the Fabric chaincode with an example.
Note: We built this application using the IBM Blockchain Platform 2.0 beta. To get started with the latest version of the IBM Blockchain Platform, you can read this blog by IBM for download instructions, which include how to get a 30-day trial.
In this post,we 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 the 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
Event Hub
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, a lender 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.
Conclusion
We hope this post helped you to get some insights into how to develop a fabric chaincode client using the Java Fabric client SDK.
We also hope the steps of implementing a fully functional enterprise blockchain application that we’ve shown in this series has made you more familiar with blockchain, as well as given you a taste of what it can do.
To see how blockchain solutions can be a business enabler for you, your customers, and your partners.