A transaction processing monitor (TP monitor) is one of the oldest and best-known forms of middleware whose main task is to support and handle interactions between applications on different, even heterogeneous computer platforms. A transaction monitor provides functionality for developing, leveraging, managing, and maintaining transactional distributed information systems; its most important task is to handle applications/operations in a transaction-oriented manner.
History
As one of the oldest forms of middleware, transaction monitors are now a mature technology. One of the oldest implementations was from IBM. The first transaction monitors provided robust runtime environments for large OLTP applications on mainframes. To enable access to shared data while ensuring data consistency, the systems implemented the transactional concept.
The next generation of transaction monitors was client/server-based; For several decades, transaction monitors were the dominant form of middleware and still play an important role in everyday processes such as the processing of bank transactions.
---
Basics of Transaction Processing Monitor
Due to the variety of its tasks, it is difficult to specify what exactly a transaction monitor is. In a competition for the vaguest software term, Transaction Monitor would be a strong contender.
Roughly speaking, a transaction monitor integrates various system components (e.g. a communication system, a runtime system, a presentation system etc), to provide standardized, uniform interfaces for applications/operations that always offer the same behaviour in the event of an error. A transaction monitor can be seen as an operating system for transaction-protected applications whose range of tasks can be roughly divided into three classes: client-server communication management, transaction management and process management.
Client-server and server-server communication: they allow the services and components involved in an application to be called in various ways, e.g. with RPCs, with asynchronous messages that use persistent queues (Message Oriented Middleware), etc. Transaction monitors partly control communication flows between thousands of clients and hundreds of servers.
Transaction management: The basic infrastructure for running distributed applications is the RPC protocol; it is a concept designed to enable a remote procedure call from a client to a server, making it transparent to the client as if it were a local procedure call.
This concept works well in client-server systems when a client contacts a server; however, if more than two entities are involved and thus more than one remote procedure call is involved in the interaction (for example, a client that calls procedures on two different servers, or a client that calls a procedure on a server, which in turn results in a database call to the server), the RPC concept handles these remote calls independently of each other, which makes it very difficult to recover from a correct system state in the event of a system failure.
A classic example to illustrate this is an application on a client that withdraws money from one bank account to transfer it to another account. Should the client crash between the two actions or a different kind of error occur, the withdrawn money would be lost, set, the client could not make its state persistent.
Transaction monitors implement a transactional extension of the RPC concept; they handle remote procedure calls in a transaction with its inherent ACID properties. In particular, the ACID property implies atomicity, that is, that either all remote procedure calls involved are handled or none. Transaction monitors thus implement an abstraction of RPC, called transactional RPC (TRPC).
In TRPC, a group of procedure calls is provided with the transactional parenthesis BOT (beginning of transaction) and EOT (end of the transaction) and treated as a unit. Ensuring this is the task of the so-called transaction management module, which controls the interactions between clients and servers and ensures their atomicity using an implementation of the 2-phase commit protocol.
Transaction management also includes the task of carrying out logging (e.g. logging messages) during normal operation to be able to take recovery measures in the event of an error.
Process management: Its tasks include starting server processes, initializing transaction programs, and controlling their operations; Furthermore, load balancing also falls into this area.
