HP RTR

This article has multiple issues. Please help or discuss these issues on the talk page. (Learn how and when to remove these template messages) This article does not cite any sources. Please help by adding citations to reliable sources. Unsourced material may be challenged and removed. Find sources:  –  ·  ·  · scholar · JSTOR (September 2010) (Learn how and when to remove this template message) This article contains content that is written like an advertisement. Please help by removing promotional content and inappropriate external links, and by adding encyclopedic content written from a neutral point of view. (February 2011) (Learn how and when to remove this template message) (Learn how and when to remove this template message)

HP Reliable Transaction Router (RTR) is a transactional middleware for computer software, marketed by Hewlett Packard. RTR is used to integrate with applications that require reliable transaction services.

Description[]

RTR manages the messages sent between client-server to provide node and network fail-over for increased reliability, transactional integrity, and interoperability between dissimilar systems.

The RTR software has three logical entities and referred to as front-end (FE), back-end (BE) and transaction-router(TR). The router is a software component that provides the fail-over intelligence and manages connections to the back-end. The client applications running on the Front-End combined with Router and Server applications running on back-end interact to provide transaction integrity and reliability. The three logical entities can exist on the same node but are usually deployed on different nodes to achieve modularity, scalability and high availability.

The client application interacts with the front-end which forwards the messages to the router, the router in turn routes the message to the intended back-end where the appropriate Server application is available for processing the message. The RTR routing capability partitions data across multiple servers and nodes for increased performance. Within an application, the partition determines how messages are routed between the client and the servers. The message exchange happens between the client and server. Transactions start at the client and involve many messages that can go to a number of different servers. Such method of messaging is used in situations where there are multiple recipients for a message, or where unsolicited messages need to be sent. RTR can help survive the failures generally seen in distributed application environment which include complete site failure, node failure, network link failure and software process failure. RTR also provides continuous availability by using redundant resources in the distributed environment.

RTR provides a Web Interface and a Command Line Interface(CLI) for managing the RTR environment. When RTR and its components are running along with the applications, then Client Application, Server Application, RTR services will be active.

RTR is integrated with client applications and can be customized. User and Management Applications can be written using RTR APIs. The C, C++, Java and .Net variants of APIs are available for creating applications to use RTR.

History[]

RTR was first conceived in Zurich, Switzerland by Dr. Paul Shrager in early 1988, and developed by a small team of four engineers, working for DEC (Digital Equipment Corporation). The initial release was written in a mix of Macro, Bliss, Pascal and SDL on top of DECnet and VMS. Later it was reimplemented in C on top of a TCP/IP stack and an OS agnostic infrastructure, that allowed it to be deployed on multiple operating systems, including various flavors of Unix/Linux, VMS, Windows. A Java and C++ veneer was added in the mid 90s to support a RPC style veneer, on top of the "services" oriented interface.

Special Characteristics[]

RTR was one of the first OLTP middleware services that provided the following features (in addition of the usual ones), viz.

• Concurrent servers (a service could be offered by multiple entities, either as multiple threads within the same process, or as independent processes)
• Standby servers (a set of services that is capable of offering the services, if required, but not currently being asked to do so)
• Shadow servers (a set of services currently processing an identical set of requests as the primary servers)

Additionally, RTR guarantees the data equivalence of the repositories behind the primary and shadow servers, by enforcing a deduced "dependency relationship" among the set of concurrent transactions being shadowed. This allows RTR to process multiple transactions on the shadow without compromising dependency violations.

Who uses it?[]

The most high-profile users are banks, stock exchanges and Railway Passenger Reservation Systems.

RTR was available on HP-UX, Linux, Windows and OpenVMS in 2010.

Further reading[]

• Transaction processing
• Middleware
• Distributed Computing Environment

External links[]

• http://h71000.www7.hp.com/doc/rtr.html
• http://www.indianmba.com/Faculty_Column/FC552/fc552.html