Generic wait service: pausing a BPEL process

• US 9,122,520 B2
• Filed: 09/17/2008
• Issued: 09/01/2015
• Est. Priority Date: 09/17/2008
• Status: Active Grant

• Current Assignee: Oracle International Corporation (Oracle Corporation)
• Original Assignee: Oracle International Corporation (Oracle Corporation)
• Inventors: Addala, Raju, Singh, Alok, Kozic, Scott, Sridharan, Sarita, Datti, Sunita
• Primary Examiner(s): Caldwell, Andrew
• Assistant Examiner(s): GEIB, BENJAMIN P
• Application Number:
  US12/212,599
• Publication Number:
  US 20100070973A1
• Time in Patent Office: 2,540 Days
• Field of Search: 709/224, 719/313, 718/100
• US Class Current: 1/1
• CPC Class Codes: G06F 2209/544 Remote
• CPC Class Codes: G06F 9/485 Task life-cycle, e.g. stopping, restarting, resuming execution G06F9/4881 takes precedence
• CPC Class Codes: G06F 9/52 Program synchronisation; Mutual exclusion, e.g. by means of semaphores
• CPC Class Codes: G06F 9/542 Event management; Broadcasting; Multicasting; Notifications

Abstract

A generic wait service for facilitating the pausing of service-oriented applications. In one set of embodiments, the generic wait service receives, from a paused instance of an application, an initiation message comprising a set of key attributes and an exit criterion. The key attributes uniquely identify the paused instance, and the exit criterion identifies a condition that should be satisfied before the paused instance is allowed to proceed. The generic wait service then receives, from one or more event producers, notification messages comprising status information (e.g., statuses of business events) and information correlating the notification messages to particular instances. If a notification message is determined to be correlated to the paused instance, the generic wait service evaluates the exit criterion based on the status information included in the message. If the exit criterion is satisfied, the paused instance is notified of the status information and is allowed to proceed.

Claims

1. A method performed by a generic wait service for pausing an instance of a service-oriented application the method comprising:

receiving, from the instance of the service-oriented application, an initiation message including a first set of attributes and an exit criterion, the first set of attributes uniquely identifying the instance, the exit criterion identifying a condition that should be satisfied before the instance is allowed to resume;

defining two or more wait states in parallel for the instance, wherein the two or more wait states include a first wait state in which a first task flow begins execution after the first wait state and a second wait state in which a second task flow begins execution after the second wait state which is parallel to the first wait state;

de-coupling the service-oriented application from event producers responsible for generating status information, wherein the service-oriented application is not required to be aware of technical complexities involved in correlating a notification message received from the event producers to a particular paused instance, and the event producers are not required to be aware of the instance that is waiting for status information;

based on the first and second wait states, creating a correlation set based on the first set of attributes, the correlation set associating the first set of attributes with the instance;

pausing the instance;

waiting for status information relevant to the instance;

receiving, from an event producer, a notification message including a second set of attributes and a status of a business event;

determining, based on the correlation set, that the status is relevant to the instance;

determining, based on the status, that the exit criterion is satisfied; and

in response to the exit criterion being satisfied, sending the status to the instance and resuming the instance.

2. The method of claim 1, wherein the service-oriented application and the generic wait service are Business Process Execution Language (BPEL) processes.

3. The method of claim 2, wherein the generic wait service is an asynchronous BPEL process.

4. The method of claim 1, wherein the event producer is a web service.

5. The method of claim 1, wherein determining, based on the correlation set, whether the status is relevant to the instance comprises comparing the second set of attributes to the first set of attributes.

6. The method of claim 1, further comprising terminating the waiting for status information relevant to the instance by deleting the correlation set.

7. The method of claim 1, wherein the initiation message further includes a target condition, the target condition identifying a condition that the instance would like to be notified of, and wherein the method further comprises:

if the status is relevant to the instance, determining, based on the status, whether the exit criterion or the target condition is satisfied;

if the exit criterion is satisfied;

sending the status to the instance; and

terminating any further waiting for status information relevant to the instance; and

if the target condition is satisfied;

sending the status to the instance; and

continuing to wait for status information relevant to the instance.

8. The method of claim 1, wherein the method further comprises:

receiving, from an intermediary update service, the notification message, the notification message originating from the event producer in communication with the intermediary update service;

if the status is relevant to the instance, determining, based on the status, whether the exit criterion is satisfied; and

if the exit criterion is satisfied;

sending the status to the instance; and

terminating any further waiting for status information relevant to the instance.

9. The method of claim 8, wherein the intermediary update service is configured to transform data in the notification message prior to sending the notification message to the generic wait service.

10. The method of claim 8, wherein the service-oriented application, generic wait service, and intermediary service are internal to an organization, and wherein the event producer is external to the organization.

11. A system for pausing an instance of a service-oriented application, the system comprising:

a first server for running the service-oriented application; and

a second server for running a generic wait service, wherein the generic wait service is configured to;

receive, from the instance of the service-oriented application, an initiation message including a first set of attributes and an exit criterion, the first set of attributes uniquely identifying the instance, the exit criterion identifying a condition that should be satisfied before the instance is allowed to resume;

define two or more wait states in parallel for the instance, wherein the two or more wait states include a first wait state in which a first task flow begins execution after the first wait state and a second wait state in which a second task flow begins execution after the second wait state which is parallel to the first wait state;

de-couple the service-oriented application from event producers responsible for generating status information, wherein the service-oriented application is not required to be aware of technical complexities involved in correlating a notification message received from the event producers to a particular paused instance, and the event producers are not required to be aware of the instance that is waiting for status information;

based on the first and second wait states, create a correlation set based on the first set of attributes, the correlation set associating the first set of attributes with the instance;

pause the instance;

wait for status information relevant to the instance;

receive, from an event producer, a notification message including a second set of attributes and a status of a business event;

determine, based on the correlation set, that the status is relevant to the instance;

determine, based on the status, that the exit criterion is satisfied; and

in response to the exit criterion being satisfied, send the status to the instance and resuming the instance.

12. The system of claim 11, wherein the initiation message further includes a target condition, the target condition identifying a condition that the instance would like to be notified of, and wherein the generic wait service is further configured to:

if the status is relevant to the instance, determine, based on the status, whether the exit criterion or the target condition is satisfied;

if the exit criterion is satisfied;

send the status to the instance; and

terminate any further waiting for status information relevant to the instance; and

if the target condition is satisfied;

send the status to the instance; and

continue to wait for status information relevant to the instance.

13. The system of claim 11 further comprising:

a third server for running an intermediary update service, wherein the intermediary update service is configured to;

receive, from the event producer, the notification message;

transform the notification message by converting the second set of attributes into a third set of attributes; and

send the transformed notification message to the generic wait service;

and wherein the generic wait service is further configured to;

receive the transformed notification message;

determine, based on the correlation set, whether the status included in the transformed notification message is relevant to the instance;

if the status is relevant to the instance, determine, based on the status, whether the exit criterion is satisfied; and

if the exit criterion is satisfied;

send the status to the instance; and

terminate any further waiting for status information relevant to the instance.

14. The system of claim 13, wherein determining, based on the correlation set, whether the status is relevant to the instance comprises comparing the third set of attributes to the first set of attributes.

15. A non-transitory machine-readable medium for a computer system, the machine-readable medium having stored thereon program code which, when executed by a processing component of the computer system, causes the processing component to:

receive, from the instance of the service-oriented application, an initiation message including a first set of attributes and an exit criterion, the first set of attributes uniquely identifying the instance, the exit criterion identifying a condition that should be satisfied before the instance is allowed to resume;

define two or more wait states in parallel for the instance, wherein the two or more wait states include a first wait state in which a first task flow begins execution after the first wait state and a second wait state in which a second task flow begins execution after the second wait state which is parallel to the first wait state;

de-couple the service-oriented application from event producers responsible for generating status information, wherein the service-oriented application is not required to be aware of technical complexities involved in correlating a notification message received from the event producers to a particular paused instance, and the event producers are not required to be aware of the instance that is waiting for status information;

based on the first and second wait states, create a correlation set based on the first set of attributes, the correlation set associating the first set of attributes with the instance;

pause the instance;

wait for status information relevant to the instance;

receive, from an event producer, a notification message including a second set of attributes and a status of a business event;

determine, based on the correlation set, that the status is relevant to the instance;

determine, based on the status, that the exit criterion is satisfied; and

in response to the exit criterion being satisfied, send the status to the instance and resuming the instance.

16. The non-transitory machine-readable medium of claim 15, wherein the initiation message further includes a target condition, the target condition identifying a condition that the instance would like to be notified of, and wherein the program code further causes the processing component to:

if the status is relevant to the instance, determine, based on the status, whether the exit criterion or the target condition is satisfied;

if the exit criterion is satisfied, send the status to the instance, and terminating any further waiting for status information relevant to the instance; and

if the target condition is satisfied, send the status to the instance, and continuing to wait for status information relevant to the instance.

17. The non-transitory machine-readable medium of claim 15, wherein the program code further causes the processing component to:

receive, from an intermediary update service, the notification message, the notification message originating from the event producer in communication with the intermediary update service;

based on the correlation set, whether the status is relevant to the instance;

if the status is relevant to the instance, determine, based on the status, whether the exit criterion is satisfied; and

if the exit criterion is satisfied, send the status to the instance, and terminating any further waiting for status information relevant to the instance.

18. The non-transitory machine-readable medium of claim 17, wherein the intermediary update service is configured to transform data in the notification message prior to sending the notification message to the generic wait service.