26-11-2012, 02:14 PM
TP Monitors
[attachment=41168]
Introduction
A request is a message that describes a unit of work for the system to execute
A TP monitor coordinates the flow of requests between message sources (displays, etc.) and application programs that perform transactions.
Basic control flow:
Translate the display input (form/menu selection, etc.) into a standard-format request.
Find the transaction type in the request header
Start the transaction
Invoke the transaction type’s application program
Send the transaction’s output to the display
TP Monitor Functions
Glue and veneer for TP applications
glue fills in gaps in system functionality
covers the interface with a seamless veneer
Provides run-time functions for applications (presentation servers, workflow control, and transaction servers). Often wired tightly to underlying OS platform.
Provides system mgmt for the running application. E.g., interprets OS and DBMS metering in TP terms
fault monitoring and repair (fail over), server mgmt
security management
performance monitoring and tuning (load balancing)
Provides some application development tools
Tier Applications
Application structure mimics system structure
Fits business rule / business object architecture
Presentation server - forms/menus, data validation
UI for invoking a transaction
Workflow controller - map requests to calls on the right program(s)
Business rules to transform request into right calls on basic objects (automatic loan payment, money transfer)
Transaction server - do the work
Business objects (customer, account, loan, teller)
Gathering Input
Gathering input, usually in a 4GL
Select transaction type (menu item or control/widget)
Fill in a form and validate input against cached tables
Forms managers for character-cell devices
Character-at-a-time, block mode (screen-at-a-time)
WYSIWYG form editor, compile form, execute it (with record defn binding to programming language)
Many specialized device types
ATMs, bar code readers, credit card authorization, gas pumps, cash registers, robots, ticket printers, etc.
Often they conform to terminal standards - IBM 3270 or asynch terminal; dialup modem or standard protocol, etc.
[attachment=41168]
Introduction
A request is a message that describes a unit of work for the system to execute
A TP monitor coordinates the flow of requests between message sources (displays, etc.) and application programs that perform transactions.
Basic control flow:
Translate the display input (form/menu selection, etc.) into a standard-format request.
Find the transaction type in the request header
Start the transaction
Invoke the transaction type’s application program
Send the transaction’s output to the display
TP Monitor Functions
Glue and veneer for TP applications
glue fills in gaps in system functionality
covers the interface with a seamless veneer
Provides run-time functions for applications (presentation servers, workflow control, and transaction servers). Often wired tightly to underlying OS platform.
Provides system mgmt for the running application. E.g., interprets OS and DBMS metering in TP terms
fault monitoring and repair (fail over), server mgmt
security management
performance monitoring and tuning (load balancing)
Provides some application development tools
Tier Applications
Application structure mimics system structure
Fits business rule / business object architecture
Presentation server - forms/menus, data validation
UI for invoking a transaction
Workflow controller - map requests to calls on the right program(s)
Business rules to transform request into right calls on basic objects (automatic loan payment, money transfer)
Transaction server - do the work
Business objects (customer, account, loan, teller)
Gathering Input
Gathering input, usually in a 4GL
Select transaction type (menu item or control/widget)
Fill in a form and validate input against cached tables
Forms managers for character-cell devices
Character-at-a-time, block mode (screen-at-a-time)
WYSIWYG form editor, compile form, execute it (with record defn binding to programming language)
Many specialized device types
ATMs, bar code readers, credit card authorization, gas pumps, cash registers, robots, ticket printers, etc.
Often they conform to terminal standards - IBM 3270 or asynch terminal; dialup modem or standard protocol, etc.