Network Operation and Distributed Application Building

In previous chapters, we established the foundations of a business network and application spanning multiple organizations and stakeholders:

• In Chapter 4, Setting the Stage with a Business Scenario, we configured and ran a barebones trade network from a set of specifications
• In Chapter 5, Designing Smart Contract Transactions and Ledger Data Structure, we built the core of a blockchain application in the form of a set of smart contracts that directly read and manipulate the ledgers that are the systems-of-record for your network

The bulk of the configuration and application logic development is done, but our task is far from finished.

As you can imagine, the contracts, which act on data used by multiple organizations, are sensitive pieces of code that ought to be accessible only via safe channels with built-in protections against misuse. Therefore, it is standard practice among blockchain developers...

Stages in a Fabric network's life cycle

Before we dive into the details of application-building, it is important to first gain a broader perspective on how a Fabric network is created and bootstrapped in readiness for deploying and running applications, and what streams of developmental activities must be undertaken. Figure 9.1 illustrates these stages and activities from the perspectives of three groups of subjects: operators and maintainers, developers, and users:

• Network setup and bootstrapping activities are classified into operations, which is the responsibility of network operators designated by their respective organizations or by the consortium. Operators will also typically oversee DevOps.
• Development, which involves designing, writing, and testing application code, can occur before or concurrently with operations. The developers responsible for this are typically distinct from operators and do not need to know operational details, though they need to...

Fabric application model and architecture

In earlier chapters, we saw how Hyperledger Fabric can be viewed as a transaction processing system over a distributed database (corresponding to channel ledgers) maintained by the network peers, exposing information through a set of views. It is the developer's job to expose the assets and data items in the ledgers, as well as the transactions and queries on them, in a way that hides the complexity of the underlying network and channel architecture. In addition, the developer must provide differentiated capabilities to various enterprise users affiliated with the network's organizations, with appropriate security and privacy safeguards built in. Figure 9.2 illustrates what such a distributed Fabric application looks like:

Figure 9.2: Typical three-layer architecture of a Hyperledger Fabric application

As we can see, the Network layer at the bottom, consisting of network peers, ordering nodes, and CAs, is the infrastructure...

Operations – network setup and bootstrap

Now we can get to work, equipped with the:

• Knowledge of what steps are involved in the creation and running of a Fabric application
• Architecture of the trade application we would like to build

We have already completed two of the steps illustrated in Figure 9.1:

• Created a network that we can launch using a single command
• Developed code for the four smart contracts illustrated in Figure 9.3

In this section, we will demonstrate steps 2 and 3, namely channel setup and contract installations.

Operations overview – channel and contract setup

Figure 9.4 expands the Operations stage illustrated in Figure 9.1. Once the number of channels required for our distributed application has been determined and each channel has been assigned a unique name, each channel is created by submitting a request to the network's ordering service. This channel creation is appended as a block...

Developing service-layer applications

Now that the network operations, including ledger and contract setup, are out of the way, we can focus on the development of applications that a user or software agent in the real world will use. (In other words, if we examine Figure 9.2, everything in the bottom layer is complete and ready for use.)

Figure 9.3 showed the architecture of our application from a component-based view. The middle portion contains the contracts representing the lowest layer of our technical stack. The components in the outer portion represent the applications we still need to build and run. And where the contracts were designed in a ledger-centric manner (because they act on the ledgers as if they are common databases, even though those ledgers are shared among multiple peers), our higher-layer applications are designed in a user-centric (or organization-centric) manner because they act on behalf of different stakeholders. Therefore, we have four applications,...

Exercising the application through a presentation layer

The service-layer applications we have designed, such as the importer application, expose REST APIs for invocation by users. The most direct way for a user to exercise these applications is by sending an HTTP query. But an HTTP query, though simple to frame for a technically skilled person, may look cryptic to the laypeople who are our applications' target users. Therefore, it is common practice to mask the complexity of framing such HTTP queries through applications that provide more intuitive interfaces, which present easy-to-understand information and options to users. For example, consider the trade request we demonstrated earlier using curl. All an importer really needs to specify is the ID of the proposed trade, the description of goods, the amount, and the exporter to whom the proposal is being made. An ideal presentation application would prompt the user to enter these pieces of information, and possibly offer a...

Using a production-grade ordering service

The network we have built and run contracts and service applications on uses an ordering service that runs in solo mode, as we saw in Chapter 4, Setting the Stage with a Business Scenario. This is a trivial ordering service consisting of a single node that is completely in charge of ordering transactions into blocks. Needless to say, centralizing block creation violates core blockchain principles and therefore cannot be the basis for any production-grade enterprise network that requires a multi-node consensus-based ordering service. And Hyperledger Fabric 2 does support and recommend ordering services built on Raft clusters. (Fabric 1 supported Kafka- and ZooKeeper-based ordering services, though support for Raft was added in 1.4.)

So why did we run our network construction and development exercise on a solo orderer that will never be used in production? There are two reasons. One, we wanted to demonstrate to our readers that all aspects...

Summary of key steps

As a reference to our readers, we list the sequence of operations that must be performed to bring up a network and distributed application from scratch and run transactions on it. We supply shortcut commands using the Bash scripts in trade-network wherever applicable. You should choose the ordering service type in the beginning and run all commands in the appropriate mode:

1. Create cryptographic and channel artifacts (the -m switch is optional):

   $ ./trade.sh generate -c tradechannel -o 3 [-m prod]
   $ ./trade.sh generate -c shippingchannel -o 4 [-m prod]
   

2. Launch the network:

   $ ./trade.sh up [-m prod]
   

3. Create channels, join peers to channels, and set anchor peers for organizations:

   $ ./startAndJoinChannels.sh
   

4. Install and initialize contracts. You can do this manually using VS Code or by running the following shortcut command:

   $ ./sampleChaincodeOperations.sh
   

5. Create a wallets...

Summary

Building a complete blockchain application is an ambitious and challenging project, not just because of the range of skills it requires—systems, networking, security, and web application development, to name a few—but because it requires concerted development, testing, and deployment by multiple organizations spanning multiple security domains.

In this chapter, we built a distributed application over a Fabric network using our trade scenario as a practical development guide. We began with a barebones four-organization network and four smart contracts and ended with a distributed application and the ability to orchestrate an entire trade workflow by six independent personas spanning four organizations. The attributes of trade- and finance-related artifacts and the history of these workflows were recorded in a pair of tamper-resistant, shared, replicated ledgers. In the process, we learned how to build and operate multiple channels, and selectively join certain...