We are using a mobile payment with a money transfer allowed between two banks as the scenario for this chapter. With the money transfer, the business logic is easy to understand. So, we do not need to worry about this part. Let's focus on the complexity of the architecture.

Money transfer between two different banks with different underlying implementations is hard. This is because we cannot directly apply the concept of traditional transactions to cope with external systems. The system is presented in the following diagram:

What are we not covering in this chapter?

The UI parts are out beyond scope of this book, so they are not available. The Receipt Generator and the Receipt Storage are optional. They are left for you to implement, if interested.

What do we implement and demonstrate? Let's discuss:

• The Parse platform, as a backend for the UI.
• The Bank Routing function. It is written in Java and deployed on Fn. This component is called routing_fn.
• Bank #1 and its function calling to a legacy web-based system. The function here is written in Node.js using the chromeless library (https://github.com/graphcool/chromeless). The function connects to a headless Chrome instance, our familiar web browser. The function drives Chrome to navigate and create a transaction for us on a real ERP system. We use Moqui as our ERP backend. Actually, Moqui comes with a complete set of REST APIs, but we intentionally use its web base to simulate the scenario where we need to modernize some legacy systems. The function of this part is called hivectl.
• Bank #2 and its function, account_ctl, connecting to a REST-based bank system. The function is written using Go and will be running on OpenWhisk. The mock bank server behind this component is a simple one written using the Grails/Spring Boot framework. We use this component to demonstrate how to write a FaaS function to wrap and simplify a REST-based API. The Bank Routing function, routing_fn, will be selectively called by each bank. This Bank #2 component will be used together with Bank #1 there.
• A set of smart contracts written in Solidity to maintain the mapping of mobile numbers to bank accounts. Also, another set of smart contracts will be used to maintain the state of the money transfer of each transaction.
• An agent written in Java and the RxJava library to demonstrate a data stream processing component that calls a function and diverts the event to other parts of the system.