WO2007120391A1 - Asynchronous fault handling in process-centric programs - Google Patents

Asynchronous fault handling in process-centric programs Download PDF

Info

Publication number
WO2007120391A1
WO2007120391A1 PCT/US2007/004642 US2007004642W WO2007120391A1 WO 2007120391 A1 WO2007120391 A1 WO 2007120391A1 US 2007004642 W US2007004642 W US 2007004642W WO 2007120391 A1 WO2007120391 A1 WO 2007120391A1
Authority
WO
WIPO (PCT)
Prior art keywords
work items
state
faulting
activity
executing
Prior art date
Application number
PCT/US2007/004642
Other languages
French (fr)
Inventor
Dharma Shukla
Bob Schmidt
Mayank Mehta
Nathan Talbert
Akash J. Sagar
Karthik Raman
Original Assignee
Microsoft Corporation
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Microsoft Corporation filed Critical Microsoft Corporation
Priority to EP07751408A priority Critical patent/EP2013716A4/en
Priority to CN2007800123531A priority patent/CN101416156B/en
Priority to BRPI0708917-1A priority patent/BRPI0708917A2/en
Priority to CA002644370A priority patent/CA2644370A1/en
Priority to MX2008011910A priority patent/MX2008011910A/en
Priority to JP2009502791A priority patent/JP5297370B2/en
Publication of WO2007120391A1 publication Critical patent/WO2007120391A1/en

Links

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00Administration; Management
    • G06Q10/06Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06QINFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00Administration; Management
    • G06Q10/06Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
    • G06Q10/063Operations research, analysis or management
    • G06Q10/0633Workflow analysis

Definitions

  • Process-oriented or process-centric programs have evolved to enable processing of complex instructions modeling real- world events.
  • Process-centric programs mirror real-world processes and mirror interactions between real-world entities.
  • Existing systems attempt to map business problems to high-level workflows by modeling the business problem.
  • real world workflows vary in a variety of dimensions such as (a) execution and modeling complexity, (b) knowledge of the structure of the flow at design time, (c) statically defined or ad-hoc/dynamic, (d) ease of authoring and editing the flow at various points in its lifecycle, and (e) weak or strong association of business logic with the core workflow process.
  • existing models fail to accommodate all these factors.
  • workflow models are based on either language-based approaches (e.g., BPEL4WS, XLANG/S, and WSFL) or application based approaches.
  • Language based approaches are high-level workflow languages with a closed set of predefined constructs which help model the workflow process to the user/programmer.
  • the workflow languages carry all of the semantic information for the closed set of constructs to enable the user to build a workflow model.
  • the languages are not extensible by the developers and represent a closed set of primitives that constitute the workflow model.
  • the languages are tied to the language compiler shipped by the workflow system vendor. Only the workflow system product vendor may extend the model by extending the language with a new set of constructs in a future version of the product.
  • workflow processes deal with cross cutting orthogonal and tangled concerns that span multiple steps of a workflow process model. For example, while parts of the workflow process are designed to participate in long running transactions, other parts of the same process are designed for concurrent execution or for accessing a shared resource. Due to design shortcomings, existing systems fail to provide interleaving of execution threads which enable users to design synchronous or interleaved execution of activities. Still other portions of the same workflow process require tracking, while other portions handle business or application level exceptions. There is a need to apply certain behaviors to one or more portions of a workflow process.
  • workflow modeling approaches are impractical as they require a complete flow-based description of an entire business process including all exceptions and human interventions. Some of these approaches provide additional functionality as exceptions arise, while other approaches exclusively employ a constraint-based approach instead of a flow-based approach to modeling a business process.
  • Existing systems implement either the flow-based or constraint-based approach. Such systems are too inflexible to model many common business situations. These systems also lack the capability to asynchronously handle exceptions or cancellations.
  • Embodiments of the invention enable asynchronous fault or exception handling by having a faulting state in a state automaton defining execution lifetime of an activity in the workflow.
  • aspects of the invention enable developers or programs to declaratively design programs for exception or fault handling such that portions of the program or the activity may be in fault handling in the faulting state while other portions of the program or the activity may be unaffected by the exception or the faulting event.
  • Alternative embodiments of the invention enable propagation or transmission of a notification of fault handling.
  • such propagation or transmission of the notification may be suppressed or inhibited.
  • a further alternative embodiment responds to input from a user for handling post-faulting or post- exception operations.
  • FIG. 1 is a block diagram illustrating an existing programming paradigm.
  • FIG.2 is an exemplary block diagram illustrating a virtualization of a workflow design framework according to an embodiment of the invention.
  • FIG. 3 is an exemplary diagram illustrating an exemplary workflow according to an embodiment of the invention.
  • FIG. 4 is a diagram illustrating an exemplary computing environment of a system for processing workflow activities according to an embodiment of the invention.
  • FIG. 5 is a diagram illustrating a hierarchical structure of a workflow activity according to an embodiment of the invention.
  • FIG. 6 is a diagram illustrating an exemplary state automaton describing execution lifetime of an activity according to an embodiment of the invention.
  • FIGS. 7 A to 7E are block diagrams illustrating an asynchronous handling of faulting events of a workflow according to an embodiment of the invention.
  • FIG. 8 is a flow diagram illustrating a method for asynchronously handling of a faulting event for an activity of a workflow according to an embodiment of the invention.
  • FIG. 9 is a block diagram illustrating an exemplary computer-readable medium on which aspects of the invention may be stored.
  • Appendix A illustrates an exemplary implementation of declaratively raising of an exception according to an embodiment of the invention.
  • FIG. 1 a block diagram illustrates an existing programming paradigm for designing programs for process-centric activities, such as a workflow.
  • the diagram shows a three-level virtualization model of existing program paradigm with a level of a managed execution environment being the highest level and a processing unit being the lowest level.
  • programs, especially process-centric programs handling workflow processes lack the ability and efficiency to accommodate complex interactions between, processes in a workflow.
  • a managed execution environment 106 e.g., a runtime environment where programs may share functions or common object-oriented classes
  • programs written one programming language may call functions in other programs written in a different programming language.
  • these programs in different programming languages are compiled to an intermediate language such that the managed execution environment 106 may expose parameters, arguments, or schemas or functions to the different programs so that the programs may interact with one another.
  • this execution environment 106 creates a common communication environment between programs, the execution environment 106 includes various strict requirements that may not be suitable for handling the complexity and capability of process-centric programs. For example, the execution environment 106 requires programs be confirmed to a specific file format. The execution environment 106 also requires that functions or operations in the programs use a fixed set of functions or a class of functions defined by the execution environment 106.
  • Embodiments of the invention build on an extensible foundation or framework 202 in FIG. 2 to overcome the shortcomings of existing programming model.
  • aspects of the invention enable program developers to design programs with specific functions without compromising its functionalities and specifics.
  • activities such as workflow tasks or processes, as the base class to be executed in the workflow framework
  • developers can easily and efficiently build domain specific (e.g., specific execution environments such as programs in the healthcare industrial, financial industry, or the like) operation codes (hereinafter "op-code”) without adhering to the rigid, hard-coded, inflexible, and the fixed set of functions or activities classes in the existing execution environment.
  • the workflow foundation embodying aspects of the invention is a continuation based runtime layered on top of any existing framework (e.g., either a managed execution environment, operating system environment, or hardware processing unit level).
  • FIG. 3 illustrates a simplistic view of a workflow 300 according to an embodiment of the invention.
  • the workflow 300 may be a workflow for processing a purchase order, and this purchase order workflow 300 may include processes or activities such as receive a purchase order, send confirmation to a customer, approve the purchase order by a manager, or the like.
  • the workflow 300 may start from a starting point 302.
  • the starting point 302 for a purchase-order workflow may be receiving an order from a customer.
  • the workflow 300 may also include a conditional statement 304 (such as an "IF statement” or a "WHILE statement"), and it can be subdivided into additional conditional statements 306 and 308.
  • the workflow 300 may also include a parallel structure 310, which further includes one or more sequences or activities 312.
  • the parallel structure 310 includes activities, such as checking the inventory and updating the available shippers, be processed in parallel. In the example shown, activities such as "Send E-mail" and "Get Approval" may be processed in parallel.
  • a user may further add or supplement more activities into the workflow 300.
  • the processes or activities will conclude in a complete step or point 314.
  • the activities may be arranged hierarchically in a tree structure (see FIG. 5) 500 or other execution sequences.
  • an activity may be a composite activity in which the activity includes more than one work item associated therewith.
  • a collection of activities may be a composite activity.
  • An activity method or operation may be in a root node 502 with two children or leaf nodes 504 and 506. The activity methods or operations in the children nodes 504 and 506 (e.g., work item_l and work item_2, respectively) may be executed according to the hierarchical structure.
  • activities include one or more of the following types: a simple activity, container activity and root activity.
  • a simple activity may include simple or container activities.
  • the entire workflow process may be used as an activity to build higher-order workflow processes.
  • an activity may be interruptible or non-interruptible.
  • a non- interruptible composite activity does not include interruptible activities.
  • a non- interruptible activity lacks services that would cause the activity to block.
  • the workflow framework or an execution context or environment defines a scope or boundary for each of the work items.
  • This scope or boundary includes and exposes information (e.g., in the form of data, metadata, or the like) such as the shared data or resources to be accessed by the work items, associated properties, handlers, constraints and interactions between autonomous agents.
  • each activity may be configured by a user code in any programming language.
  • the user code may represent business or application logic or rules written in a specific domain or execution environment.
  • Each activity may support pre-interception hooks and post-interception hooks into execution in the user code.
  • FIG. 4 is a diagram illustrating a system 400 for processing workflow activities according to an embodiment of the invention.
  • the system 400 includes a processor 402, which may be a processing unit or a collection of processing units.
  • the system 400 also includes a storage or memory area 404 for storing data accessible by the processor 402.
  • the system 400 may be a computer having one or more processors or processing units (e.g., processor 402) and a system memory (e.g., memory area 404) having other components to couple various system components including the system memory to the processor 402.
  • the memory area 404 may include computer readable media, either volatile, nonvolatile, removable, or non-removable media, implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data.
  • computer storage media include RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that may be used to store the desired information and that may be accessed by the system 400.
  • the memory 404 may also include communication media embodying computer readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism and include any information delivery media. Those skilled in the art are familiar with the modulated data signal, which has one or more of its characteristics set or changed in such a manner as to encode information in the signal.
  • the memory area 404 stores a plurality of activities 406 for processing in a workflow (e.g., the workflow 300).
  • Each of the plurality of activities 406 includes one or more work items, and the work items may be organized in a hierarchical structure such as a tree structure (see FIG. 5).
  • the processor 402 accesses or executes a scheduler 408, which is configured to set up an organized set of activities.
  • the processor 408 accesses the work items in the plurality of activities 406 via a component or a set of computer-executable instructions such as the scheduler 408 to enqueue or to store the work items 422 to a queue 410.
  • a dispatcher 412 accessible by the processor 402, dispatches the work items 422 for execution.
  • a work item 422-1 may include an activity method or an activity operation 424, routine, or a collection of codes for performing a function of "requesting input from a user".
  • One or more other activity methods, activity operations, routines, or codes may be included in each of the work items 422 without departing from the scope of the invention.
  • the processor 402 executes each of the methods 424 in the work items 422 at 414.
  • the processor 402 may provide a user via a user interface (UI) to input the requested information or data.
  • the processor 402 may connect to or access an external data source for requesting input from the user.
  • the processor 402 Upon completion of the activity method or activity operation 424, the processor 402 concludes execution of the work items 422 at 416.
  • the processor 402 passivates the executing state of work items at 418 to a data store 420.
  • the processor 402 executes the work items 422 according to a state automaton, such as the automaton shown in FIG. 6, which is a diagram illustrating an exemplary state automaton 600 describing processing states of work items associated with an activity according to an embodiment of the invention.
  • the state automaton 600 defines an execution lifetime of an activity.
  • the state automaton 600 may include an initialized state, an executing state, and a closed state (as shown in FIG.4).
  • the state automaton 600 includes an initialized state 602, an executing state 604, a canceling state 606, a faulting state 608, a compensating state 610, and a closed state 612.
  • the state automaton 600 describes a process flow of execution of work items (e.g., work items 422) in a workflow activity.
  • the work item 422-1 as illustrated in FIG. 4, is first initialized when it is enqueued in the queue 410.
  • the work item 422-1 is next dequeued or removed from the queue 410 to the dispatcher 412 before being executed in the executing state (e.g., the executing state 604 in FIG. 6).
  • the work item 422-1 may proceed to the canceling state 606 (e.g., the canceling state 426 in FIG. 4) or the faulting state 608.
  • the work item 422-1 may proceed from the canceling state 606 to the faulting state 608.
  • the compensating state 610 describes a set of operations or functions to be performed when faulting or exception has occurred.
  • a work item e.g., work item 422-1
  • the system 400 transitions the work item 422-1 to the faulting state 608.
  • garbage collection e.g., removing previously executed portion of the operations from cache or memory, reset parameter values, or the like
  • work items in the compensating state 610 may trigger operations such as recovering data that was previously used for executing other work items.
  • the closed state 612 indicates that the execution of the activity (e.g., activity 500 in FIG. 5) has completed.
  • the state automaton 600 establishes relationship between work items in a composite activity.
  • one of the relationship rules may include that, before transitioning to the closed state 612 methods or work items in the root node of the activity tree, all of the work items in the children nodes should be in the initialized state 602 or the closed state 612.
  • Another rule may require that, in order to transition the work items in the children node of the activity tree to the executing state 604, the work item in the root node must already be in the executing state 604.
  • one or more additional states may be defined in the state automaton 600 without departing from the scope of embodiments of the invention.
  • FIG. 7A shows a composite activity 702 which includes three children work items organized in a tree structure: transaction_l 704, transaction_2 706, and transaction_3 708.
  • the root activity 702 includes a method to "write text on display.”
  • Activity methods or operations for the work items above also include the following: transaction_l 704: ⁇ INSERT TEXT ("1 AND 2");
  • ⁇ transaction_2 706 ⁇ INSERT TEXT ("3 AND 4"); HANDLEFAULTO; ⁇ transaction_3 708:
  • PAUSE 180 SECONDS; INSERT TEXT ("END");
  • the transaction ⁇ 704 executes the included operations by inserting texts ("1 and 2") on the display (e.g., a user interface 428) to a user 430.
  • a faulting event 722 or an exception has occurred.
  • the faulting event 722 may include a warning notification for missing data, an execution fault, an inaccurate access to a data store, or the like.
  • the transaction_l 704 includes a handleFaultQ function 716 for handling the faulting event 722.
  • the handleFault function 716 resembles a "catch" function for fault handling in other execution environments, such as an operating system or a managed execution environment. As such, the fault propagation or dispatch to the handleFault function 716 or the "catch" handler is asynchronous.
  • the transaction_l 704 transitions to a faulting state 712, and the transaction_l 704 is transitioned to a closed state 714.
  • the handleFault() function 716 is called and is placed in a queue (not shown) for processing.
  • alternative embodiments may handle multiple exceptions, and multiple exceptions may be scheduled while the propagation of exceptions may be interleaved with the normal program execution.
  • the transaction_2 706 and the transaction 708 are in the executing state 710. Similar to executing the transaction_l 704, the transaction_2 706 executes the included operations. In this example, the texts ("3 and 4") are inserted on the display.
  • the transaction_2 706 also includes a similar handleFaultO function as the handleFaultO function 716 in the transaction ⁇ 704 for handling the faulting event 722.
  • the handleFaultO function 716 may propagate or transmit a notification 720 to the remaining work items in the executing state 710 as a function of the execution hierarchy or the execution hierarchical structure of the activity.
  • the handleFaultO function 716 may propagate the notification 720 (e.g., a "throw" function) so that the handleFaultO function of the parent Activity_l 702 may handle it as if the notification 720 is a faulting event or an exception.
  • a child activity may limit the target of the throw function to its parent in the activity tree.
  • exception handling may be highly associated with or tied to the tree like structure of activities.
  • embodiments of the invention enable asynchronous faulting handling or exception handling, and the remaining work items or activities in the executing state 710 continue to be executed.
  • another alternative embodiment enables scheduling of handling faulting events. For example, upon responding to the notification 720, the transaction_2 706 may be placed in a scheduler queue 718 before being transitioned to the faulting state 712.
  • the notification 720 may be suppressed such that other work items or activities in the executing state 710 continue to be executed.
  • the transaction ⁇ 704 transitions to a closed state 714 after propagating or transmitting the notification 720.
  • fault propagation and handling survive and span across passivation cycles.
  • the transaction_3 708 is being executed in the executing state 710.
  • the included operations of the transaction_3 708 insert the texts "(5 and 6") and pause 180 seconds before inserting the text ("END") on the display.
  • the included operations do not include functions for faulting handling.
  • the transaction_3 708 is transitioned to the closed state 714 in FIG. 7E.
  • the transaction_2 706 also transitions to the closed state 714 after being dequeued from the scheduler queue 718 to the faulting state 712.
  • Appendix A illustrates an exemplary implementation of declaratively raising of an exception according to an embodiment of the invention.
  • programmers or developers may design a fault handler for handling a particular type of faulting events or exceptions.
  • work items or activities in the workflow may not include a function or incapable to handle faulting events.
  • the workflow execution environment handles the faulting events.
  • one or more post-fault-handling operations may be provided to the user via the UI 428 to the user 430 in FIG. 4.
  • FIGS. 7A to 7E illustrate snapshots of the executing state or parts of the state automaton sequentially (e.g., transactions are executed sequentially), work items in the executing state may be processed simultaneously or substantially simultaneously without departing from the scope of the invention.
  • FIG. 8 is a flow diagram illustrating a method for asynchronously handling of a faulting event for an activity of a workflow according to an embodiment of the invention.
  • the method illustrated in FIG. 8 may be represented as computer-executable instructions to be stored in a computer-readable medium as shown in FIG. 9.
  • a state machine 902 defines a state automaton (e.g., state automaton 600) for an activity at 802, and the state automaton includes at least an executing state, a faulting state, and a closed state.
  • An activity component 904 defines the activity to include a plurality of work items at 804.
  • the defined activity has an execution hierarchy or an execution sequence (e.g., a tree structure) for the plurality of work items.
  • a scheduler component 906 transitions each of the work items to the executing state at 806.
  • An execution component 908 executes the included operation of transitioned work items in the executing state at 808.
  • an identification component 910 identifies one or more of the transitioned work items in response to the faulting event based on the execution hierarchy and the included operation.
  • a fault handler 912 asynchronously handles the faulting event by invoking a fault handling operation (e.g., the handleFaultQ function 716) in the one or more identified work items to transition the one or more identified work items to the faulting state while executing the included operation of the remaining transitioned work items not identified in response to the faulting event by the identification component.
  • the fault handler 912 asynchronously handles the faulting event by transitioning the one or more identified work items to the faulting state.
  • the fault handler 912 asynchronously handles the faulting event by enqueuing the one or more identified work items in a scheduler queue (e.g., scheduler queue 718).
  • the computer-readable medium 900 further includes a fault propagation component 914 for transmitting a notification from the one or more identified work items to the remaining transitioned work items as a function of the execution hierarchy of the activity.
  • the notification 720 indicates that the identified one or more work items are in the faulting state.
  • the computer- readable medium 900 further includes a transition component 916 for transitioning the remaining transitioned work items from the executing state to the faulting state in response to the transmitted notification.
  • the computer-readable medium may also include a compensation component 918 for recovering or compensating data associated with the activity as a function of the asynchronously handling the faulting event in yet another alternative embodiment.
  • An inhibition component may also be part of the computer-readable medium 900 for suppressing the transmission of the notification to the remaining transitioned work items.
  • Examples of well known computing systems, environments, and/or configurations that may be suitable for use with aspects of the invention include, but are not limited to, personal computers, server computers, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, mobile telephones, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.
  • Embodiments of the invention may be described in the general context of computer-executable instructions, such as program modules, executed by one or more computers or other devices.
  • program modules include, but are not limited to, routines, programs, objects, components, and data structures that perform particular tasks or implement particular abstract data types.
  • aspects of the invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network.
  • program modules may be located in both local and remote computer storage media including memory storage devices.
  • the system 400 executes computer-executable instructions such as those illustrated in the figures, such as FIG. 8, to implement aspects of the invention.
  • the order of execution or performance of the operations in embodiments of the invention illustrated and described herein is not essential, unless otherwise specified. That is, the operations may be performed in any order, unless otherwise specified, and embodiments of the invention may include additional or fewer operations than those disclosed herein. For example, it is contemplated that executing or performing a particular operation before, contemporaneously with, or after another operation is within the scope of aspects of the invention.
  • Embodiments of the invention may be implemented with computer-executable instructions.
  • the computer-executable instructions may be organized into one or more computer-executable components or modules. Aspects of the invention may be implemented with any number and organization of such components or modules. For example, aspects of the invention are not limited to the specific computer-executable instructions or the specific components or modules illustrated in the figures and described herein. Other embodiments of the invention may include different computer-executable instructions or components having more or less functionality than illustrated and described herein.
  • the articles "a,” “an,” “the,” and “said” are intended to mean that there are one or more of the elements.

Abstract

Asynchronous fault handling for a workflow. A state automaton for an activity in the workflow is defined. The state automaton includes at least an executing state, a faulting state, and a closed state and classifies an execution lifetime of the activity. The activity is defined to include work items and includes an execution hierarchy for the work items. Each work item includes an operation for executing a portion of the activity. Each work item is transitioned to the executing state. The included operation of transitioned work items is executed in the executing state. One or more of the transitioned work items are identified in response to the faulting event as a function of the execution hierarchy and the included operation. The faulting event is asynchronously handled by transitioning the one or more identified work items to the faulting state while executing the included operation of the remaining transitioned work items.

Description

ASYNCHRONOUS FAULT HANDLING IN PROCESS-CENTRIC PROGRAMS
BACKGROUND
[0001] Process-oriented or process-centric programs have evolved to enable processing of complex instructions modeling real- world events. Process-centric programs mirror real-world processes and mirror interactions between real-world entities. Existing systems attempt to map business problems to high-level workflows by modeling the business problem. However, real world workflows vary in a variety of dimensions such as (a) execution and modeling complexity, (b) knowledge of the structure of the flow at design time, (c) statically defined or ad-hoc/dynamic, (d) ease of authoring and editing the flow at various points in its lifecycle, and (e) weak or strong association of business logic with the core workflow process. Existing models fail to accommodate all these factors. [0002] Further, most existing workflow models are based on either language-based approaches (e.g., BPEL4WS, XLANG/S, and WSFL) or application based approaches. Language based approaches are high-level workflow languages with a closed set of predefined constructs which help model the workflow process to the user/programmer. The workflow languages carry all of the semantic information for the closed set of constructs to enable the user to build a workflow model. However, the languages are not extensible by the developers and represent a closed set of primitives that constitute the workflow model. The languages are tied to the language compiler shipped by the workflow system vendor. Only the workflow system product vendor may extend the model by extending the language with a new set of constructs in a future version of the product. This often requires upgrading the compiler associated with the language. In addition, the languages usually do not declaratively expose or define functions or operations that can be readily and efficiently used by other programs. [ 0003 ] Application based approaches are applications which have the workflow capabilities within the application to solve a domain specific problem. These applications are not truly extensible nor do they have a programmable model. [0004 ] In addition, with the existing approaches, the issues of complexity, foreknowledge, dynamic workflows, authoring ease, and strength of associations with business logic and core workflows are not adequately addressed. There are no extensible, customizable, and re-hostable workflow designer frameworks available to build visual workflow designers to model different classes of workflows. Existing systems lack a rapid application development (RAD) style workflow design experience which allows users to graphically design the workflow process and associate the business logic in a programming language of developer's choice.
[0005] Also, workflow processes deal with cross cutting orthogonal and tangled concerns that span multiple steps of a workflow process model. For example, while parts of the workflow process are designed to participate in long running transactions, other parts of the same process are designed for concurrent execution or for accessing a shared resource. Due to design shortcomings, existing systems fail to provide interleaving of execution threads which enable users to design synchronous or interleaved execution of activities. Still other portions of the same workflow process require tracking, while other portions handle business or application level exceptions. There is a need to apply certain behaviors to one or more portions of a workflow process.
[0006] Some workflow modeling approaches are impractical as they require a complete flow-based description of an entire business process including all exceptions and human interventions. Some of these approaches provide additional functionality as exceptions arise, while other approaches exclusively employ a constraint-based approach instead of a flow-based approach to modeling a business process. Existing systems implement either the flow-based or constraint-based approach. Such systems are too inflexible to model many common business situations. These systems also lack the capability to asynchronously handle exceptions or cancellations.
SUMMARY
[0007] Embodiments of the invention enable asynchronous fault or exception handling by having a faulting state in a state automaton defining execution lifetime of an activity in the workflow. By having the faulting state, aspects of the invention enable developers or programs to declaratively design programs for exception or fault handling such that portions of the program or the activity may be in fault handling in the faulting state while other portions of the program or the activity may be unaffected by the exception or the faulting event.
[0008] Alternative embodiments of the invention enable propagation or transmission of a notification of fault handling. In yet another alternative embodiment, such propagation or transmission of the notification may be suppressed or inhibited. In addition, a further alternative embodiment responds to input from a user for handling post-faulting or post- exception operations.
[0009] This summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used as an aid in determining the scope of the claimed subject matter. [ 0010 ] Other features will be in part apparent and in part pointed out hereinafter.
BRIEF DESCRIPTION OF THE DRAWINGS [0011] FIG. 1 is a block diagram illustrating an existing programming paradigm. [0012] FIG.2 is an exemplary block diagram illustrating a virtualization of a workflow design framework according to an embodiment of the invention.
[0013] FIG. 3 is an exemplary diagram illustrating an exemplary workflow according to an embodiment of the invention. [0014] FIG. 4 is a diagram illustrating an exemplary computing environment of a system for processing workflow activities according to an embodiment of the invention.
[0015] FIG. 5 is a diagram illustrating a hierarchical structure of a workflow activity according to an embodiment of the invention.
[0016] FIG. 6 is a diagram illustrating an exemplary state automaton describing execution lifetime of an activity according to an embodiment of the invention.
[0017] FIGS. 7 A to 7E are block diagrams illustrating an asynchronous handling of faulting events of a workflow according to an embodiment of the invention.
[0018] FIG. 8 is a flow diagram illustrating a method for asynchronously handling of a faulting event for an activity of a workflow according to an embodiment of the invention. [0019] FIG. 9 is a block diagram illustrating an exemplary computer-readable medium on which aspects of the invention may be stored.
[0020] Appendix A illustrates an exemplary implementation of declaratively raising of an exception according to an embodiment of the invention.
[0021] Corresponding reference characters indicate corresponding parts throughout the drawings.
DETAILED DESCRIPTION
[0022] Referring first to FIG. 1 , a block diagram illustrates an existing programming paradigm for designing programs for process-centric activities, such as a workflow. For example, the diagram shows a three-level virtualization model of existing program paradigm with a level of a managed execution environment being the highest level and a processing unit being the lowest level. In this programming design system, even at the managed execution environment level, programs, especially process-centric programs handling workflow processes, lack the ability and efficiency to accommodate complex interactions between, processes in a workflow.
[ 0023 ] It is known by those skilled in the art that certain constraints are associated with designing software or application programs. In this example, in writing an operating system software program 104, the programming codes or routines are dependent on the type or configuration of processing units 102, being specific to the type of computing architecture (e.g., IBM® compatible, APPLE® computers, or other systems), or other constraints. In addition, programming languages typically need to accurately identify and utilize data structures such as stacks, heap, thread base, or other hardware-specific structures for the operating system 104 to function properly. [0024] In dealing with complex workflow processes, existing applications use a concept of a managed execution environment 106 (e.g., a runtime environment where programs may share functions or common object-oriented classes) in which programs written one programming language may call functions in other programs written in a different programming language. In such execution environment, these programs in different programming languages are compiled to an intermediate language such that the managed execution environment 106 may expose parameters, arguments, or schemas or functions to the different programs so that the programs may interact with one another. [0025] While this execution environment 106 creates a common communication environment between programs, the execution environment 106 includes various strict requirements that may not be suitable for handling the complexity and capability of process-centric programs. For example, the execution environment 106 requires programs be confirmed to a specific file format. The execution environment 106 also requires that functions or operations in the programs use a fixed set of functions or a class of functions defined by the execution environment 106.
[0026] Embodiments of the invention build on an extensible foundation or framework 202 in FIG. 2 to overcome the shortcomings of existing programming model. By allowing programs written in any programming language and composed in any file format, aspects of the invention enable program developers to design programs with specific functions without compromising its functionalities and specifics. By defining activities, such as workflow tasks or processes, as the base class to be executed in the workflow framework, developers can easily and efficiently build domain specific (e.g., specific execution environments such as programs in the healthcare industrial, financial industry, or the like) operation codes (hereinafter "op-code") without adhering to the rigid, hard-coded, inflexible, and the fixed set of functions or activities classes in the existing execution environment. In addition, the workflow foundation embodying aspects of the invention is a continuation based runtime layered on top of any existing framework (e.g., either a managed execution environment, operating system environment, or hardware processing unit level).
[0027] Aspects of the invention free the constraint of defining activities in a particular file format by enabling workflow designs in any fashion or representation (e.g., a flow chart, a diagram, a numbered description, or the like) as long as activities in the workflow can be constructed from the representation of the workflow designs. [0028] In addition, the workflow framework or foundation is able to handle fault or exception raised from a lower level (e.g., OS) or exception raising functions written in other formats (e.g., intermediate language). [0029] FIG. 3 illustrates a simplistic view of a workflow 300 according to an embodiment of the invention. For example, the workflow 300 may be a workflow for processing a purchase order, and this purchase order workflow 300 may include processes or activities such as receive a purchase order, send confirmation to a customer, approve the purchase order by a manager, or the like.
[0030] The workflow 300 may start from a starting point 302. For example, the starting point 302 for a purchase-order workflow may be receiving an order from a customer. The workflow 300 may also include a conditional statement 304 (such as an "IF statement" or a "WHILE statement"), and it can be subdivided into additional conditional statements 306 and 308. The workflow 300 may also include a parallel structure 310, which further includes one or more sequences or activities 312. For example, the parallel structure 310 includes activities, such as checking the inventory and updating the available shippers, be processed in parallel. In the example shown, activities such as "Send E-mail" and "Get Approval" may be processed in parallel. At "drop activities here" 316, a user may further add or supplement more activities into the workflow 300. To complete the workflow 300, the processes or activities will conclude in a complete step or point 314. [0031] In one embodiment, the activities may be arranged hierarchically in a tree structure (see FIG. 5) 500 or other execution sequences. For example, an activity may be a composite activity in which the activity includes more than one work item associated therewith. In another embodiment, a collection of activities may be a composite activity. An activity method or operation may be in a root node 502 with two children or leaf nodes 504 and 506. The activity methods or operations in the children nodes 504 and 506 (e.g., work item_l and work item_2, respectively) may be executed according to the hierarchical structure. In addition, the children nodes 504 and 506 may also include other children nodes having respective work items to be executed. [0032 ] In another embodiment, activities include one or more of the following types: a simple activity, container activity and root activity. In this embodiment, there is one root activity in the model, and none or any quantity of simple activities or container activities inside the root activity. A container activity may include simple or container activities. The entire workflow process may be used as an activity to build higher-order workflow processes. Further, an activity may be interruptible or non-interruptible. A non- interruptible composite activity does not include interruptible activities. A non- interruptible activity lacks services that would cause the activity to block. [ 0033 ] Moreover, in executing activities and the work items included in the activities, the workflow framework or an execution context or environment defines a scope or boundary for each of the work items. This scope or boundary includes and exposes information (e.g., in the form of data, metadata, or the like) such as the shared data or resources to be accessed by the work items, associated properties, handlers, constraints and interactions between autonomous agents. Also, each activity may be configured by a user code in any programming language. For example, the user code may represent business or application logic or rules written in a specific domain or execution environment. Each activity may support pre-interception hooks and post-interception hooks into execution in the user code. Each activity has associated runtime execution semantics and behavior (e.g., state management, transactions, event handling and exception handling). Activities may share state or resources with other activities. In addition, activities may be primitive activities or grouped into a composite activity. A primitive or basic activity has no substructure (e.g., child activities), and thus is a leaf node in a tree structure. A composite activity contains substructure (e.g., it is the parent of one or more child activities). [0034 ] FIG. 4 is a diagram illustrating a system 400 for processing workflow activities according to an embodiment of the invention. The system 400 includes a processor 402, which may be a processing unit or a collection of processing units. The system 400 also includes a storage or memory area 404 for storing data accessible by the processor 402. In one embodiment, the system 400 may be a computer having one or more processors or processing units (e.g., processor 402) and a system memory (e.g., memory area 404) having other components to couple various system components including the system memory to the processor 402. [0035 ] In one example, the memory area 404 may include computer readable media, either volatile, nonvolatile, removable, or non-removable media, implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. For example, computer storage media include RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disks (DVD) or other optical disk storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, or any other medium that may be used to store the desired information and that may be accessed by the system 400. The memory 404 may also include communication media embodying computer readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism and include any information delivery media. Those skilled in the art are familiar with the modulated data signal, which has one or more of its characteristics set or changed in such a manner as to encode information in the signal. Wired media, such as a wired network or direct-wired connection, and wireless media, such as acoustic, RF, infrared, and other wireless media, are examples of communication media. Combinations of any of the above are also included within the scope of computer readable media. [0036] For example, the memory area 404 stores a plurality of activities 406 for processing in a workflow (e.g., the workflow 300). Each of the plurality of activities 406 includes one or more work items, and the work items may be organized in a hierarchical structure such as a tree structure (see FIG. 5). In processing the plurality of activities 406, the processor 402 accesses or executes a scheduler 408, which is configured to set up an organized set of activities.
[0037] For example, the processor 408 accesses the work items in the plurality of activities 406 via a component or a set of computer-executable instructions such as the scheduler 408 to enqueue or to store the work items 422 to a queue 410. A dispatcher 412, accessible by the processor 402, dispatches the work items 422 for execution. For example, a work item 422-1 may include an activity method or an activity operation 424, routine, or a collection of codes for performing a function of "requesting input from a user". One or more other activity methods, activity operations, routines, or codes may be included in each of the work items 422 without departing from the scope of the invention. [0038] Once the work items 422 are dispatched by the dispatcher 412, the processor 402 executes each of the methods 424 in the work items 422 at 414. In the example of work item 422-1, the processor 402 may provide a user via a user interface (UI) to input the requested information or data. In another embodiment, the processor 402 may connect to or access an external data source for requesting input from the user. Upon completion of the activity method or activity operation 424, the processor 402 concludes execution of the work items 422 at 416. In one embodiment, the processor 402 passivates the executing state of work items at 418 to a data store 420.
[0039] In another embodiment, the processor 402 executes the work items 422 according to a state automaton, such as the automaton shown in FIG. 6, which is a diagram illustrating an exemplary state automaton 600 describing processing states of work items associated with an activity according to an embodiment of the invention. In one embodiment, the state automaton 600 defines an execution lifetime of an activity. In one example, the state automaton 600 may include an initialized state, an executing state, and a closed state (as shown in FIG.4). In another embodiment, the state automaton 600 includes an initialized state 602, an executing state 604, a canceling state 606, a faulting state 608, a compensating state 610, and a closed state 612.
[0040] For example, the state automaton 600 describes a process flow of execution of work items (e.g., work items 422) in a workflow activity. The work item 422-1, as illustrated in FIG. 4, is first initialized when it is enqueued in the queue 410. The work item 422-1 is next dequeued or removed from the queue 410 to the dispatcher 412 before being executed in the executing state (e.g., the executing state 604 in FIG. 6). Depending on the parameters or conditions during the execution of the work item 422-1, the work item 422-1 may proceed to the canceling state 606 (e.g., the canceling state 426 in FIG. 4) or the faulting state 608. In one embodiment, the work item 422-1 may proceed from the canceling state 606 to the faulting state 608. Li an alternative embodiment, the compensating state 610 describes a set of operations or functions to be performed when faulting or exception has occurred.
[0041] For example, suppose an exception occurs during the execution of a work item, (e.g., work item 422-1), such as a parameter for a function is missing. The system 400 transitions the work item 422-1 to the faulting state 608. In doing so, the system 400 also performs garbage collection (e.g., removing previously executed portion of the operations from cache or memory, reset parameter values, or the like) operations in the compensating state 610 before transitioning the work item 422-1 to the closed state 612. For example, work items in the compensating state 610 may trigger operations such as recovering data that was previously used for executing other work items. The closed state 612 indicates that the execution of the activity (e.g., activity 500 in FIG. 5) has completed. [0042] In one embodiment, the state automaton 600 establishes relationship between work items in a composite activity. For example, one of the relationship rules may include that, before transitioning to the closed state 612 methods or work items in the root node of the activity tree, all of the work items in the children nodes should be in the initialized state 602 or the closed state 612. Another rule may require that, in order to transition the work items in the children node of the activity tree to the executing state 604, the work item in the root node must already be in the executing state 604. [0043] In another embodiment, one or more additional states may be defined in the state automaton 600 without departing from the scope of embodiments of the invention. [0044] Referring next to FIGS. 7 A and 7E, block diagrams illustrate asynchronous handling of faulting events in a workflow according to an embodiment of the invention. For simplistic purposes only and without limitations, FIG. 7A shows a composite activity 702 which includes three children work items organized in a tree structure: transaction_l 704, transaction_2 706, and transaction_3 708. As illustrated, the root activity 702 includes a method to "write text on display." Activity methods or operations for the work items above also include the following: transaction_l 704: { INSERT TEXT ("1 AND 2");
HANDLEFAULTO;
} transaction_2 706: { INSERT TEXT ("3 AND 4"); HANDLEFAULTO; } transaction_3 708:
{ INSERT TEXT("5 AND 6");
PAUSE 180 SECONDS; INSERT TEXT ("END");
}
[ 0045 ] In FIG. 7B, the transaction^ 704, the transaction_2 706, and the transaction_3 708 are transitioned to the executing state 710. As illustrated, the transaction^ 704 executes the included operations by inserting texts ("1 and 2") on the display (e.g., a user interface 428) to a user 430.
[0046] While in the executing state 710, a faulting event 722 or an exception has occurred. The faulting event 722 may include a warning notification for missing data, an execution fault, an inaccurate access to a data store, or the like. In this example, the transaction_l 704 includes a handleFaultQ function 716 for handling the faulting event 722. In one embodiment, the handleFault function 716 resembles a "catch" function for fault handling in other execution environments, such as an operating system or a managed execution environment. As such, the fault propagation or dispatch to the handleFault function 716 or the "catch" handler is asynchronous. [0047] Upon the occurrence of the faulting event 722, the transaction_l 704 transitions to a faulting state 712, and the transaction_l 704 is transitioned to a closed state 714. In one embodiment, in responding to the faulting event 722, the handleFault() function 716 is called and is placed in a queue (not shown) for processing.
[0048] With this well-defined protocol for exception propagation and handling, alternative embodiments may handle multiple exceptions, and multiple exceptions may be scheduled while the propagation of exceptions may be interleaved with the normal program execution.
[0049] In FIG. 7C, the transaction_2 706 and the transaction 708 are in the executing state 710. Similar to executing the transaction_l 704, the transaction_2 706 executes the included operations. In this example, the texts ("3 and 4") are inserted on the display. In addition, the transaction_2 706 also includes a similar handleFaultO function as the handleFaultO function 716 in the transaction^ 704 for handling the faulting event 722. [0050] In an alternative embodiment, the handleFaultO function 716 may propagate or transmit a notification 720 to the remaining work items in the executing state 710 as a function of the execution hierarchy or the execution hierarchical structure of the activity. For example, while the transaction^ 704 is in faulting state 712, the handleFaultO function 716 may propagate the notification 720 (e.g., a "throw" function) so that the handleFaultO function of the parent Activity_l 702 may handle it as if the notification 720 is a faulting event or an exception. In one embodiment, a child activity may limit the target of the throw function to its parent in the activity tree. In another embodiment, exception handling may be highly associated with or tied to the tree like structure of activities.
[0051 ] By establishing the faulting state 712 for handling faulting events, embodiments of the invention enable asynchronous faulting handling or exception handling, and the remaining work items or activities in the executing state 710 continue to be executed. In addition, another alternative embodiment enables scheduling of handling faulting events. For example, upon responding to the notification 720, the transaction_2 706 may be placed in a scheduler queue 718 before being transitioned to the faulting state 712. In another embodiment, the notification 720 may be suppressed such that other work items or activities in the executing state 710 continue to be executed. In one embodiment, the transaction^ 704 transitions to a closed state 714 after propagating or transmitting the notification 720. In yet another embodiment, fault propagation and handling survive and span across passivation cycles.
[0052] In FIG. 7D, the transaction_3 708 is being executed in the executing state 710. For example, the included operations of the transaction_3 708 insert the texts "(5 and 6") and pause 180 seconds before inserting the text ("END") on the display. The included operations, however, do not include functions for faulting handling. As such, upon completion of the included operations, the transaction_3 708 is transitioned to the closed state 714 in FIG. 7E. In addition, the transaction_2 706 also transitions to the closed state 714 after being dequeued from the scheduler queue 718 to the faulting state 712.
[ 0053 ] Without limitations, Appendix A illustrates an exemplary implementation of declaratively raising of an exception according to an embodiment of the invention. In one embodiment, programmers or developers may design a fault handler for handling a particular type of faulting events or exceptions. In yet another embodiment, work items or activities in the workflow may not include a function or incapable to handle faulting events. In this embodiment, the workflow execution environment handles the faulting events. In yet another embodiment, one or more post-fault-handling operations may be provided to the user via the UI 428 to the user 430 in FIG. 4. [0054 ] While FIGS. 7A to 7E illustrate snapshots of the executing state or parts of the state automaton sequentially (e.g., transactions are executed sequentially), work items in the executing state may be processed simultaneously or substantially simultaneously without departing from the scope of the invention.
[0055] FIG. 8 is a flow diagram illustrating a method for asynchronously handling of a faulting event for an activity of a workflow according to an embodiment of the invention. For example, the method illustrated in FIG. 8 may be represented as computer-executable instructions to be stored in a computer-readable medium as shown in FIG. 9. For example, a state machine 902 defines a state automaton (e.g., state automaton 600) for an activity at 802, and the state automaton includes at least an executing state, a faulting state, and a closed state. An activity component 904 defines the activity to include a plurality of work items at 804. The defined activity has an execution hierarchy or an execution sequence (e.g., a tree structure) for the plurality of work items. Each of the work items including an operation for executing a portion of the activity. to 056] A scheduler component 906 transitions each of the work items to the executing state at 806. An execution component 908 executes the included operation of transitioned work items in the executing state at 808. At 810, an identification component 910 identifies one or more of the transitioned work items in response to the faulting event based on the execution hierarchy and the included operation. At 812, a fault handler 912 asynchronously handles the faulting event by invoking a fault handling operation (e.g., the handleFaultQ function 716) in the one or more identified work items to transition the one or more identified work items to the faulting state while executing the included operation of the remaining transitioned work items not identified in response to the faulting event by the identification component. In one embodiment, the fault handler 912 asynchronously handles the faulting event by transitioning the one or more identified work items to the faulting state. In yet another embodiment, the fault handler 912 asynchronously handles the faulting event by enqueuing the one or more identified work items in a scheduler queue (e.g., scheduler queue 718).
[0057] In an alternative embodiment, the computer-readable medium 900 further includes a fault propagation component 914 for transmitting a notification from the one or more identified work items to the remaining transitioned work items as a function of the execution hierarchy of the activity. The notification 720 indicates that the identified one or more work items are in the faulting state. In a further embodiment, the computer- readable medium 900 further includes a transition component 916 for transitioning the remaining transitioned work items from the executing state to the faulting state in response to the transmitted notification. [0058] The computer-readable medium may also include a compensation component 918 for recovering or compensating data associated with the activity as a function of the asynchronously handling the faulting event in yet another alternative embodiment. An inhibition component may also be part of the computer-readable medium 900 for suppressing the transmission of the notification to the remaining transitioned work items. [0059] Although described in connection with an exemplary computing system environment, such as the system 400 in FIG. 4, embodiments of the invention are operational with numerous other general purpose or special purpose computing system environments or configurations. The computing system environment is not intended to suggest any limitation as to the scope of use or functionality of any aspect of the invention. Moreover, the computing system environment should not be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the exemplary operating environment. Examples of well known computing systems, environments, and/or configurations that may be suitable for use with aspects of the invention include, but are not limited to, personal computers, server computers, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, mobile telephones, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like. [0060] Embodiments of the invention may be described in the general context of computer-executable instructions, such as program modules, executed by one or more computers or other devices. Generally, program modules include, but are not limited to, routines, programs, objects, components, and data structures that perform particular tasks or implement particular abstract data types. Aspects of the invention may also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote computer storage media including memory storage devices.
[0061] In operation, the system 400 executes computer-executable instructions such as those illustrated in the figures, such as FIG. 8, to implement aspects of the invention. [ 0062 ] The order of execution or performance of the operations in embodiments of the invention illustrated and described herein is not essential, unless otherwise specified. That is, the operations may be performed in any order, unless otherwise specified, and embodiments of the invention may include additional or fewer operations than those disclosed herein. For example, it is contemplated that executing or performing a particular operation before, contemporaneously with, or after another operation is within the scope of aspects of the invention.
[0063] Embodiments of the invention may be implemented with computer-executable instructions. The computer-executable instructions may be organized into one or more computer-executable components or modules. Aspects of the invention may be implemented with any number and organization of such components or modules. For example, aspects of the invention are not limited to the specific computer-executable instructions or the specific components or modules illustrated in the figures and described herein. Other embodiments of the invention may include different computer-executable instructions or components having more or less functionality than illustrated and described herein. [0064] When introducing elements of aspects of the invention or the embodiments thereof, the articles "a," "an," "the," and "said" are intended to mean that there are one or more of the elements. The terms "comprising," "including," and "having" are intended to be inclusive and mean that there may be additional elements other than the listed elements. [0065] Having described aspects of the invention in detail, it will be apparent that modifications and variations are possible without departing from the scope of aspects of the invention as defined in the appended claims. As various changes could be made in the above constructions, products, and methods without departing from the scope of aspects of the invention, it is intended that all matter contained in the above description and shown in the accompanying drawings shall be interpreted as illustrative and not in a limiting sense.
APPENDIX A
[0066] <myActivities:Sequence x:Name="myWorkflow" x :Class="myApp .my Workflow" xmlns:myActivities="http://schemas.com/myActivities" xmlns:x="http://schemas.microsoft.com/winβc/2006/xainrι xmlns="http://schemas.microsofl.com/winfx/2006/xaml/workflow"> <myActivities:WriteLme Text="One"/> <myActivities:WriteLine Text="Two"/>
<Throw Activity FaultType="{x:Type InvalidOperationException}"/> <myActivities:WriteLine Text="Unreachable code"/>
<FaultHandlersActivity>
<FaultHandler Activity FaultType=" {x:Type InvalidOperationException} ">
<myActivities: WriteLine Text="Three"/> </FaultHandlerActivity>
<FaultHandlerActivity FaultType=" {x:Type AppDomainUnloadedException} ">
<myActivities:WriteLine Text="Four'7> </FaultHandlerActivity> </FaultHandlersActivity>
</myActivities:Sequence>
<myActivities:Sequence x:Name="myWorkflow" x:Class="myApρ.myWorkflow" xmlns:myActivities="http://schemas.com/myActivities" xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml" xmlns="http ://schemas.πiicrosofi.coπ]/wiπix/2006/xaml/workflow"> <myActivities:WriteLine Text=Ηello World"/> <Throw Activity FaultType=" {x:Type InvalidOperationException}" /> <myActivities:WriteLine Text="Unreachable Code"/> </my Activities : Sequence>

Claims

CLAIMSWhat is claimed is:
1. A method for asynchronous handling a faulting event (722) for an activity of a workflow, said method comprising: defining a state automaton (600) for an activity (702), said state automaton (600) including at least an executing state (604), a faulting state (608), and a closed state (612), said state automaton (600) classifying an execution lifetime of the activity (702); defining the activity (702) to include a plurality of work items (422), said defined activity (702) having an execution hierarchy (500) for the plurality of work items (422), each of the work items (422) including an operation for executing a portion of the activity (702); transitioning each of the work items (422) to the executing state (604); executing the included operation of transitioned work items (422) in the executing state (604); identifying one or more of the transitioned work items in response to the faulting event (722) as a function of the execution hierarchy (500) and the included operation; and asynchronously handling the faulting event (722) by transitioning the one or more identified work items (422) to the faulting state (608) while executing the included operation of the remaining transitioned work items not identified in response to the faulting event (608).
2. The method of claim 1, wherein asynchronously handling the faulting event (722) comprises invoking a fault handling operation in the one or more identified work items (422).
3. The method of claim 2, wherein invoking the fault handling operation comprises enqueuing the one or more identified work items in a scheduler queue (718).
4. The method of claim 1, further comprising propagating a notification (720) from the one or more identified work items (422) to the remaining transitioned work items (422) as a function of the execution hierarchy (500) of the activity (702), said notification (720) indicating that the identified one or more work items (422) being in the faulting state (608).
5. The method of claim 4, further comprising transitioning the remaining transitioned work items (422) from the executing state (604) to the faulting state (608) in response to the propagated notification (720).
6. The method of claim.4, further comprising suppressing the propagation of the notification (720) to the remaining transitioned work items (422).
7. The method of claim 1, further comprising providing operations to a user for post- faulting handling in response to the one or more identified work items (422) being transitioned to the faulting state (608).
8. The method of claim 1, wherein one or more computer-readable media have computer- executable instructions for performing the method of claim 1.
9. A system (400) for asynchronously handling faulting events (722) in a workflow, said system (400) comprising: a storage (404) for storing data associated with work items of an activity (406) in the workflow, said activity (406) having an execution hierarchy (500) for the work items (422), each of the work items (422) including an operation for executing a portion of the activity (406); a processor (402) configured to executing computer-executable instructions for: defining a state automaton (600) for the activity (406), said state automaton (600) including at least an executing state (604), a faulting state (608), and a closed state (612), said state automaton (600) classifying an execution lifetime of the activity (406); transitioning each of the work items (422) to the executing state (604); executing the included operation of transitioned work items (422) in the executing state (604); identifying one or more of the transitioned work items (422) in response to a faulting event (608) based on the execution hierarchy (500) and the included operation; and asynchronously handling the faulting event (722) by transitioning the one or more identified work items (422) to the faulting state (608) while executing the included operation of the remaining transitioned work items (422) not identified in response to the faulting event (722).
10. The system (400) of claim 9, wherein the processor (402) is configured to asynchronously handle the faulting event (722) using one or more of the following method: by invoking a fault handling operation in the one or more identified work items (422), and by enqueuing the one or more identified work items (422) in a scheduler queue (718).
11. The system (600) of claim 9, further comprising a component for propagating a notification (720) from the one or more identified work items to the remaining transitioned work items (422) as a function of the execution hierarchy (500) of the activity (406), said notification (720) indicating that the identified one or more work items (422) being in the faulting state (608).
12. The system (400) of claim 11, further comprising a component for transitioning the remaining transitioned work items from the executing state (604) to the faulting state (608) in response to the propagated notification (720).
13. The system (400) of claim 9, further comprising a component for compensating for . recovering data associated with the activity from the storage (404) as a function of the asynchronously handling the faulting event (722) by the processor (402).
14. The system (400) of claim 9, further comprising a component for suppressing the propagation of the notification (720) to the remaining transitioned work items (422).
15. One or more computer-readable media (900) having computer-executable components for asynchronously handling a faulting event (722) in a workflow, said computer- executable components comprising: a state machine (902) for defining a state automaton (600) for an activity (406), said state automaton (600) including at least an executing state (604), a faulting state (608), and a closed state (612), said state automaton (600) classifying an execution lifetime of the activity (406); an activity component (904) for defining the activity (406) to include a plurality of work items (422), said defined activity (406) having an execution hierarchy (500) for the plurality of work items (422), each of the work items (422) including an operation for executing a portion of the activity (406); a scheduler component (906) for transitioning each of the work items (422) to the executing state (604); an execution component (908) for executing the included operation of transitioned work items (422) in the executing state (604); an identification component (910) for identifying one or more of the transitioned work items in response to the faulting event (722) based on the execution hierarchy (500) and the included operation; and a fault handler (912) for asynchronously handling the faulting event (722) by invoking a fault handling operation in the one or more identified work items (422) to transition the one or more identified work items (422) to the faulting state (60S) while executing the included operation of the remaining transitioned work items (422) not identified in response to the faulting event (722) by the identification component (910).
16. The computer-readable media (900) of claim 15, wherein the fault handler (912) enqueues the one or more identified work items (422) in a scheduler queue (718) to transition the one or more identified work items to the faulting state (608).
17. The computer-readable media (900) of claim 15, further comprising a fault propagation component (914) for transmitting a notification (720) from the one or more identified work items (422) to the remaining transitioned work items (422) as a function of the execution hierarchy (500) of the activity (406), said notification (720) indicating that the identified one or more work items (422) being in the faulting state (608).
18. The computer-readable media (900) of claim 17, further comprising a transition component (916) for transitioning the remaining transitioned work items from the executing state (604) to the faulting state (608) in response to the transmitted notification (720).
19. The computer-readable media (900) of claim 15, further comprising a compensation component (918) for recovering data associated with the activity (406) as a function of the asynchronously handling the faulting event (608).
20. The computer-readable media (900) of claim 15, further comprising an inhibition component (920) for suppressing the transmission of the notification (720) to the remaining transitioned work items.
PCT/US2007/004642 2006-03-30 2007-02-21 Asynchronous fault handling in process-centric programs WO2007120391A1 (en)

Priority Applications (6)

Application Number Priority Date Filing Date Title
EP07751408A EP2013716A4 (en) 2006-03-30 2007-02-21 Asynchronous fault handling in process-centric programs
CN2007800123531A CN101416156B (en) 2006-03-30 2007-02-21 Method and system of asynchronous fault handling in process-centric programs
BRPI0708917-1A BRPI0708917A2 (en) 2006-03-30 2007-02-21 asynchronous failure handling in process-centric programs
CA002644370A CA2644370A1 (en) 2006-03-30 2007-02-21 Asynchronous fault handling in process-centric programs
MX2008011910A MX2008011910A (en) 2006-03-30 2007-02-21 Asynchronous fault handling in process-centric programs.
JP2009502791A JP5297370B2 (en) 2006-03-30 2007-02-21 Asynchronous fault handling in process-centric programs

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US11/393,093 US7739135B2 (en) 2006-03-30 2006-03-30 Asynchronous fault handling in process-centric programs
US11/393,093 2006-03-30

Publications (1)

Publication Number Publication Date
WO2007120391A1 true WO2007120391A1 (en) 2007-10-25

Family

ID=38560925

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/US2007/004642 WO2007120391A1 (en) 2006-03-30 2007-02-21 Asynchronous fault handling in process-centric programs

Country Status (10)

Country Link
US (1) US7739135B2 (en)
EP (1) EP2013716A4 (en)
JP (1) JP5297370B2 (en)
KR (1) KR20080106567A (en)
CN (1) CN101416156B (en)
BR (1) BRPI0708917A2 (en)
CA (1) CA2644370A1 (en)
MX (1) MX2008011910A (en)
RU (1) RU2008138701A (en)
WO (1) WO2007120391A1 (en)

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8849691B2 (en) 2005-12-29 2014-09-30 Microsoft Corporation Modeling user input and interaction in workflow based applications
US20080082960A1 (en) * 2006-09-29 2008-04-03 Mcdougal Monty D Method and System For Controlling The Release of Data For Multiple-Level Security Systems
US8145335B2 (en) * 2006-12-19 2012-03-27 Palo Alto Research Center Incorporated Exception handling
US9442620B2 (en) * 2007-08-21 2016-09-13 Oracle International Corporation Navigation systems with event notification
US7827127B2 (en) * 2007-10-26 2010-11-02 Microsoft Corporation Data scoping and data flow in a continuation based runtime
US9354847B2 (en) 2008-12-29 2016-05-31 Microsoft Technology Licensing, Llc Interface infrastructure for a continuation based runtime
US8307368B2 (en) * 2009-05-26 2012-11-06 Microsoft Corporation Locality-based scheduling in continuation-based runtimes
US9536264B2 (en) 2011-11-14 2017-01-03 Microsoft Technology Licensing, Llc Host agnostic messaging in a continuation based runtime
US9170915B1 (en) 2011-12-06 2015-10-27 Amazon Technologies, Inc. Replay to reconstruct program state
US9152533B1 (en) 2011-12-06 2015-10-06 Amazon Technologies, Inc. Asynchronous programming system
US9015533B1 (en) * 2011-12-06 2015-04-21 Amazon Technologies, Inc. Error handling for asynchronous applications
US8996937B2 (en) * 2011-12-28 2015-03-31 Stmicroelectronics International N.V. Apparatus for monitoring operating conditions of a logic circuit
US10235209B2 (en) * 2015-08-28 2019-03-19 Vmware, Inc. Hybrid task framework
US10324783B1 (en) * 2016-09-01 2019-06-18 Servicenow, Inc. System and method for workflow error handling

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0697652A1 (en) * 1994-08-16 1996-02-21 International Business Machines Corporation Method for re-executing a process on a computer system for fault correction
US20040153350A1 (en) * 2003-01-31 2004-08-05 Handysoft Corporation System and method of executing and controlling workflow processes
US20050193286A1 (en) * 2000-04-28 2005-09-01 Microsoft Corporation Compensation framework for long running transactions

Family Cites Families (110)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4697266A (en) * 1983-03-14 1987-09-29 Unisys Corp. Asynchronous checkpointing system for error recovery
US5287537A (en) * 1985-11-15 1994-02-15 Data General Corporation Distributed processing system having plural computers each using identical retaining information to identify another computer for executing a received command
US4920483A (en) * 1985-11-15 1990-04-24 Data General Corporation A computer memory for accessing any word-sized group of contiguous bits
US5301320A (en) * 1991-06-28 1994-04-05 Digital Equipment Corporation Workflow management and control system
JPH09501517A (en) * 1993-02-08 1997-02-10 アクション・テクノロジーズ・インコーポレーテッド Method and apparatus for managing business processes
US5734837A (en) * 1994-01-14 1998-03-31 Action Technologies, Inc. Method and apparatus for building business process applications in terms of its workflows
US5627981A (en) * 1994-07-01 1997-05-06 Digital Equipment Corporation Software mechanism for accurately handling exceptions generated by instructions scheduled speculatively due to branch elimination
US5634127A (en) * 1994-11-30 1997-05-27 International Business Machines Corporation Methods and apparatus for implementing a message driven processor in a client-server environment
JP3547215B2 (en) * 1995-01-20 2004-07-28 富士通株式会社 Transmission fault handling device
US5774661A (en) * 1995-04-18 1998-06-30 Network Imaging Corporation Rule engine interface for a visual workflow builder
DE19712946A1 (en) * 1996-05-30 1997-12-04 Ibm Computerised method of automatically expanding specifications of process model in workflow process environment
US5930512A (en) * 1996-10-18 1999-07-27 International Business Machines Corporation Method and apparatus for building and running workflow process models using a hypertext markup language
US6158044A (en) * 1997-05-21 2000-12-05 Epropose, Inc. Proposal based architecture system
US6016394A (en) * 1997-09-17 2000-01-18 Tenfold Corporation Method and system for database application software creation requiring minimal programming
US6807583B2 (en) * 1997-09-24 2004-10-19 Carleton University Method of determining causal connections between events recorded during process execution
US6621505B1 (en) * 1997-09-30 2003-09-16 Journee Software Corp. Dynamic process-based enterprise computing system and method
US6225998B1 (en) * 1997-12-02 2001-05-01 Aspect Communications Visual design of workflows for transaction processing
US6115646A (en) * 1997-12-18 2000-09-05 Nortel Networks Limited Dynamic and generic process automation system
US6078982A (en) * 1998-03-24 2000-06-20 Hewlett-Packard Company Pre-locking scheme for allowing consistent and concurrent workflow process execution in a workflow management system
US6560626B1 (en) * 1998-04-02 2003-05-06 Microsoft Corporation Thread interruption with minimal resource usage using an asynchronous procedure call
US6430538B1 (en) 1998-04-30 2002-08-06 Enterworks Workflow management system, method and medium with personal subflows
US6567783B1 (en) * 1998-06-05 2003-05-20 I2 Technologies Us, Inc. Communication across one or more enterprise boundaries regarding the occurrence of a workflow event
US6397192B1 (en) * 1998-06-05 2002-05-28 I2 Technologies Us, Inc. Synchronizing one or more workflows using one or more synchronization-join activities that include synchronization logic
WO2000014618A2 (en) * 1998-08-24 2000-03-16 Fujitsu Limited Workflow system and method
US6606740B1 (en) * 1998-10-05 2003-08-12 American Management Systems, Inc. Development framework for case and workflow systems
US6308318B2 (en) * 1998-10-07 2001-10-23 Hewlett-Packard Company Method and apparatus for handling asynchronous exceptions in a dynamic translation system
US7133833B1 (en) 1998-10-27 2006-11-07 Netscape Communications Corporation Lightweight directory access protocol workflow management system
US6411961B1 (en) * 1999-01-15 2002-06-25 Metaedge Corporation Apparatus for providing a reverse star schema data model
US7233952B1 (en) 1999-01-15 2007-06-19 Hon Hai Precision Industry, Ltd. Apparatus for visualizing information in a data warehousing environment
US6412109B1 (en) * 1999-01-29 2002-06-25 Sun Microsystems, Inc. Method for optimizing java bytecodes in the presence of try-catch blocks
US6678882B1 (en) * 1999-06-30 2004-01-13 Qwest Communications International Inc. Collaborative model for software systems with synchronization submodel with merge feature, automatic conflict resolution and isolation of potential changes for reuse
US6633878B1 (en) * 1999-07-30 2003-10-14 Accenture Llp Initializing an ecommerce database framework
US6609128B1 (en) * 1999-07-30 2003-08-19 Accenture Llp Codes table framework design in an E-commerce architecture
US7100195B1 (en) 1999-07-30 2006-08-29 Accenture Llp Managing user information on an e-commerce system
US6405364B1 (en) * 1999-08-31 2002-06-11 Accenture Llp Building techniques in a development architecture framework
CA2281331A1 (en) * 1999-09-03 2001-03-03 Cognos Incorporated Database management system
US7020697B1 (en) * 1999-10-01 2006-03-28 Accenture Llp Architectures for netcentric computing systems
JP3825597B2 (en) * 1999-11-18 2006-09-27 日本電信電話株式会社 Content display frequency control method, apparatus, and program recording medium thereof
US6898790B1 (en) * 1999-12-06 2005-05-24 International Business Machines Corporation Mapping actions to tasks within customer service processing systems
WO2001063446A2 (en) * 2000-02-25 2001-08-30 Ocwen Technology Xchange, Inc. Method for workflow processing through computer network
EP1277104A1 (en) 2000-03-30 2003-01-22 Ideogramic APS Method for gesture based modeling
US6964034B1 (en) * 2000-04-20 2005-11-08 International Business Machines Corporation Application development server and a mechanism for providing different views into the same constructs within a strongly encapsulated environment
US6845507B2 (en) * 2000-05-18 2005-01-18 Ss & C Technologies, Inc. Method and system for straight through processing
US6971096B1 (en) * 2000-05-19 2005-11-29 Sun Microsystems, Inc. Transaction data structure for process communications among network-distributed applications
WO2002003225A2 (en) * 2000-06-15 2002-01-10 Xis Incorporated Method and system for product lifecycle management
US6708186B1 (en) * 2000-08-14 2004-03-16 Oracle International Corporation Aggregating and manipulating dictionary metadata in a database system
WO2002017652A2 (en) * 2000-08-22 2002-02-28 Symbian Limited Database for use with a wireless information device
US20020032692A1 (en) * 2000-09-08 2002-03-14 Atsuhito Suzuki Workflow management method and workflow management system of controlling workflow process
US6886094B1 (en) * 2000-09-28 2005-04-26 International Business Machines Corporation Apparatus and method for detecting and handling exceptions
US7555459B2 (en) * 2000-10-02 2009-06-30 International Projects Consultancy Services, Inc. Automated loan processing system and method
US6604104B1 (en) * 2000-10-02 2003-08-05 Sbi Scient Inc. System and process for managing data within an operational data store
US7653566B2 (en) * 2000-11-30 2010-01-26 Handysoft Global Corporation Systems and methods for automating a process of business decision making and workflow
US7917888B2 (en) * 2001-01-22 2011-03-29 Symbol Technologies, Inc. System and method for building multi-modal and multi-channel applications
US7240324B2 (en) * 2001-02-28 2007-07-03 Hewlett-Packard Development Company, L.P. Event-based scheduling method and system for workflow activities
US20020128068A1 (en) 2001-03-09 2002-09-12 Randall Whitten Jon Marcus Method and apparatus for managing data in a gaming system
US20020147606A1 (en) * 2001-03-14 2002-10-10 Norbert Hoffmann Application development method
US7120896B2 (en) * 2001-10-31 2006-10-10 Vitria Technology, Inc. Integrated business process modeling environment and models created thereby
US20020188644A1 (en) * 2001-06-08 2002-12-12 Verano Workflow automated task component manager
US20030018643A1 (en) * 2001-06-19 2003-01-23 Peiwei Mi VIGIP006 - collaborative resolution and tracking of detected events
US7069536B2 (en) * 2001-06-28 2006-06-27 International Business Machines Corporation Method, system, and program for executing a workflow
US6898604B1 (en) * 2001-06-29 2005-05-24 Microsoft Corporation XML serialization and deserialization
US20030018508A1 (en) * 2001-07-19 2003-01-23 Schwanke Robert W. Data-triggered workflow processes
US7222334B2 (en) 2001-07-24 2007-05-22 Hewlett-Packard Development Comapny, L.P. Modeling tool for electronic services and associated methods and businesses
WO2003014927A2 (en) * 2001-08-08 2003-02-20 Trivium Systems Inc. Scalable messaging platform for the integration of business software components
US6985939B2 (en) * 2001-09-19 2006-01-10 International Business Machines Corporation Building distributed software services as aggregations of other services
US6895573B2 (en) * 2001-10-26 2005-05-17 Resultmaker A/S Method for generating a workflow on a computer, and a computer system adapted for performing the method
US20030177046A1 (en) * 2001-12-03 2003-09-18 John Socha-Leialoha Method and system for reusing components
US6928582B2 (en) * 2002-01-04 2005-08-09 Intel Corporation Method for fast exception handling
US7089287B2 (en) * 2002-01-16 2006-08-08 Xerox Corporation Message-based system having embedded information management capabilities
US20030144891A1 (en) * 2002-01-26 2003-07-31 International Business Machines Corporation Supervising the processing status of activities within workflow management systems
US20030233374A1 (en) * 2002-03-14 2003-12-18 Ulrich Spinola Dynamic workflow process
US20030217054A1 (en) * 2002-04-15 2003-11-20 Bachman George E. Methods and apparatus for process, factory-floor, environmental, computer aided manufacturing-based or other control system with real-time data distribution
US7424717B2 (en) * 2002-05-01 2008-09-09 Bea Systems, Inc. Systems and methods for business process plug-in development
US7272816B2 (en) 2002-07-31 2007-09-18 Sap Aktiengesellschaft Transformations between private and shared workflows
US8374966B1 (en) * 2002-08-01 2013-02-12 Oracle International Corporation In memory streaming with disk backup and recovery of messages captured from a database redo stream
US20040078105A1 (en) * 2002-09-03 2004-04-22 Charles Moon System and method for workflow process management
US7398525B2 (en) * 2002-10-21 2008-07-08 International Business Machines Corporation Resource scheduling in workflow management systems
US8056046B2 (en) * 2002-10-22 2011-11-08 The Boeing Company Integrated system-of-systems modeling environment and related methods
US7062537B2 (en) * 2002-11-25 2006-06-13 Microsoft Corporation Workflow services architecture
US20040148213A1 (en) * 2002-11-25 2004-07-29 Microsoft Corporation Automated workflow constraints
US7272820B2 (en) * 2002-12-12 2007-09-18 Extrapoles Pty Limited Graphical development of fully executable transactional workflow applications with adaptive high-performance capacity
US20040162741A1 (en) * 2003-02-07 2004-08-19 David Flaxer Method and apparatus for product lifecycle management in a distributed environment enabled by dynamic business process composition and execution by rule inference
US7114146B2 (en) * 2003-05-02 2006-09-26 International Business Machines Corporation System and method of dynamic service composition for business process outsourcing
EP1620830A2 (en) * 2003-05-07 2006-02-01 Sap Ag An end user oriented workflow approach including structured processing of ad hoc workflows with a collaborative process engine
US8332864B2 (en) * 2003-06-12 2012-12-11 Reuters America Inc. Business process automation
US8645420B2 (en) * 2003-08-05 2014-02-04 Accenture Global Services Limited Methodology framework and delivery vehicle
US7693973B2 (en) * 2003-08-28 2010-04-06 International Business Machines Corporation Pluggable state meta-data processors based on meta information modeling in a service oriented architecture
CA2543330A1 (en) 2003-09-02 2005-04-14 Infoglide Software Corporation System and method for workflow process management
CA2442796A1 (en) * 2003-09-26 2005-03-26 Ibm Canada Limited - Ibm Canada Limitee Binding a workflow engine to a data model
CA2443447A1 (en) * 2003-09-30 2005-03-30 Ibm Canada Limited-Ibm Canada Limitee System and method for conversion between graph-based representations and structural text-based representations of business processes
US7278065B2 (en) * 2003-11-17 2007-10-02 Electronic Data Systems Corporation Enterprise directory service domain controller replication alert and repair
US7137033B2 (en) * 2003-11-20 2006-11-14 International Business Machines Corporation Method, system, and program for synchronizing subtasks using sequence numbers
US7197502B2 (en) * 2004-02-18 2007-03-27 Friendly Polynomials, Inc. Machine-implemented activity management system using asynchronously shared activity data objects and journal data items
US7359909B2 (en) * 2004-03-23 2008-04-15 International Business Machines Corporation Generating an information catalog for a business model
US20050246692A1 (en) * 2004-04-28 2005-11-03 Convey Development, Inc. Asynchronous compilation
US20060064335A1 (en) * 2004-08-17 2006-03-23 International Business Machines Corporation Method, system, and storage medium for performing business process modeling
US20060053120A1 (en) * 2004-09-07 2006-03-09 Hong Kong Applied Science And Technology Research Institute Co., Ltd. Web service registry and method of operation
US7464366B2 (en) * 2004-10-01 2008-12-09 Microsoft Corporation Programming interface for a componentized and extensible workflow model
US7631291B2 (en) * 2004-10-01 2009-12-08 Microsoft Corporation Declarative representation for an extensible workflow model
US20060074735A1 (en) * 2004-10-01 2006-04-06 Microsoft Corporation Ink-enabled workflow authoring
US20060112122A1 (en) * 2004-11-23 2006-05-25 International Business Machines Corporation Method, system, and storage medium for implementing business process modules
US7954090B1 (en) 2004-12-21 2011-05-31 Zenprise, Inc. Systems and methods for detecting behavioral features of software application deployments for automated deployment management
US7433887B2 (en) 2004-12-29 2008-10-07 Microsoft Corporation Method and apparatus for metadata driven business logic processing
JP2006215713A (en) 2005-02-02 2006-08-17 Canon Inc Preceding work instruction and its cancellation method in workflow system
US7493594B2 (en) 2005-03-14 2009-02-17 Research In Motion System and method for designing component based applications
US7983943B2 (en) 2005-05-27 2011-07-19 Xerox Corporation Method and system for workflow process node synchronization
CA2637413A1 (en) 2006-01-20 2007-07-26 Paxfire, Inc. Systems and methods for discerning and controlling communication traffic
US8069439B2 (en) * 2006-03-30 2011-11-29 Microsoft Corporation Framework for modeling continuations in workflows
US20070239505A1 (en) * 2006-03-30 2007-10-11 Microsoft Corporation Abstract execution model for a continuation-based meta-runtime
US20070239498A1 (en) * 2006-03-30 2007-10-11 Microsoft Corporation Framework for modeling cancellation for process-centric programs

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP0697652A1 (en) * 1994-08-16 1996-02-21 International Business Machines Corporation Method for re-executing a process on a computer system for fault correction
US20050193286A1 (en) * 2000-04-28 2005-09-01 Microsoft Corporation Compensation framework for long running transactions
US20040153350A1 (en) * 2003-01-31 2004-08-05 Handysoft Corporation System and method of executing and controlling workflow processes

Non-Patent Citations (4)

* Cited by examiner, † Cited by third party
Title
BRAMBILLA M. ET AL.: "Exception Handling within Workflow-based Web Applications", WEB ENGINEERING 4TH INTERNATIONAL CONFERENCE, MUNICH: LNCS SPRINGER, 2004, XP019009035 *
HAGEN C. ET AL.: "Exception Handling in Workflow Management Systems", IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, vol. 26, no. 10, October 2000 (2000-10-01), pages 943 - 958, XP003005543 *
N. TALBERT, ACTIVITYEXECUTIONSTATUS.FAULTING - ADVANCED WORKFLOW: ENABLING TRICKY SCENARIOS - SITE HOME - MSDN BLOGS, 22 February 2006 (2006-02-22)
See also references of EP2013716A4

Also Published As

Publication number Publication date
US20070234129A1 (en) 2007-10-04
CN101416156A (en) 2009-04-22
JP5297370B2 (en) 2013-09-25
EP2013716A4 (en) 2009-06-24
CN101416156B (en) 2013-03-06
RU2008138701A (en) 2010-04-10
JP2009532760A (en) 2009-09-10
US7739135B2 (en) 2010-06-15
EP2013716A1 (en) 2009-01-14
MX2008011910A (en) 2008-09-29
KR20080106567A (en) 2008-12-08
CA2644370A1 (en) 2007-10-25
BRPI0708917A2 (en) 2011-06-14

Similar Documents

Publication Publication Date Title
US7739135B2 (en) Asynchronous fault handling in process-centric programs
US8024405B2 (en) Declarative model for concurrency-control across lightweight threads
US8069439B2 (en) Framework for modeling continuations in workflows
US20070239498A1 (en) Framework for modeling cancellation for process-centric programs
US20070239505A1 (en) Abstract execution model for a continuation-based meta-runtime
KR20060087998A (en) Unified model for authoring and executing flow-based and constraint-based workflows

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 07751408

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 2644370

Country of ref document: CA

WWE Wipo information: entry into national phase

Ref document number: MX/a/2008/011910

Country of ref document: MX

ENP Entry into the national phase

Ref document number: 2008138701

Country of ref document: RU

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 2009502791

Country of ref document: JP

Ref document number: 1020087024029

Country of ref document: KR

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 200780012353.1

Country of ref document: CN

WWE Wipo information: entry into national phase

Ref document number: 2007751408

Country of ref document: EP

ENP Entry into the national phase

Ref document number: PI0708917

Country of ref document: BR

Kind code of ref document: A2

Effective date: 20080925