In earlier chapters, we saw how Hyperledger Fabric can be viewed as a distributed transaction processing system, with a staged pipeline of operations that may eventually result in a change to the state of the shared replicated ledger maintained by the network peers. To the developer, a blockchain application is a collection of processes through which a user may submit transactions to, or read state from, a smart contract. Under the cover, the developer must channel a user request into the different stages of the transaction pipeline and extract results to provide feedback at the end of the process. Essentially, it is the application developer's job to implement one or more layers of wrappers around the smart contract, regardless of whether the contract was implemented by hand (see Chapter 4, Designing a data and transaction model with Golang) or using Hyperledger Composer (see  Chapter 6, Business Networks).

An application developed with the smart contract (or the asset-entity model) at its core can be viewed as a transaction-processing database application with a set of views or a service API. However, the developer must keep in mind that every Hyperledger Fabric transaction is asynchronous, that is, the result of the transaction will not be available in the same communication session that it was submitted in. This is because, as we have seen in previous chapters, a transaction must be collectively approved by the peers in the network through consensus. As such, consensus may potentially take an unbounded amount of time, and the communication of a transaction result is designed as a publish/subscribe mechanism. The following diagram illustrates the blockchain application and transaction pipeline from the perspective of the developer:

In the next section, the operations mentioned in this diagram will be described in more detail and mapped to specific Fabric mechanisms.