Evaluation of synchronization gateways in process models

A system may include a thread monitor that is arranged and configured to monitor progress of multiple threads of a workflow process at a synchronization point with each of the threads having a state, and configured to generate at least one inspection trigger for inspection of the threads. A thread inspector may inspect the threads at the synchronization point for a change in the state in any of the threads in response to the inspection trigger. A firing rules engine may determine whether or not the synchronization point should fire based at least in part on the change in the state of at least one of the threads.

TECHNICAL FIELD

This description relates to the evaluation of synchronization gateways in process models.

BACKGROUND

Modeling languages may be used as meta-languages to describe and execute underlying processes, such as business processes. For example, process modeling languages allow an enterprise to describe tasks of a process, and to automate performance of those tasks in a desired order to achieve a desired result. For instance, the enterprise may implement a number of business software applications, and process modeling may allow coordination of functionalities of these applications, including communications (e.g., messages) between the applications, to achieve a desired result. Further, such process modeling generally relies on language that is common to, and/or interoperable with, many types of software applications and/or development platforms. As a result, process modeling may be used to provide integration of business applications both within and across enterprise organizations.

Thus, such modeling languages allow a flow of activities or tasks to be graphically captured and executed, thereby enabling resources responsible for the activities to be coordinated efficiently and effectively. The flow of work in a process is captured through routing (e.g., control flow) constructs, which allow the tasks in the process to be arranged into the required execution order through sequencing, choices (e.g., decision points allowing alternative branches), parallelism (e.g., tasks running in different branches which execute concurrently), iteration (e.g., looping in branches) and synchronization (e.g., the coming together of different branches).

In the context of such processes, as just referenced, it may be that one or more of the constructs in the process model may be computationally complex or otherwise difficult to evaluate. For example, one or more types of synchronization points in the process model may be computationally complex or otherwise difficult to evaluate because of the number of branches and predecessor branches converging at a point. Also, different types of synchronization points may be configured to be enabled based on different parameters. For instance, one type of synchronization point such as an inclusive merge gateway (hereinafter called the OR-join) may depend on the presence or absence of events in places in the process model that are far away from the synchronization point.

Further, in real-world scenarios, it may occur that the enablement of the synchronization point may be unnecessarily delayed because of the computationally complex nature of evaluating whether or not the process may proceed beyond the synchronization point, thus delaying the execution of subsequent tasks. For example, a business process model may include multiple tasks, executing in parallel, that are each related to processing and checking shipment feasibility for purchase orders, and that converge at a synchronization point. The synchronization point may or may not need to wait on all of the incoming tasks to complete before proceeding to subsequent tasks. It may be that subsequent tasks may be completed without all of the preceding tasks in the process being completed, because some tasks may be unreachable. However, the subsequent tasks may be unnecessarily delayed if the synchronization point is not enabled because it is waiting on a task to complete, where the task is no longer active or may be unreachable. For example, as different shipping options are evaluated, one type of shipping option task may not be attainable, yet the entire process may be delayed if the fact that a particular shipping option is not attainable cannot be evaluated in a timely manner. Consequently, for example, subsequent tasks, such as allocating an order to shipment, may be significantly delayed.

Frequently, it may be difficult or problematic to express and evaluate such synchronization points in a manner that is executable as a process model. Thus, in these and other cases, process models may fail or be limited in their goal of expressing real-world processes in a flexible, repeatable, computer-executable manner.

SUMMARY

According to one general aspect, a system may include a thread monitor that is arranged and configured to monitor progress of multiple threads of a workflow process that converge at a synchronization point with each of the threads having a state. The thread monitor may generate at least one inspection trigger for inspection of the threads. The system may further include a thread inspector that is arranged and configured to inspect the threads at the synchronization point for a change in the state in any of the threads in response to the inspection trigger and a firing rules engine that is arranged and configured to determine whether or not to fire the synchronization point based at least in part on the change in the state of at least one of the threads. In one exemplary implementation, the synchronization point may include an OR-join.

According to another general aspect, a computer program product may be used for evaluating synchronization points in process models, the computer program product being tangibly embodied on a computer-readable medium and including executable code that, when executed, is configured to cause at least one data processing apparatus to execute an orchestration engine. The orchestration engine may be configured to monitor progress of multiple threads of a workflow process at a synchronization point, with each of the threads having a state, generate at least one inspection trigger for inspection of the threads, inspect the threads at the synchronization point for a change in the state in any of the threads in response to the inspection trigger, and determine whether or not to fire the synchronization point based at least in part on the change in the state of at least one of the threads. In one exemplary implementation, the synchronization point may an OR-join or may include a synchronization point that may exhibit behavior similar to that of an OR-join. In this example, the OR-join or the synchronization point that behaves like an OR-join may wait for at least one thread to be completed, and for the remaining threads to be in a state where they have completed or they can no longer complete.

DETAILED DESCRIPTION

FIG. 1is a block diagram of a system100for evaluating synchronization points in process models. For example, the system100allows for evaluation of OR-joins or other complex joins in a manner that monitors and evaluates incoming threads to the OR-join and allows for a determination of whether or not to execute or fire the OR-join, such that subsequent tasks may be completed in a timely manner. In one example, the OR-join is a synchronization gateway in the process model where several branches or threads converge. For each of the incoming threads, the OR-join will normally wait for a token indicating the completion of that thread. But if at some point in time it can be determined that no token will ever arrive along a given incoming thread, the OR-join does not need to wait for a token along that thread and may be enabled. For example, the system100may monitor the progress of multiple threads of a workflow process at a synchronization point and generate an inspection trigger for inspection of the threads. The threads may be inspected for a change in state in any of the threads in response to the inspection trigger and the synchronization point may be evaluated whether or not to fire based at least in part on the change in the state of at least one of the threads. Consequently, the system100provides workflow designers and users with the ability to implement workflow process models in a manner that more accurately and completely reflects real-world usage scenarios of synchronization points, such as OR-joins or other complex joins.

In other exemplary implementations, the synchronization point include a synchronization point that may exhibit behavior similar to that of an OR-join. In this example, the synchronization point that behaves like an OR-join may wait for at least one thread to be completed, and for the remaining threads to be in a state where they have completed or they can no longer complete.

In the example ofFIG. 1, a global process model102represents a business process model that is implemented, and agreed on, by a number of collaborating service providers, such that the service providers perform tasks104of the global process model102. The service providers may make pre-arrangements regarding their interactions with one another (e.g., arrangements governing messages, message formats, or message types, as well as arrangements governing an order of the messages to be sent and/or tasks to be performed). By way of specific example, a purchase order may be sent by one service provider that may require either acknowledgement or rejection by one or more other service provider(s). The global process model102(also referred to as a global choreography model) thus provides a way of capturing, contractualizing, and implementing potentially complex and long-running message exchange sequences between service providers, in order to execute a desired business process.

For example, a business application106may be built and implemented by an enterprise or other entity to perform some business functionality, such as, for example, creating a purchase order and sending the purchase order or loan request to a number of (possibly competing) suppliers. The business application106may implement a local process model108that, analogously to the global process model102, formalizes and defines the roles of the business application106within the global process model102, e.g., with respect to the purchase order or loan request example(s) just mentioned. For example, the local process model108may describe what types of messages may or should be exchanged with the suppliers as part of the purchase order.

In the example ofFIG. 1, tasks of the global process model102and the local process model108are executed at least in part using application services. For example, the business application106and the local process model108may be associated with at least one service110. In this context, the service110refers to an application having one or more specific functionalities that are exposed to other applications, often over a network (e.g., the Internet) by way of a service interface (where an operation and use of the interface may be known or determined, as needed). When such a service (and/or an interface of the service) is exposed/available over the World Wide Web (referred to herein as the WWW or the web), then the service may be known as a web service.

Using such services and service interactions to implement process models may be referred to as a service-oriented architecture (SOA), in which, as just described, process tasks result in execution of the services. Further, processes that rely on services to realize process steps may themselves be deployed and accessed as services, which may be referred to as process-based service composition. Languages exist, such as, for example, the Business Process Execution Language (BPEL), that are designed to provide such compositions of services (e.g., web services), and thus provide a top-down, process-oriented approach to the SOA. Accordingly, BPEL or other such languages (such as, for example, the Web Services Flow Language (WSFL), the eXtensible language (XLANG), and/or the Business Process Modeling Language (BPML)), or modifications/extensions thereof, may be used to define the global process model102and/or the local process model108.

InFIG. 1, in order to integrate the service110within the global process model102, a messaging infrastructure112is included. Generally, the messaging infrastructure112facilitates instantiation and execution of the local process model108. The messaging infrastructure112includes an orchestration engine114that is operable, among other functions, to execute an instance of the local process model108. For example, the orchestration engine114may be in charge of ensuring that a given task of the local process model108has actually been executed and completed, before allowing the instance to proceed to a following task. Other functions and examples of the orchestration engine114are described in more detail, below.

A message repository116represents a database or other memory that may be used, for example, to store message types or templates, as well as actual messages (including both outgoing and/or incoming messages). For example, as described in more detail below, the message repository116may include a number of message types that are specific to, or associated with, (functionality of) the business application106. For instance, in the case where the business application106is used to generate purchase orders, there may be a number of associated message types in the message repository116, which may be pre-configured to some extent based on, for example, a type of purchase order or an identity of the recipient(s) of the purchase order.

A message handler118may be used to send and receive actual messages of the messaging infrastructure112during communications with other services, such as a service120having messaging infrastructure122. For example, in a case where the orchestration engine114is executing a plurality of instances of the local process model108, the message handler118may be responsible for sending messages of the various instances to the appropriate recipients, using appropriate transmission techniques and/or protocols. Conversely, for incoming messages, the message handler118may be used to sort and/or route messages to appropriate portions of the messaging infrastructure112, the service110, and/or the business application106.

The message handler118also may serve as a buffer or queue for incoming and outgoing messages. In this regard, for example, the message handler118may serve as a queue for incoming messages, which may ultimately be forwarded to a message log124. The message log124may be used to track each incoming (and outgoing) message(s), and, ultimately, persist the messages to the message repository116.

Thus, for example, the process model108may describe tasks to be performed, as well as messages that may be sent/received as part of such tasks, by a manufacturer as part of a manufacturing process, or by some other party/entity. As referenced above, such process models generally include a plurality of nodes or tasks that are joined and ordered to obtain a desired result. That is, as illustrated by the example process model108illustrated inFIG. 1(which is intended merely as a conceptualization or illustration of a process model having multiple synchronizations, and not intended necessarily to represent a particular process model being executed inFIG. 1), nodes/tasks may be joined by appropriate edges (arrows) and control tasks (e.g., splits and/or joins) to obtain structures including parallel tasks, iterative tasks, nested loops, or other known task progressions.

In particular, the process model108conceptually illustrates a simplified example in which some or all of three parallel tasks126a,126b,126care synchronized and result in one or more subsequent tasks128a,128b. Synchronization is illustrated as occurring at a synchronization point130, which may represent or be implemented by a gateway or similar workflow construct, examples of which are discussed in more detail, below. As shown, the tasks126a,126b,126care respectively associated with branches132a,132b,132c(hereinafter referred to interchangeably as branches or threads). For example, although the simplified process model108ofFIG. 1illustrates a single task associated with each branch132a,132b,132c, it will be appreciated that, in practice, a number of tasks may exist that are respectively associated with the branches132a,132b,132c. Similarly, the subsequent tasks128a,128bare illustrated as being respectively associated with branches134a,134b.

An example of the process model108may include a process for fulfilling, scheduling and delivering goods related to multiple purchase orders, where each purchase order is associated with one of the branches132a,132b,132c. That is, three purchase orders may be sent in parallel to a company for fulfilling and delivering. It may be desirable to fulfill all of the orders and process them in a single shipment. As such, a synchronization point130may be configured to wait for each of the purchase orders on each of the branches132a,132b,132cbefore triggering subsequent branches, such as branches134a,134b. However, if it can be determined that one or more of the branches132a,132b,132cwill never be completed then the synchronization point130may fire or continue so as not to delay shipment of the other purchase orders that can be fulfilled. For example, the current state of the branches132a,132b,132cmay be monitored and upon fulfilling one of the purchase orders (e.g., branch132acompletes), an inspection of the other branches (e.g., branches132b,132c) may be initiated, while the synchronization point130is placed on a hold. If the inspection results in a determination that the other branches132b,132care still active such that they may reach a state of fulfilling the purchase orders, then the synchronization point130may remain on hold and continue to wait for the other branches132b,132cto complete the purchase orders. If, however, the inspection results in a determination that the other branches132b,132care in an unreachable state, meaning that the branch will never reach a state of completion, then the hold may be lifted from the synchronization point130and the fulfillment and delivery of the filled purchase order on branch132amay continue to a subsequent branch(s)134a,134bso shipment of the filled purchase order is not unnecessarily delayed.

Each of the branches132a,132b,132cmay be associated with and go through various states. For example, the state of a branch may include a completed state in which the branch has completed its tasks and delivered its token. The state of a branch may include an active state in which the branch may eventually reach a state of completion. For example, a branch in the active state may still be executing its tasks, but not yet completed the tasks, yet it is anticipated that the branch may eventually complete the tasks. Furthermore, the state of a branch may include an unreachable state, meaning that the branch will never reach a state of completion. In the purchase order and shipping example given above, a branch may enter an unreachable state when, for instance, a purchase order is canceled. In this situation, the branch will never reach a state of completion because the purchase order was canceled.

In this context, it may be appreciated that the branches132a,132b,132cmay include more complex threads and additional synchronization points within a given instance of the local process model108, as is shown below inFIGS. 5A and 5B. Moreover, triggers other than the completion of a thread may be used to initiate an inspection of the threads for a potential change of state. In some cases, the same branch may be used multiple times within a given instance of the local process model108, yet other branches may be used fewer times. Still further, in the example cases where the synchronization point is an OR-join, it may not be sufficient to examine the presence of tokens in its immediate vicinity. Instead, enablement of the OR-join may depend on the presence or absence of tokens in places far away in the process model108. Still further, in the example cases where the synchronization point is an OR-join, the state of enablement of the OR-join may depend on the state of enablement of another OR-join in the model and vice-versa. In one exemplary implementation, an OR-join may be enabled if there is at least one token in one of its incoming branches, and for each of its incoming branches the incoming branches either has at least one token or, assuming the OR-join will not fire, that no token will arrive to flow through a sequence of firings starting from the current state. These and other considerations may be taken into account by the system100when evaluating synchronization points in process models108.

For example a process execution engine136may be used by, or in conjunction with, the synchronization point130to evaluate the synchronization point130in the local process model108. For example, the process execution engine136may be spawned by the orchestration engine114when a process instance is created or at a later point in time. As referenced above, the synchronization point130may be implemented as a gateway construct such as, for example, an OR-join or a complex join or other constructs known within existing process modeling and/or execution languages, so that, in some example implementations, the process execution engine136may be spawned by the orchestration engine114and implemented within such a gateway. This ability of the process execution engine136to perform evaluations of synchronization points allows the system100, as referenced above, to contemplate and execute a variety of real-world scenarios using OR-join and other complex gateways, examples of which are described herein, and which may include purchase order processing or business tendering, or other examples in which a number of interactions are required through different and distributed actors (e.g., external parties).

In practice, the process execution engine136may include a thread monitor138, a thread inspector140, a firing rules engine142, and a process scheduler144. In the process of evaluating synchronization points, the process execution engine136and its modules may access model instance data146as well as firing rules148. In this context, the model instance data146may refer, for example, to virtually any data that is specific to, or associated with, evaluating synchronization points in the process model108. For example, the model instance data146may be associated with state data regarding a current state of a branch132a,132b,132c, or other process model and/or workflow processing data associated with evaluating synchronization points of the process model108. The model instance data146may include thread state data150, trigger point data152, process model data154and process state data156.

In practice, the process execution engine136may instantiate the thread monitor138to monitor progress of some or all of the multiple threads (e.g., branches132a,132b,132c) of a workflow process that converge at a synchronization point130and to generate one or more inspection triggers for inspection of the threads. The thread monitor138tracks the progress of the multiple threads and populates the thread state data150with the information about the progress of the threads. The thread monitor138may refer to the trigger point data152to determine if and/or when to generate the inspection triggers. For example, the thread monitor138may monitor the progress of the branches132a,132b,132cand populate the thread state data150with information such as a current state of each of the branches132a,132b,132c. The thread monitor138may check the current state or other information relating to the branches132a,132b,132cand use that information to lookup the trigger point data152to determine whether or not to generate an inspection trigger.

The trigger point data152may include information about different types of triggers that a particular instance of a process model may use to determine when to generate an inspection trigger. For example, a trigger point may be when at least one of the branches132a,132b,132creaches a completed state. In the shipping and delivery example provided above, a trigger point was reached when branch132acompleted its purchase order. Another trigger point may be when multiple branches132a,132b,132creach a completed state. For example, the business process may deem it efficient to wait to generate an inspection trigger until at least two of the branches132a,132b,132chave completed purchase orders before an inspection of any remaining branches would be initiated. Other types of trigger points are possible including, for example, when a particular type of thread completes, when a particular type of combination of threads complete, or when any thread reaches a particular state. Still, further types of trigger points may include configurable temporal limitations, manual triggers and/or trigger points based on events external to the process model108.

Once the thread monitor138generates an inspection trigger, then the thread inspector140may inspect the threads at the synchronization point130for a change in the state in any of the threads. The thread inspector140may reference the thread state data150, which may have been populated by the thread monitor138, and the process model data154prior to, during, and/or after inspecting the threads to aid in the inspection process. The process model data154may contain information relating to the architecture and structure of the process model108. The structure of the process model provides relevant information about each object (e.g., task, branch, synchronization point) in the process model in the region of the synchronization point130, including enablement information for the particular type of object. For example, the process model data154may contain enablement rules that define when an object may be enabled and thus, may still be in an active state. The enablement rules contained in the process model data also may provide information that defines when an object may never be enabled and thus, may be in an unreachable state. The thread inspector140may access this data to assist in determining a change in the state of any threads and/or the potential for a change in the state of the threads.

In the example ofFIG. 1, once the branch132achanges to a completed state, the thread monitor138generated an inspection trigger that spawned the thread inspector140to inspect the other branches132b,132cfor a change in the state of the those branches. The thread inspector140may determine whether any of the branches may eventually be enabled and/or are still in an active state based at least in part on the structure and architecture of the incoming branch as looked-up in the process model data154. Thus, the thread inspector140may compute the set of predecessor objects along each empty (i.e., no token at the synchronization point130) branch and then iterate over this set of predecessor objects to determine if the branch is in an active state. Thus, the complexity of the inspection by the thread inspector140may be based upon the total number of elements in the process model.

In one exemplary implementation, the thread inspector140may use one function to inspect branches that do not contain any OR-joins. For each element in the branch, the thread inspector140may determine whether or not the branch is active by applying the enablement rules from the process model data154for that particular type of object. For example, for the branches132a,132b,132cthat may include other types of objects such as, for instance, AND-joins, XOR-joins, or other objects, the thread inspector140may use the enablement rules for that particular type of object to determine the potential for a change in the state of the object.

The thread inspector140may use a second different function to inspect branches that contain at least one OR-join in the branch. An OR-join for which the state or enablement needs to be determined may not actually need to know whether a preceding OR-join is enabled or not. Instead, the thread inspector140may inspect whether there is at least one token in at least one incoming branch of a preceding OR-join and there is at least one token in each incoming branch of the preceding OR-join that is part of a path starting at the OR-join and finishing at the preceding OR-join. For example, for the branches132a,132b,132cthat may include a preceding OR-join as part of the branch, then the thread inspector140may inspect the branch to determine if a change in state may occur by evaluating whether there is at least one token in at least one of the incoming branches to the preceding OR-join and to determine whether or not there is at least one token in each incoming branch of the preceding OR-join that is part of a path starting at the synchronization point130and finishing at the preceding OR-join.

The thread inspector140may or may not use a recursive process to inspect the branches for a change in the state of any of the threads. For example, once the thread monitor138generates an inspection trigger, the thread inspector140may continuously inspect one or more of the branches132a,132b,132cfor a change in the state in any of the branches using one or more of the functions, as described above. Additionally and/or alternatively, once the thread monitor138generates an inspection trigger, the thread inspector140may conduct a single inspection of one or more of the branches132a,132b,132cfor a change in the state in any of the branches and then wait for other indicia such as, for example, another inspection trigger that may be generated by the thread monitor140.

The thread inspector140may use one or more variants when inspecting the branches according to the different functions, as described above. In one exemplary implementation, the thread inspector140may use a variant that looks backwards from the synchronization point130at the branches to apply the functions to the branches to determine a potential for a change in state of the branches. In another exemplary implementation, the thread inspector140may use a variant that looks forward from the synchronization point130at the branches to apply the functions to the branches to determine a potential for a change in state of the branches. Still in other exemplary implementations, the thread inspector140may use a combination of the variants that both looks backwards and forwards from the synchronization point130to apply the functions to the branches to determine a potential for a change in the state of the branches.

The firing rules engine142may use the information obtained during the inspection of the branches by the thread inspector140to determine whether or not the synchronization point130should fire. The firing rules engine142may use the information from the thread inspector140, along with the firing rules data148, to determine whether or not the synchronization point130should fire. In the example ofFIG. 1, if the thread inspector140determines the state of the non-completed branches is unreachable, then the firing rules engine142may fire the synchronization point130. If the thread inspector140determines the state of at least one of the non-completed branches is active, then the firing rules engine may continue to hold the synchronization point130such that it does not fire, as discussed in more detail below with respect toFIG. 6.

The firing rules data148may refer to data that are associated with the executing instance of the process model108and/or may refer to data associated with a particular structure or architecture of an object in the process model108. Meanwhile, in a business-related example, such firing rules148may be considered to be business rules, and may include how to process purchase order and schedule delivery and shipment of goods associated with the purchase orders. The firing rules148also may determine if all, some or none of the branches emanating from the synchronization point will be executed after the synchronization point is fired. For example, if one of the synchronized threads completed successfully, and two others did not reach a state of completion, the firing rules148may determine that only one branch should be executed and not the other(s).

The firing rules engine142also may use information contained in the process state data156to determine whether or not the synchronization point130should fire. The process state data156may contain information related to the overall state of the local process model108. The process state data156may contain information about the state of the branches following inspection and may include indicia of the state using one or more types of indicators. For example, the process state data156may include a color indicator that indicates the particular state of a thread. For instance, red may be used to mark a thread as complete, blue may be used to mark a thread as active, and green may be used to mark a thread as unreachable. Other indicators may be used. The firing rules engine142may use the information contained in the process state data156to look up the rules for when to fire the synchronization point130in the firing rules data148. The firing rules data148may contain different firing or must wait scenarios based on different combinations of thread states as marked by the indicators in the process state data156.

The process scheduler144may be configured to update an overall state of the process model and/or configured to update a state of the synchronization point130. For example, the process scheduler144may mark the state of the branches using one or more of the example indicators, as discussed above, following the evaluation by the thread inspector. In one exemplary implementation, the process scheduler144may modify the behavior of the synchronization point130based on the updates to the process state data156.

The process scheduler144may be used such that an overall incremental evaluation of the synchronization point130may be performed. The use of an incremental evaluation by the process execution engine136may reduce and/or eliminate the need for multiple recursive iterations of the monitoring and inspection process. In the example ofFIG. 1, if one of the branches complete, (e.g., branch132a), then the process scheduler144may mark the branch132aas red in the process state data156. The other non-completed branches132b,132cmay be marked as appropriate following inspection by the thread inspector140. For instance, if branch132bis in an unreachable state, then the process scheduler144may mark branch132bas green in the process state data156. If branch132cis in an active state, then the process scheduler144may mark branch132cas blue in the process state data156. Since, in this example, one of the branches132cis still active, the firing rules engine142will not fire the synchronization point130a. Upon the next inspection by the thread inspector140, the thread inspector140may have to inspect fewer than all of the branches using the information from the process state data156. Specifically, in this example, since branch132ais marked as complete and branch132bis marked as unreachable, the thread inspector140does not need to inspect these branches and may just inspect branch132c, thus reducing the need for multiple iterations and inspections of certain branches.

As referenced above, a number of different types of languages may be used both to design/create process models, and also to execute the process models, such as the process model108. In the examples that follow, the modeling language Business Process Modeling Notation (BPMN) is used as an example of a language that developers and designers may use to create the process model108. As is known, BPMN provides intuitive, graphical interfaces, with which designers (even non-technical or business designers) may easily create the process model108. More specifically, the created BPMN-based model may be transformed or converted into a format that is executable by the orchestration engine114, such as an executable language like BPEL, referenced above, for executing instances of the process model108(including the process execution engine136).

AlthoughFIG. 1is discussed in terms of business processes associated with the illustrated global process model102, the business application106, the local process model108, as well as the various service and messaging systems, it will be appreciated thatFIG. 1is only an example context. For example, the term business application should be interpreted broadly as including any application that is used in profit generation of some sort, although the business application106also may refer to non-profit endeavors as well, including, for example, schools, churches, charities, hospitals, or virtually any other organization. Further, the business application106is merely an example, and other applications, such as applications for personal use, also may be used. Consequently, the process execution engine136may be used in virtually any scenario in which evaluation of a synchronization point130may be needed, especially in the context of more complex synchronization points such as, for example, OR-joins and other complex joins.

FIG. 2is a flowchart200illustrating example operations of the system100ofFIG. 1. Thus,FIG. 2again relates to examples associated with the evaluation of one or more synchronization points130. That is, as described herein,FIG. 2relates to the evaluation of points in the process model108, in which multiple branches, such as the incoming branches132a,132b,132c, converge at a single point and a determination is made whether or not to fire the synchronization point or to hold the synchronization point based on the state and/or potential changes of state of the incoming branches following an inspection.

Thus, inFIG. 2, the progress of the multiple threads of the workflow process may be monitored at the synchronization point (202). For example, the orchestration engine114may spawn the process execution engine136upon the initiation of a process model108. The thread monitor138may monitor the progress of the multiple incoming branches132a,132b,132cflowing into the synchronization point130(202). As discussed above, the synchronization point130may be different types of synchronization points including, for example, an OR-join or other complex joins. As part of the monitoring process (202), the thread monitor138may update and/or populate the thread state data150.

At least one inspection trigger may be generated for the inspection of the threads (204). For example, the thread monitor138may access the trigger point data152to assist in determining whether or not to generate an inspection trigger for the inspection of the branches132a,132b,132c. In the example ofFIG. 1, the thread monitor may detect that one of the branches132ahas reached a completion state. The trigger point data152may include information that states when at least one branch reaches a state of completion, then the thread monitor138should generate an inspection trigger (204). As discussed in more detail herein, there may be various types of inspection triggers that may cause the thread monitor138to generate an inspection trigger.

In response to the generation of an inspection trigger, the threads may be inspected at the synchronization point for a change in the state in any of the threads (206). For example, the thread inspector140may use information from the thread state data150and/or the process model data154and conduct an inspection in one or more of the threads for a change in the state of the inspected threads. For instance, if the inspection trigger is based on one of the branches132areaching a state of completion, the thread inspector140may inspect the other non-completed branches132b,132cfor a potential change in the state of these branches132b,132c.

Based at least in part of the change of state of at least one of the threads, it may be determined whether or not to fire the synchronization point (208). For example, the firing rules engine142may use the information from the thread inspector140in conjunction with the firing rules data148and/or the process state data156to determine whether or not to fire the synchronization point130.

FIG. 3is a block diagram300of an implementation of the system100ofFIG. 1. InFIG. 3, several of the elements are the same or similar to elements ofFIG. 1, as indicated by like reference numerals. It will be appreciated fromFIG. 3, however, that the process execution engine136and related elements may be implemented in different environments than the example environment ofFIG. 1. For example, the process execution engine136need not be associated with some or all of the service110, messaging infrastructure112, or global process model102, or may be implemented with different versions or types of these or other elements ofFIG. 1.

InFIG. 3, then, a specific example is illustrated with an OR-join synchronization point130that includes three incoming branches132a,132b,132c, with branch132aassociated with task126a. The other branches132b,132care associated with tasks that are not illustrated in this example. When an instance of this process model is initiated, the orchestration engine114may spawn the process execution engine136to evaluate the OR-join130to determine when the OR-join130is enabled and should fire. The process execution engine136may reside at the OR-join130or, in other cases, may reside elsewhere in the process model.

The thread monitor138monitors the state of the branches132a,132b,132cat the OR-join130. When branch132areaches a state of completion, as indicated by the token302arriving at the OR-join130, the thread monitor138may generate an inspection trigger. In response to the inspection trigger, the thread inspector140may inspect the non-completed branches132b,132cto determine whether or not the OR-join130should wait for either of these branches132b,132cto be enabled before firing. The firing rules engine142may place a hold on the OR-join130while the thread inspector140conducts the inspection of the non-completed branches132b,132c. In this example, the thread inspector140may check the process model data154to find out information relating to the structure of the branches132b,132c. Here, the thread inspector140determines that no task will be enabled in the region from the branches132b,132c. The firing rules engine142can use this information along with other information from the firing rules data148and process state data156to fire the OR-join130so that the process model may continue. Here, the thread inspector140determined it not to be necessary to wait for branches132b,132cto complete because those branches132b,132cwere in an unreachable state.

The systems ofFIGS. 1 and 3are capable of even more complex evaluations of synchronization points, examples of which are provided below. For example, it may occur that later OR-joins have one or more preceding OR-joins in their path.

FIG. 4is a block diagram400of an implementation of the system100ofFIG. 1. InFIG. 4, several of the elements are the same or similar to elements ofFIG. 1, as indicated by like reference numerals. It will be appreciated fromFIG. 4, however, that the process execution engine136and related elements may be implemented in different environments than the example environment ofFIG. 1. For example, the process execution engine136need not be associated with some or all of the service110, messaging infrastructure112, or global process model102, or may be implemented with different versions or types of these or other elements ofFIG. 1.

InFIG. 4, then, a specific example is illustrated with an OR-join synchronization point130athat includes two incoming branches432a,432bwith branch432aassociated with the task “Abstract Variability”426aand branch432bassociated with the task “Specify Integrated Subsystem”426b. When an instance of this process model is initiated, the orchestration engine114may spawn the process execution engine136to evaluate the OR-join130ato determine when the OR-join130ais enabled and should fire. The process execution engine136may reside at the OR-join130aor, in other cases, may reside elsewhere in the process model.

The first time this process model is executed, both tasks Abstract Variability426aand Specify Integrated Subsystem426bare executed in parallel. This parallel execution is captured by the AND-split gateway470. The OR-join130awill then wait for both tasks426a,426bto complete before firing the first time. For example, the thread monitor138may monitor the progress of the branches432a,432band upon one of the branches (e.g.,432a) reaching a trigger point such as a completed state, as may be specified in the trigger point data152, the thread monitor138may generate an inspection trigger. The thread inspector140may then inspect the non-completed branch (e.g.,432b) to determine whether a change of state is possible, as may be specified in the process model data154. In this first execution of the process model, the thread inspector140may designate the branch432bas being in an active state because a completed state is attainable. Thus, the firing rules engine142will hold the OR-join130afrom firing until both of the branches432a,432breach a completed state. Once both of the branches432a,432breach a completed state, then the firing rules engine142will fire the OR-join130a.

Following the firing of the OR-join130athe first time, the tasks “Generate Significant Paths”426cand “Generate Optimal Path Combination”426dmay be executed. After completion of this latter task426d, a choice is made at XOR gateway472between repeating task426bor proceeding with the rest of the process model (not shown in the figure). The process scheduler144may update the process state data156with information that the process model has completed a first execution. The branches432a,432bmay be marked with indicators according to the schema that the process scheduler144may have in place. If the decision is to repeat task426b, then when the second execution of the Specify Integrated Subsystem426breaches a completed state the OR-join130awill receive a token along branch432b. As the thread monitor138monitors the branches432a,432bduring this second execution, the thread monitor138may generate an inspection trigger when the branch432breaches a completed state. The thread inspector140may inspect branch432aand, using data from the thread state data150and the process model data154, determine that the branch432ais in an unreachable state. Thus, the firing rules engine142may fire the OR-join130a, because the OR-join130adoes not need to wait on branch432ain order to fire. Then, the process model may proceed with the rest of the process model.

FIGS. 5A and 5Bshow an example process model500that may be used in the system(s)100/300ofFIGS. 1 and 3. In the example ofFIGS. 5A and 5B, an example is provided for allocating ad-hoc order requests to existing shipments. In this example, one of the tasks ofFIG. 5Ais expanded to show its subroutines and/or sub processes, which includes multiple OR-joins. At each of the OR-joins, a process execution engine136fromFIG. 1may be spawned to evaluate whether and when the OR-join should fire. Process model500includes multiple tasks including “Collect open orders”502, “Select order”504, “Find candidate shipments”506, “Select candidate shipment”508, “Check shipment feasibility for order”510and “Post check analysis”512. Two decision points follow the tasks, such that depending on the decision, one or more of the tasks502-512may be repeated. The first decision point is “Allocate order to shipment”514and “More orders left”516. As can be seen from this example inFIG. 5B, task510“Check shipment feasibility for order” is expanded to illustrate its sub processes.

Upon completion of the task508, a first OR-join530ais encountered. In this example, there is a single branch526aentering the OR-join530a. The process execution engine136and its components and related data may be used to determine when the OR-join530ais ready to fire. Following the OR-join530a, then one or more of the multiple branches526b-526ebegin processing, each of which have corresponding OR-joins530b-530e. As illustrated, task510may have other multiple steps that are illustrated by the ellipses, all culminating in three incoming branches526x,526y,526zto OR-join530n. As described above, process execution engine136and its components and related data may be used in the evaluation the OR-join530n. The example ofFIGS. 5A and 5Billustrates the complex level of OR-joins that can be evaluated by the process execution engine136.

FIG. 6illustrates an example block diagram600, where multiple branches626a,626bflow into an OR-join630and multiple branches626c,626dflow out of the OR-join630. In this example, and as discussed above with respect toFIG. 1, the firing rules148may dictate which of the outgoing branches,626c,626dwill execute, if any. For example, if branches A626aand B626bcomplete, then the firing rules148may dictate that just branch D626dshould be started. Alternatively, for example, if only branch A626aor branch B626bcompletes and the synchronization point630fires, then the firing rules148may dictate that both branch C626cand branch D626dshould start. Other possible combinations are possible as may be dictated by the firing rules148, including the option of no outgoing branches626c,626dbeing started and/or being skipped altogether.