Browse Prior Art Database

RECOVERY MECHANISM IN LONG RUNNING CONVERSATIONAL APPLICATION

IP.com Disclosure Number: IPCOM000014417D
Original Publication Date: 2000-Jul-01
Included in the Prior Art Database: 2003-Jun-19
Document File: 2 page(s) / 40K

Publishing Venue

IBM

Abstract

In a transaction processing environment, the underlying resource managers, e.g., Databases, file systems, maintain a log of inter- actions of an application in order to achieve atomicity of a set of interactions of the application with the resource manager(s); Upon a failure the resource managers use undo and/or redo oper- ations based on the log to bring the resources to a consistent state. In addition, a recoverable application and/or an under- lying monitor checkpoints the states of the recoverable applica- tion at all commit points for recovery upon a failure.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 2

RECOVERY MECHANISM IN LONG RUNNING CONVERSATIONAL APPLICATION

In a transaction processing environment, the underlying resource managers, e.g., Databases, file systems, maintain a log of inter- actions of an application in order to achieve atomicity of a set of interactions of the application with the resource manager(s); Upon a failure the resource managers use undo and/or redo oper- ations based on the log to bring the resources to a consistent state. In addition, a recoverable application and/or an under- lying monitor checkpoints the states of the recoverable applica- tion at all commit points for recovery upon a failure.

Disclosed is a method via which the state of a long running application that interacts with autonomous external entities
(e.g., autonomous applications, resource managers, etc. where interactions can not be undone) can be recreated by an underlying monitor without checkpointing various intermediate states of the application. The monitor maintains a log of interactions with all other autonomous entities on behalf of the application, and upon a failure, replays the external events (e.g., request/reply from autonomous entities) in order to drive the application from an initial state to its before failure state.

DETAILED DESCRIPTION OF THE FRAMEWORK: Coyote architecture

___________________________________________

defines a framework for long running conversational applications between autonomous organizations. A service contract between two participants is used to specify an external interface, rules of engagement, and obligations and responsibilities of both parties. Coyote provides a tool which generates a group of framework com- ponents from service contract to enforce it. The application developer adds a separate component which embodies business logic to the above framework generated components. The business logic component together with framework generated components defines a coyote application.

A typical Coyote application during its normal operation inter- acts with other coyote applications (i.e., autonomous applica- tions), and other local resources. Various failure scenarios are possible: 1. Coyote application might fail, 2. Communication link between two coyote applications might fail, and finally, 3. Local resources might fail. In this document we disclose a novel recovery mechanism of a failed coyote application.

During normal course of operation an interaction history with all the necessary details of each and every interaction of a coyote application with other coyote applications and local resources is maintained. This interaction history is key...