Application integration developer

For many years, I served as an integration specialist in Oracle Fusion Middleware. My day-to-day job consisted of developing web service integrations between cloud and/or on-premises applications, and creating business applications that processed B2B transactions. Blockchain will definitely affect integration developers who work on the latter. To sketch you a picture from my experience, with traditional B2B transactions, the majority run through a trusted third-party gateway instead of a direct peer-to-peer connection. One reason for this is that a message needs to be routed to multiple partners.

This means that the transaction or message goes through multiple B2B clients in which the trusted third party receiving the message routes the message, using an enterprise service bus, to multiple receiving B2B clients. The following diagram illustrates this pattern:

The problem with this scenario is that, as a partner, you don't have end-to-end visibility of the transaction. If you send a message and expect a response in return but do not receive one, you will probably contact the receiving party first, and in case they did not receive anything, you will then need to contact the trusted third party. A lot of things can happen in the transport of your message. For example, the routing of messages to multiple partners can result in unexpected errors. Since everybody uses their own B2B gateway, you can forget about end-to-end visibility on a transaction, because each gateway holds its own state (transaction log) that is not shared. So, how do you know in an instant what happened to the transaction?

Also, when using traditional B2B gateways, such as Axway, you need to define a contract between partners (called a CPA) to configure the permissions (for example, what kind of operations and messages each can send/receive) and connection metadata. These contracts need to be duplicated and mirrored between partnering gateways. This maintains a trusted and secure connection between the two peers, but it can bring with it a lot of overhead. Certainly, when multiple partners want to interact with each other in the same conversation, then the administrative tasks can become annoying (such as duplicating contracts on each node for each participating party).

These types of transactions is where blockchain can be very disruptive (in a good way). Blockchain can provide one single point of truth that is distributed to each of the B2B partners in the same network. Every transaction that a partner submits to the network is visible almost instantly to other nodes in the network. All partners can process the data within the transaction into their own backend system, but this is done based on the same data. You can even go so far as applications being built directly on top of the blockchain database instead of in a separate data store. This means that as an integration developer, it has an impact on how you handle B2B transactions. Instead of calling an API provided by the B2B gateway, you submit your transaction and the data directly to the API of the blockchain database. The node with which you are communicating can be one of many nodes available to you, but it will usually be a local node. Depending on the blockchain platform used, transactions will be locally validated, so instead of waiting for an acknowledgment from the receiving B2B partner, you know that your transaction is valid once accepted by this node. Since the blockchain has its own database, your process does not have to listen to an (asynchronous) response, but it can issue a query whenever it wants to check to current state of the data. A platform like Hyperledger Fabric also supports an event architecture, so your process can be notified when data has changed. Thus, there is no need for long-running processes. In Chapter 9, Building a Next-Generation Oracle B2B Platform, I will focus on these disruptive effects in more detail.