Transaction management is much like FedEx or UPS managing movement of parcels from one location to another starting with payment, tagging with an ID, routing, monitoring/tracking and confirmation of delivery. The package moves through multiple distribution centers and is confirmed at each location it travels through. When it is delivered, a final confirmation happens.
So using this analogy, let’s start with defining what is the Transactional Supply Chain for in-memory and cloud architectures. First, it can include a variety of transactions, ACID Transactions for payment, commerce, financial commitment, etc., NO-ACID or what I will call “less than ACID” transactions for messaging, logging, updating catalogues. Overall, there are several types of transactions, and there is not a one-fit-all scenario — a transaction is specific to the need based upon the business. In addition, there are multiple data stores where persistence has to happen. For this example, let’s say 16 data stores/databases located across the world.
In the Transactional Supply Chain, let’s assume we have a Transactional Bus that manages transactions for purposes of placing an order, invoicing, updating inventory, shipping and messaging to the buyer. The buyer may participate in social commerce where he or she brags about buying an item by sending a message (transaction) to others they know. If these others like it, they go and buy it, and we start the transactional bus moving down the transactional supply chain over and over again. The information about these buyers can be aggregated in real time and sent to a big data analytics engine, a data warehouse, for example, so that analysis will help to understand both individual customers as well as demographic groups, creating more business. Then once again a new buyer engages, which at some point triggers an ACID commerce transaction to confirm the order and payment, updates inventory, invoicing, shipping information, and tracks this transaction until confirmation of delivery.
The notion that one type of transaction can handle all of this has changed to what type of transaction is best used for in-memory grids and cloud architectures. That said, whether it starts or ends with an ACID transaction, ACID transactions are an essential part of the transactional supply chain. Without this ACID transaction option we would be writing brittle transaction management code to maintain and monitor—very time consuming and very costly.
Well, if there were an out-of-the-box solution for distributed ACID transactions that could deliver high scalability and exception performance, much of the bally ho above would be unnecessary. This would be a technology solution that business managers and developers obviously have a crying need for. So for distributed transactions, if you could do them in a highly scalable way, with consistent performance for commit time, and quickly (e.g., milliseconds) in a scale out/grid environment, whether in-house or in a private, public or hybrid cloud… would this seem a much more reasonable choice?
So the world of transactions is NOT about one single transaction type. It is about what kind of transaction serves the best purpose for the business intent such as socializing, commerce, ordering, etc. It is about a Transactional Supply Chain where a single database or data source is no longer enough!! Frankly, it is one of the biggest bottlenecks. The choking point for the web and worse for the grid, and even worse for the cloud is the database. Hence having a Transactional Bus to manage the transaction supply chain and the in-transit data movement to any and all data sources located around the world is essential. Much like an application server layer there needs to be a data server layer. A transactional bus independent of databases with transaction management and monitoring unbundled for flexibility, performance and scale to meet business needs seems so logical. Then why has someone not done it? Well, as you know, it is a very complex problem and some want to waddle in the “it can’t be done” camp. Well, it can be done.
As we move to in-memory data grids and cloud architectures, the need for a Transactional Supply Chain will become a requirement and reality. It will be a critically important business asset. Businesses will have much more flexibility to change and grow, the limits on transaction management will be lifted, and the transactional supply chain will include the full business life cycle of the transaction including such aspects as distributed ACID transactions uniting in-memory and disk for persistence, active to active transactional duplication, workflow management, aggregation for business intelligence, data policy management, active-state transaction tracking for alerts, customer tracking, and more. These topics and more will be covered in future blogs.
It is an exciting time, and it all starts with the wonderful new way for businesses to be nimble transacting their business free of technology silos, free of limitations on transactions, and free to build your business with no limits!