Compaq Reliable Transaction Router Getting Started page 20

RTR Terminology
All components can reside on a single node but are typically
deployed on different nodes to achieve modularity, scalability,
and redundancy for availability. With different systems, if one
physical node goes down or off line, another router and backend
node takes over. In a slightly different configuration, you could
have an application that uses an external applet running on a
browser that connects to a client running on the RTR frontend.
Such a configuration is shown in Figure 1–8.
Figure 1–8 Browser Applet Configuration
The RTR client application could be an ASP (Active Server
Page) script or a process interfacing to the webserver through a
standard interface such as CGI (Common Gateway Interface).
RTR provides automatic software failure tolerance and failure
recovery in multinode environments by sustaining transaction
integrity in spite of hardware, communications, application,
or site failures. Automatic failover and recovery of service can
exploit redundant or underutilized hardware and network links.
As you modularize your application and distribute its
components on frontends and backends, you can add new
nodes, identify usage bottlenecks, and provide redundancy to
increase availability. Adding backend nodes can help divide
the transactional load and distribute it more evenly. For
example, you could have a single node configuration as shown in
Figure 1–9, RTR with Browser, Single Node, and Database. A
1–10 Introduction
PC Browser
Applet
RTR Frontend
Web Server
Process
RTR Client
Application
LKG-11206-98WI