CodeStreet ReplayService™ for JMS extends the capabilities of Message Oriented Middleware such as TIBCO EMS™ by providing critical record and replay capabilities. ReplayService allows previously recorded messages to be inspected and replayed upon request, filtered by a wide variety of criteria.

Why ReplayService?

Robust messaging platforms at financial institutions are standard today, but the reality is that messages often need to be redelivered to consuming applications. In banking production environments, ReplayService allows applications and administrators to elegantly recover specific sets of messages, freeing development groups from having to build their own custom recovery capabilities.

Building message recovery into an application is costly and additionally involves long-term support costs. ReplayService allows applications groups to leverage a robust, hardened message recovery solution that is running successfully at the heart of some of the world's most mission critical banking systems.

Customers use ReplayService today for

Features of ReplayService for JMS

Rewindable Destinations

Rewindable Destinations are a unique feature of ReplayService for JMS that allows a topic or queue to be rewound so that messages that have previously been consumed can be recovered. The magic happens through a custom implementation of the JMS client API that includes a software switch that can be triggered to switch between replayed messages and live messages. Leveraging this switch, messages can be injected into an ongoing message stream or the stream itself can be rewound to begin consuming from a particular point in time.

Rewindable destinations provide an optimal architecture for message recovery, providing an out-of-the-critical-path recording and replay solution that does not add any latency to the message path. Replayed messages can be sent to one or more subscribers, simultaneously providing fine grained control of the message recovery process.

Below is an interactive Flash demonstration of Rewindable Destinations.

Since the Replay API fully implements the JMS 1.1 API, Rewindable Destinations can be introduced without code changes. Through configuration, a different connection factory is retrieved from your JNDI implementation - your code stays the same. In the non-recovery mode, Rewindable Consumers are simply a wrapper around an underlying TIBCO EMS consumer of the same type. Only during the 'rewind phase' will messages be dispatched from a temporary destination that was previously created for each consumer. Once the 'rewind phase' is completed, standard messaging resumes with the underlying TIBCO EMS consumer retrieving messages from the regular topic or queue.

Thus, rewindable destinations represent an ideal recovery architecture whereby all messages are available for replay via the JMS API or via an administrator initiated replay session and where the recovery facility does not impact the flow of messages and the latency within the system under normal operating conditions.

Platform Support

ReplayService for JMS is available on the following platforms: Linux RHEL AS, ES, and WS 3.0, 4.0, 5.0 and SuSE SLES 8, 9, 10; Windows XP Service Pack 2 or later, 32-bit and 64-bit editions of Windows Vista, Windows 7, Windows Server 2003 R2 and Windows Server 2008 R2; Solaris 2.6, Solaris 8, 9, 10 SPARC and x86.

For a product demonstration or further information, contact us: sales@codestreet.com
CodeStreet
317 Madison Avenue
7th Floor
New York, NY 10017
Telephone: 646-442-2800
www.codestreet.com