English Case Studies
Message Repair and Recovery
Codestreet ReplayService™ extends the standard qualities of JMS with a ‘Replay Quality of Service’, providing access to messages sent previously over JMS. This ability is very useful in creating distributed system architectures that are tolerant of machine failures. Being able to recover the state of applications routinely or after a disaster is crucial in most production deployments, and thus ReplayService™ plays a critical role in high availability distributed messaging environments.
Codestreet ReplayService™ can be deployed outside the critical path and record all messages flowing through the JMS server as a passive consumer. All messages are recorded on a shared disk and a Fault-Tolerance-enabled ReplayServer would automatically rollover in failure situations. Transactional semantics ensures messages cannot be lost.
To find a previously failed message, the ReplayService™ Web GUI supports finding messages by time range, destination and content searches, such as text patterns or XML XPath queries. Individual messages or header fields can then be edited in the GUI before resending them to a JMS destination. For example, if a trade message should have been processed, but it didn’t succeed because a user name was misspelled, it is simple to find this message, rectify the user name, and resend the message.
In case the JMS consumers use Codestreet Rewindable Destinations (a JMS 1.1 compatible extension), messages can be injected to just exactly one durable subscriber on a shared JMS topic.
Codestreet ReplayService™ also simplifies application recovery by allowing consuming applications to recover from an arbitrary time in the past, and then seamlessly continue to process real-time messages.
A trading application, for example, can request replay of all trades since the start of trading. A middle-office application can request a replay from the last successfully processed message. With Codestreet ReplayService™ working in the messaging layer, applications can be built simpler because they don’t have to be concerned with persisting and recovering their internal state.
- Compare new XSD against previous XML structure
- Replay a whole day to a new version of the application with the original or 2x/4x the speed
- Simpler Store-and-Forward Delivery Message senders and consumers can operate at their own message rates without pre-registration of consumers.
- Application State Recovery Simplifies building fault-tolerance and state recovery into applications.
- Reference Data Distribution Applications throughout the enterprise automatically receive reference data updates, so there is no need to centralize data access or struggle with complex replication schemes.
- Auditing of Business Activity ReplayService records information moving within the enterprise, so it's easy to maintain activity logs for business and regulatory purposes.
- Functional and Performance Testing of Applications Application performance can be tested by varying the replay rate and by simulating a live stream.
- Business Activity Monitoring (BAM) ReplayService gathers the data required for complex Business Activity Monitoring, so there is no need for re-architecting.
- Simple record and replay capabilities provides messages on demand.
- Content of messages can be easily manipulated
- Provides extensive flow control. Replays messages at any flat rate or as a function of the original message spacing.
- Guarantees message order — messages from a given group of channels are always forwarded/replayed in the same sequence in which they were recorded.
- Replayed messages can be selected by specifying a group of channels, topics or queues, and by additional criteria such as JMS message selectors.