Transaction Processing monitors
Originally TP monitors meant teleprocessing monitors – a program that multiplexed several terminals (clients) to a single central server. Over time, TP monitors took on more than just multiplexing and routing functions and TP came to mean transaction processing. A TP monitor goes beyond a database systems narrow view of ACID applications. A TP monitor treats each subsystem (that is database manager, queue manager and message transport) as an ACID resource manager. The TP monitor coordinates transactions among them. For example – A TP system assures that when a database gets updated, an output message is delivered, an entry is made to the work queue, either all these actions will occur or none will.
Beyond ACID,
Configuring and managing client server interactions.
Queued transaction processing is convenient for applications where some clients produce data while others process and consume it. Typical examples are: e-mail, job dispatching, print spooling, and batch report generation.
TP monitor includes a subsystem that manages transactional queues. The router inserts a client request into a queue for later processing by other applications. The TP monitor may manage a pool of application servers to process the queue. Conversely, the TP monitor may attach a queue to each client and inform the client when messages appear in its queue. Messaging applications are examples of queued transactions.
Conversational transactions require the client and server to exchange several messages as a single ACID unit. These relationships are sometimes not a simple request-response but rather –
The router acts as an intermediary between the client and the server for conversational transactions. Conversational transactions often invoke multiple servers and maintain client context between interactions. Menu and forms processing systems are so common that TP monitors have scripting tools to quickly define menus and forms and the flows among them.
The current Menu State is part of the client context. Application designers can attach server invocations and procedural logic to each menu or form. In these cases, the TP monitor (router) manages the client context and controls the conversation with a workflow language. Workflow is the natural combination of conversational and queued transactions. In its simplest form, a workflow is a sequence of ACID transactions following a workflow script.
Example: The script for a person-to-person e-mail message is compose-deliver-receive. Typical scripts are quite complex. Workflow systems capture and manage individual flows. A client may advance a particular workflow workflow by performing a next step in the script. Administrative tools report and administer the current work-in-progress.
Writing applications in a TP system.
TP systems vary enormously, but the general programming style is to define a set of services that the server will provide. Each service has a message interface. To implement a system, you define client programs that generate these messages and server programs that service them.
Service programs are invoked with a message either from the queue or directly from a client. The service program executed the application logic and responds to the client with a response message. TP systems generally provide tools to automate construction of forms oriented clients and of simple application servers that can serve as templates for customization.
Configuration, Management and Operation of the system.
Earlier it was hard to even scale up to 300 clients (forget managing). Today we find thousands of clients attached to server clusters. But the problem is in managing the systems. TP monitors have evolved a large suite of tools to configure and manage servers.
TP monitors think of each database and application as a resource manager. These resource managers register with the TP monitor who in turn informs them of system checkpoints and provides an overall operations interface to coordinate orderly system startup and shutdown. Database systems, transactional queue managers and remote TP systems all appear to be resource managers.
Managing server pools.
The TP monitor packages short-running or high-priority services together, and batch or low-priority work is packaged in separate processes. After packaging the services, administrator assigns security attributes to them. It authenticates clients and checks their authority on each request, rejecting those that violate the security policy.
Each service has a desired response time, some services have a longer response time (e.g.: batch processes), while others are simple requests. TP monitors manage the size and priority of server pools so that each service meets its response-time goals. The administrator can control how many processes/threads are available to each service. Server pools can be spread over multiple nodes of a cluster, and this number can be dynamic, growing as loads do. When the number of requests for service exceed the maximum size of the server pool, requests are queued until the next server becomes available.