Applications

Referring to Figure 5.2: Typical three-layer architecture of a Hyperledger Fabric application, and our discussion in the Application Model and Architecture section of this chapter, different users of a Hyperledger Fabric application may need different and distinct applications. Our trade scenario is an example of this: users representing trading parties, banks, shippers, and governmental authorities may need different things from our application, even while they are collectively participating in the trade network and endorsing smart contract operations.

There are common operations that administrators of the different organizations must have the capability to perform. This includes the stages from the creation of a channel up to the instantiation of chaincode. Therefore, if we need to build different applications for each network participant, we should expose these capabilities to every instance of those applications. Once we get to the application itself, which consists of the set of invoke and query functions offered by the chaincode, we must create space for differentiation. An application designed for the trading parties and their banks must expose trade and Letter of Credit operations to the users. However, there is no need to expose these operations to a carrier, and therefore an application designed for the latter can and ought to limit the capabilities offered to those that impact the carrier's role, such as the functions to create Bills of Lading and to record the location of a shipment.

Here, for simplicity, we will amalgamate all the applications into one and demonstrate how to make it work. Diversification based on user roles and requirements is left as an exercise for the reader. Our amalgamated application will be implemented as a web server, loosely connecting the smart contract and the middleware, sounding it from the end users.