which provided the ability to specify transactional properties for tasks that identified how failures should be dealt with; ConTracts [210], which proposed a coordinated, nested transaction model for workflow execution allowing for forward, backward, and partial recovery in the event of failure; and Exotica [34], which provided a mechanism for incorporating Sagas and Flexible transactions in the commercial FlowMark workflow product. OPERA [113, 114] was one of the first initiatives to incorporate language primitives for exception handling into a workflow system, and it also allowed exception handling strategies to be modeled in the same notation as that used for representing workflow processes. TREX [243] proposed a transaction model that involves treating all types of workflow failures as exceptions. A series of exception types were delineated and the exception handler utilized in a given situation was determined by a combination of the task and the exception experienced. WIDE [55] developed a comprehensive language – Chimera-Exc – for specifying exception handling strategies in the form of Event-Condition-Action (ECA) rules.