Generic wait service: pausing a BPEL process

Information

  • Patent Grant
  • 9122520
  • Patent Number
    9,122,520
  • Date Filed
    Wednesday, September 17, 2008
    16 years ago
  • Date Issued
    Tuesday, September 1, 2015
    9 years ago
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.
Description
BACKGROUND OF THE INVENTION

Embodiments of the present invention relate to service-oriented computing, and more particularly relate to techniques for pausing an instance of a service-oriented application.


In recent years, many organizations have adopted Service-Oriented Architecture (SOA) for building and integrating their business applications. Generally speaking, SOA is a software model that encapsulates business functionality into a collection of modular software components, known as services. Each service exposes a well-defined interface that is independent of the service's underlying implementation (e.g., hardware/software platform, programming language, etc.). Using these interfaces, the various services can interact to provide services to, and consume services from, each other.


One advantage of the SOA paradigm is that business applications can be structured as compositions of one or more component services. These types of applications are referred to herein as service-oriented applications. For example, a service-oriented application for carrying out an order fulfillment business process may be structured as a composition of (1) an internal query service for retrieving the details of a customer order, (2) an external credit service for checking the customer's credit, (3) an internal inventory service for reserving the items included in the order, and (4) an external shipping service for processing shipment. The structural definition of a service-oriented application (including, for example, the types of services accessed, the sequencing of service operation invocations, fault handling, etc.) is typically expressed in an orchestration language, such as Business Process Execution Language (BPEL). A BPEL-based definition of a service-oriented application is known as a BPEL process.


In many instances, it may be desirable to suspend, or pause, the runtime flow of a BPEL process until one or more business conditions have been satisfied. For example, in the order fulfillment application above, it may be desirable to wait for verification that the customer's credit is satisfactory, and/or wait for confirmation that the customer's order items have been reserved, before proceeding to ship the order. According to one known approach, this “pausing” functionality can be implemented by using a synchronized message exchange between the BPEL process and the entities responsible for generating status information relevant to the business conditions (referred to herein as “event producers”). In this type of implementation, the BPEL process invokes an event producer and waits for an indication from the event producer that the business condition is satisfied before proceeding to the next task or step.


One problem with the above approach is that it requires the BPEL process to wait for responses from event producers in a serial fashion. Thus, the application cannot handle multiple simultaneous (or parallel) wait states in a single runtime instance. For example, using a synchronous message exchange pattern, an instance of the order fulfillment application cannot wait for responses from the credit service and the inventory service in parallel; rather, the instance must wait for a response from the credit service, and then wait for a response from the inventory service, or vice versa. This limits the types of task flows that can implemented within the process.


BRIEF SUMMARY OF THE INVENTION

Embodiments of the present invention address the foregoing and other such problems by providing a generic wait service for facilitating the pausing of service-oriented applications (e.g., BPEL processes). 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.


Since the processing performed by the generic wait service is performed independently and asynchronously of the calling application, the limitations associated with prior art “pausing” techniques are minimized or eliminated. For example, using the embodiments described herein, the calling application can be designed to incorporate multiple simultaneous (or parallel) wait states by simply making multiple, asynchronous calls to the generic wait service. Further, since all of the pausing logic (e.g., logic for correlating event statuses to specific instances, logic for determining when an exit criterion is satisfied, etc.) is encapsulated in the generic wait service, this logic does not need to be duplicated in each calling application or each event producer. Rather, these entities can simply interact with a single, central service (i.e., the generic wait service) to implement pausing functionality.


According to one embodiment of the present invention, a method performed by a generic wait service for pausing an instance of a service-oriented application comprises receiving, from the instance of the application, an initiation message including a first set of attributes that uniquely identify the instance, and an exit condition that identifies a condition that should be satisfied before the instance is allowed to proceed. The method further comprises creating a correlation set based on the first set of attributes, the correlation set associating the first set of attributes with the instance, and waiting for status information relevant to the instance. In one embodiment, the service-oriented application and the generic wait service are separate BPEL processes. In a further embodiment, the generic wait service is an asynchronous BPEL process.


In one set of embodiments, the method above further comprises receiving, from an event producer, a notification message including a second set of attributes and a status of a business event, and determining, based on the correlation set, whether the status is relevant to the instance. In an embodiment, the determining step comprises comparing the second set of attributes to the first set of attributes. If the status is relevant to the instance, the exit criterion is evaluated based on the status. If the exit criterion is satisfied, the status is sent to the instance and any further waiting for status information relevant to the instance is terminated. In an embodiment, the terminating step comprises deleting the correlation set.


In one set of embodiments, the initiation message includes a target condition identifying a condition that the instance would like to be notified of. In these embodiments, the method above further comprises receiving, from an event producer, a notification message including a second set of attributes and a status of a business event, and determining, based on the correlation set, whether the status is relevant to the instance. If the status is relevant to the instance, the exit criterion and/or the target condition is evaluated based on the status. If the exit criterion is satisfied, the status is sent to the instance and any further waiting for status information relevant to the instance is terminated. If the target condition is satisfied, the status is sent to the instance and the generic wait service continues to wait for status information relevant to the instance.


In one set of embodiments, the event producers are configured to communicate with an intermediary update service rather than the generic wait service. In these embodiments, the method above further comprises receiving, from the intermediary update service, a notification message including a second set of attributes and a status of a business event, the notification message originating from an event producer in communication with the intermediary update service, and determining, based on the correlation set, whether the status is relevant to the instance. If the status is relevant to the instance, the exit criterion is evaluated based on the status. If the exit criterion is satisfied, the status is sent to the instance and any further waiting for status information relevant to the instance is terminated. In an embodiment, the intermediary update service is configured to transform data in the notification message prior to sending the notification message to the generic wait service.


In one set of embodiments, the service-oriented application, generic wait service, and intermediary update service are internal to an organization, and the event producer is external to the organization.


According to another embodiment of the present invention, a system for pausing an instance of a service-oriented application is disclosed. The system comprises a first server for running the service-oriented application, and a second server for running a generic wait service. In various embodiments, the generic wait service is configured to receive, from the instance of the application, an initiation message including a first set of attributes that uniquely identifies the instance, and an exit criterion that identifies a condition that should be satisfied before the instance is allowed to proceed. The generic wait service then creates a correlation set based on the first set of attributes, the correlation set associating the first set of attributes with the instance, and waits for status information relevant to the instance.


In one set of embodiments, the generic wait service is further configured to receive, from an event producer, a notification message including a second set of attributes and a status of a business event, and determine, based on the correlation set, whether the status is relevant to the instance. If the status is relevant to the instance, the generic wait service is configured to determine, based on the status, whether the exit criterion is satisfied. If the exit criterion is satisfied, the generic wait service is configured to send the status to the instance and terminate any further waiting for status information relevant to the instance.


In one set of embodiments, the initiation message includes a target condition identifying a condition that the instance would like to be notified of. In these embodiments, the generic wait service is further configured to receive, from an event producer, a notification message including a second set of attributes and a status of a business event, and determine, based on the correlation set, whether the status is relevant to the instance. If the status is relevant to the instance, the generic wait service is configured to determine, based on the status, whether the exit criterion or the target condition is satisfied. If the exit criterion is satisfied, the generic wait service is configured to send the status to the instance and terminate any further waiting for status information relevant to the instance. If the target condition is satisfied, the generic wait service is configured to send the status to the instance and continue to wait for status information relevant to the instance.


In one set of embodiments, the system further comprises a third server for running an intermediary update service, wherein the intermediary update service is configured to receive, from an event producer, a notification message including a second set of attributes and a status of a business event, 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. In these embodiments, the generic wait service is configured to receive the transformed notification message and 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, the generic wait service is configured to determine, based on the status, whether the exit criterion is satisfied. If the exit criterion is satisfied, the generic wait service is configured to send the status to the instance and terminate any further waiting for status information relevant to the instance. In one embodiment, the step of determining whether the status is relevant to the instance comprises comparing the third set of attributes to the first set of attributes.


According to another embodiment of the present invention, a machine-readable medium for a computer system is disclosed. The machine-readable medium has stored thereon program code which, when executed by a processing component of the computer system, causes the processing component to pause an instance of a service-oriented application. The program code comprises code for receiving, from the instance of the application, an initiation message including a first set of attributes that uniquely identifies the instance, and an exit criterion that uniquely identifies a condition that should be satisfied before the instance is allowed to proceed. The program code further comprises code for creating a correlation set based on the first set of attributes, the correlation set associating the first set of attributes with the instance, and code for waiting for status information relevant to the instance.


In one set of embodiments, the program code above further comprises code for receiving, from an event producer, a notification message including a second set of attributes and a status of a business event; code for determining, based on the correlation set, whether the status is relevant to the instance; code for, if the status is relevant to the instance, determining, based on the status, whether the exit criterion is satisfied; and code for, if the exit criterion is satisfied, sending the status to the instance and terminating any further waiting for status information relevant to the instance.


In one set of embodiments, the initiation message includes a target condition identifying a condition that the instance would like to be notified of. In these embodiments, the program code above further comprises code for receiving, from an event producer, a notification message including a second set of attributes and a status of a business event; code for determining, based on the correlation set, whether the status is relevant to the instance; code for, if the status is relevant to the instance, determining, based on the status, whether the exit criterion or the target condition is satisfied; code for, 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 code for, if the target condition is satisfied, sending the status to the instance and continuing to wait for status information relevant to the instance.


In one set of embodiments, the event producers are configured to communicate with an intermediary update service rather than the generic wait service. In these embodiments, the program code above further comprises code for receiving, from the intermediary update service, a notification message including a second set of attributes and a status of a business event, the notification message originating from an event producer in communication with the intermediary update service; code for determining, based on the correlation set, whether the status is relevant to the instance; code for, if the status is relevant to the instance, determining, based on the status, whether the exit criterion is satisfied; and code for, if the exit criterion is satisfied, sending the status to the instance and terminating any further waiting for status information relevant to the instance. In an embodiment, the intermediary update service is configured to transform data in the notification message prior to sending the notification message to the generic wait service.


A further understanding of the nature and advantages of the embodiments disclosed herein may be realized by reference to the remaining portions of the specification and the attached drawings.





BRIEF DESCRIPTION OF THE DRAWINGS

Various embodiments in accordance with the present invention will be described with reference to the drawings, in which:



FIG. 1 is a simplified block diagram illustrating functional components of a service-oriented system in accordance with an embodiment of the present invention.



FIG. 2 is a flowchart illustrating steps performed by a generic wait service in processing an initiation message received from a service-oriented application in accordance with an embodiment of the present invention.



FIG. 3 is a flowchart illustrating steps performed by a generic wait service in processing a notification message received from an event producer in accordance with an embodiment of the present invention.



FIG. 4 is a flowchart illustrating further steps performed by a generic wait service in processing a notification message received from an event producer in accordance with an embodiment of the present invention.



FIG. 5 is a simplified block diagram illustrating functional components of another service-oriented system in accordance with an embodiment of the present invention.



FIG. 6 is a flowchart illustrating steps performed by a generic wait service in processing a notification message received from an intermediary update service in accordance with an embodiment of the present invention.



FIG. 7 is a simplified block diagram illustrating a system environment that may be used in accordance with an embodiment of the present invention.



FIG. 8 is a simplified block diagram illustrating a computer system that may be used in accordance with an embodiment of the present invention.





In the drawings, the use of like reference numbers in different drawings indicates similar components.


DETAILED DESCRIPTION OF THE INVENTION

In the following description, for the purposes of explanation, numerous specific details are set forth in order to provide an understanding of the present invention. It will be apparent, however, to one skilled in the art that the present invention may be practiced without some of these specific details.


Embodiments of the present invention provide a generic wait service for facilitating the pausing of service-oriented applications (e.g., BPEL processes). As discussed above, it is often useful to pause a runtime instance of a service-oriented application until a specific business condition has been satisfied. The generic wait service of the present invention is capable of tracking these conditions for multiple paused instances, consuming status information from various event producers, determining, based on the consumed status information, whether any of the conditions have been satisfied, and notifying the paused instances accordingly.


Embodiments of the present invention have several advantages. First, unlike prior art approaches, these embodiments allow an application developer to define multiple simultaneous (or parallel) wait states in a single runtime instance. For example, the application developer could create one task flow that begins execution after a first wait state, and another task flow that begins execution after a second wait state that is parallel to the first. Second, these embodiments effectively de-couple the service-oriented applications from the event producers responsible for generating status information. In other words, the service-oriented applications do not need to be aware of the technical complexities involved in correlating a notification message received from an event producer to a particular paused instance, and the event producers do not need to be aware of the actual instances that are waiting for status information. Third, since the logic for implementing pausing functionality is encapsulated in the generic wait service, this logic does not need to duplicated in the service-oriented applications or the event producers, thereby reducing code duplication and increasing development productivity.



FIG. 1 is a simplified block diagram illustrating functional components of a service-oriented system 100 in accordance with an embodiment of the present invention. As shown, system 100 includes two applications 104, 106 and two event producers 108, 110. In one set of embodiments, applications 104, 106 are service-oriented applications that are designed to be paused until one or more business conditions are satisfied. Event producers 108, 110 are entities that generate status information (e.g., statuses of business events) relevant to those business conditions. For example, assume application 104 is an order fulfillment application and event producer 108 is an external shipping service. In this case, application 104 may be paused at a point in its task flow until its receives a notification from event producer 108 that a customer's order has been shipped. In one set of embodiments, applications 104, 106 and event producers 108, 110 are BPEL processes. In a further set of embodiments, applications 104, 106 and event producers 108,110 are implemented as web services.


To facilitate the pausing of applications 104, 106, system 100 includes a generic wait service 102. As shown, generic wait service 102 is a standalone service that is independent of applications 104, 106 and event producers 108, 110. Like applications 104, 106 and event producers 108, 110, generic wait service 102 may be a BPEL process. In one set of embodiments, generic wait service 102 is configured to receive initiation messages from instances of applications 104, 106 that identify the business conditions they are waiting for, and notification messages from event producers 108, 110 that identify the statuses of business events. Using the information received via these messages, generic wait service 102 can determine when the respective business conditions identified by the instances of applications 104, 106 are satisfied and notify the instances accordingly. In one set of embodiments, generic wait service 102 is configured to correlate the notification messages received from event producers 108, 110 to particular application instances via key attributes associated with each instance. This enables generic wait service 102 to process multiple paused instances simultaneously. The interactions between applications 104, 106, event producers 108, 110, and generic wait service 102 are discussed in further detail below.


It should be appreciated that FIG. 1 illustrates a particular functional configuration of a service-oriented system according to an embodiment of the present invention. Other configurations are possible according to alternative embodiments. For example, although only two applications and two event producers are depicted, any number of applications and event producers may be supported by a single generic wait service. One of ordinary skill in the art would recognize many variations, modifications, and alternatives.



FIG. 2 is a flowchart 200 illustrating steps performed for pausing an instance of a service-oriented application in accordance with an embodiment of the present invention. In particular, flowchart 200 illustrates steps that may be performed by generic wait service 102 for pausing an instance of application 102 or application 104.


At step 202, a generic wait service (e.g., generic wait service 102) receives, from an instance of a service-oriented application (e.g., application 102, 104), an initialization message comprising a first set of attributes and an exit criterion. The first set of attributes are key attributes that uniquely identify the instance, and the exit criterion identifies a business condition that should be satisfied before the instance is allowed to proceed. For example, generic wait service 102 may receive from an instance of application 104 an initiation message comprising an order ID (that uniquely identifies the order being processed by the instance) and an exit criterion of “order status=shipped.”


At step 204, the generic wait service creates a correlation set based on the first set of attributes, where the correlation set associates the first set of attributes and the exit criterion with the instance. Since the generic wait service may receive initiation messages from a plurality of different application instances (each with different key attributes and exit criteria), the correlation set is used to map, or correlate, notification messages received from event producers to the specific instance of step 202.


Once the correlation set is created, the generic wait service waits for status information from one or more event producers (e.g., event producers 108, 110) (step 206). To facilitate this, the generic wait service will typically expose a one-way notification operation that is invoked by the event producers when a business condition is satisfied or the status of a business event changes. Although not shown in flowchart 100, it is important to note that the calling application instance can continue to execute parallel task flows (i.e., task flows independent of the currently paused flow) while the generic wait service is waiting for status information in step 206. In other words, the generic wait service operates asynchronously of the calling instance. Once the generic wait service receives notification that the exit criterion is satisfied and sends that information to the calling instance, the calling instance can resume execution of the paused task flow.


It should be appreciated that the steps illustrated in FIG. 2 provide a particular method for pausing an instance of a service-oriented application in accordance with an embodiment of the present invention. Other sequences of steps may also be performed according to alternative embodiments. For example, alternative embodiments of the present invention may perform the steps outlined above in a different order. Moreover, the individual steps illustrated in FIG. 2 may include multiple sub-steps that may be performed in various sequences as appropriate to the individual step. Furthermore, additional steps may be added or removed depending on the particular application. One of ordinary skill in the art would recognize many variations, modifications, and alternatives.



FIG. 3 is a flowchart 300 illustrating steps performed by a generic wait service in processing a notification message received from an event producer in accordance with an embodiment of the present invention. In particular, flowchart 300 represents a continuation of the processing in flowchart 200.


At step 302, the generic wait service checks whether it has received any notification messages from event producers. If it has not, the generic wait service continues waiting as per step 206 of flowchart 200. If it has received a notification message, the generic wait service evaluates the message to determine (1) whether it is relevant to the paused instance of step 202 (step 304), and (2) whether the exit criterion is satisfied (step 306). Generally speaking, the notification message will include a status of a business event and a set of key attributes indicating the particular entity/process that the status is related to. For example, a notification message from event producer 108 may include an order ID and a shipping status for the order. Thus, the generic wait service can determine whether the notification message is relevant to the paused instance by comparing the key attributes in the notification message to the key attributes associated with the paused instance (via the correlation set created in step 204). Further, the generic wait service can determine whether the exit criterion is satisfied based on the status of the business event.


If the notification message is determined to be relevant to the paused instance, and if the notification message indicates that the exit criterion is satisfied, the status is sent to the paused instance (step 308). In this manner, the instance is notified that it can proceed to the next task or step in its flow. Although not shown, the generic wait service will also terminate any further waiting for notification messages relevant to the instance. In one embodiment, this comprises deleting the correlation set for the instance. However, the generic wait service will continue waiting for notification messages that are relevant to other paused instances.


It should be appreciated that the steps illustrated in FIG. 3 provide a particular method for processing a notification message received from an event producer in accordance with an embodiment of the present invention. Other sequences of steps may also be performed according to alternative embodiments. For example, alternative embodiments of the present invention may perform the steps outlined above in a different order. Moreover, the individual steps illustrated in FIG. 3 may include multiple sub-steps that may be performed in various sequences as appropriate to the individual step. Furthermore, additional steps may be added or removed depending on the particular application. One of ordinary skill in the art would recognize many variations, modifications, and alternatives.


In some embodiments, the initialization message received at step 202 of flowchart 200 may include (in addition to the key attributes and the exit criterion) one or more target conditions. These target conditions are business conditions that the calling instance is interested in being notified of while waiting for the exit criterion to be satisfied. For example, application 104 might be interested in knowing when a customer order is assigned an estimated shipping date while waiting for the order to be shipped. FIG. 4 is a flowchart 400 illustrating steps performed by a generic wait service in processing a notification message when the paused instance has specified a target condition.


At steps 402 and 404, the generic wait service determines whether a notification message is received, and if so, whether the message is relevant to the paused instance. These steps are substantially similar to steps 302 and 304 of flowchart 300. At step 406, the exit criterion for the paused instance is evaluated based on status information included in the received notification message. If the exit criterion is satisfied, the status is sent to the paused instance and the generic wait service terminates any further waiting for the instance (step 408). If the exit criterion is not satisfied, the target condition is evaluated based on the status information. If the target condition is satisfied, the status is sent to the instance and the generic wait service continues waiting for notification messages relevant to the instance (step 412). Further, even if the target condition is not satisfied, the generic wait service continues waiting for notification message relevant to the instance. Thus, the waiting process will only terminate once the exit criterion has been reached.


It should be appreciated that the steps illustrated in FIG. 4 provide a particular method for processing a notification message received from an event producer in accordance with an embodiment of the present invention. Other sequences of steps may also be performed according to alternative embodiments. For example, alternative embodiments of the present invention may perform the steps outlined above in a different order. Moreover, the individual steps illustrated in FIG. 4 may include multiple sub-steps that may be performed in various sequences as appropriate to the individual step. Furthermore, additional steps may be added or removed depending on the particular application. One of ordinary skill in the art would recognize many variations, modifications, and alternatives.



FIG. 5 is a simplified block diagram illustrating functional components of another service-oriented system 500 in accordance with an embodiment of the present invention. Like system 100 of FIG. 1, system 500 includes service-oriented applications 104, 106, event producers 108, 110, and generic wait service 102. However, system 500 also includes an intermediary update service 502 that acts as an interface between generic wait service 102 and event producers 108, 110. Specifically, intermediary update service 502 is configured to receive notification messages from event producers 108, 110 and route those messages to generic wait service 102. In situations where generic wait service 102 is internal to an enterprise and event producers 108, 110 are external to the enterprise, this type of configuration is useful in protecting the generic wait service from direct exposure to external networks.


In addition, intermediary update service 502 can be configured to perform some transformation and/or enrichment of the information received from event producers 108, 110 prior to sending the information to generic wait service 102. For example, in some cases the event producers may refer to business entities/events using key attributes that do not directly correspond to the key attributes used by applications 104, 106. In these cases, intermediary update service 502 can store mappings between these disparate key attribute sets and transform one set to another as appropriate. Thus, if event producer 108 or 110 sends a notification message to intermediary update service 502 comprising key attributes that are unknown to applications 102, 104 or generic wait service 102, the update service will transform those key attributes into a known set of attributes prior to forwarding the notification message to the generic wait service.



FIG. 6 is a flowchart illustrating steps performed for processing a notification message received from an intermediary update service in accordance with an embodiment of the present invention. In particular, flowchart 600 illustrates the steps performed by generic wait service 102 in processing notification messages received from intermediary update service 502. The steps of flowchart 600 are substantially similar to flowchart 300 of FIG. 3. However, as shown in step 602, the notification message is received from the update service rather than directly from the event producers.



FIG. 7 is a simplified block diagram illustrating components of a system environment 700 that may be used to implement embodiments of the present invention. As shown, system environment 700 includes one or more server computers 702, 704, 706, 708, 712, 714 which may be general purpose computers, specialized server computers (i.e., PC servers, UNIX servers, mid-range servers, mainframe computers rack-mounted servers, etc.), server farms, server clusters, or any other appropriate arrangement and/or combination. In various embodiments, servers 702, 704, 706, 708, 712, 714 are adapted to run one or more services or software applications described in the foregoing disclosure. For example, application servers 702, 704 may be configured to run service-oriented applications 104, 106, generic wait server 706 may be configured to run generic wait service 102, intermediary update server 708 may be configured to run intermediary update service 502, and event producer servers 712, 714 may be configured to run event producers 108, 110. It should be appreciates that system environment 700 illustrates a particular configuration of servers, and other configurations are also within the scope of the present invention. For example, although two application servers, one generic wait server, one intermediary update server, and two event producer servers are shown, any number of such servers may be supported. Further, the function of various servers may, in certain embodiments, be consolidated into a single server. Yet further, although servers 702, 704, 706, 708 are shown as being “intra-enterprise” (i.e., situated within an enterprise) and servers 712, 714 are shown as being “extra-enterprise” (i.e., situated outside the enterprise), this configuration may be rearranged such that any of the servers are situated within, or outside, an enterprise.


Each server 702, 704, 706, 708, 712, 714 is configured to run an operating system, such as Microsoft Windows XP or Vista, Apple OSX, and/or UNIX-based operating systems (including without limitation the variety of GNU/Linux operating systems). Servers 702, 704, 706, 708, 712, 714 may also run any of a variety of additional server applications and/or mid-tier applications, including the services described herein. In one set of embodiments, servers 702, 704, 706, 708, 712, 714 are implemented as Web-based services. In these embodiments, servers 702, 704, 706, 708, 712, 714 may be configured to run one or more HTTP servers.


As shown, system environment 700 includes a network 710. Network 710 may be any type of network familiar to those skilled in the art that can support data communications using any of a variety of commercially-available protocols, including without limitation TCP/IP, SNA, IPX, AppleTalk, and the like. Merely by way of example, network 710 can be a local area network (LAN), such as an Ethernet network, a Token-Ring network and/or the like; a wide-area network; a virtual network, including without limitation a virtual private network (VPN); the Internet; an intranet; an extranet; a public switched telephone network (PSTN); an infra-red network; a wireless network (e.g., a network operating under any of the IEEE 802.11 suite of protocols, the Bluetooth protocol known in the art, and/or any other wireless protocol); and/or any combination of these and/or other networks.


Although not shown, system environment 700 may also include one or more databases. For instance, these databases may include a repository for storing correlation set data used by generic wait server 706 and/or intermediary update server 708. The databases may reside in a variety of locations. By way of example, the databases may reside on a storage medium local to (and/or resident in) one or more of the servers 702, 704, 706, 708, 712, 714. Alternatively, the databases may be remote from any or all of the servers 702, 704, 706, 708, 712, 714, and/or in communication (e.g., via network 710) with one or more of these. In one set of embodiments, the databases may reside in a storage-area network (SAN) familiar to those skilled in the art. Similarly, any necessary files for performing the functions attributed to the servers 702, 704, 706, 708, 712, 714 may be stored locally on the respective server and/or remotely, as appropriate. In one set of embodiments, the databases may include relational databases, such as Oracle 10g, that are adapted to store, update, and retrieve data in response to SQL-formatted commands.



FIG. 8 illustrates an exemplary computer system 800 that may be used in accordance with embodiments of the present invention. In various embodiments, computer system 800 may be used to implement any of the servers 702, 704, 706, 708, 712, 714 described above. Computer system 800 is shown comprising hardware elements that may be electrically coupled via a bus 824. The hardware elements may include one or more central processing units (CPUs) 802, one or more input devices 804 (e.g., a mouse, a keyboard, etc.), and one or more output devices 806 (e.g., a display device, a printer, etc.). Computer system 800 may also include one or more storage devices 808. By way of example, the storage device(s) 808 may include devices such as disk drives, optical storage devices, and solid-state storage devices such as a random access memory (RAM) and/or a read-only memory (ROM), which can be programmable, flash-updateable and/or the like.


Computer system 800 may additionally include a computer-readable storage media reader 812, a communications subsystem 814 (e.g., a modem, a network card (wireless or wired), an infra-red communication device, etc.), and working memory 818, which may include RAM and ROM devices as described above. In some embodiments, computer system 800 may also include a processing acceleration unit 816, which can include a digital signal processor (DSP), a special-purpose processor, and/or the like.


Computer-readable storage media reader 812 can further be connected to a computer-readable storage medium 810, together (and, optionally, in combination with storage device(s) 808) comprehensively representing remote, local, fixed, and/or removable storage devices plus storage media for temporarily and/or more permanently containing computer-readable information. Communications system 814 may permit data to be exchanged with network 710 and/or any other computer described above with respect to system environment 700.


Computer system 800 may also comprise software elements, shown as being currently located within working memory 818, including an operating system 820 and/or other code 822, such as code for service-oriented applications 104, 106, generic wait service 102, intermediary update service 502, and/or event producers 108, 110. It should be appreciated that alternative embodiments of computer system 800 may have numerous variations from that described above. For example, customized hardware might also be used and/or particular elements might be implemented in hardware, software, or both. Further, connection to other computing devices such as network input/output devices may be employed.


Storage media and computer readable media for containing code, or portions of code, can include any appropriate media known or used in the art, including storage media and communication media, such as but not limited to volatile and non-volatile, removable and non-removable media implemented in any method or technology for storage and/or transmission of information such as computer readable instructions, data structures, program modules, or other data, including RAM, ROM, EEPROM, flash memory or other memory technology, CD-ROM, digital versatile disk (DVD) or other optical storage, magnetic cassettes, magnetic tape, magnetic disk storage or other magnetic storage devices, data signals, data transmissions, or any other medium which can be used to store or transmit the desired information and which can be accessed by a computer.


Further, while the present invention has been described using a particular combination of hardware and software, it should be recognized that other combinations of hardware and software are also within the scope of the present invention. The present invention may be implemented only in hardware, or only in software, or using combinations thereof.


The specification and drawings are, accordingly, to be regarded in an illustrative rather than a restrictive sense. Many variations of the invention will become apparent to those skilled in the art upon review of the disclosure. The scope of the invention should, therefore, be determined not with reference to the above description, but instead should be determined with reference to the pending claims along with their full scope or equivalents.

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; andin 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; andterminating any further waiting for status information relevant to the instance; andif the target condition is satisfied: sending the status to the instance; andcontinuing 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; andif the exit criterion is satisfied: sending the status to the instance; andterminating 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; anda 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; andin 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; andterminate any further waiting for status information relevant to the instance; andif the target condition is satisfied: send the status to the instance; andcontinue 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; andsend 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; andif the exit criterion is satisfied: send the status to the instance; andterminate 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; andin 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; andif 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; andif 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.
US Referenced Citations (247)
Number Name Date Kind
4595981 Leung Jun 1986 A
5659754 Grove et al. Aug 1997 A
5790778 Bush et al. Aug 1998 A
5850518 Northrup Dec 1998 A
5946492 Bates Aug 1999 A
6078745 De et al. Jun 2000 A
6117180 Dave et al. Sep 2000 A
6138270 Hsu Oct 2000 A
6154877 Ramkumar et al. Nov 2000 A
6161219 Ramkumar et al. Dec 2000 A
6397254 Northrup May 2002 B1
6401134 Razavi et al. Jun 2002 B1
6421705 Northrup Jul 2002 B1
6442751 Cocchi et al. Aug 2002 B1
6487713 Cohen et al. Nov 2002 B1
6546413 Northrup Apr 2003 B1
6601233 Underwood Jul 2003 B1
6671713 Northrup Dec 2003 B2
6671746 Northrup Dec 2003 B1
6779000 Northrup Aug 2004 B1
6807636 Hartman et al. Oct 2004 B2
6901580 Iwanojko et al. May 2005 B2
6922675 Chatterjee et al. Jul 2005 B1
6922705 Northrup Jul 2005 B1
6947992 Shachor Sep 2005 B1
6954792 Kang et al. Oct 2005 B2
6973460 Mitra Dec 2005 B1
6990532 Day et al. Jan 2006 B2
7028019 McMillan et al. Apr 2006 B2
7062749 Cyr et al. Jun 2006 B2
7086009 Resnick et al. Aug 2006 B2
7117216 Chakraborty et al. Oct 2006 B2
7177878 Wason Feb 2007 B2
7188158 Stanton et al. Mar 2007 B1
7203938 Ambrose et al. Apr 2007 B2
7263686 Sadiq Aug 2007 B2
7343360 Ristanovic et al. Mar 2008 B1
7349913 Clark et al. Mar 2008 B2
7505990 Krishna et al. Mar 2009 B2
7535927 Northrup May 2009 B1
7536606 Andrews et al. May 2009 B2
7584207 Mortensen et al. Sep 2009 B2
7590644 Matsakis et al. Sep 2009 B2
7603674 Cyr et al. Oct 2009 B2
7644262 Bromley et al. Jan 2010 B1
7680752 Clune, III et al. Mar 2010 B1
7685604 Baartman et al. Mar 2010 B2
7693851 Becker Apr 2010 B2
7721158 Lee May 2010 B2
7774477 Zintel et al. Aug 2010 B2
7783782 Cromp et al. Aug 2010 B2
7788338 Savchenko et al. Aug 2010 B2
7793340 Kiester et al. Sep 2010 B2
7827494 Hedayatpour et al. Nov 2010 B1
7840941 Brookins et al. Nov 2010 B2
7853899 Damaschke et al. Dec 2010 B1
7865544 Kordun et al. Jan 2011 B2
7895512 Roberts Feb 2011 B2
7933946 Livshits et al. Apr 2011 B2
7945907 Dreiling et al. May 2011 B2
7950424 Ozanne et al. May 2011 B2
7954111 Waguet May 2011 B2
7984424 Dengler et al. Jul 2011 B2
7992130 Bozza et al. Aug 2011 B2
8015545 Seto et al. Sep 2011 B2
8032390 Waguet Oct 2011 B2
8065668 Bosworth et al. Nov 2011 B2
8074214 Isaacson et al. Dec 2011 B2
8108825 Goodwin et al. Jan 2012 B2
8122292 Nanjundaswamy Feb 2012 B2
8166450 Fuhler et al. Apr 2012 B2
8209672 Ivanov Jun 2012 B2
8209675 Zhao et al. Jun 2012 B2
8271609 Addala et al. Sep 2012 B2
8332654 Anbuselvan Dec 2012 B2
8423973 Saunders et al. Apr 2013 B2
8494832 Krishnan et al. Jul 2013 B2
8538998 Barrow Sep 2013 B2
8560938 Barrow et al. Oct 2013 B2
8667031 Konduri et al. Mar 2014 B2
8782604 Konduri et al. Jul 2014 B2
8788542 Barrow Jul 2014 B2
8799319 Srinivasan et al. Aug 2014 B2
20020013938 Duesterwald et al. Jan 2002 A1
20020023140 Hile et al. Feb 2002 A1
20020103660 Cramon et al. Aug 2002 A1
20020129060 Rollins et al. Sep 2002 A1
20020143735 Ayi et al. Oct 2002 A1
20020147757 Day et al. Oct 2002 A1
20020188613 Chakraborty et al. Dec 2002 A1
20030005117 Kang et al. Jan 2003 A1
20030023587 Dennis et al. Jan 2003 A1
20030025732 Prichard Feb 2003 A1
20030033310 Factor et al. Feb 2003 A1
20030034989 Kondo Feb 2003 A1
20030084424 Reddy et al. May 2003 A1
20030088857 Balva et al. May 2003 A1
20030172127 Northrup Sep 2003 A1
20030172168 Mak et al. Sep 2003 A1
20030172193 Olsen Sep 2003 A1
20030192031 Srinivasan et al. Oct 2003 A1
20030204518 Lang et al. Oct 2003 A1
20030204645 Sharma et al. Oct 2003 A1
20030233631 Curry et al. Dec 2003 A1
20030233642 Hank Dec 2003 A1
20040046787 Henry et al. Mar 2004 A1
20040046789 Inanoria Mar 2004 A1
20040054991 Harres Mar 2004 A1
20040073565 Kaufman et al. Apr 2004 A1
20040078424 Yairi et al. Apr 2004 A1
20040111533 Beisiegel et al. Jun 2004 A1
20040111673 Bowman et al. Jun 2004 A1
20040148588 Sadiq Jul 2004 A1
20040181534 Mortensen et al. Sep 2004 A1
20040194016 Liggitt Sep 2004 A1
20040205117 Hertling et al. Oct 2004 A1
20040205765 Beringer et al. Oct 2004 A1
20040230639 Soluk et al. Nov 2004 A1
20050044197 Lai Feb 2005 A1
20050091639 Patel Apr 2005 A1
20050097503 Zintel et al. May 2005 A1
20050183074 Alexander et al. Aug 2005 A1
20050193061 Schmidt et al. Sep 2005 A1
20050223361 Belbute Oct 2005 A1
20050251788 Henke et al. Nov 2005 A1
20050273772 Matsakis et al. Dec 2005 A1
20060010163 Herzog et al. Jan 2006 A1
20060015847 Carroll, Jr. Jan 2006 A1
20060031264 Bosworth et al. Feb 2006 A1
20060031750 Waldorf et al. Feb 2006 A1
20060036463 Patrick et al. Feb 2006 A1
20060075387 Martin et al. Apr 2006 A1
20060080117 Carr et al. Apr 2006 A1
20060101038 Gabriel et al. May 2006 A1
20060106626 Jeng et al. May 2006 A1
20060117073 Bosworth et al. Jun 2006 A1
20060130047 Burugapalli Jun 2006 A1
20060136832 Keller et al. Jun 2006 A1
20060143229 Bou-Ghannam et al. Jun 2006 A1
20060150156 Cyr et al. Jul 2006 A1
20060165105 Shenfield et al. Jul 2006 A1
20060168132 Bunter et al. Jul 2006 A1
20060168355 Shenfield et al. Jul 2006 A1
20060168557 Agrawal et al. Jul 2006 A1
20060184866 Rees Aug 2006 A1
20060206858 Becker et al. Sep 2006 A1
20060235733 Marks Oct 2006 A1
20060235986 Kim Oct 2006 A1
20060242636 Chilimbi et al. Oct 2006 A1
20060253490 Krishna et al. Nov 2006 A1
20060265702 Isaacson et al. Nov 2006 A1
20060271537 Chandrasekharan et al. Nov 2006 A1
20060277542 Wipfel Dec 2006 A1
20060282767 Suryanarayana et al. Dec 2006 A1
20060294474 Taylor et al. Dec 2006 A1
20060294506 Dengler et al. Dec 2006 A1
20070016429 Bournas et al. Jan 2007 A1
20070055936 Dhanjal et al. Mar 2007 A1
20070106975 Deline May 2007 A1
20070113191 Keller et al. May 2007 A1
20070130205 Dengler et al. Jun 2007 A1
20070157078 Anderson Jul 2007 A1
20070169199 Quinnell et al. Jul 2007 A1
20070174763 Chang et al. Jul 2007 A1
20070174822 Moser et al. Jul 2007 A1
20070203956 Anderson et al. Aug 2007 A1
20070220429 Kureshy et al. Sep 2007 A1
20070240096 Pontoppidan et al. Oct 2007 A1
20070245340 Cohen et al. Oct 2007 A1
20070260575 Robinson et al. Nov 2007 A1
20070266377 Ivanov Nov 2007 A1
20070271552 Pulley Nov 2007 A1
20070277095 Ukigawa Nov 2007 A1
20070282885 Baude et al. Dec 2007 A1
20070294586 Parvathy et al. Dec 2007 A1
20070294664 Joshi Dec 2007 A1
20080004887 Brunswig et al. Jan 2008 A1
20080022257 Baartman et al. Jan 2008 A1
20080028302 Meschkat Jan 2008 A1
20080065675 Bozich et al. Mar 2008 A1
20080077848 Roberts Mar 2008 A1
20080083012 Yu et al. Apr 2008 A1
20080104617 Apacible et al. May 2008 A1
20080120557 Offenhartz et al. May 2008 A1
20080126396 Gagnon May 2008 A1
20080127087 Brookins et al. May 2008 A1
20080127124 Gilfix et al. May 2008 A1
20080162208 Waguet Jul 2008 A1
20080162304 Ourega Jul 2008 A1
20080162565 Waguet Jul 2008 A1
20080163164 Chowdhary et al. Jul 2008 A1
20080183479 Iwashita et al. Jul 2008 A1
20080183744 Adendorff et al. Jul 2008 A1
20080184201 Burns et al. Jul 2008 A1
20080189358 Charles Aug 2008 A1
20080189617 Covell et al. Aug 2008 A1
20080196024 Barfield et al. Aug 2008 A1
20080243901 Super et al. Oct 2008 A1
20080250313 Kamdar et al. Oct 2008 A1
20080275844 Buzsaki et al. Nov 2008 A1
20080276218 Taylor et al. Nov 2008 A1
20080276260 Garlick et al. Nov 2008 A1
20080295109 Huang et al. Nov 2008 A1
20080313648 Wang et al. Dec 2008 A1
20080320246 Fuhler et al. Dec 2008 A1
20090031280 Koehler Jan 2009 A1
20090083297 Pohl et al. Mar 2009 A1
20090089741 Bornhoevd et al. Apr 2009 A1
20090094588 Chipman Apr 2009 A1
20090106494 Knebel Apr 2009 A1
20090144716 Felts Jun 2009 A1
20090144729 Guizar Jun 2009 A1
20090150565 Crossner et al. Jun 2009 A1
20090157859 Morris Jun 2009 A1
20090158237 Zhang et al. Jun 2009 A1
20090178020 Goodwin et al. Jul 2009 A1
20090204567 Barrow Aug 2009 A1
20090204629 Barrow Aug 2009 A1
20090204884 Barrow et al. Aug 2009 A1
20090204943 Konduri Aug 2009 A1
20090205013 Lowes Aug 2009 A1
20090217153 Oshima et al. Aug 2009 A1
20090259993 Konduri et al. Oct 2009 A1
20090292797 Cromp et al. Nov 2009 A1
20090313256 Konduri et al. Dec 2009 A1
20100057482 Radhakrishnan et al. Mar 2010 A1
20100057836 Anbuselvan Mar 2010 A1
20100070553 Addala et al. Mar 2010 A1
20100082556 Srinivasan et al. Apr 2010 A1
20100132009 Khemani et al. May 2010 A1
20100146291 Anbuselvan Jun 2010 A1
20100236660 Ozanne et al. Sep 2010 A1
20100313038 Bradley Dec 2010 A1
20100332401 Prahlad et al. Dec 2010 A1
20100332454 Prahlad et al. Dec 2010 A1
20100333116 Prahlad et al. Dec 2010 A1
20110010692 Hattori et al. Jan 2011 A1
20110023071 Li et al. Jan 2011 A1
20110047415 Nanjundaswamy Feb 2011 A1
20110119649 Kand et al. May 2011 A1
20110119651 Utschig-Utschig et al. May 2011 A1
20110282829 Rangaswamy et al. Nov 2011 A1
20120116980 Mercuri May 2012 A1
20120296624 Jeng et al. Nov 2012 A1
20130024424 Prahlad et al. Jan 2013 A1
20130086568 Krishnamurthy Apr 2013 A1
20140081896 Ranganathan et al. Mar 2014 A1
Non-Patent Literature Citations (109)
Entry
Altenhofen et al.; “ASMs in Service Oriented Architectures”; Journal of Universal Computer Science; vol. 14, No. 12; 2008.
Hohpe et al “Messaging Systems” Enterprise Integration Patterns 2004, pp. 57-97, Chapter 3, Pearson Education, Inc, Boston, Massachusetts.
Box et al., “Web Services Addressing (WS-Addressing)” Aug. 10, 2004, 23 pages, http://www.w3.org/Submission/ws-addressing/#—Toc77464317, printed on Aug. 18, 2009, 23 pages.
Carey, “Making BPEL Processes Dynamic” Oracle Technology Network, 8 pages, printed on Aug. 18, 2009, 8 pages.
Non-Final Office Action for U.S. Appl. No. 12/210,657 mailed on Apr. 25, 2011, 21 pages.
Non-Final Office Action for U.S. Appl. No. 12/210,657 mailed on Sep. 30, 2011, 21 pages.
Dynamic Structure in ADF UIX Pages, from Oracle ADF UIX Developer's Guide, Copyright 2001, 2004 Oracle, downloaded on Mar. 7, 2012 from http://download.oracle.com/otn—hosted—doc/jdeveloper/1012/uixhelp/uixdevguide/dynamic.html, 11 pages.
“Client-Server Modernization—From Oracle® Forms to Java,” VGO Software Products, Copyright 2009 Vgo Software Inc., printed on Aug. 28, 2009, downloaded from URL: http://www.vgosoftware.com/products/evo/index.php, 2 pages.
“Vgo Software First to Convert Oracle Forms to Oracle ADF V11”; VGO News, Sep. 16, 2008, downloaded on Aug. 28, 2009 from URL: http://www.vgosoftware.com/about/news/view—article.php?new id=35 , 2 pages.
“Oracle Forms to Java Modernization” printed on Aug. 28, 2009, at URL: http://www.vgosoftware.com/products/evo/walkthrough.php; VGO Software Information printed 5 pages.
CipherSoft Inc, “Exodus-Main Features Benefits” Products, at URL: http://www.ciphersoftinc.com/products/expdus-features-benefits.html; printed on Aug. 28, 2009; 3 pages.
CipherSoft Inc, “Exodus™ Products,” printed on Aug. 28, 2009, at URL: http://www.ciphersoftinc.com/products/migration-products-overview.html; 3 pages.
Shepherd, et al., “Oracle SCA—The Power of the Composite,” An Oracle White Paper, Aug. 2009, Oracle, pp. 1-19, 19 pages.
Chappell, “Introducing SCA,” David Chappell & Associates, Jul. 2007, pp. 1-22, 22 pages.
Chapman, et al., “SCA Service Component Architecture—Client and Implementation Model Specification for WS-BPEL,” Mar. 21, 2007, SCA version 1.00, 15 pages, BEA Systems, Inc.
Beisiegel, et al., “SCA Service Component Architecture—Assembly Model Specification,” Mar. 15, 2007, SCA version 1.00, 91 pages, BEA Systems, Inc.
“Business Process Language (BPEL) and Oracle BPEL Process Manager,” Oracle FAQ, updated Jun. 26, 2004, printed on Nov. 11, 2009, at URL: http://www.oracle.com/technology/products/ias/bpel/htdocs/orabpel—faq.html?—template=. . . , 3 pages.
Zhang, et al., “Schema Based XML Security: RBAC Approach,” Machine Simulator, Third International Conference on Computer Assisted Learning, Published 2003, at URL: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.3.6016, pp. 1-15, 15 pages.
Smith, Portals: Toward an Application Framework for Interoperability,: Communications of the ACM, Oct. 2004, vol. 47, No. 10, pp. 93-97, 5 pages.
Phanouriou, “UIML: A Device-Independent User Interface Markup Language,” Doctoral Dissertation, Virginia Polytechnic Institute and State University, Sep. 26, 2000, 172 pages.
“File and Registry Virtualization—the good, the bad, and the ugly,” Jerry's Incoherent Babbling; Windows Connected Blog; Published Dec. 19, 2005; at URL: http://windowsconnected.com/blogs/jerry/archive/2005/12/19/file-and-registry-virtualization-the-good-the-bad-and-t . . . , 6 pages.
Hildebrandt, G., “Web-based Document Management”, Apr. 2001, 22 pages.
Shang-Pin Ma, “Discovery-Based Service Composition,” National Central University, Doctoral Dissertation. Jan. 2007, 109 pages.
Yang et al., “Web Component: A Substrate for Web Service Reuse and Composition”. Proc. 14th Conf. Advanced Information Systems Eng. (CAiSE 02), LNCS 2348, Springer-Verlag, 2002, 16 pages.
“AJAX & Security: Vulnerability in DWR Security Logic Identified Can Potentially be exploited to launce DoS attacks and break into back-end servers”, published Jan. 8, 2007, AjaxWorld™ Magazine, pp. 1-4 downloaded on Oct. 6, 2008 from http://ajax.sys-con.com/node/319868, 4 pages.
“Direct Web Remoting, About DWR's Javascript Security”, 4 pages downloaded from http://directwebremoting.org/dwr/security/script-tag-protection on Oct. 6, 2008.
“Direct Web Remoting, DWR version 2—New and Noteworthy”, 4 pages downloaded from http://directwebremoting.org/dwr/changelog/dwr20 on Dec. 5, 2008.
“Direct Web Remoting, DWR: Easy AJAX for JAVA”, 2 pages downloaded from http://directwebremoting.org/dwr/overview/dwr on Oct. 6, 2008.
“Direct Web Remoting, Safari, GET and Request Forgery”, 1 page downloaded from http://directwebremoting.org/dwr/security/allowGetForSafariButMakeForgeryEasier on Oct. 6, 2008.
“Direct Web Remoting, Security”, 4 pages downloaded from http://directwebremoting.org/dwr/security on Oct. 6, 2008.
“Google Web Toolkit, Product Overview”, 3 pages downloaded from http://code.google.com/webtoolkit/overview.html on Oct. 6, 2008.
“Oracle Application Framework”, Oracle, Dec. 2006, pp. 1-242, 242 pages.
Claypool et al., “Optimizing Performance of Schema Evolution Sequences”, Objects and Databases [online], 2000 [retrieved Feb. 7, 2012], retrieved from Internet: http://se-pubs.dbs.uni-leipzig.de/files/Claypool2000OptimizingPerformanceofSchemaEvolutionSequences.pdf, pp. 114-127, 14 pages.
Curphey et al., “Web Application Security Assessment Tools”, IEEE, 2006, pp. 32-41, 10 pages.
Dipaola et al., “Subverting Ajax”, Dec. 2006, 23rd CCC Conference, pp. 1-8, 8 pages.
Mietzner, et al., “Defining Composite Configurable SaaS Application Packages Using SCA Variability Descriptors and Multi-Tenancy Patters,”, 2008, pp. 156-161.
Nagappan et al., “XML Processing and Data Binding with Java APIs” in: Developing Java Web Services: Architecting and Developing Secure Web Services Using Java [online], 2003 [retrieved Feb. 7, 2012], retrieved from Internet: http://java.sun.com/developer/Books/j2ee/devjws/, pp. 313-399, 89 pages.
Phillips, Josh. Window's Connected UseriD: Jerry. Jerry's Incoherent Babbling: “File and Registry Virtualization—the good, the bad, and the ugly”. <http:/ /wi ndowsco n nected. co m/b logs/jerry/archive/2005/ 12/1 9/fi l e-and-reg istry-vi rtual izatio n-th e-good-th ebad-and-the-ugly.aspx>. Published: Dec. 19, 2005.
Steinberg, “Data Binding with JAXB” [online], 2003 [retrieved Feb. 7, 2012], retrieved from Internet: https://www6.software.ibm.com/developerworks/education/x-jabx/x-jaxb-a4.pdf pp. 1-34, 34 pages.
Non-Final Office Action for U.S. Appl. No. 12/029,600 mailed on Apr. 27, 2011, 29 pages.
Non-Final Office Action for U.S. Appl. No. 12/029,605 mailed on Jul. 20, 2011, 12 pages.
Non-Final Office Action for U.S. Appl. No. 12/029,605 mailed on May 12, 2010, 10 pages.
Final Office Action for U.S. Appl. No. 12/029,605 mailed on Sep. 28, 2010, 13 pages.
Non-Final Office Action for U.S. Appl. No. 12/029,609 mailed on May 26, 2010, 14 pages.
Final Office Action for U.S. Appl. No. 12/029,609 mailed on Oct. 13, 2010, 13 pages.
Non-Final Office Action for U.S. Appl. No. 12/203,816 mailed on Sep. 2, 2010, 16 pages.
Final Office Action for U.S. Appl. No. 12/203,816 mailed on Jan. 20, 2011, 23 pages.
Non-Final Office Action for U.S. Appl. No. 12/203,816 mailed on Oct. 26, 2012 30 pages.
Non-Final Office Action for U.S. Appl. No. 12/029,724 mailed on Dec. 14, 2010, 21 pages.
Final Office Action for U.S. Appl. No. 12/029,724 mailed on May 5, 2011, 19 pages.
Non-Final Office Action for U.S. Appl. No. 12/029,724 mailed on Jan. 7, 2013, 39 pages.
Final Office Action for U.S. Appl. No. 12/029,724 mailed on Apr. 30, 2013, 33 pages.
Non-Final Office Action for U.S. Appl. No. 12/138,997 mailed on Jun. 24, 2011, 14 pages.
Non-Final Office Action for U.S. Appl. No. 12/101,420 mailed on Oct. 5, 2011, 18 pages.
Final Office Action for U.S. Appl. No. 12/029,600 mailed on Oct. 19, 2011, 20 pages.
Terminal Disclaimer—Approved for U.S. Appl. No. 12/029,600 mailed on Oct. 25, 2011, 1 page.
Non-Final Office Action for U.S. Appl. No. 12/029,600 mailed on Sep. 17, 2012, 38 pages.
Notice of Allowance for U.S. Appl. No. 12/029,600 mailed on Nov. 7, 2012, 16 pages.
Notice of Allowance for U.S. Appl. No. 12/029,600 mailed on Feb. 5, 2013, 16 pages.
Final Office Action for U.S. Appl. No. 12/029,605 mailed on Nov. 2, 2011, 13 pages.
Non-Final Office Action for U.S. Appl. No. 12/029,605 mailed on Apr. 10, 2013, 38 pages.
Final Office Action for U.S. Appl. No. 12/029,609 mailed on Nov. 8, 2011, 13 pages.
Non-Final Office Action for U.S. Appl. No. 12/029,609 mailed on Jul. 28, 2011, 29 pages.
Notice of Allowance for U.S. Appl. No. 12/029,609 mailed on Feb. 4, 2013, 52 pages.
Final Office Action for U.S. Appl. No. 12/138,997 mailed on Dec. 5, 2011, 13 pages.
Non-Final Office Action for U.S. Appl. No. 12/487,004 mailed on Sep. 28, 2011, 29 pages.
Non-Final Office Action for U.S. Appl. No. 12/330,008 mailed on Dec. 21, 2011, 14 pages.
Non-Final Office Action for U.S. Appl. No. 12/029,615 mailed on Feb. 15, 2012, 27 pages.
Final Office Action for U.S. Appl. No. 12/101,420 mailed on Feb. 24, 2012, 20 pages.
Final Office Action for U.S. Appl. No. 12/487,004 mailed on Mar. 19, 2012, 30 pages.
Advisory Action for U.S. Appl. No. 12/487,004 mailed on May 24, 2012, 5 pages.
Final Office Action for U.S. Appl. No. 12/210,657 mailed on Apr. 3, 2012, 23 pages.
Final Office Action for U.S. Appl. No. 12/330,008 mailed on Apr. 10, 2012, 13 pages.
Notice of Allowance for U.S. Appl. No. 12/330,008 mailed on Jun. 11, 2012, 7 pages.
Notice of Allowance for U.S. Appl. No. 12/210,657 mailed on Jun. 26, 2012, 6 pages.
Final Office Action for U.S. Appl. No. 12/029,615 mailed on Jul. 31, 2012, 33 pages.
Advisory Action for U.S. Appl. No. 12/029,615 mailed on Oct. 16, 2012, 5 pages.
Notice of Allowance for U.S. Appl. No. 12/330,008 mailed on Aug. 7, 2012, 17 pages.
Non-Final Office Action for U.S. Appl. No. 12/790,437 mailed on Jan. 30, 2013, 31 pages.
Non-Final Office Action for U.S. Appl. No. 12/790,445 mailed on Dec. 19, 2012, 30 pages.
Claessens, J., et al., “A Tangled World Web of Security Issues.” First Monday vol. 7, No. 3-4, (Mar. 2002): 24 pages. Web. Jun. 25, 2013.
U.S. Appl. No. 12/029,600, Notice of Allowance mailed on Jun. 11, 2013, 6 pages.
U.S. Appl. No. 12/029,605, Final Office Action mailed on Sep. 6, 2013, 19 pages.
U.S. Appl. No. 12/029,605, Advisory Action mailed on Dec. 18, 2013, 4 pages.
U.S. Appl. No. 12/029,609, Notice of Allowance mailed on May 29, 2013, 14 pages.
U.S. Appl. No. 12/101,420, Notice of Allowance mailed on Aug. 28, 2013, 9 pages.
U.S. Appl. No. 12/138,997, Notice of Allowance mailed on Nov. 27, 2013, 13 pages.
U.S. Appl. No. 12/203,816, Advisory Action mailed on Aug. 15, 2013, 3 pages.
U.S. Appl. No. 12/203,816, Final Office Action mailed on Jul. 5, 2013, 25 pages.
U.S. Appl. No. 12/487,004, Non Final Office Action mailed on Sep. 24, 2013, 22 pages.
U.S. Appl. No. 12/790,437, Final Office Action mailed on Jul. 12, 2013, 12 pages.
U.S. Appl. No. 12/790,445, Final Office Action mailed on Jul. 5, 2013, 10 pages.
Cetin et al., A mashup-based strategy for migration to service-oriented computing, IEEE International Conference on Pervasive Services, IEEE, Jul. 20, 2007.
Li et al., Leveraging legacy codes to distributed problem-solving environments: a Web services approach, Software: Practice and experience, vol. 34, No. 13, 2004, pp. 1297-1309.
Li et al., SGrid: a service-oriented model for the Semantic Grid, Future Generation Computer Systems, vol. 20, No. 1, 2004, pp. 7-18.
Sneed et al., Integrating legacy software into a service oriented architecture, Software Maintenance and Reengineering, CSMR, IEEE, 2006.
U.S. Appl. No. 12/487,004, Final Office Action mailed on Dec. 27, 2013, 18 pages.
U.S. Appl. No. 12/790,437, Non-Final Office Action mailed on Dec. 30, 2013, 15 pages.
U.S. Appl. No. 12/790,445, Non-Final Office Action mailed on Dec. 31, 2013, 13 pages.
U.S. Appl. No. 12/029,605, Notice of Allowance on Mar. 3, 2014, 9 pages.
U.S. Appl. No. 12/487,004, Notice of Allowance on Mar. 6, 2014, 5 pages.
Chen et. al., Feature Analysis for Service-Oriented Reengineering, IEEE 12th Asia-Pacific Software Engineering Conference (APSEC 2005), Dec. 2005, Taipei, Taiwan.
U.S. Appl. No. 12/029,615, Non-Final Office Action mailed on Mar. 21, 2014, 29 pages.
U.S. Appl. No. 12/101,420, Notice of Allowance mailed on Mar. 17, 2014, 8 pages.
U.S. Appl. No. 13/360,127, Non-Final Office Action mailed on Apr. 22, 2014, 16 pages.
Chappell et al., Ready for Primetime: The Next-Generation, Grid-Enabled Service-Oriented Architecture, SOA-The SOA Magazine, Sep. 3, 2007, pp. 1-10.
U.S. Appl. No. 12/029,724, Notice of Allowance mailed on Jun. 24, 2014, 13 pages.
U.S. Appl. No. 12/790,437, Notice of Allowance mailed on Jun. 12, 2014, 5 pages.
U.S. Appl. No. 12/790,445, Notice of Allowance mailed on Jun. 4, 2014, 5 pages.
Related Publications (1)
Number Date Country
20100070973 A1 Mar 2010 US