HP Reliable Transaction Router User manual

HPReliableTransactionRouter
GettingStarted
Order Number: AA-RLE1C-TE
June 2005
This document introduces HP 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,
Version 4.2.
Software Version: HP Reliable Transaction Router Version
5.0
Hewlett-Packard Company
Palo Alto, California

© Copyright 2003, 2005 Hewlett-Packard Development Company, L.P.
Confidential computer software. Valid license from HP 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
standard commercial license.
The information contained herein is subject to change without notice. The only
warranties for HP products and services are set forth in the express warranty
statements accompanying such products and services. Nothing herein should
be construed as constituting an additional warranty. HP shall not be liable for
technical or editorial errors or omissions contained herein.
Microsoft and Windows are U.S. registered trademarks of Microsoft Corporation.
Intel and Itanium are trademarks or registered trademarks of Intel Corporation
or its subsidiaries in the United States and other countries.
UNIX is a registered trademark of The Open Group. Java is a US trademark
of Sun Microsystems, Inc.
This document was prepared using DECdocument, Version 3.3-1B.

Contents
Preface ..................................................... vii
1 Introduction
Reliable Transaction Router . . ........................... 1–1
RTR Continuous Computing Concepts . . ................... 1–3
RTR Terminology . . ................................... 1–4
RTR Server Types . ................................... 1–17
RTR Networking Capabilities ........................... 1–26
2 Architectural Concepts
The Three-Tier Architecture . ........................... 2–1
RTR Facilities Bridge the Gap ........................... 2–3
Broadcasts .......................................... 2–4
Flexibility and Growth ................................. 2–4
Transaction Integrity .................................. 2–5
The Partitioned Data Model . . ........................... 2–6
Object-Oriented Programming ........................... 2–6
Objects .......................................... 2–8
Messages ........................................ 2–9
Class Relationships ................................ 2–9
Polymorphism . ................................... 2–10
Object Implementation Benefits....................... 2–10
Java Support ........................................ 2–11
XA Support ......................................... 2–11
iii

3 Reliability Features
RTR Server Types .................................... 3–1
Failover and Recovery . ................................ 3–2
Router Failover . . . ................................ 3–2
Recovery Scenarios .................................... 3–3
Backend Recovery . ................................ 3–3
Router Recovery . . ................................ 3–3
Frontend Recovery ................................ 3–4
4 RTR Interfaces
RTR Management .................................... 4–6
RTR Administrator ................................ 4–6
RTR Command Line Interface ........................ 4–10
Application Programming Interfaces ...................... 4–16
RTR Java Object-Oriented Interface . . . ................ 4–16
RTR C++ Object-Oriented Programming Interface . . ....... 4–18
RTR C Programming Interface ....................... 4–21
5 The RTR Environment
The RTR System Management Environment ................ 5–1
Monitoring RTR . . . ................................ 5–3
Transaction Management ............................ 5–4
Partition Management .............................. 5–5
RTR Runtime Environment ............................. 5–6
What’s Next? ........................................ 5–7
Glossary
Index
Examples
2–1 Objects-Defined Sample ............................. 2–9
4–1 The user issues the following commands on the server
application where RTR is running on the backend. . ....... 4–12
4–2 When the next command is issued, RTR waits for the
message from the client, which does not appear until after
the client sends it (Example 4-3). ...................... 4–13
iv

4–3 Commands and system response at client. ............... 4–14
4–4 The following lines arrive at the client from RTR after the
user enters commands at the server. ................... 4–15
4–5 Creating a Facility with the C++ API .................. 4–20
4–6 Starting RTR with the C++ API ....................... 4–21
4–7 Creating a Facility with the C++ API .................. 4–21
4–8 Creating a Partition with the C++ API ................. 4–21
Figures
1RTR Reading Path ................................. xi
1–1 Client Symbol . ................................... 1–5
1–2 Server Symbol . ................................... 1–6
1–3 Roles Symbols . ................................... 1–7
1–4 Facility Symbol ................................... 1–8
1–5 Components in the RTR Environment .................. 1–8
1–6 Two-Tier Client/Server Environment ................... 1–11
1–7 Three-Tier Client/Server Environment .................. 1–11
1–8 Browser Applet Configuration ........................ 1–12
1–9 RTR with Browser, Single Node, and Database . .......... 1–13
1–10 RTR Deployed on Two Nodes ......................... 1–13
1–11 RTR Deployed on Three Nodes ....................... 1–14
1–12 Standby Server Configuration ........................ 1–15
1–13 Transactional Shadowing Configuration ................. 1–16
1–14 Standby Servers ................................... 1–19
1–15 Shadow Servers ................................... 1–20
1–16 Concurrent Servers ................................ 1–21
1–17 A Callout Server .................................. 1–22
1–18 Bank Partitioning Example .......................... 1–24
1–19 Standby with Partitioning ........................... 1–25
2–1 The Multitier Model ................................ 2–2
2–2 Partitioned Data Model . . ........................... 2–7
4–1 RTR Administrator ................................ 4–2
4–2 RTR Command Line Interface ........................ 4–3
4–3 RTR Manager . . ................................... 4–7
4–4 RTR Explorer: View of All Facilities ................... 4–8
4–5 RTR Explorer: View of One Facility ................... 4–9
v

4–6 RTR Service Provider ............................... 4–17
5–1 RTR System Management Environment ................ 5–4
5–2 RTR Runtime Environment . . ........................ 5–7
Tables
1RTR Documents . . . ................................ viii
2–1 Functional and Object-Oriented Programming Compared . . . 2–8
4–1 RTR Development Interfaces and their Use .............. 4–5
vi

Preface
Purpose of this Document
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.
Document Structure
This document contains the following chapters:
• Chapter 1, Introduction, provides information on RTR
technology, basic RTR concepts, and RTR terminology.
• Chapter 2, Architectural Concepts, introduces the RTR
three-tier model and explains the use of RTR functions and
programming capabilities.
• Chapter 3, Reliability Features, highlights RTR server types
and failover and recovery scenarios.
• Chapter 4, RTR Interfaces, introduces the management and
programming interfaces of RTR.
• Chapter 5, The RTR Environment, describes the RTR
system management and runtime environments, and
provides explicit pointers to further reading in the RTR
documentation set.
vii

Related Documentation
Table 1 describes RTR documents and groups them by
audience.
Table 1 RTR Documents
Document Content
For all users:
HP Reliable Transaction Router
Release Notes1Describes new features, corrections, restrictions, and
known problems for RTR.
HP Reliable Transaction Router
Getting Started
Provides an overview
of RTR technology and
solutions, and includes the
glossary that defines all
RTR terms.
HP Reliable Transaction Router
Software Product Description
Describes product features.
For the system manager:
HP Reliable Transaction Router
Installation Guide
Describes how to install
RTR on all supported
platforms.
HP Reliable Transaction Router
System Manager’s Manual
Describes how to configure,
manage, and monitor RTR.
For the application
programmer:
HP Reliable Transaction Router
Application Design Guide
Describes how to design
application programs for
use with RTR, with both
C++ and C interfaces.
1Distributed on software kit.
(continued on next page)
viii

Table 1 (Cont.) RTR Documents
Document Content
HP Reliable Transaction Router
JRTR Getting Started 2Provides an overview of the object-oriented
JRTR Toolkit including
installation, configuration
and Java programming
concepts, with links
to additional online
documentation.
HP Reliable Transaction Router
C++ Foundation Classes
Describes the object-
oriented C++ interface that
can be used to implement
RTR object-oriented
applications.
HP 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.
2In downloadable kit.
You can find additional information about RTR, including the
Software Product Descriptions, on the RTR website found
through http://www.hp.com links to middleware products or at
http://www.hp.com/go/rtr .
Reader’s Comments
HP welcomes your comments on this manual. Please send
comments to either of the following addresses:
Internet [email protected]
Postal Mail Hewlett-Packard Company
RTR Documentation Group, ZKO3-4/Y17
110 Spit Brook Rd.
Nashua, NH 03062-2698
ix

Conventions
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.
Reading Path
The reading path to follow when using the Reliable Transaction
Router information set is shown in Figure 1.
x

Figure 1 RTR Reading Path
VM-0818A-AI
System Manager Application Programmer
= Tutorial
(Online Only)
If C++
If Java
If C
Getting
Started
C Application
Programmer’s
Reference
Manual
Application
Design
Guide
JRTR
Getting
Started
System
Manager’s
Manual
Installation
Guide
RTR Help
(Online Only)
C++
Foundation
Classes
= Glossary
Release
Notes
SPD
xi

1
Introduction
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
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.
Introduction 1–1

Reliable Transaction Router
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
HP 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
1–2 Introduction

Reliable Transaction Router
processing system using RTR requires analysis, planning, and
considered execution.
RTR Continuous Computing Concepts
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:
• Reliability
• Failure tolerance
• Data and transaction integrity
• Scalability
• Ease of building and maintaining applications
• Interoperability with multiple operating systems
RTR additionally provides the following capabilities, essential in
the demanding transaction processing environment:
• Flexibility
• Parallel execution at the transaction level
• Potential for step-by-step growth
• Comprehensive monitoring tools
• Management station for single console system management
• WAN deployability
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:
• Atomic
• Consistent
• Isolated
Introduction 1–3

RTR Continuous Computing Concepts
• Durable
For more details on transactional ACID properties, see the brief
discussion later in this document in the section Transaction
Integrity and refer to the HP Reliable Transaction Router
Application Design Guide.
RTR Terminology
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:
• Application
• Client, client application
• Server, server application
• Channel
• RTR configuration
• Roles
• Frontend
• Router
• Backend
• Facility
• Transaction
• Transaction controller
• Transactional messaging
• Nontransactional messaging
• Transaction ID
• Tier
1–4 Introduction

RTR Terminology
• Standby server
• Transactional shadowing
• RTR journal
• Partition
• Key range
•XA
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, C++, or Java 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 Aclient 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
Client
VM-0819A-AI
Introduction 1–5

RTR Terminology
Server Aserver 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
Server
VM-0820A-AI
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++ and Java
APIs.
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 among others (for the full set of supported operating
systems, refer to the appropriate SPD). Nodes are connected by
network links.
1–6 Introduction

RTR Terminology
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
FE TR BE
Frontend Transactional
Router Backend
VM-0821A-AI
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. Normally a facility is defined across all
roles but facility definition depends on application design.
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.
Introduction 1–7

RTR Terminology
Figure 1–4 Facility Symbol
VM-0822A-AI
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
FE TR BE
User Accounts Facility
Server
application
General Ledger Facility
VM-0823A-AI
Client
application
1–8 Introduction