US20050267765A1 - Apparatus and method for policy-driven business process exception handling - Google Patents
Apparatus and method for policy-driven business process exception handling Download PDFInfo
- Publication number
- US20050267765A1 US20050267765A1 US10/853,503 US85350304A US2005267765A1 US 20050267765 A1 US20050267765 A1 US 20050267765A1 US 85350304 A US85350304 A US 85350304A US 2005267765 A1 US2005267765 A1 US 2005267765A1
- Authority
- US
- United States
- Prior art keywords
- policy
- exception
- exception handling
- task
- policies
- Prior art date
- Legal status (The legal status 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 status listed.)
- Abandoned
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION 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/00—Administration; Management
- G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
- G06Q10/067—Enterprise or organisation modelling
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION 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/00—Administration; Management
- G06Q10/10—Office automation; Time management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION 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/00—Administration; Management
- G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
- G06Q10/063—Operations research, analysis or management
- G06Q10/0637—Strategic management or analysis, e.g. setting a goal or target of an organisation; Planning actions based on goals; Analysis or evaluation of effectiveness of goals
- G06Q10/06375—Prediction of business process outcome or impact based on a proposed change
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06Q—INFORMATION 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/00—Administration; Management
- G06Q10/06—Resources, workflows, human or project management; Enterprise or organisation planning; Enterprise or organisation modelling
- G06Q10/063—Operations research, analysis or management
- G06Q10/0639—Performance analysis of employees; Performance analysis of enterprise or organisation operations
- G06Q10/06395—Quality analysis or management
Definitions
- the present invention generally relates to a model-driven and QoS-aware infrastructure for facilitating the scalable composition of Web services in highly dynamic environments and, more particularly, to an exception management framework which supports two modes of exception management for business processes, providing a novel policy-driven approach to exception management implemented in the system infrastructure.
- Process-based composition of Web services has recently gained significant momentum in the implementation of business processes.
- a critical and time-consuming part of modeling any business process is the detection and handling of exceptions that may occur during process execution.
- the Web services paradigm promises to take across-network application interactions one step further by enabling programmatic access to applications over the Web.
- process-based composition of Web services has emerged as the technology of choice for integrating heterogeneous and loosely coupled applications (see Boualem Benatallah and Fabio Casati, editors, Distributed and Parallel Database, Special Issue on Web Services , Springer-verlag, 2002).
- process-based integration of services has been the subject of intense research and standardization efforts. This approach provides an attractive alternative to hand-coding the interactions between applications using general-purpose programming languages.
- An example of a business process would be a “Security Investment” system that aggregates multiple component services for security selection, budget analysis, market analysis, share exchange and future exchange, which are executed sequentially or concurrently.
- Web services may operate in a highly dynamic environment, e.g., new services may become available at any time, existing services may become obsolete or temporarily unavailable, and services may offer different QoS (Quality of Service) properties or withdraw of advertised QoS properties.
- QoS Quality of Service
- exception management is implemented in the system infrastructure, with exception handling policies supplied by individual business processes.
- exception management framework developers define exception policies in a declarative manner.
- the service composition middleware integrates the exception policies with normal business logic to generate a complete process schema.
- Our initial experiments show that our policy driven-approach can significantly reduce the development time of business processes through its separation of the development of the business logic and the exception handling policies.
- FIG. 1 is a statechart of a business process “security investment”
- FIG. 2 is a listing of the exception handling policy syntax
- FIG. 3 is a listing of the timeout policy
- FIG. 4 is a listing of the retry policy
- FIG. 5 is a listing of the multiple binding policy
- FIG. 6 is a listing of the replacement policy
- FIG. 7 is a listing of the skip policy
- FIG. 8 is a listing of the rollback policy
- FIG. 9 is a block diagram of the procedure of processing exception handling policy
- FIG. 10 is a block diagram of the processing result of a multiple binding policy
- FIG. 11 is a block diagram of the processing result of a retry policy
- FIG. 12 is a block diagram illustrating a compound state with a null state
- FIG. 13 is a block diagram of the processing result of a replacement policy
- FIG. 14 is a block diagram of the processing result of a skip policy
- FIG. 15 is a block diagram of processing a rollback policy
- FIG. 16 is a statechart of the business process “security investment” after policy based reconstructing.
- FIG. 17 is a block diagram of the architecture of the prototype of the invention.
- a composite Web service is an aggregation of multiple other elementary and composite Web services, which interact with each other according to a process model.
- the choice of statecharts for specifying business process is motivated by two main reasons: (i) statecharts have a well-defined semantics; and (ii) they offer the basic flow constructs found in contemporary process modelling languages (i.e., sequence, conditional branching, structured loops, concurrent threads, and inter-thread synchronization). It should be noted that exception management techniques developed in the context of statecharts, can be adapted to other process modeling languages (e.g., BPEL4WS, WSCI, BPML).
- Service communities provide descriptions of a desired functionality (e.g., flight booking) without referring to any actual service (e.g., Qantas flight booking Web service).
- the set of members of a community can be fixed when the community is created, or it can be determined through a registration mechanism, thereby allowing service providers to join, quit, and reinstate the community at any time.
- Definition 2 (Execution plan).
- the syntax of an exception handling policy is shown in FIG. 2 .
- every word in bold is a token in the language and optional elements are specified with square brackets [ ].
- the event can be a primitive event or a compound event which is composed from primitive events using event combination operators (see Sharma Chakravarthy et al., “Composite events for active databases: Semantics, contexts and detection”, Proceedings of 20 th International Conference on Very Large Data Bases, Sep. 12-15, 1994, Santiago de Chile, Chile, pp. 606-617, Morgan Kaufmann, 1994.
- a primitive event can be an execution exception (e.g., E(failure)) or a QoS exception event.
- the term subject refers to either composite, communities or component services.
- the target object indicates the scope of the exception handling policy, or the entire business process.
- the do-clause specifies exception management actions that include primitive and compound actions. See table 1 for examples.
- timeout namely: timeout, retry, multiple binding, replacement, skip and rollback policies.
- types of policy in our framework is extensible: new types of policies can be added without fundamentally altering the exception handling techniques built on top of the framework.
- TABLE 1 Exception Handling Action Action Brief Explanation timeout( ) Timouts a task execution retry( ) Retries task execution by same services or different services multiple( ) Invokes multiple services at the same time and returns the results of the service that completes execution first.
- Timeout Policy specifies the condition when service execution should be timeout. For example, in FIG. 3 , the timeout policy is associated with the tasks RiskAnalysis and SecuritySelection. In this policy, if the completion of the execution of the task is delayed more than 120 seconds, then the execution will be timeout.
- Retry Policy specifies how many times the service binding in sequence is allowed for a certain task.
- the alternative approach indicates to attempt the service binding by assigning the task to different services in sequence, while the repeat method indicates to retry the service binding using the same services.
- the service binding is retried until either the service execution is successful or the number of retries reaches the specified upper bound.
- a retry policy is associated with the task FutureExchange and StockExchange, which sets the upper bound of retry to be two. It should be noted that the retry policy is applied whenever the execution of a task timeout or fails.
- a multiple binding policy specifies the condition that allows the concurrent invocation of multiple services for a task execution. For example, in FIG. 5 , a multiple bind policy is associated with the task SecuritySearching, which allows three concurrent service execution bindings. Therefore, three services can now be invoked at the same time to execute the task SecuritySearching, which completes when any of the services have completed their execution of the task.
- a replacement policy specifies what other task can be used to replace a certain task in a business process when the execution of the task fails or has timeout and the number of retries had reach the upper bound as specified in the retry policy. For example, in FIG. 6 , the replacement is associated with the task OnlineStockExchange, which indicates that when the number of retry has reached a given upper bound, the task OnlineStockExchange is to be replaced by the task ManualStockExchange.
- a skip policy specifies a condition when a business process needs to skip the execution of a certain task. For example, in FIG. 7 , a skip policy is associated with the task LowPriceBid, which specifies that if the task execution has failed or timeout, then the execution LowPriceBid is to be skipped.
- a rollback policy specifies the point at which execution of business process has to rollback when the execution of task has failed or timeout and the maximal allowed number of retries had been reached.
- the rollback policy is associated with the tasks SecuritySearch and RiskAnalysis specifies that if the execution has failed or timeout and the maximal allowed number of retries had been reached, the business process execution is rollbacked to the task BudgetAnalysis.
- the services selected to execute the tasks are required to support the cancellation or compensation of a given operation within a certain time interval from its completion (see Boualem Benatallah et al., ibid.).
- FIG. 9 illustrates the procedure for applying policies to generate exception handling aware process schemas.
- a task is associated with only one instance of each type of policy.
- the action in the retry policy can only be retry (t, n, repeat).
- a task can only associate with either skip, replacement or rollback policy at a business process instance. The procedure starts with processing the multiple and retry policies, and then processes any skip, replacement or rollback policies.
- the process schema is a 2-tuple ⁇ ST, TR>, where ST is the set of states and TR is the set of transitions between these states; a transition tr is a 3-tuple ⁇ initialState, targetState, r> and r is an Event Condition Action rule.
- Processing a multiple binding policy is done by duplicating t i and enabling both t i and its duplicates at the same time (see Algorithm 1 below).
- Algorithm 1 For example, in the business process Security Investment, the task SecuritySearching is associated with a multiple binding policy.
- the processing result is shown in FIG. 10 .
- Task t i is not associated with any multiple binding policy. This is a simple case which can be implemented by duplicating ti and enabling both t i and its duplicates in sequence.
- Task t i is also associated with a multiple binding policy. In this case, after processing the multiple binding policy, for each concurrent thread k the algorithm duplicates the task t i j and enables both t i j and its duplicates in sequence. For example, in the business process Security Investment, the task FutureExchange is associated with a retry policy but no multiple binding policies, which corresponds to case 1 of algorithm 2.
- Task t i is associated with both a retry policy and a multiple binding policy.
- a compound state (see FIG. 12 ) is created to synchronize the concurrent threads when all of the tasks in all of concurrent threads fail.
- the compound state is also used to enable the alternative task.
- Task t i is only associated with a retry and possibly other types of policies but not with any multiple binding policy. In this case, the alternative task is enabled when the last duplicated task fails.
- Task t i is associated with a multiple binding policy and possibly other types of policies but not with any retry policy.
- the policy processing is similar to case 1.
- Task t i is not associated with any retry or multiple binding policy.
- the alternative task is enabled when the execution of t i fails.
- the task OnlineStockExchange is associated with a both replacement policy a retry policy, which corresponds to case 2 of algorithm 3.
- the processing result is shown in FIG. 13 .
- Algorithm 3 Processing a replacement policy input : Task t i , Process Schema CS, Replacement Policy p begin t a is the replacement task of t i ; ST ST ⁇ ⁇ t a ⁇ if t i is associated with both Retry and Multiple Binding Policy then M multiple binding upper bound; N retry upper bound create a compound state st co with a NULL state ST ST ⁇ ⁇ st co ⁇ tr is the transition between st ini and st null in st co tr ⁇ st ini , st null , (E(failure, t i 1,N ) E(timeout, t i 1,N )) ...
- Task t i is associated with both a retry and a multiple binding policy.
- a compound state (see FIG. 12 ) is created to synchronize the concurrent threads when all of the tasks in all of concurrent threads fail.
- the compound state is also used to enable the next task so that t i can be skipped.
- Task t i is only associated with a retry policy and possibly other types of policies but not with any multiple binding policy. In this case, the next task is enabled when the execution of t i s last duplicate fails.
- Task t i is associated with a multiple binding policy and possibly other types of policies but not with any retry policy.
- the policy processing is similar to case 1.
- Task t i is not associated with any retry or multiple binding policy.
- the next task is enabled when the execution of t i fails.
- the task LowPriceBid is associated with both a skip policy and a retry policy, which corresponds to case 2 of algorithm 4.
- the processing result is shown in FIG. 14 .
- Algorithm 4 Processing a skip policy input : Task t i , Process Schema CS, Skip Policy p begin if t i is associated with both Retry and Multiple Binding Policy then M multiple binding upper bound; N retry upper bound create a compound state st co with a NULL state ST ST ⁇ ⁇ st co ⁇ tr is the transition between st ini and st null in st co tr ⁇ st ini , st null , (E(failure, t i 1,N ) E(timeout, t i 1,N )) ...
- Processing of a rollback policy for task t i also needs to consider four cases (see Algorithm 5 below):
- Task t i is associated with both a retry and multiple binding policy.
- a compound state (see FIG. 12 ) is created to synchronize the concurrent threads when all the tasks in all concurrent threads fail.
- the compound state is also used to enable the rollback of the execution of the business process to the re-entry point.
- Task t i is associated with a retry policy and possibly other types of policies but not with any multiple binding policy.
- the rollback is enabled when the execution of t i 's last duplicated task fails.
- Task t i is only associated with a multiple binding policy and possibly other types of policies but not with any retry policy. In this case, the policy processing is similar to case 1.
- Task t i is not associated with any retry or multiple binding policy.
- the rollback is enabled when the execution of t i fails.
- Algorithm 5 Processing a rollback policy input : Task ti, Process Schema CS, Rollback Policy p begin the rollback entry point is t a if t i is associated with both Retry and Multiple Binding Policy then M multiple binding upper bound; N retry upper bound create a compound state st co with a NULL state ST ST ⁇ ⁇ st co ⁇ tr is the transition between st ini and st null in st co tr ⁇ st ini , st null , (E(failure, t i 1,N ) E(timeout, t i 1,N )) ...
- the extended process schema (see the example in FIG. 16 in which the processing result of the business process Security Investment is based on the exception handling policies given above) that contains exception management knowledge is used to conduct the execution planning.
- the extended process schema see the example in FIG. 16 in which the processing result of the business process Security Investment is based on the exception handling policies given above.
- BPEL4WS allows process modelers to create complex processes by creating and writing together different activities that can perform Web services invocations, manipulate data, throw fault, or terminate a process.
- BPEL4WS we separate normal processes that are specified in BPEL4WS and the knowledge of exception management.
- the Aggregator exploits the schema re-construction algorithms described in previous sections and transforms such BPEL4WS-based process schema into an extended process schema that is also presented by BPEL4WS but contains more constructs reflecting the requirement of exception handling policies.
- the BPEL4WS script is deployed into the BPMS (Business Process Management System) that is essentially an execution engine for BPEL4WS.
- BPMS Business Process Management System
- IBM's DragonFly engine for this purpose.
- the system utilizes the orchestration and exception handling mechanism provided by the DragonFly engine to manage business processes.
Abstract
A model-driven and QoS-aware infrastructure facilitates the scalable composition of Web services in highly dynamic environments. An exception management framework supports two modes of exception management for business processes, providing a novel policy-driven approach to exception management implemented in the system infrastructure. Exception management is implemented in the system infrastructure, with exception handling policies supplied by individual business processes. Using the exception management framework, developers define exception policies in a declarative manner. Before a business process is executed, the service composition middleware integrates the exception policies with normal business logic to generate a complete process schema. This policy driven-approach can significantly reduce the development time of business processes through its separation of the development of the business logic and the exception handling policies.
Description
- 1. Field of the Invention
- The present invention generally relates to a model-driven and QoS-aware infrastructure for facilitating the scalable composition of Web services in highly dynamic environments and, more particularly, to an exception management framework which supports two modes of exception management for business processes, providing a novel policy-driven approach to exception management implemented in the system infrastructure.
- 2. Background Description
- Process-based composition of Web services has recently gained significant momentum in the implementation of business processes. A critical and time-consuming part of modeling any business process is the detection and handling of exceptions that may occur during process execution. The Web services paradigm promises to take across-network application interactions one step further by enabling programmatic access to applications over the Web. Recently, process-based composition of Web services has emerged as the technology of choice for integrating heterogeneous and loosely coupled applications (see Boualem Benatallah and Fabio Casati, editors, Distributed and Parallel Database, Special Issue on Web Services, Springer-verlag, 2002). As such, process-based integration of services has been the subject of intense research and standardization efforts. This approach provides an attractive alternative to hand-coding the interactions between applications using general-purpose programming languages. An example of a business process would be a “Security Investment” system that aggregates multiple component services for security selection, budget analysis, market analysis, share exchange and future exchange, which are executed sequentially or concurrently.
- Modeling business processes would be easier if all the activities could be completed successfully without any occurrence of exceptions (see Paul Greenfield et al., “Compensation is not enough”, 7th IEEE International Enterprise Distributed Object Computing Conference, September 2003). Unfortunately experiences show (see Chris Peltz, “Web Services Orchestration: a review of emerging technologies, tools and standards”, Technical Report, Hewlett-Packard Company, 2003) that a large amount of effort in the development of a business process is spent on exception management. In particular, Web services may operate in a highly dynamic environment, e.g., new services may become available at any time, existing services may become obsolete or temporarily unavailable, and services may offer different QoS (Quality of Service) properties or withdraw of advertised QoS properties. Such highly dynamic environment increases the probability of deviation situations during the execution of a business process and an increased complexity in exception handling logic. Therefore, it is important to provide support for exception management in the infrastructure so that developers can focus on defining the business logic, or normal flow, of a business process and delegate exception handling to the system infrastructure.
- It is therefore an object of the present invention to provide a novel policy-driven approach to exception management, which can substantially simplify the development of business processes.
- According to the invention, exception management is implemented in the system infrastructure, with exception handling policies supplied by individual business processes. Using the exception management framework, developers define exception policies in a declarative manner. Before a business process is executed, the service composition middleware integrates the exception policies with normal business logic to generate a complete process schema. Our initial experiments show that our policy driven-approach can significantly reduce the development time of business processes through its separation of the development of the business logic and the exception handling policies.
- The novel policy-driven exception-management framework for business processes according to the invention is characterized by the following:
-
- In our framework, the development of business processes is substantially simplified by separating the development of the business logic and the exception handling policies.
- In order to capture the exception management knowledge, we identify a set of exception handling policy templates or patterns for declaratively defining deviation situations and associated exception handlers. At run time, the service composition middleware dynamically integrates the exception handling policies with the business logic to generate complete process schemas that specify both the normal and exceptional behaviors of the business processes.
- The framework supports two modes of exception management in business processes, namely, centralized and distributed. In the centralized mode, since a generated process schema contains all the necessary exception handlers, the exception management can be supported using the exception handling capabilities of the underlying process execution engine. In the distributed mode, our exception management framework dynamically binds exception policies with a specific execution plan (i.e., a business process instance) at runtime to generate control tuples. When these control tuples are deployed to component services, they enable local exception detecting and handling which is able to react to an exception faster than the centralized approach.
- The foregoing and other objects, aspects and advantages will be better understood from the following detailed description of a preferred embodiment of the invention with reference to the drawings, in which:
-
FIG. 1 is a statechart of a business process “security investment”; -
FIG. 2 is a listing of the exception handling policy syntax; -
FIG. 3 is a listing of the timeout policy; -
FIG. 4 is a listing of the retry policy; -
FIG. 5 is a listing of the multiple binding policy; -
FIG. 6 is a listing of the replacement policy; -
FIG. 7 is a listing of the skip policy; -
FIG. 8 is a listing of the rollback policy; -
FIG. 9 is a block diagram of the procedure of processing exception handling policy; -
FIG. 10 is a block diagram of the processing result of a multiple binding policy; -
FIG. 11 is a block diagram of the processing result of a retry policy; -
FIG. 12 is a block diagram illustrating a compound state with a null state; -
FIG. 13 is a block diagram of the processing result of a replacement policy; -
FIG. 14 is a block diagram of the processing result of a skip policy; -
FIG. 15 is a block diagram of processing a rollback policy; -
FIG. 16 is a statechart of the business process “security investment” after policy based reconstructing; and -
FIG. 17 is a block diagram of the architecture of the prototype of the invention. - We begin by briefly describing the main concepts of the service composition model we use in this disclosure. A composite Web service is an aggregation of multiple other elementary and composite Web services, which interact with each other according to a process model. We choose to specify the process model of a business process as a statechart which is a platform independent modeling tool, as shown in
FIG. 1 . The choice of statecharts for specifying business process is motivated by two main reasons: (i) statecharts have a well-defined semantics; and (ii) they offer the basic flow constructs found in contemporary process modelling languages (i.e., sequence, conditional branching, structured loops, concurrent threads, and inter-thread synchronization). It should be noted that exception management techniques developed in the context of statecharts, can be adapted to other process modeling languages (e.g., BPEL4WS, WSCI, BPML). - A basic state of a statechart describing a business process can be labelled with an invocation to either of the following:
-
- An elementary Web service, i.e., a service which does not transparently rely on other Web services.
- A business process aggregating several other services.
- A Web service community, i.e., a collection of Web services with a common functionality although different non-functional properties (e.g., with different providers, different QoS parameters, reputation, etc.)
- Web services in a community share a common service ontology. Service communities provide descriptions of a desired functionality (e.g., flight booking) without referring to any actual service (e.g., Qantas flight booking Web service). The set of members of a community can be fixed when the community is created, or it can be determined through a registration mechanism, thereby allowing service providers to join, quit, and reinstate the community at any time.
- In general, by selecting a candidate service (see Liangzhao Zeng et al., “Quality Driven Web Services Composition”, Proceedings of the 12th International Conference on World Wide Web (WWW), Budapest, Hungary, ACM Press, May 2003) (see Definition 1) for each task in the business process, an execution plan (see Definition 2) can be generated to create execution instance of business processes.
- Definition 1 (Candidate services) Let us assume that T={t1, t2, . . . , tn} represents the set of all tasks in the business process CS. Function S(ti) gives a set of candidate services that can be used to execute task ti, where
S(t i)={S 1i , S 2i , . . . , s mi} (1) - Definition 2 (Execution plan). A set of pairs p={<t1, s1>, <t2, s2>, . . . , <tn, sn>} is an execution plan of a business process if:
-
- {t1, t2, . . . , tn} is the set of tasks in the business process.
- For each 2-tuple <ti, si> in p, the service si is assigned the execution of task ti.
- The syntax of an exception handling policy is shown in
FIG. 2 . In this syntax, every word in bold is a token in the language and optional elements are specified with square brackets [ ]. Note the required exception event specification following the on keyword. The event can be a primitive event or a compound event which is composed from primitive events using event combination operators (see Sharma Chakravarthy et al., “Composite events for active databases: Semantics, contexts and detection”, Proceedings of 20th International Conference on Very Large Data Bases, Sep. 12-15, 1994, Santiago de Chile, Chile, pp. 606-617, Morgan Kaufmann, 1994. A primitive event can be an execution exception (e.g., E(failure)) or a QoS exception event. The term subject refers to either composite, communities or component services. The target object indicates the scope of the exception handling policy, or the entire business process. The do-clause specifies exception management actions that include primitive and compound actions. See table 1 for examples. We distinguish between six types of exception handling policies, namely: timeout, retry, multiple binding, replacement, skip and rollback policies. It should be noted that the types of policy in our framework is extensible: new types of policies can be added without fundamentally altering the exception handling techniques built on top of the framework.TABLE 1 Exception Handling Action Action Brief Explanation timeout( ) Timouts a task execution retry( ) Retries task execution by same services or different services multiple( ) Invokes multiple services at the same time and returns the results of the service that completes execution first. replace( ) Replaces the execution of a task (resp., segment) with other task (resp., segment) skip( ) Skips the execution of tasks or a segment rollback( ) Rollbacks the task execution to a task and then resumes the task execution - Timeout Policy. A timeout policy specifies the condition when service execution should be timeout. For example, in
FIG. 3 , the timeout policy is associated with the tasks RiskAnalysis and SecuritySelection. In this policy, if the completion of the execution of the task is delayed more than 120 seconds, then the execution will be timeout. - Retry Policy. A retry policy specifies how many times the service binding in sequence is allowed for a certain task. There are two approaches to retry the service binding, namely alternative and repeat. The alternative approach indicates to attempt the service binding by assigning the task to different services in sequence, while the repeat method indicates to retry the service binding using the same services. The service binding is retried until either the service execution is successful or the number of retries reaches the specified upper bound. For example, in
FIG. 4 , a retry policy is associated with the task FutureExchange and StockExchange, which sets the upper bound of retry to be two. It should be noted that the retry policy is applied whenever the execution of a task timeout or fails. - Multiple Binding Policy. A multiple binding policy specifies the condition that allows the concurrent invocation of multiple services for a task execution. For example, in
FIG. 5 , a multiple bind policy is associated with the task SecuritySearching, which allows three concurrent service execution bindings. Therefore, three services can now be invoked at the same time to execute the task SecuritySearching, which completes when any of the services have completed their execution of the task. - Replacement Policy. A replacement policy specifies what other task can be used to replace a certain task in a business process when the execution of the task fails or has timeout and the number of retries had reach the upper bound as specified in the retry policy. For example, in
FIG. 6 , the replacement is associated with the task OnlineStockExchange, which indicates that when the number of retry has reached a given upper bound, the task OnlineStockExchange is to be replaced by the task ManualStockExchange. - Skip Policy. A skip policy specifies a condition when a business process needs to skip the execution of a certain task. For example, in
FIG. 7 , a skip policy is associated with the task LowPriceBid, which specifies that if the task execution has failed or timeout, then the execution LowPriceBid is to be skipped. - Rollback Policy. A rollback policy specifies the point at which execution of business process has to rollback when the execution of task has failed or timeout and the maximal allowed number of retries had been reached. For example, in
FIG. 8 , the rollback policy is associated with the tasks SecuritySearch and RiskAnalysis specifies that if the execution has failed or timeout and the maximal allowed number of retries had been reached, the business process execution is rollbacked to the task BudgetAnalysis. It should be noted that when a rollback policy is specified, for affected tasks (e.g., the task of BudgetAllocation), the services selected to execute the tasks are required to support the cancellation or compensation of a given operation within a certain time interval from its completion (see Boualem Benatallah et al., ibid.). - In our framework, an exception handling policy is separated of any individual business processes. It regulates the behavior of business processes when execution exceptions are raised during runtime. Such an approach requires dynamically binding the exception handling policies with process schemas.
- In order to implement policy binding, the system identifies the exception handling policies that are associated with each task in a business process and then uses these policies to reconstruct the process schema. It should be noted that all types of policies except timeout policies can modify the structure of the process schema of a business process.
FIG. 9 illustrates the procedure for applying policies to generate exception handling aware process schemas. In this procedure, we assume that: (i) A task is associated with only one instance of each type of policy. (ii) If a task is associated with both retry and multiple binding policies, then the action in the retry policy can only be retry (t, n, repeat). (iii) A task can only associate with either skip, replacement or rollback policy at a business process instance. The procedure starts with processing the multiple and retry policies, and then processes any skip, replacement or rollback policies. - In the remainder of this section, we present the algorithms for generating exception-aware process schemas. Here, we assume that the process schema is a 2-tuple <ST, TR>, where ST is the set of states and TR is the set of transitions between these states; a transition tr is a 3-tuple <initialState, targetState, r> and r is an Event Condition Action rule.
- Processing a multiple binding policy. The processing of a multiple binding policy for task ti is done by duplicating ti and enabling both ti and its duplicates at the same time (see Algorithm 1 below). For example, in the business process Security Investment, the task SecuritySearching is associated with a multiple binding policy. The processing result is shown in
FIG. 10 .Algorithm 1: processing a multiple binding policy input : Task ti, Process schema CS, Multiple Binding Policy p begin N is multiple binding upper bound; ti+1 is the next task of ti, the transition between ti and ti+1 is tri; ti−1 is the previous task of ti, the transition between ti−1 and ti is tri−1 for k 1 to N do ti k clone(ti k) if k = = 1 then replace ti with ti k in CS else ST ST ∪ {ti k} tr clone(tri−1) tri−1 k replace ti with ti k in tr; TR TR ∪ {tri−1 k} tr clone(tri) tri k replace ti, with ti k in tr; TR TR ∪ {tri k} end - Processing a retry policy. The processing of a retry policy for task ki needs to consider two cases (see Algorithm 2 below): (i) Task ti is not associated with any multiple binding policy. This is a simple case which can be implemented by duplicating ti and enabling both ti and its duplicates in sequence. (ii) Task ti is also associated with a multiple binding policy. In this case, after processing the multiple binding policy, for each concurrent thread k the algorithm duplicates the task ti j and enables both ti j and its duplicates in sequence. For example, in the business process Security Investment, the task FutureExchange is associated with a retry policy but no multiple binding policies, which corresponds to case 1 of algorithm 2. The policy processing result is shown in
FIG. 11 .Algorithm 2: Processing a retry policy input : Task ti, Process schema CS, Retry Policy p begin N is multiple binding upper bound; ti+1 is the next task of ti, the transition between ti and ti+1 is tr if ti is not associated with any binding policies then for k 1 to N do ti k clone(ti) if k = = 1 then rename ti with ti k in CS tr < ti k, ti+1, E(completed, ti k) TR TR ∪ {tr} else ST ST ∪ {ti k} tr < ti k−1, ti k, E(failure, ti,) E(timeout, ti)> TR TR ∪ {tr} tr < ti k, ti+1, E(completed, ti k)> TR TR ∪ {tr} else M multiple binding upper bound for j 1 to M do for k 1 to N do ti j, k clone (ti j) if k = = 1 then rename ti with ti k in CS tr < ti j, ti j, k, E(completed, ti j, k)> TR TR ∪ {tr} else ST ST ∪ {ti j, k} tr < ti j, k−1, ti j, k, E(failure, ti j, k−1) E(timeout, ti j, k−1)> TR TR ∪ {tr} tr < ti j, k, ti+1, E(completed, ti j, k)> TR TR ∪ {tr} end - Processing a replacement policy. The processing of a replacement policy for task ti needs to consider four cases (see Algorithm 3 below):
- (i) Task ti is associated with both a retry policy and a multiple binding policy. In this case, a compound state (see
FIG. 12 ) is created to synchronize the concurrent threads when all of the tasks in all of concurrent threads fail. The compound state is also used to enable the alternative task. - (ii) Task ti is only associated with a retry and possibly other types of policies but not with any multiple binding policy. In this case, the alternative task is enabled when the last duplicated task fails.
- (iii) Task ti is associated with a multiple binding policy and possibly other types of policies but not with any retry policy. In this case, the policy processing is similar to case 1.
- (iv) Task ti is not associated with any retry or multiple binding policy. The alternative task is enabled when the execution of ti fails. For example, in the business process Security Investment, the task OnlineStockExchange is associated with a both replacement policy a retry policy, which corresponds to case 2 of algorithm 3. The processing result is shown in
FIG. 13 .Algorithm 3: Processing a replacement policy input : Task ti, Process Schema CS, Replacement Policy p begin ta is the replacement task of ti; ST ST ∪ {ta} if ti is associated with both Retry and Multiple Binding Policy then M multiple binding upper bound; N retry upper bound create a compound state stco with a NULL state ST ST ∪ {stco} tr is the transition between stini and stnull in stco tr < stini, stnull, (E(failure, ti 1,N) E(timeout, ti 1,N)) ... (E(failure, ti M,N) E(timeout, ti M,N))> for j 1 to M do tr < ti j, N, stco, E(failure, ti j,N) E(timeout, ti j,N)> TR TR ∪ {tr} tr < stco, ta >; TR TR ∪{tr} if ti is associated with Retry but not Multiple binding Policy then N retry upper bound tr < ti N, ta, E(failure, ti N) E(timeout, ti N)> TR TR ∪ {tr} if ti is associated with Multiple Binding but not Retry Policy then M multiple binding upper limit create a compound state stco with a NULL state ST ST ∪ {stco} tr is the transition betwen stini and stnull in stco tr < stini, stnull, (E(failure, ti 1) E(timeout, ti 1)) ... (E(failure, ti 1) E(timeout, ti M))> for j 1 to M do tr < ti j, stco, E(failure, ti j) E(timeout, ti j)> TR TR ∪ {tr} tr < stco, ta >; TR TR{tr} if ti is not associated with either Retry or Multiple Binding Policy then tr < ti, ta, E(failure, ti) E(timeout, ti)> TR TR ∪ {tr} tr < ta, ti+1, E(completed, ta) >; TR TR ∪ {tr} end - Processing a skip policy. The processing of a skip policy for task ti also needs to consider four cases (see Algorithm 4 below):
- (i) Task ti is associated with both a retry and a multiple binding policy. In this case, a compound state (see
FIG. 12 ) is created to synchronize the concurrent threads when all of the tasks in all of concurrent threads fail. The compound state is also used to enable the next task so that ti can be skipped. - (ii) Task ti is only associated with a retry policy and possibly other types of policies but not with any multiple binding policy. In this case, the next task is enabled when the execution of tis last duplicate fails.
- (iii) Task ti is associated with a multiple binding policy and possibly other types of policies but not with any retry policy. In this case, the policy processing is similar to case 1.
- (iv) Task ti is not associated with any retry or multiple binding policy. The next task is enabled when the execution of ti fails. For example, in the business process Security Investment, the task LowPriceBid is associated with both a skip policy and a retry policy, which corresponds to case 2 of algorithm 4. The processing result is shown in
FIG. 14 .Algorithm 4: Processing a skip policy input : Task ti, Process Schema CS, Skip Policy p begin if ti is associated with both Retry and Multiple Binding Policy then M multiple binding upper bound; N retry upper bound create a compound state stco with a NULL state ST ST ∪ {stco} tr is the transition between stini and stnull in stco tr < stini, stnull, (E(failure, ti 1,N) E(timeout, ti 1,N)) ... (E(failure, ti M,N) E(timeout, ti M,N))> for j 1 to M do tr < ti j, N stco, E(failure, ti j,N) E(timeout, ti j,N)> TR TR ∪ {tr} tr < stco, ti+1 > TR TR ∪ {tr} if ti is associated with Retry Policy but not Multiple Binding Policy then N retry upper bound tr < ti N, ti+1, E(failure, ti N) E(timeout, ti N)> TR TR ∪ {tr} if ti is associated with Multiple Binding Policy but not Retry Policy then M multiple binding upper bound create a compound state stco ST ST ∪ {stco} tr is the transition between stini and stnull tr < stini, stnull, (E(failure, ti 1) E(timeout, ti 1)) ... (E(failure, ti 1) E(timeout, ti M))> for j 1 to M do tr < stini,stnull, (E(failure, ti j) E(timeout, ti j)> TR TR ∪ {tr} tr < stco, ti+1, >; TR ∪ {tr} if ti is not associated with either Retry or Multiple Binding Policy then tr < ti, ti+1, E(failure, ti) E(timeout), ti)> TR TR ∪ {tr} end - Processing a rollback policy. Processing of a rollback policy for task ti also needs to consider four cases (see Algorithm 5 below):
- (i) Task ti is associated with both a retry and multiple binding policy. In this case, a compound state (see
FIG. 12 ) is created to synchronize the concurrent threads when all the tasks in all concurrent threads fail. The compound state is also used to enable the rollback of the execution of the business process to the re-entry point. - (ii) Task ti is associated with a retry policy and possibly other types of policies but not with any multiple binding policy. In this scenario, the rollback is enabled when the execution of ti's last duplicated task fails.
- (iii) Task ti is only associated with a multiple binding policy and possibly other types of policies but not with any retry policy. In this case, the policy processing is similar to case 1.
- (iv) Task ti is not associated with any retry or multiple binding policy. The rollback is enabled when the execution of ti fails.
Algorithm 5: Processing a rollback policy input : Task ti, Process Schema CS, Rollback Policy p begin the rollback entry point is ta if ti is associated with both Retry and Multiple Binding Policy then M multiple binding upper bound; N retry upper bound create a compound state stco with a NULL state ST ST ∪ {stco} tr is the transition between stini and stnull in stco tr < stini, stnull, (E(failure, ti 1,N) E(timeout, ti 1,N)) ... (E(failure, ti M,N) E(timeout, ti M,N))> for j 1 to M do tr < ti j, N, stco, E(failure, ti 1,N) E(timeout, ti 1,N)> TR TR ∪ {tr} for task tk between ta and ti (includes ta) do if task tk needs to be compensated then ST ST ∪ {undo(tk)} tr < stco, undo(tk)) >; TR TR ∪ {tr} if ti is associated with Retry but not Multiple Binding Policy then N retry upper bound for task tk between ta and ti (includes ta) do if task tk needs to be compensated then ST ST ∪{undo(tk)} tr < ti N, undo(tk)) >; TR TR ∪ {tr} if ti is associated with Multiple Binding but not Retry Policy then M multiple binding upper bound create a compound state stco with a NULL state ST ST ∪ {stco} tr is the transition between stini and stnull in stco tr < stini, stnull, (E(failure, ti 1) E(timeout, ti 1)) ... (E(failure, ti 1) E(timeout, ti M)) > for j to M do tr < ti j, stco, E(failure, ti j) E(timeout, ti j) > TR TR ∪ {tr} for task tk between ta and ti (includes ta) do if task tk needs to be compensated then ST ST ∪ {undo(tk)} tr < stco, undo(tk)) >; TR TR ∪ {tr} if ti is not associated with either Retry or Multiple Binding Policy then for task tk between ta and ti (includes ta) do if task tk needs to be compensated then ST ST ∪ (undo(tk)} tr < ti, undo(tk), E(failure, ti) E(timeout, ti) >; TR TR ∪ {tr} tr < undo(ta), ta >; TR TR ∪ {tr} end - It should be noted that some completed tasks need to be undone if the compensation process is required. For example, in the business process Security Investment, the task FutureExchange is associated with both a rollback policy and a retry policy, which corresponds to case 2 of algorithm 5. The processing result is shown in
FIG. 15 . - After the reconstruction of the process schema is completed, the extended process schema (see the example in
FIG. 16 in which the processing result of the business process Security Investment is based on the exception handling policies given above) that contains exception management knowledge is used to conduct the execution planning. In our previous work (see Liangzhao Zeng et al., ibid.), we adopted Multiple Criteria Decision Making (see Valerie Belton and Theodor Stewart, Multiple Criteria Decision Analysis: An Integrated Approach, Kluwer Academic Publishers, 2002) techniques and used the integer programming (IP) approach to select an optimal execution plan for a business process. It should be noted that based on the extended process schema and the selected execution plan, a fully executable description of the business process can be generated. For example, a BPEL4WS script that contains exception handlers can be generated to execute the business process by a process execution engine. - The preferred implementation of the policy-driven exception-management framework for business processes is shown in
FIG. 17 . In the implementation, we use BPEL4WS as the language to describe process schemas. BPEL4WS allows process modelers to create complex processes by creating and writing together different activities that can perform Web services invocations, manipulate data, throw fault, or terminate a process. In our implementation framework, we separate normal processes that are specified in BPEL4WS and the knowledge of exception management. There are two types of persistent storage, the Normal Business Process Schema Models and the Exception Handling Knowledge. The former stores normal process schemas that are defined by business analysts and the latter manages exception handling policies that are defined by exception handling experts. - The Aggregator exploits the schema re-construction algorithms described in previous sections and transforms such BPEL4WS-based process schema into an extended process schema that is also presented by BPEL4WS but contains more constructs reflecting the requirement of exception handling policies. The BPEL4WS script is deployed into the BPMS (Business Process Management System) that is essentially an execution engine for BPEL4WS. In our case, we are using IBM's DragonFly engine for this purpose. The system utilizes the orchestration and exception handling mechanism provided by the DragonFly engine to manage business processes. While the invention has been described in terms of a single preferred embodiment, those skilled in the art will recognize that the invention can be practiced with modification within the spirit and scope of the appended claims.
Claims (9)
1. A system for executing business process and handling runtime exceptions, comprising:
an aggregator that is able to integrate normal business logic with exception handling knowledge to generated extended business process definition; and
a business process engine that is able to execute business process definitions that contains knowledge on runtime exception handling.
2. The system in claim 1 , further comprising an exception handling policy repository that contains exception handling policies.
3. The system in claim 2 , wherein said exception handling policies includes said runtime exception specifications and exception handling action specifications
4. The system in claim 2 , wherein said business process engine can understand runtime exception specifications, detect runtime exceptions and execute exception handling actions.
5. A method for executing business processes and handling runtime exceptions, comprising the steps of:
specifying exception handling knowledge from normal business process logic;
integrating normal business logic with exception handling knowledge to generate extended business process definitions;
executing business process definition that contains runtime exception handling knowledge;
detecting runtime exceptions; and
executing exception handling actions.
6. The method in claim 5 , further comprising the step of defining exception specification.
7. The method in claim 5 , further comprising the step of defining exception handling knowledge as exception handling policies.
8. The method in claim 5 , further comprising the step of checking the compatibility between the exception handling policies and normal business logic.
9. The method in claim 5 , further comprising the step of checking the conflicts among the exception handling policies.
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/853,503 US20050267765A1 (en) | 2004-05-26 | 2004-05-26 | Apparatus and method for policy-driven business process exception handling |
US12/061,089 US11205150B2 (en) | 2004-05-26 | 2008-04-02 | Apparatus and method for policy-driven business process exception handling |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US10/853,503 US20050267765A1 (en) | 2004-05-26 | 2004-05-26 | Apparatus and method for policy-driven business process exception handling |
Related Child Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US12/061,089 Continuation US11205150B2 (en) | 2004-05-26 | 2008-04-02 | Apparatus and method for policy-driven business process exception handling |
Publications (1)
Publication Number | Publication Date |
---|---|
US20050267765A1 true US20050267765A1 (en) | 2005-12-01 |
Family
ID=35426542
Family Applications (2)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US10/853,503 Abandoned US20050267765A1 (en) | 2004-05-26 | 2004-05-26 | Apparatus and method for policy-driven business process exception handling |
US12/061,089 Active 2029-04-21 US11205150B2 (en) | 2004-05-26 | 2008-04-02 | Apparatus and method for policy-driven business process exception handling |
Family Applications After (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US12/061,089 Active 2029-04-21 US11205150B2 (en) | 2004-05-26 | 2008-04-02 | Apparatus and method for policy-driven business process exception handling |
Country Status (1)
Country | Link |
---|---|
US (2) | US20050267765A1 (en) |
Cited By (17)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20050222895A1 (en) * | 2004-04-03 | 2005-10-06 | Altusys Corp | Method and Apparatus for Creating and Using Situation Transition Graphs in Situation-Based Management |
US20060036687A1 (en) * | 2004-07-19 | 2006-02-16 | Eric Wood | Computer implemented method and system for running a plurality of business processes |
US20070179833A1 (en) * | 2006-01-31 | 2007-08-02 | Infosys Technologies Ltd. | Assisted business process exception management |
US20070233500A1 (en) * | 2006-02-27 | 2007-10-04 | Microsoft Corporation | Pluggable business logic |
US20080184201A1 (en) * | 2007-01-26 | 2008-07-31 | Microsoft Corporation | Universal schema for representing management policy |
US20080184277A1 (en) * | 2007-01-26 | 2008-07-31 | Microsoft Corporation | Systems management policy validation, distribution and enactment |
US20080263060A1 (en) * | 2007-04-23 | 2008-10-23 | Benantar Messaoud B | Policy-Based Access Control Approach to Staff Activities of a Business Process |
US20080282262A1 (en) * | 2007-05-10 | 2008-11-13 | Microsoft Corporation | Automatic and configurable loading of loosely coupled service oriented software components |
US20090018983A1 (en) * | 2007-07-13 | 2009-01-15 | El-Rafei Sherif M | Method and system for detecting anomalous process behavior |
US20090125366A1 (en) * | 2007-11-13 | 2009-05-14 | Dipanjan Chakraborty | Method and system for dynamic adaptation of workflows |
CN102571752A (en) * | 2011-12-03 | 2012-07-11 | 山东大学 | Service-associative-index-map-based quality of service (QoS) perception Top-k service combination system |
CN102902543A (en) * | 2012-09-29 | 2013-01-30 | 山东浪潮齐鲁软件产业股份有限公司 | Web service application framework model |
US20130247136A1 (en) * | 2012-03-14 | 2013-09-19 | International Business Machines Corporation | Automated Validation of Configuration and Compliance in Cloud Servers |
US8793706B2 (en) | 2010-12-16 | 2014-07-29 | Microsoft Corporation | Metadata-based eventing supporting operations on data |
US20150019699A1 (en) * | 2013-07-12 | 2015-01-15 | Samsung Eletrônica da Amazônia Ltda. | System and method for controlling the trigger and execution of management policies |
US9406040B2 (en) * | 2014-08-13 | 2016-08-02 | Sap Se | Classification and modelling of exception types for integration middleware systems |
US11205150B2 (en) * | 2004-05-26 | 2021-12-21 | International Business Machines Corporation | Apparatus and method for policy-driven business process exception handling |
Families Citing this family (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8949104B2 (en) | 2011-05-19 | 2015-02-03 | International Business Machines Corporation | Monitoring enterprise performance |
US9201723B2 (en) * | 2011-06-27 | 2015-12-01 | International Business Machines Corporation | Fault handling in a distributed IT environment |
US10565536B2 (en) | 2015-07-01 | 2020-02-18 | International Business Machines Corporation | Automated process reversal |
CN106789343B (en) * | 2017-01-21 | 2019-11-12 | 桂林电子科技大学 | A kind of service combining method having accessibility authentication mechanism |
Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20030191679A1 (en) * | 2002-04-08 | 2003-10-09 | Fabio Casati | Method and system for event management in business processes |
US6640249B1 (en) * | 1999-08-31 | 2003-10-28 | Accenture Llp | Presentation services patterns in a netcentric environment |
US6853974B1 (en) * | 1998-08-24 | 2005-02-08 | Hitachi, Ltd. | Workflow system, workflow control method and storage medium |
US6918053B1 (en) * | 2000-04-28 | 2005-07-12 | Microsoft Corporation | Compensation framework for long running transactions |
Family Cites Families (24)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP2500355B2 (en) * | 1993-05-07 | 1996-05-29 | 工業技術院長 | Josephson logic integrated circuit device |
US5485620A (en) * | 1994-02-25 | 1996-01-16 | Automation System And Products, Inc. | Integrated control system for industrial automation applications |
US5845067A (en) * | 1996-09-09 | 1998-12-01 | Porter; Jack Edward | Method and apparatus for document management utilizing a messaging system |
US6434628B1 (en) * | 1999-08-31 | 2002-08-13 | Accenture Llp | Common interface for handling exception interface name with additional prefix and suffix for handling exceptions in environment services patterns |
US6256773B1 (en) * | 1999-08-31 | 2001-07-03 | Accenture Llp | System, method and article of manufacture for configuration management in a development architecture framework |
WO2001046884A2 (en) * | 1999-12-21 | 2001-06-28 | Ecargoservice, Inc. | System for interdependent integration and aggregation |
US20020029207A1 (en) * | 2000-02-28 | 2002-03-07 | Hyperroll, Inc. | Data aggregation server for managing a multi-dimensional database and database management system having data aggregation server integrated therein |
IT1320393B1 (en) * | 2000-06-05 | 2003-11-26 | Cselt Centro Studi Lab Telecom | PROCEDURE FOR ELECTROMAGNETIC MODELING OF EXISTING ELECTRONIC COMPONENTS. |
US6895382B1 (en) * | 2000-10-04 | 2005-05-17 | International Business Machines Corporation | Method for arriving at an optimal decision to migrate the development, conversion, support and maintenance of software applications to off shore/off site locations |
US20020107830A1 (en) * | 2001-02-07 | 2002-08-08 | Murthi Nanja | Aggregating web data on clients and distributing the aggregated data to wireless handheld device |
US7082610B2 (en) * | 2001-06-02 | 2006-07-25 | Redback Networks, Inc. | Method and apparatus for exception handling in a multi-processing environment |
US7761319B2 (en) * | 2001-06-08 | 2010-07-20 | Click Acqusitions, Inc. | Supply chain management |
US7363353B2 (en) * | 2001-07-06 | 2008-04-22 | Juniper Networks, Inc. | Content service aggregation device for a data center |
US20030090514A1 (en) * | 2001-10-23 | 2003-05-15 | Cole Douglas J. | Business process user interface generation system and method |
US8321236B2 (en) * | 2002-02-01 | 2012-11-27 | Walgreen Co. | Method and apparatus for prescription processing |
DE10206000A1 (en) * | 2002-02-14 | 2003-08-21 | Alcatel Sa | Installation Server |
US20030233631A1 (en) * | 2002-06-13 | 2003-12-18 | Ambrose Curry | Web services development method |
US20040230447A1 (en) * | 2003-03-14 | 2004-11-18 | Sven Schwerin-Wenzel | Collaborative workspaces |
US20050267765A1 (en) * | 2004-05-26 | 2005-12-01 | Jun-Jang Jeng | Apparatus and method for policy-driven business process exception handling |
US7848942B2 (en) * | 2004-12-28 | 2010-12-07 | Sap Aktiengesellschaft | Distribution of integrated business process models |
US7469406B2 (en) * | 2006-07-31 | 2008-12-23 | Sap Ag | Process suspension through process model design |
US20080065397A1 (en) * | 2006-09-08 | 2008-03-13 | Ying Huang | Managing composite enterprise services through multi-layer decomposition |
US20080119201A1 (en) * | 2006-11-22 | 2008-05-22 | Jonathan Kolber | System and method for matching users of mobile communication devices |
ES2408054B1 (en) * | 2010-11-10 | 2014-02-28 | Telefónica, S.A. | METHOD AND SYSTEM FOR THE MANAGEMENT OF VIRTUAL MACHINES IN CLOUD STORAGE ENVIRONMENTS WITH NETWORK CONNECTION |
-
2004
- 2004-05-26 US US10/853,503 patent/US20050267765A1/en not_active Abandoned
-
2008
- 2008-04-02 US US12/061,089 patent/US11205150B2/en active Active
Patent Citations (4)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6853974B1 (en) * | 1998-08-24 | 2005-02-08 | Hitachi, Ltd. | Workflow system, workflow control method and storage medium |
US6640249B1 (en) * | 1999-08-31 | 2003-10-28 | Accenture Llp | Presentation services patterns in a netcentric environment |
US6918053B1 (en) * | 2000-04-28 | 2005-07-12 | Microsoft Corporation | Compensation framework for long running transactions |
US20030191679A1 (en) * | 2002-04-08 | 2003-10-09 | Fabio Casati | Method and system for event management in business processes |
Cited By (24)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20050222895A1 (en) * | 2004-04-03 | 2005-10-06 | Altusys Corp | Method and Apparatus for Creating and Using Situation Transition Graphs in Situation-Based Management |
US11205150B2 (en) * | 2004-05-26 | 2021-12-21 | International Business Machines Corporation | Apparatus and method for policy-driven business process exception handling |
US7739695B2 (en) * | 2004-07-19 | 2010-06-15 | Sap Ag | Computer implemented method and system for running a plurality of business processes |
US20060036687A1 (en) * | 2004-07-19 | 2006-02-16 | Eric Wood | Computer implemented method and system for running a plurality of business processes |
US20070179833A1 (en) * | 2006-01-31 | 2007-08-02 | Infosys Technologies Ltd. | Assisted business process exception management |
US20070233500A1 (en) * | 2006-02-27 | 2007-10-04 | Microsoft Corporation | Pluggable business logic |
US7873967B2 (en) | 2006-02-27 | 2011-01-18 | Microsoft Corporation | Pluggable business logic |
US20080184201A1 (en) * | 2007-01-26 | 2008-07-31 | Microsoft Corporation | Universal schema for representing management policy |
US20080184277A1 (en) * | 2007-01-26 | 2008-07-31 | Microsoft Corporation | Systems management policy validation, distribution and enactment |
US8104080B2 (en) | 2007-01-26 | 2012-01-24 | Microsoft Corporation | Universal schema for representing management policy |
US20080263060A1 (en) * | 2007-04-23 | 2008-10-23 | Benantar Messaoud B | Policy-Based Access Control Approach to Staff Activities of a Business Process |
US8904391B2 (en) * | 2007-04-23 | 2014-12-02 | International Business Machines Corporation | Policy-based access control approach to staff activities of a business process |
US20080282262A1 (en) * | 2007-05-10 | 2008-11-13 | Microsoft Corporation | Automatic and configurable loading of loosely coupled service oriented software components |
US9633198B2 (en) | 2007-07-13 | 2017-04-25 | International Business Machines Corporation | Detecting anomalous process behavior |
US20090018983A1 (en) * | 2007-07-13 | 2009-01-15 | El-Rafei Sherif M | Method and system for detecting anomalous process behavior |
US8719190B2 (en) | 2007-07-13 | 2014-05-06 | International Business Machines Corporation | Detecting anomalous process behavior |
US20090125366A1 (en) * | 2007-11-13 | 2009-05-14 | Dipanjan Chakraborty | Method and system for dynamic adaptation of workflows |
US8793706B2 (en) | 2010-12-16 | 2014-07-29 | Microsoft Corporation | Metadata-based eventing supporting operations on data |
CN102571752A (en) * | 2011-12-03 | 2012-07-11 | 山东大学 | Service-associative-index-map-based quality of service (QoS) perception Top-k service combination system |
US20130247136A1 (en) * | 2012-03-14 | 2013-09-19 | International Business Machines Corporation | Automated Validation of Configuration and Compliance in Cloud Servers |
CN102902543A (en) * | 2012-09-29 | 2013-01-30 | 山东浪潮齐鲁软件产业股份有限公司 | Web service application framework model |
US9584368B2 (en) * | 2013-07-12 | 2017-02-28 | Samsung Eletrônica da Amazônia Ltda. | System and method for controlling the trigger and execution of management policies |
US20150019699A1 (en) * | 2013-07-12 | 2015-01-15 | Samsung Eletrônica da Amazônia Ltda. | System and method for controlling the trigger and execution of management policies |
US9406040B2 (en) * | 2014-08-13 | 2016-08-02 | Sap Se | Classification and modelling of exception types for integration middleware systems |
Also Published As
Publication number | Publication date |
---|---|
US11205150B2 (en) | 2021-12-21 |
US20080189534A1 (en) | 2008-08-07 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US11205150B2 (en) | Apparatus and method for policy-driven business process exception handling | |
Zeng et al. | Policy-driven exception-management for composite web services | |
Georgakopoulos et al. | An overview of workflow management: From process modeling to workflow automation infrastructure | |
Dayal et al. | Business Process Coordination: State of the Art, Trends, and Open Issues. | |
Wohed et al. | Pattern based analysis of BPEL4WS | |
Van Der Aalst et al. | Design and implementation of the YAWL system | |
Pinter et al. | Discovering workflow models from activities’ lifespans | |
US8572633B2 (en) | Exception handling for collaborating process models | |
US20060080117A1 (en) | Maintaining integrity within an adaptive value chain involving cross enterprise interactions | |
Wohed et al. | Patterns-based evaluation of open source BPM systems: The cases of jBPM, OpenWFE, and Enhydra Shark | |
US8819695B2 (en) | Controlling application landscapes | |
Elmagarmid et al. | Workflow management: State of the art versus state of the products | |
Rukoz et al. | Faceta*: Checkpointing for transactional composite web service execution based on petri-nets | |
US20090158242A1 (en) | Library of services to guarantee transaction processing application is fully transactional | |
Fugini et al. | Recovery of faulty web applications through service discovery | |
Golani et al. | Flexible business process management using forward stepping and alternative paths | |
Casati et al. | Error handling in process support systems | |
Redding et al. | Generating business process models from object behavior models | |
Fang et al. | Dynamic support for BPEL process instance adaptation | |
JP4493692B2 (en) | Self-healing device for handling complex web service processes | |
Du et al. | Workflow management: State of the art vs. state of the products | |
Soleimani Malekan et al. | Overview of business process modeling languages supporting enterprise collaboration | |
Luo | Knowledge sharing, coordinated exception handling, and intelligent problem solving for cross-organizational business processes | |
Maamar et al. | On business process monitoring using cross-flow coordination | |
Dasgupta et al. | Design of a Fault-tolerant Job-flow Manager for Grid Environments Using Standard Technologies, Job-flow Patterns, and a Transparent Proxy. |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: INTERNATIONAL BUSINESS MACHINES CORPORATION, NEW Y Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:JENG, JUN-JANG;LEI, HUI;ZENG, LIANGZHAO;AND OTHERS;REEL/FRAME:015401/0544;SIGNING DATES FROM 20040517 TO 20040525 |
|
STCB | Information on status: application discontinuation |
Free format text: ABANDONED -- FAILURE TO RESPOND TO AN OFFICE ACTION |