Order Number: AA-RLE1B-TE
This document introduces Reliable Transaction Router and describes its concepts for the system manager, system administrator, and applications programmer.
Revision/Update Information: This manual supersedes Reliable Transaction Router Getting Started for RTR Version 4.1.
Software Version:
Reliable Transaction Router Version 4.2
Hewlett-Packard Company
Palo Alto, California
© 2003 Hewlett-Packard Development Company, L.P.
Microsoft, MS-DOS, Windows, and Windows NT are US registered trademarks of Microsoft Corporation.
Intel is a US registered trademark of Intel Corporation.
UNIX is a registered trademark of The Open Group.
Confidential computer software. Valid license from HP and/or its subsidiaries required for possession, use, or copying. Consistent with FAR 12.211 and 12.212, Commercial Computer Software, Computer Software Documentation, and Technical Data for Commercial Items are licensed to the U.S. Government under vendor's commercial license.
Neither HP nor any of its subsidiaries shall be liable for technical or editorial errors or omissions contained herein. The information in this document is provided "as is" without warranty of any kind and is subject to change without notice. The warranties for HP products are set forth in the express limited warranty statements accompanying such products. Nothing herein should be construed as constituting an additional warranty.
| Contents | Index |
The goal of this document is to assist an experienced system manager, system administrator, or application programmer to understand the Reliable Transaction Router (RTR) product.
This document contains the following chapters:
Table 1 describes RTR documents and groups them by audience.
| Document | Content |
|---|---|
| For all users: | |
| Reliable Transaction Router Release Notes 1 | Describes new features, changes, and known restrictions for RTR. |
| Reliable Transaction Router Getting Started | Provides an overview of RTR technology and solutions, and includes the glossary that defines all RTR terms. |
| Reliable Transaction Router Commands | A pocket-sized handbook that lists all RTR commands, their qualifiers and defaults. |
| Reliable Transaction Router Software Product Description | Describes product features. |
| For the system manager: | |
| Reliable Transaction Router Installation Guide | Describes how to install RTR on all supported platforms. |
| Reliable Transaction Router System Manager's Manual | Describes how to configure, manage, and monitor RTR. |
| Reliable Transaction Router Migration Guide 2 | Explains how to migrate from RTR Version 2 to RTR Version 3 or 4 (OpenVMS only). |
| For the application programmer: | |
| Reliable Transaction Router Application Design Guide | Describes how to design application programs for use with RTR, with both C++ and C interfaces. |
| Reliable Transaction Router C++ Foundation Classes | Describes the object-oriented C++ interface that can be used to implement RTR object-oriented applications. |
| Reliable Transaction Router C Application Programmer's Reference Manual | Explains how to design and code RTR applications using the C programming language and the RTR C API. Contains full descriptions of the basic RTR API calls. |
You can find additional information about RTR, including the Software Product Descriptions, on the RTR website at http://www.compaq.com/rtr/.
HP welcomes your comments on this manual. Please send us your comments by email to rtrdoc@hp.com. Please include the following with your comments or suggestions: the title of the manual, date from the title page, section and page numbers.
This manual adopts the following conventions:
| Convention | Description |
|---|---|
| New term | New terms are shown in bold when introduced and defined. All RTR terms are defined in the glossary at the end of this document. |
| User input | User input and programming examples are shown in a monospaced font. Boldface monospaced font indicates user input. |
| Terms and titles | Terms defined only in the glossary are shown in italics when presented for the first time. Italics are also used for titles of manuals and books, and for emphasis. |
| FE | RTR frontend |
| TR | RTR transaction router or router |
| BE | RTR backend |
| Refer to ... | References another manual. |
| See ... | References another part of this manual. |
The reading path to follow when using the Reliable Transaction Router information set is shown in Figure 1.
This document introduces RTR and describes RTR concepts. It is intended for the system manager or administrator and for the application programmer who is developing an application that works with Reliable Transaction Router (RTR).
Reliable Transaction Router (RTR) is failure-tolerant transactional messaging middleware used to implement large, distributed applications with client/server technologies. RTR helps ensure business continuity across multivendor systems and helps maximize uptime.
Failure and fault tolerance
Failure tolerance is supplied by the RTR software that enables an application to continue even when failures such as node or site outages occur. Failover is automatic. Fault tolerance is supplied by systems with hardware that is built with redundant components to ensure that processing survives failure of an individual component. Depending on system requirements and hardware, an RTR configuration can be both failure and fault tolerant.
Interoperability
You use the architecture of RTR to ensure high availability and transaction completion. RTR supports applications that run on different hardware and different operating systems. RTR applications can be designed to work with several database products including Oracle, Microsoft Access, Microsoft SQL Server, Sybase, and Informix. For specifics on operating systems, operating system versions, and supported hardware, refer to the Reliable Transaction Router Software Product Description for each supported operating system.
Networking
RTR can be deployed in a local or wide area network and can use either TCP/IP or DECnet for its underlying network transport.
Transaction processing
A transaction involves the exchange of something for something else, for example, the exchange of cash for something purchased such as a book or restaurant meal. Transactions are the fodder of the commercial world in which we live. Transaction processing is the use of computers to do the bookkeeping for the physical transactions in which people engage. RTR is the premier transaction processing software available for many computer systems, offering unique benefits to ensure the integrity and correctness of transactions under its control.
Corporations and institutions benefit when the data they need is current and kept rapidly up-to-date. This ensures that they have increased control of their business or institution, and can react more effectively to changes in the business or institutional environment.
For example, an inventory management system provides current inventory for inquiry and can automatically request inventory updates when needed. Or an production manager can make production decisions based on current status of manufacturing elements directly from the shop floor, and a credit card company can respond with accurate information when a card request for validation arrives. Or a shipping company can determine and report the location of a package in transit anywhere in the world, or a personnel system can enable an employee to update personal information online. All of these systems perform transaction processing tasks as designed by their developers.
With RTR, applications can be written to be deployed over a wide geography to take advantage of distributed resources, both computers and personnel. Implementing a transaction processing system using RTR requires analysis, planning, and considered execution.
RTR provides a continuous computing environment that is particularly valuable in financial transactions, for example in banking, stock trading, or passenger reservations systems. RTR satisfies many requirements of a continuous computing environment:
RTR additionally provides the following capabilities, essential in the demanding transaction processing environment:
RTR also ensures that transactions have the ACID properties that have been established as crucial in a transaction processing environment. A transaction with the ACID properties is:
For more details on transactional ACID properties, see the brief discussion later in this document in the section Transaction Integrity and refer to the Reliable Transaction Router Application Design Guide.
In addition to the terms previously defined, the following terms are either unique to RTR or redefined when used in the RTR context. If you have learned any of these terms in other contexts, take the time to assimilate their meaning in the RTR environment. These and other terms are also defined in the Glossary of this manual. The terms are described in the following order:
RTR Application
An RTR application is user-written software that executes within the confines of several distributed processes. The RTR application may perform user interface, business, and server logic tasks and is written in response to some business need. An RTR application can be written in one of the supported languages, C or C++, and includes calls to RTR. RTR applications are composed of two kinds of actors, client applications and server applications. An application process is shown in diagrams as an oval, open for a client application (see Figure 1-1), filled for a server application (see Figure 1-2).
Client
A client is always a client application, one that initiates and demarcates a piece of work. In the context of RTR, a client must run on a node defined to have the frontend role. Clients typically deal with presentation services, handling forms input, screens, and so on. A client could connect to a browser running a browser applet or be a webserver acting as a gateway. In other contexts, a client can be a physical system, but in RTR and in this document, physical clients are called frontends or nodes. You can have more than one instance of a client on a node.
Figure 1-1 Client Symbol
Server
A server is always a server application, one that reacts to a client's units of work and carries them through to completion. This may involve updating persistent storage such as a database file, toggling a switch on a device, or performing another predefined task. In the context of RTR, a server must run on a node defined to have the backend role. In other contexts, a server can be a physical system, but in RTR and in this document, physical servers are called backends or nodes. You can have more than one instance of a server on a node. Servers interact with partitions and can have partition states such as primary, standby, or shadow.
Figure 1-2 Server Symbol
Channel
RTR expects client and server applications to identify themselves before they request RTR services. During the identification process, RTR provides a tag or handle that is used for subsequent interactions. This tag or handle is called an RTR channel. A channel is used by client and server applications to exchange units of work with the help of RTR. An application process can have one or more client or server channels. Channel management is handled transparently by the C++ API.
RTR configuration
An RTR configuration consists of nodes that run RTR client and server applications. An RTR configuration can run on several operating systems including OpenVMS, Tru64 UNIX, and Windows NT among others (for the full set of supported operating systems, refer to the appropriate SPD). Nodes are connected by network links.
Roles
A node that runs client applications is called a frontend (FE), or is said to have the frontend role. A node that runs server applications is called a backend (BE). Additionally, the transaction router (TR) contains no application software but acts as a traffic cop between frontends and backends, routing transactions to the appropriate destinations. The router controls the distributed RTR nodes, and takes care of two-phase commit, failover and failback.
The router also eliminates any need for frontends and backends to know about each other in advance. This relieves the application programmer from the need to be concerned about network configuration details. The router can reside on a node running as a frontend or a backend but is often run on a node where neither backends nor frontends are running. Figure 1-3 shows the symbol for each of the RTR roles.
Figure 1-3 Roles Symbols
Facility
The mapping between nodes and roles is done using a facility. An RTR facility is the user-defined name for a particular configuration whose definition provides the role-to-node map for a given application. The facility symbol (see Figure 1-4) illustrates its use in the RTR environment. Nodes can share several facilities. The role of a node is defined within the scope of a particular facility.
The router is the only role that knows about all three roles. A router can run on the same physical node as the frontend or backend, if that is required by configuration constraints, but such a setup would not take full advantage of failover characteristics.
Figure 1-4 Facility Symbol
A facility name is mapped to specific physical nodes and their roles using the CREATE FACILITY command.
Figure 1-5 shows the logical relationship between client application, server application, frontends (FEs), routers (TRs), and backends (BEs) in the RTR environment at a specific location. The database is represented by the cylinder. Two facilities are shown (indicated by the large double-headed arrows), the User Accounts Facility and the General Ledger Facility. The User Accounts Facility uses three nodes, FE, TR, and BE, while the General Ledger Facility uses only two, TR and BE in the configuration shown. Its FEs are on nodes not shown in the figure, at another location.
Figure 1-5 Components in the RTR Environment
Clients send messages to servers to ask that a piece of work be done. Such requests may be bundled together into transactions. An RTR transaction consists of one or more messages that have been grouped together by a client application, so that the work done as a result of each message can be undone completely, if some part of that work cannot be done. If the system fails or is disconnected before all parts of the transaction are done, then the transaction remains incomplete.
Transaction
A transaction is a piece of work or group of operations that must be executed together to perform a consistent transformation of data. This group of operations can be distributed across many nodes serving multiple databases. Applications use services that RTR provides.
Because typically a transaction consists of several operations, a system or network failure at any step in the process will cause the transaction to be in doubt. RTR ensures that all transactions have the ACID properties so that all transactions are in a known state. (See the description of "Transactional messaging" for further clarification of transaction integrity.)
Transaction Controller
With the C++ API, the Transaction Controller manages transactions (one at a time), channels, messages, and events.
Transactional messaging
RTR provides transactional messaging in which transactions are enclosed in messages controlled by RTR.
Transactional messaging ensures that each transaction is complete, and not partially recorded. For example, a transaction or business exchange in a bank account might be to move money from a checking account to a savings account. The complete transaction is to remove the money from the checking account and add it to the savings account.
A transaction that transfers funds from one account to another consists of two individual updates: one to debit the first account, and one to credit the second account. The transaction is not complete until both actions are done. If a system performing this work goes down after the money has been debited from the checking account but before it has been credited to the savings account, the transaction is incomplete.
With transactional messaging, RTR ensures that a transaction is "all or nothing"---either fully completed or discarded; either both the checking account debit and the savings account credit are done, or the checking account debit is backed out and not recorded in the database. RTR transactions have the ACID properties.
Nontransactional messaging
An application will also contain nontransactional tasks such as writing diagnostic trace messages or sending a broadcast message about a change in a stock price after a transaction has been completed.
Transaction ID
Every transaction is identified on initiation with a transaction identifier or transaction ID (TID), with which it can be logged and tracked. RTR guarantees that TIDs are unique.
To reinforce the use of these terms in the RTR context, this section briefly reviews other uses of configuration terminology.
Tiers
A traditional two-tier client/server environment is based on hardware that separates application presentation and business logic (the clients) from database server activities. The client hardware runs presentation and business logic software, and server hardware runs database or data manager (DM) software, also called resource managers (RM). This type of configuration is illustrated in Figure 1-6. (In all diagrams, all lines are actually bidirectional, even when represented otherwise for clarity. For a given transaction, the initial action is typically from left to right.) In Figure 1-6, Application Presentation and Business Logic are the first tier, and the Database Server is the second tier.
Figure 1-6 Two-Tier Client/Server Environment
Further separation into three tiers is achieved by separating presentation software from business logic on two systems, and retaining a third physical system for interaction with the database. This is illustrated in Figure 1-7, where Presentation and User Interface are the first tier, the Application Server and Business Logic are the second tier, and the Database Server is the third tier.
Figure 1-7 Three-Tier Client/Server Environment
RTR extends the three-tier model, which is based on hardware, to a multilayer, or multicomponent software model.
RTR Software Components
RTR provides a multicomponent software model where client applications running on frontends, combined with routers and server applications running on backends cooperate to provide reliable service and transactional integrity. Application users interact with the client (presentation layer) on the node with the frontend role that forwards messages to the current router. The router in turn routes the messages to the current, appropriate backend, where server applications reside, for processing. The connection to the current router is maintained until the current router fails or connections to it are lost.
All RTR software components can reside on a single node but are typically deployed on different nodes to achieve modularity, scalability, and redundancy for availability. During initial application development, it can be convenient to use a single physical node for all RTR roles and application software.
With different physical systems, if one node goes down or off line, another router or backend node can take over application processing. In a slightly different configuration, you could have an application that uses an external applet component running on a browser that connects to a client running on the RTR frontend. Such a configuration is shown in Figure 1-8. In the figure, the applet is separate from but connects to the client application written to work directly with RTR.
Figure 1-8 Browser Applet Configuration
The RTR client application could be an ASP (Active Server Page) or a process interfacing to the webserver through a standard interface such as CGI (Common Gateway Interface) script.
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. This automatic failover and recovery of service can exploit redundant or underutilized hardware and network links. For example, you could use an underutilized system as a standby server in certain configurations.
As you modularize your application and distribute its components on frontends and backends, you can identify usage bottlenecks, add new nodes, 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 single node configuration can be useful during development, but would not normally be used when your application is deployed.
Figure 1-9 RTR with Browser, Single Node, and Database
| Next | Contents | Index |