Page 38 - MSDN Magazine, September 2018

any update to the model’s state and raise events on change of this state. By subscribing to notifications of these events, a separate smart contract can build a completely independent and query- optimized model that doesn’t need to be shared with any other contractorexternalservice.YoucanlearnmoreaboutCQRSfrom Martin Fowler’s post at bit.ly/2Awoz33.
Figure 7 describes the data model that I designed for the bet- ting application using event sourcing. This simple model employs a similar structure regardless of the event handled. It’s not necessary to know the current state of the bet to read the sequence of events. The event’s data structure depends on the event itself. Although a sequence of states exists as defined in the workflow, it’s irrelevant from a data-model perspective. Think bigger: In a supply-chain scenario, multiple workflows and events exist, with different enti- ties and attributes. Your structural data model may grow complex, whereas the event-based model, bar a few different attributes for each event, remains constant.
Distributed Transactions
A shared data model isn’t the only use case that can introduce tight coupling between smart contracts. Another important threat is workflows. A lot of real-life processes cannot be repre- sented with a single, atomic operation. With such workflows, the result only makes sense if all the steps can be executed. If any step in the sequence fails, the resulting state of the relevant system becomes invalid. In the RDBMS world, such processes are called “transactions.” Database transactions are typically local, contained within the confines of a single database, and rely on locks on tables before updates. If a step fails, you can roll back the steps already attempted before a final commit.
For distributed workflows and stateless microservices, a tradi- tional transaction implementation with data locks and Atomicity, Consistency, Isolation, Durability (ACID) compliance (en.wikipedia.org/ wiki/ACID) is impractical. Sagas (bit.ly/2AzdKNR) are long-lived distributed transactions that allow running workflows in loosely coupled envi- ronments, without making any assumption of the reliability of each component of the complex system.
In sagas, every step in the workflow executes its portion of the work, registers a call back to a compensating transaction in a mes- sage called “routing slip” and passes the updated message down the activity chain. If any step downstream fails, that step looks at the routing slip and invokes the most recent step’s compensating transaction, passing back the routing slip. The previous step does the same thing, calling its predecessor’s compensating transaction and so on until all already executed transactions are compensated. This pattern leads to eventual consistency of data in a distributed transaction (bit.ly/2v8T360). Due to its highly fault-tolerant, distributed nature, sagas are very well-suited to a microservice architecture, as well as to blockchain smart contracts.
You can implement a sort of routing slip via fallback functions in Solidity. A fallback function is an unnamed function defined with no input argument and no return value. It’s executed on a call to the con- tract if none of the other functions match the given function identifier or whenever the contract receives Ether (in the case of Ethereum). Additionally, in order to receive Ether, the fallback function must
be marked payable. If no such function exists, the contract cannot receive Ether through regular (address-to-address) transactions. It’s worth mentioning that a contract without a payable fallback
function can receive Ether as a recipient of a coinbase transaction, suchasaminerblockreward.AcontractcannotreacttosuchEther transfers and, thus, also cannot reject them. This is a design choice of Ethereum, and Solidity cannot work around it. A contract can have exactly one unnamed function, as shown here:
// Fallback function function() public payable {
emit AmountTransfered(msg.sender);
}
event AmountTransfered(address sender);
In Ethereum, fallback functions are necessary for a smart con- tract to allow account-to-account direct transfers. This is because the transferring account may need to make transfers to both Externally Owned Accounts (EOAs) and to other smart contracts. As EOAs can only accept direct transfers, the only way for an account to transfer value to another account is for the executing contract to implement a fallback function. This means that any contract that wants to accept such transfers must be prepared for direct transfers by having a fallback function. Without that function, the transfer would fail, and it would be impossible for the contract to accept Ether from the other contract.
Asynchronous messaging plays a key role in keeping things loosely coupled
in a microservice architecture.
A best practice is to not have any logic in the fallback function. It’s possible to put code in the body of this function, but it’s best to avoid anything beyond very short, simple logging. The reason is important and unique to smart contracts: You don’t want this function to fail because it runs out of gas. As a rule of thumb, you’ll have just enough gas to raise an event, but not enough to write data to storage.
Asynchronous Messaging
Asynchronous messaging plays a key role in keeping things loosely coupled in a microservice architecture. For example, we can use a mes- sage broker to deliver event notifications in an asynchronous manner, preventing point-to-point connections that create a dependency on each endpoint availability and message format. By the same token, smart contracts can benefit from messaging-enabled integration for inbound (from outside to inside the blockchain) and outbound (from the blockchain toward external applications) communication.
In addition to providing a REST API, Azure Blockchain Work- bench provides messaging-based integration based on ledger-centric events. Events are published to an Azure Event Grid, and consum- ers can ingest data or take action based on these events. For those clients that require reliable messaging, Azure Blockchain Workbench
30 msdn magazine
Microservices