Workflow service with translator

A provider network is configured to provide continuous workflow service for an open-ended number of workflows using non-persistent threads. The provider network includes a workflow translator service configured to receive workflows defined according to multiple workflow domain specific languages and translate the received workflows into a particular domain specific language used by the workflow service to execute workflows. In some cases, the provider network includes a workflow handling service and a workflow evaluation service. The workflow handling service may receive indications of task completion events related to respective workflows, and in turn may send non-blocking requests for workflow decisions from the workflow evaluation service. In generating a workflow decision, the workflow evaluation service may determine resources for executing a workflow.

BACKGROUND

Web service providers, and provider networks in general, often allow customers to specify a workflow that accomplishes a set of computational tasks to solve a given computational problem, logistical problem, or generally any process that may be directed by a computer system.

Traditional approaches for providing workflow services usually rely on a service based from a client system. However, such traditional approaches are inflexible in that to provide additional workflow services, the client system becomes a bottleneck. Further, traditional systems often dedicate a continuous allotment of computational resources per workflow. However, such a continuous allotment of computational resources becomes inefficient in the case that there are idle periods between computational activity for a given workflow. Further, traditional approaches may utilize an interface that limits how clients may submit workflows.

DETAILED DESCRIPTION

The systems and techniques described in this disclosure specify implementations of a workflow service for providing translation and registration of workflow definitions and execution of a workflow corresponding to the workflow definition. The workflow service allows workflows defined in multiple workflow domain specific languages, such as a graph based data structure workflow domain specific language or a workflow domain specific language that visually defines a workflow, to be submitted to the workflow service and translated into a workflow definition in accordance with a workflow domain specific language used by the workflow service. Further, the architecture of the workflow service allows parallel execution of multiple different workflows across multiple host computers within a provider network. In particular, the workflow service provides continuous execution of given workflows without dedicating computing resources for executing the workflow in between states of the workflow, which allows different host computers within the provider network to work on a single given workflow at different points in time—and preventing idle dedication of computing resources for servicing a given workflow.

According to some embodiments, a system includes a workflow translator service implemented on one or more computing devices, and a workflow service implemented on one or more computing devices. In some embodiments, the workflow translator service may be part of a workflow service, or may be a separate service that interacts with a workflow service. The workflow translator service is configured to receive workflows defined in a first domain specific language, wherein the first domain specific language is specific to a first workflow application domain and is structured according to a graph based data structure. For example, the workflow translator service may be configured to receive a workflow defined in accordance with a particular workflow application domain specific language, such as a business process and model notation (BPMN) domain specific language. The workflow translator service is further configured to identify elements of respective in-memory models of respective ones of the workflows defined in the first domain specific language that correspond to workflow elements in a second workflow domain specific language, wherein the second workflow domain specific language is specific to a different workflow application domain and is structured according to a different structure than the first workflow domain specific language.

For example, the workflow translator service may receive a workflow defined in an extensible mark-up language (XML) file that is structured according to a domain specific language specific to a particular workflow application, such as a BPMN workflow. The workflow translator service may convert the XML file into a graphical in-memory model of the workflow defined in the XML file according to the particular application domain specific language, such as the BPMN domain specific language. The workflow translator service may further traverse the graphical in-memory model of the workflow to identify workflow elements, such as nodes, branches, flow objects, connecting objects, and other workflow elements. For identified workflow elements the workflow translator service may determine whether a second domain specific language includes a corresponding workflow element, such as a corresponding connecting object, or a corresponding flow object, etc. In response to determining the second domain specific language includes one of the workflow elements identified in the graphical in-memory model, the workflow translator service may add the corresponding workflow element to a workflow template defined in accordance with the second workflow domain specific language.

The second domain specific langue may be a domain specific language that is used by a workflow service to execute workflows. For example in some embodiments the second domain specific language may be a proprietary workflow language used by a workflow service provider and, in some embodiments, may be formatted in accordance with a different data structure than the first domain specific language. For example, in some embodiments, the second domain specific language may be structured according to a tree based data structure whereas the first domain specific language may be structured according to a graph based data structure. Also, in some embodiments, the second domain specific language may be defined using a different coding language. For example, the first domain specific language may be formatted in accordance with an XML format and the second domain specific language may be formatted in accordance with a different coding language, such as Java script object notation (JSON), or other suitable coding language. In some embodiments, other coding languages, file formats, or structures may be used in the first domain specific language or in the second domain specific language. In some embodiments, both the first domain specific language and the second domain specific language may be non-proprietary domain specific languages. For example, in some embodiments the first domain specific language or the second domain specific language may be open source domain specific languages.

Further, the workflow service of the system is configured to store, in a workflow data store, one or more respective workflow definitions of the one or more workflows according to the second workflow domain specific language, wherein the respective ones of the one or more workflow definitions define states of a respective workflow indicating tasks to be performed for the workflow and transitions between the states. In addition, the workflow service is configured to generate a state machine for a particular workflow according to a particular workflow definition of the one or more respective workflow definitions stored in the workflow data store for the particular workflow; evaluate a current state for the particular workflow to determine a workflow decision for the particular workflow; and schedule for execution a task corresponding to the workflow decision.

According to some embodiments, a method includes receiving a workflow defined in a first workflow domain specific language; identifying elements of a model of the workflow defined in the first domain specific language that correspond to workflow elements in a second workflow domain specific language, wherein the second workflow domain specific language is structured using a different structure than the first workflow domain specific language; selecting the corresponding workflow elements for inclusion in a workflow definition according to the second workflow domain specific language that corresponds to the received workflow defined in the first domain specific language; and storing a workflow definition of the workflow according to the second workflow domain specific language, wherein the workflow definition according to the second workflow domain specific language comprises states of the workflow, tasks to be performed, and transitions between the states.

According to some embodiments, a non-transitory computer readable storage medium stores program instructions that when executed on one or more hardware processors causes the one or more processors to receive a workflow defined in a first workflow domain specific language; identify elements of a model of the workflow defined in the first domain specific language that correspond to workflow elements in a second workflow domain specific language; select the corresponding workflow elements for inclusion in a workflow definition according to the second workflow domain specific language that corresponds to the received workflow defined in the first domain specific language; and store a workflow definition of the workflow according to the second workflow domain specific language, wherein the workflow definition according to the second workflow domain specific language comprises states of the workflow, tasks to be performed, and transitions between the states

As a further example, the workflow service may provide a client interface, such as a graphical user interface and a front end, where the client interface provides a platform for the creation and registration of a workflow definition for a workflow. In some embodiments, a client may submit a workflow defined in a domain specific language used by the workflow service to execute workflows directly to the front end without using a workflow translator service. In other embodiments, a client may define a workflow using a graphical user interface generated by a workflow service and a workflow translator service may translate input received via the graphical user interface into a workflow definition in accordance with a domain specific language used by the workflow service to execute workflows. For example, in some embodiments, a client may drag and drop workflow elements to form a visual representation of a workflow using a graphical user interface generated by a workflow service and a workflow translator service may translate the visually defined workflow into a workflow definition in accordance with a domain specific language used by the workflow service to execute workflows.

In some embodiments, a workflow service may support versioning of workflow definitions and a workflow translator service may add a version identifier to a workflow definition. Also, in some embodiments, a workflow translator service may be configured to translate a workflow stored in a second workflow domain specific language back into a first workflow domain specific language.

For example, a client of a workflow service may visually define a workflow using a GUI generated by the workflow service where inputs from the client received via the GUI define the workflow according to a first domain specific language. For example a workflow may be defined via a drag and drop technique via a GUI generated by a workflow service. A workflow translator service of the workflow service may then translate the visually defined workflow from the first workflow domain specific language into a second workflow domain specific language. Prior to storing the translated workflow according to the second workflow domain specific language, a version identifier may be added to the workflow definition.

Subsequently, the client may desire to modify the stored workflow. In such cases, the workflow translator service may translate the stored workflow definition according to the second domain specific language into a corresponding workflow definition according to the first domain specific language. The workflow translated back into the first workflow domain specific language may be made available for the client to view and modify via the GUI and subsequent to the client of the workflow service modifying the workflow definition via the GUI, the modified workflow definition may be translated back into the second domain specific language and stored with a unique version identifier that indicates the modified workflow definition is a subsequent version of the original workflow definition that was stored according to the second domain specific language.

In some embodiments, multiple versions of a workflow may be made without visually defining a workflow via a GUI interface. For example, in some embodiments, a workflow may be received as a file formatted in accordance with a first domain specific language. Subsequently, a modified version of the file may be received as an additional version of the workflow and stored with a unique version identifier indicating that the subsequently received workflow is a version of the original workflow. In some embodiments, an application separate from a workflow service or a workflow translator service may be used to modify a workflow to create multiple versions of the workflow and the different versions of the workflow may be submitted to a workflow service and stored in a workflow depository of a workflow service with unique version identifiers after being translated into a workflow domain specific language used by the workflow service to execute workflows.

Further, in some cases, the front end may validate a workflow definition, and if the workflow definition is valid, then the front end may provide the workflow definition to a workflow handling service to begin executing the workflow. In some cases, the workflow definition may be defined as a state machine, where given states of the state machine specify one or more tasks to be performed for the state, and a transition to other states of the state machine. In this way, as progress is made through different states of the state machine, different tasks corresponding to the workflow are executed. Further, one workflow definition may be used to create any number of workflow threads. For example, if the workflow definition is for a workflow for processing online orders for items to be fulfilled, then the same workflow definition may be used in creating a workflow for each given item ordered.

Continuing with this example, the workflow handling service may begin execution of the workflow corresponding to the workflow definition. For example, the workflow handling service may receive an indication from the front end to begin execution of the workflow, and in response, the workflow handling service may make a request to a workflow evaluation service to determine a next task to schedule for the workflow. Requests from the workflow handling service to the workflow evaluation service may be non-blocking, which allows the workflow handling service to continue to receive indications to advance other workflows without waiting for the response from the workflow evaluation service. Further, the requests may include a log of completed tasks related to the workflow. As noted above, a single workflow definition may correspond to multiple, different workflows, and in such cases, the workflow handling service may maintain a respective workflow log for each respective workflow.

In this example, the workflow evaluation service, for each given request from the workflow handling service for a decision corresponding to a given workflow, may create a workflow evaluation thread to determine the decision and continue to receive requests for decisions for other workflows as each workflow evaluation thread executes. Further, in some cases, different workflow evaluation threads may execute on different computing hosts of a provider network, or within different instantiated computing resources of a given computing host of the provider network. In different embodiments, a workflow evaluation thread may generally be considered a sequence or collection of program instructions whose execution may progress concurrently, in parallel, or in an interlaced manner with other workflow evaluation threads. In some embodiments, a workflow evaluation thread may be spawned, created, or allocated by a parent process or thread, such as the workflow evaluation service. In other embodiments, a workflow evaluation thread may be a worker thread in a thread pool managed by a thread service.

Continuing with this example, for the workflow being initiated, the workflow evaluation thread, created by the workflow handling service in response to receiving the request for a decision, may construct a state machine for the workflow and determine a current state of the state machine. In this example, after evaluation the current state, the workflow evaluation thread may determine a next workflow decision and provide the workflow decision to the workflow handling service so that the workflow handling service may determine a corresponding task for the workflow decision and schedule the task for execution.

Further, the workflow handling service may log or record the workflow decision so that a subsequent workflow evaluation thread may determine a current state for the state machine corresponding to the workflow in order to determine a next workflow decision.

In this example, after the workflow evaluation thread completes, the workflow evaluation thread may terminate and any computing resources that were allocated for performing the workflow evaluation thread may be unallocated, or freed, for use. In this example, because each workflow evaluation thread terminates upon determining a workflow decision, a subsequent workflow evaluation thread—in order to determine a current state for the same workflow—uses the workflow log for a workflow to determine a current state of the state machine for the workflow.

In this way, for any given workflow, because a given workflow evaluation thread is provided with information for determining a current state of a workflow, a workflow evaluation thread does not need to persist in order to determine a current state of a workflow. Thereby preventing idle allocation of computing resources in providing continuous workflow execution.

FIG. 1Aillustrates an example computing environment that includes an example embodiment of a workflow translator service, workflow translator service102. A workflow translator service may be implemented as part of a workflow service or may be a service that interacts with a workflow service. In some embodiments, a workflow translator service may be implemented on computing resources of a provider network or on client computing resources. In some embodiments, a provider network may include a workflow translator service, such as workflow translator service102, and may receive one or more workflows submitted by clients of the provider network.

In some embodiments, a workflow service may be configured to execute workflows according to workflow definitions that are defined in accordance with a domain specific language in use by the workflow service of the provider network. However, in some cases, clients of a workflow service may desire to submit workflows defined in a different workflow domain specific language other than the domain specific language used by the workflow service to execute workflows. For example, some clients may desire to submit workflows defined in a domain specific language that visually defines a workflow, such as a business process model notation (BPMN) formatted domain specific language. In some embodiments, a workflow service may execute workflows defined in a workflow domain specific languages having a different structure than a structure of a domain specific language in which clients desire to submit workflows. For example clients may desire to submit workflows defined in a domain specific language with a graph based data structure and a workflow service may execute workflows defined in a domain specific language with a different data structure, such as a tree data structure. In some embodiments, a workflow translator service may allow clients of a workflow service to submit workflows defined in a variety of workflow domain specific languages, other than a domain specific language used by the workflow service to execute workflows, to the workflow service for execution by the workflow service. For example, in some embodiments, a workflow service may allow clients of the workflow service to submit workflows defined in YAWL (yet another workflow language), an XPDL workflow language, Business Process Execution Language (BPEL), or various other suitable workflow domain specific languages.

Workflow translator service102includes model converter104. In some embodiments, a workflow may be submitted to a workflow translator service as an XML, file of a graph based data structure. For example, workflow114defined in a first domain specific language may be a graph based data structure workflow defined according to a BPMN standard. Workflow114illustrates an example of both a visually defined workflow and a workflow defined according to a graph based data structure, such as a workflow defined according to a BPMN standard. In some embodiments, a workflow translator service may translate workflows defined in a workflow domain specific language that does not have a graph based data structure or that is not a visually defined workflow.

As can be seen inFIG. 1A, a workflow may include various workflow elements. For example, workflow114includes event116, which is a workflow start event, multiple activities, such as activity118“receive order” and activity120“prepare order.” Furthermore workflow114includes other workflow elements such as an exclusive gateway122used to determine whether “gift wrapping” is requested, and a parallel gateway124that allows a “fraud check” and a “bank account check” to be performed concurrently. Workflow114also includes sequence flow elements between activities and gateways, such as sequence flow elements128and130. In addition, workflow114includes a stop event126at the end of the workflow. Ellipses are illustrated in workflow114to indicate that the workflow may include any number or type of elements supported by a domain specific language in which the workflow is defined. Workflow114is illustrated only as an example workflow and should not be construed as an exhaustive list of workflow elements that may be included in a workflow submitted to a workflow translator service.

A model converter of a workflow translator service, such as model converter104of workflow translator service102may convert a workflow file into an in-memory model. For example, model converter104may receive workflow114as an XML file and covert workflow114into an in-memory model of the workflow, such as in memory model106.

A model translator of a workflow translator service, such as model translator108, may traverse an in-memory model of a workflow, such as in-memory model106, to identify elements of the workflow, such as activities118and120, sequence flow128, exclusive gateway122, parallel gateway124, event stop126, etc. A model translator may then determine if a second domain specific language, such as a domain specific language used by a workflow service to execute workflows, supports the identified workflow elements. In some embodiments, a determination of whether a second domain specific language supports a workflow element may be performed while a model translator is traversing an in-memory model of a workflow, or in some embodiments, a determination of whether a second domain specific language supports identified workflow elements may be performed after traversing an in-memory model to identify workflow elements.

A model translator of a workflow translator service, such as model translator108of workflow translator service102, may, for identified workflow elements, add corresponding workflow elements defined in accordance with the second domain specific language to a workflow template formatted in accordance with the second domain specific language. In some embodiments, a workflow translator service may cause a workflow service to generate a notification to a client for any workflow elements of a workflow submitted by the client that is not supported in a second domain specific language used by the workflow service to execute workflows. In some embodiments, a client may have an option to modify the submitted workflow to not include the non-supported workflow element or may have an option to attempt to register the workflow and have the workflow translator service not include the non-supported workflow elements in a workflow definition for the workflow.

Once the in-memory model of the submitted workflow has been traversed to identify workflow elements and corresponding workflow elements have been added to a workflow template formatted in accordance with a second domain specific language, the populated workflow template may be stored in a workflow definition storage as a workflow definition for the submitted workflow. For example workflow definition110formatted in accordance with a domain specific language used by a workflow service to execute workflows may be stored in workflow definition storage110. Workflow definition110may be a translated version of workflow114. In some embodiments, a domain specific language used by a workflow service may include additional features that are not supported in a first domain specific language in which a client submits a workflow to the workflow service. For example, workflow definition110includes a “time out” feature for tasks or activities that may not be included in workflow114defined in accordance with the first domain specific language. In some embodiments, default values may be used for features supported in the second domain specific language that are not included in a domain specific language that is used to define a workflow submitted to a workflow service by a client. In some embodiments, a client of a workflow service, may adjust one or more parameters of a workflow definition translated from a submitted workflow. For example, a client may adjust a timeout value for an activity. In some embodiments, a workflow translator service may be configured to translate workflows defined in multiple different domain specific languages into a domain specific language used by a workflow service to execute workflows.

Workflow definition110illustrates a code snippet of a workflow that has been translated into a second domain specific language as an example of a translated workflow. However, in some embodiments, various domain specific languages may be used by a workflow service to execute workflows and a workflow translator service may be configured to translate a workflow received in a first domain specific language into a second domain specific language, wherein the second domain specific language is a different domain specific language than the domain specific language shown in the example code snippet illustrated inFIG. 1A.

FIG. 1Billustrates an example computing environment that includes an example embodiment of a workflow service, workflow service152. In this example, the workflow service is implemented within provider network154. In this example, one or more clients, through one or more respective client computing devices156may access client interface158of the workflow service using network150. For example, a client may access a client interface to adjust one or more parameters of a workflow definition. Also, in some embodiments, a client may submit a workflow to a workflow translator service of a workflow service via a client interface. In some embodiments, a client interface may be a graphical user interface that allows a client to visually define a workflow.

As discussed above, a client interface may provide a platform for the specification of a workflow definition. In some examples, the workflow specification may be specified in a development environment providing tools for using a programming language with domain specific language features for defining workflows. In some embodiments, such a domain specific language may include language features for specifying workflow states, workflow tasks, including serial or parallel tasks, workflow state transitions, and workflow error handling, among other features. In some examples, the development environment may also include tools for specifying some or all features of a workflow using graphical tools.

In some examples, the client interface may be provided through a website. In other cases, the client interface may provide an application programming interface for interfacing with a client-side application such as a development kit installation.

As depicted, the client interface may communicate with workflow translator service102and front end160of the workflow service. The front end may validate a workflow definition received from a workflow translator service and then register the workflow or indicate to a client computing device that a workflow definition failed to validate. While front end160, workflow translator service102, and client interface168are depicted as separate for the purposes of clarity, the logical functionality of front end160, workflow translator service102, and client interface158may be combined in different embodiments.

As depicted, workflow service152may also include workflow handling service162, workflow evaluation service164, and job dispatcher166. In some embodiments, the logical functionality of a job dispatcher may be included within a workflow handling service instead of being a separate component of the workflow service. As discussed above, workflow handling service162may receive indications to either begin a workflow or to advance a workflow. For example, when a workflow is initially validated, the front end may indicate to the workflow handling service to begin execution of the workflow. In other cases, the workflow may have already been started, and the front end may provide to the workflow handling service an indication that a task corresponding to a given workflow has completed, and consequently, that a decision is to be made with regard to a next task to execute for the workflow.

As discussed above, to advance execution of a workflow, the workflow handling service may request a decision to be made for the workflow, where the decision is requested from the workflow evaluation service. Further, in some cases, the request from the workflow handling service may specify a workflow and a corresponding workflow log, where the workflow log may include previous events, completed tasks, or other information related to the workflow. As depicted, workflow logs168may be stored in workflow log storage170.

In some cases, in response to a request from the workflow handling service for a decision for the workflow, the workflow evaluation service may access a workflow definition for the workflow. As depicted, workflow definitions110may be stored in workflow definition storage112.

Further in this implementation, the workflow service may be one of multiple different services provided within a provider network, such as provider network176. As depicted, other services may include database service178, virtual computing service180, and event-based computing service182, among others. Further, in some embodiments, a database service, such as database service178, may provide the storage services provided by workflow definition storage174and/or workflow log storage170. More generally, any of the storage services used by the workflow service may be provided by either local storage, a storage service, or a combination of local storage and storage services.

In some embodiments, a workflow may be specified to use services provided entirely within provider network176. However, in other examples, a workflow may be specified to use one or more services provided from a third party, for example, services184. In some cases, a combination of provider network services and third party services may be used in the execution of a given workflow.

In this way, beginning with a client system specifying a workflow, a workflow service may begin executing the workflow in a manner that provides continuous workflow processing using multiple, discrete deployments of computation resources in a manner that avoids idle allocations of computing resources. Further, given that a given workflow may be serviced by a new processing thread each time the workflow is to be advanced, distribution of the computation for the processing threads may be spread across different computing hosts of the provider network to avoid computational bottlenecks and to allow for efficient scaling of the servicing of multiple different workflows.

FIG. 2Aillustrates flowchart200depicting example operations performed in a workflow translator service102of a workflow service in receiving a workflow from a client, wherein the received workflow is not formatted in accordance with a domain specific language used by the workflow service to execute workflows. In some embodiments, a workflow service may be configured to receive workflows defined in a domain specific language other than a domain specific language used by the workflow service to execute workflows. Also, in some embodiments, a workflow service, may generate a graphical user interface (GUI) allowing a client to define a workflow using the graphical user interface. In some embodiments, a workflow service may be configured to both receive workflows defined in a domain specific language other than a domain specific language used by the workflow service to execute workflows and implement a GUI allowing a client to define a workflow via the GUI.

At202, workflow translator service102implements a GUI for defining a graphical workflow. In some embodiments, a workflow translator service, such as workflow translator service102, may generate a GUI interface for defining a workflow and implement the GUI via a client interface of a workflow service, such as client interface158. A GUI interface for defining workflows may include a set of workflow elements, such as activities, events, gateways, connections, etc. and may allow a client to drag and drop different combinations of workflow elements to define a workflow via the GUI interface. For example, at206, the workflow translator service102receives input from a client for defining a workflow via the GUI interface. In some embodiments, the received input, may be based on a client dragging and dropping workflow elements to define a workflow via the GUI interface.

In addition, in some embodiments, a workflow translator service, such as workflow translator service102, may receive a workflow file defined according to a domain specific language other than a domain specific language used by the workflow service to execute workflows. For example, a client may submit an XML file defining a workflow according to a BPMN standard. The BPMN standard may be structured according to a graph based data structure, whereas, in some embodiments, a workflow service may be configured to execute workflows defined using a different data structure, such as a tree based data structure. In some embodiments, a workflow service may be configured to execute workflows defined in multiple different domain specific languages having different data structures without translating the workflows to a specific domain specific language or, in some embodiments, a workflow translator service may support translation of workflows defined in multiple different domain specific languages. For example, in some embodiments, a workflow service may be configured to execute workflows in multiple native domain specific languages or translate workflows defined in multiple different workflow domain specific languages into a common domain specific language used by the workflow service to execute workflows.

At208, once a workflow is received at204or at206, a model converter of a workflow translator service may convert the received workflow into an in-memory model. For example, the in-memory model may represent a graphical structure of the workflow. In some embodiments, an in-memory model may have a structure other than a graphical structure.

At210, a model translator of a workflow translator service may traverse the in-memory model to identify workflow elements of the in-memory model. For example, elements of a workflow may include, events, activities, gateways, nodes, branches, switches, etc. In, addition, a workflow translator service may traverse the in-memory model to identify other workflow elements, such as variables.

Some workflow domain specific languages may utilize global variables so that new variables may be introduced anywhere in the workflow, whereas other domain specific languages may use local variables, global variables, control variables, or some other combination of variables. Some domain specific languages may be formatted such that certain variables are initially declared in the workflow definition, such that it is necessary to determine such variables at the outset of translating a workflow to a particular domain specific language. Thus, in some embodiments, a model translator of a workflow translator service may initially traverse an in-memory model to determine variables defined in the model before adding corresponding workflow elements to a workflow definition of the workflow according to a second domain specific language.

In some embodiments, a domain specific language used by a workflow service to execute workflows may define branches of a workflow, where, in order to define the branch, a start point and end point for the branch needs to be determined. In some embodiments, a model translator of a workflow translator service may trace out branches of an in-memory model to determine starting points, ending points, or converging points of branches of the in-memory model in order to define the branches in a workflow definition in a domain specific language used by a workflow service to execute workflows. In some embodiments, after identifying workflow elements of the in-memory model, a model translator of a workflow translator service may determine corresponding workflow elements that correspond to the identified workflow elements of the in-memory model that are defined according to another domain specific language, such as a domain specific language used by a workflow service to execute workflows. The identified corresponding workflow elements defined in the other domain specific language may be selected for inclusion in a workflow template formatted in accordance with the other domain specific language. In some embodiments, a model translator of a workflow translator service may determine corresponding workflow elements defined in the other particular domain specific language and add the corresponding workflow elements defined in the other domain specific language to a workflow template while traversing the in-memory model to identify workflow elements. While in other embodiments, a model translator of a workflow translator service may add corresponding workflow elements to a workflow template after traversing the in-memory model to identify workflow elements.

At214, a model translator of a workflow translator service may identify workflow elements in the in-memory model that do not have corresponding workflow elements in the other particular domain specific language. For example, a first workflow domain specific language may include a particular type of gateway that is not supported in a second domain specific language in which a workflow service executes workflows. In response to identifying workflow elements that are not supported in the other particular domain specific language, the workflow service may generate a message to a client of the workflow service indicating that one or more workflow elements of the submitted workflow are not supported by a domain specific language that the workflow service uses to execute workflows. In some situations, the client may revise the workflow to not include the non-supported workflow element(s) and re-submit the workflow. In other situations, the client may continue with registration of the workflow and the workflow translator service may omit the non-supported workflow elements from a translated version of the submitted workflow.

At216, a workflow definition is assembled in a workflow template using the identified workflow elements that are supported in the particular domain specific language. For example, assembling the workflow definition may include adding paths between identified workflow elements that have been translated into the particular workflow domain specific language. In some embodiments, the particular domain specific language may include features not included in a domain specific language in which the workflow was submitted. For example, in some embodiments, a domain specific language used by a workflow service to execute workflows, may support workflow logs, task timeout periods, and other additional features. In some embodiments, assembling a workflow definition for the workflow according to the other particular domain specific language may include setting default values for features supported in the other particular domain specific language but not supported in the domain specific language in which the workflow was submitted. For example, assembling a workflow definition may include setting a default amount of time for a task timeout feature that is not supported in a domain specific language in which the workflow was submitted.

FIG. 2Billustrates flowchart250depicting example operations performed in a workflow service in receiving a workflow definition for a workflow from a workflow translator service or in receiving a workflow definition already defined in a domain specific language used by the workflow service to execute workflows. In this example, the workflow service may receive a workflow definition from a workflow translator service or from a client, as depicted at252. As discussed above, the workflow definition may be specified in a domain specific language that describes a state machine for the workflow, including tasks, transitions, error handling, and a terminating condition, among others or may be translated into a domain specific language that describes a state machine for the workflow, including tasks, transitions, error handling, and a terminating condition, among others. In some embodiments, at252in addition to receiving a workflow an indication of a version for the received workflow may be received. For example, a client may indicate that a submitted workflow is a second version of the workflow.

The workflow service, given a workflow definition, may validate the workflow definition, as depicted at254. In some cases, the validation may include validating that certain types of error handling are valid, data flows between states of the workflow state machine are valid with regard to parameter inputs and outputs, including other forms of validation.

If the workflow definition is valid, and as depicted at256, the workflow service may store the workflow definition in a workflow repository and return a workflow registration success message, as depicted at258and260, respectively. Otherwise, if the workflow definition is not determined to be valid, the workflow service may return a workflow validation error, as depicted at262. In some embodiments, a version identifier may be associated with the workflow when the workflow is stored at258. In some embodiments, a workflow service may generate a version identifier for a workflow at258.

Once a workflow definition is successfully registered, the workflow service may invoke the workflow handling service to begin execution of the workflow.

FIG. 3illustrates flowchart300depicting example operations performed in a workflow service in executing a workflow. As one example, workflow service152within provider network176may validate and register a workflow definition. As described with regard toFIG. 2B, if the workflow definition is determined to be valid, the workflow handling service may be invoked to either begin executing or to advance the workflow. For example, front end160, may call the workflow handling service with parameters indicating the workflow, and indicating that the workflow is to begin executing.

In this example, as depicted at302, the workflow handling service may receive the call or indication to start the workflow. In other cases, once the workflow has begun executing, the workflow handling service may receive indications with regard to the already executing workflow describing a task completion event for the workflow. In such an instance, as depicted at302, the workflow handling service may receive an indication to advance the workflow and also receive a description of, for example, a task that has completed for the workflow.

The workflow handling service may also log or record an indication of the event within a workflow log corresponding to the workflow. In this example, the workflow handling service may record an indication that the workflow was requested to begin executing or record an indication that a task for the workflow has completed. In other cases, the event may indicate a task failure, or some other status information related to the workflow, and the workflow handling service may record any and all information with regard to the workflow. Further, in some cases, the workflow handling service may log each recording of information with a sequence number or timestamp so that an order may be determined with regard to the logged information.

In this example, the workflow handling service, in response to receiving the indication to start or advance the workflow, may request a workflow decision from the workflow service, as depicted at304. The request from the workflow handling service to the workflow service may include an indication of the workflow and the workflow log or a reference to the workflow log, where the workflow log may include events related to the workflow, as depicted at304.

In this example, the operations performed by the workflow handling service are indicated within flowchart300by workflow handling service330. The request for a workflow decision from workflow handling service330to the workflow evaluation service340may be a non-blocking request such that after the workflow handling service sends the request, the workflow handling service is available to process additional indications to start or advance other workflows while the workflow handling service340is processing a previous request. Further, workflow evaluation service340may receive a workflow decision request and create a workflow evaluation thread350to determine a workflow decision. In some cases, after the workflow evaluation service340creates and initiates a workflow evaluation thread350, the workflow evaluation service is available to receive additional requests for additional workflow decisions. In this way, workflow evaluation service340may spawn any number of workflow evaluation threads to execute in parallel to determine any number of respective workflow decisions.

One effect of the workflow handling service using non-blocking requests and the workflow evaluation service spawning parallel workflow evaluation threads is that as increased numbers of workflows are created and serviced, there are no bottlenecks in the actual processing of the workflow decisions, but rather the limit is in how quickly the workflow handling service receives and sends requests for workflow decisions—which may be done efficiently since this is a small number of quick operations—and how quickly the workflow evaluation service receives and creates workflow evaluation threads which, again, may be done efficiently since this is a small number of quick operations.

Continuing with this example, as depicted at306, workflow evaluation service340may receive the workflow decision request for the workflow. In this example, the workflow decision request from the workflow handling service may include a workflow log for the workflow. Receiving the workflow log may effectively transfer state of the workflow to the workflow evaluation service. To determine a workflow decision, workflow service340may allocate computing resources on a host computer and create a workflow evaluation thread to determine the workflow decision, where the workflow evaluation thread may execute on the allocated computing resources. In this example, the host computer may be one of multiple different host computers available to the workflow evaluation service within the provider network.

The workflow evaluation thread, once created, may proceed to generate a state machine for the workflow, where the workflow is specified according to a workflow definition, as depicted at308. In this example, the state machine is created from scratch and has no dependencies or reliance on previously generated state machines or previously determined workflow decisions. Given a created state machine, the workflow evaluation thread may determine a current state of the workflow based at least in part on applying the workflow log to the state machine to transition the state machine to a current state of the workflow, as depicted at310. For example, an ordered list of completed tasks in the workflow log may be accessed, and the workflow evaluation thread may correspond each completed task with a transition in the state machine as indicated by transitions specified in the workflow definition. In this way, events logged in the workflow log, in correspondence with the workflow definition, may be used to transition from an initial state of a state machine for the workflow to a current state for the workflow.

Given a current state of the state machine for the workflow, the workflow evaluation thread may evaluate the current state to determine a workflow decision, as depicted at312. For example, the workflow evaluation thread may determine, according to the workflow definition for the workflow, that at a current state, and given previously completed tasks, that a next decision includes a particular task, operation, or decision. The workflow evaluation thread may then provide the workflow decision to the workflow handling service, as depicted at314.

The workflow handling service, in response to receiving the workflow decision from the workflow evaluation thread, may record the workflow decision in the workflow log, as depicted at316. Further, the workflow handling service may determine, as depicted at318, that the workflow decision corresponds to completion of the workflow or that the workflow decision corresponds to a task.

If the workflow decision corresponds to a task to be executed for processing the workflow, as depicted at320, then the workflow handling service may dispatch a task according to the workflow decision. In other cases, the workflow handling service may instead provide the task to be performed to a job dispatcher, where the job dispatcher may schedule the task to be executed. At this point, if the workflow handling service is not servicing additional requests to advance other workflows, then the workflow handling service may wait for a task completion event, upon which the workflow handling service may begin again as depicted at302.

If the workflow decision corresponds to completion of the workflow, as depicted at322, then the workflow handling service may report completion of the workflow, for example, to the front end. In turn, the front end may notify a client of the completion of the workflow.

FIG. 4illustrates flowchart400depicting example operations performed by a workflow evaluation service. As discussed above with regard toFIG. 3, a workflow evaluation service may be workflow evaluation service340. In between processing workflow decision requests, a workflow evaluation service may wait for request from the workflow handling service, as depicted at402.

In this example, a request may be received from a workflow handling service, such as a request from304in flowchart300ofFIG. 3. As depicted at404, the workflow evaluation service may then receive the request for a workflow decision from the workflow handling service, where the request may include a workflow log for the workflow.

As described above with regard toFIG. 3, the workflow evaluation service, to determine a workflow decision, may allocate computing resources for executing a workflow evaluation thread that determines and returns the workflow decision to the workflow handling service, where after the workflow evaluation thread is created and initiated, the workflow evaluation service may wait for additional requests, as depicted at406.

As described above with regard toFIG. 3, the workflow evaluation thread may proceed to determine a workflow decision for the workflow, including the operations308-314ofFIG. 3. After the workflow evaluation thread provides the workflow handling service with a workflow decision, the workflow evaluation thread may terminate and the allocated computing resources used to execute the workflow evaluation thread may be freed, as depicted at408and410. In this way, the allocated resources may be made available for processing other workflow decisions.

As discussed above, the allocated resources may be freed or unallocated because each time a request for a workflow decision is received, a workflow evaluation thread may determine, from scratch or entirely from the workflow log and workflow definition, a current state for the workflow and a next workflow decision.

FIG. 5illustrates parallel operations between the workflow handling service, the workflow evaluation service, and workflow evaluation threads discussed above with regard toFIGS. 2B-4. In this example, the workflow handling service may receive an indication to start or advance a workflow, as depicted at302at time t1, where302corresponds to the operations described above with regard toFIG. 3.

In this example, the workflow handling service may then request a decision for a workflow decision for a first workflow, as depicted at304at time t2. Further, the request from the workflow handling service to the workflow evaluation service may be a non-blocking call, as depicted by non-blocking call502. Given that the request for a workflow decision is non-blocking, as soon as the workflow handling service makes the request, the workflow handling service is available to process or receive additional requests, which in this example, is depicted at302at time t3.

In this example, the request from the workflow handling service is received by the workflow evaluation service at time t3, which as described above, is also approximately the time at which the workflow handling service receives another indication to start or advance another workflow. As depicted by workflow evaluation service420at time t3, the workflow evaluation service may receive the request for a workflow decision, along with a workflow log, allocate computing resources for a workflow evaluation thread to determine the workflow decision and then proceed to initiate or call the workflow evaluation thread. In this example, the call to the workflow evaluation thread from the workflow evaluation service420at time t3is depicted by non-blocking call504.

As depicted at time t4, at this point, the workflow handling service has already received an indication to start or advance another workflow, and may then request a workflow decision via non-blocking call506. Further at time t4, a workflow evaluation thread for determining a workflow decision for the first workflow has been started, as depicted by workflow evaluation thread430called by non-blocking call504.

The request for a workflow decision for the other workflow at time t4and via non-blocking call506may be received by workflow evaluation service420at time t5. Further at time t5, while the workflow evaluation service420is processing the request for the other workflow decision, the workflow evaluation thread430initiated at time t4for the first workflow decision is still executing.

Further as depicted at time t5, after the workflow evaluation service420allocates computing resources for a workflow evaluation thread to determine the other workflow decision, the workflow evaluation service420may call the workflow evaluation thread430via non-blocking call508.

As depicted at time t6, at this point, both workflow evaluation thread430initiated at time t4to determine the first workflow decision and workflow evaluation thread430initiated at time t6to determine the other workflow decision are executing. As described above, the different workflow evaluation threads may be executing on different allocated resources, and in some cases, the different allocated resources may be on different host computers of the provider network. In other cases, the different allocated resources may be on the same host computer of the provider network. As discussed below inFIG. 6, a determination of what resources to use to execute the workflow evaluation threads may be made by a load balancer.

FIG. 6illustrates an embodiment of workflow service152with additional possible features. In this embodiment, workflow service152includes, as depicted inFIG. 1, client interface158, workflow translator service102, front end160, workflow handling service162, and job dispatcher166. However, in this example, workflow evaluation service164includes a load balancer, load balancer602, and a workflow evaluation fleet of host computers or systems, hosts604H(1)-604H(n).

As discussed above with regard toFIG. 5, a workflow evaluation service may receive multiple requests from a workflow handling service for different workflow decisions for different workflows. In such an example, the workflow evaluation service may determine how to distribute processing of the workflow decisions. As depicted, the workflow evaluation service may include a load balancer that serves to receive multiple requests for workflow decisions, and to determine which computing resources to deploy for executing respective workflow evaluation threads for determining the workflow decisions.

In this example, the computing resources from among which the load balancer602may deploy for executing different workflow evaluation threads is depicted by workflow evaluation fleet604. In this example, workflow evaluation fleet604may include multiple computing hosts, hosts604H(1)-604H(n). Example workflow evaluation threads are depicted by workflow evaluation threads604W(1)-604W(n).

In some embodiments, each of computing hosts604H(1)-604H(n) may include a respective local cache, local caches604C(1)-604C(n). While the examples discussed above with regard toFIGS. 1B-5describe workflow evaluation services and workflow evaluation threads that operate without persisting a current workflow state for a workflow from one instance of a workflow evaluation thread to a subsequent instance of a workflow evaluation thread, in some cases, while the workflow evaluation thread may terminate, the state machine created by the workflow evaluation thread may remain stored in a local cache for the host on which the workflow evaluation thread executed.

In some cases, for example in a workflow that quickly transitions between states of the state machine for the workflow, a state machine created by a workflow evaluation thread at, say, time to, may still reside in the local cache when a subsequent workflow evaluation thread executes at, say, time to. In different example, the local cache for a given host may store data according to different retention policies.

Further, in some instances, it may be that while a state machine for a given workflow may be in a local cache, say local cache604C(1), when a subsequent workflow evaluation thread is initiated, the load balancer may deploy the subsequent workflow evaluation thread to execute on a different host and different local cache, for example host604H(n) and local cache604C(n). In such an example, the previously constructed state machine for the given workflow may not be available to the subsequent workflow evaluation thread even though the state machine for the given workflow still resides in a different local cache.

To overcome such a situation, in some embodiments, the workflow evaluation service may use a cache service, such as cache service606. Cache service104may be a distributed cache, and in some cases, cache service606may be the storage tier from which data in the host caches move data. For example, in the previous example, where a load balancer deploys a workflow evaluation thread to determine a workflow decision from host604H(1), and the state machine for the workflow is stored in local cache604C(1), the state machine may be flushed or copied from local cache604C(1) into cache service606.

In this way, in this example, at a subsequent time, when a subsequent workflow evaluation thread for the given workflow executes from a different host, the workflow evaluation thread may access the state machine for the workflow from the cache service606. In such an example, the subsequent workflow evaluation thread may determine a workflow decision without constructing a state machine from the workflow definition.

In other embodiments, a workflow service may also use checkpoints to determine a current state of a state machine without transitioning through all states of the state machine from the initial state to a current state. For example, the workflow handling service may periodically or aperiodically store a checkpoint, where the checkpoint defines a particular state of the state machine up to a particular point in the workflow. In this example, a workflow evaluation thread may apply the checkpoint to the state machine to reach the particular state of the state machine. In some implementations, the checkpoint for a workflow may be received as a parameter of the request for a workflow decision and passed from the workflow evaluation service to the workflow evaluation thread. In other implementations, the workflow evaluation service or the workflow evaluation thread may access the checkpoint corresponding to a given workflow from a data store or database service. In this example, the workflow evaluation thread may then reference the workflow log to transition the state machine from the particular state to the current state of the state machine, for example. For example, the workflow evaluation thread may find an event in the workflow log corresponding to the checkpoint, and transition the state machine using events subsequent to the checkpoint up to a current event. Further in this example, the workflow checkpoints are indicated by workflow checkpoints610.

Further, in this embodiment of workflow service152, the workflow handling service may use a workflow log storage for maintaining current workflow logs, such as workflow log storage612. As depicted, workflow log storage612may store workflow logs614.

In some embodiments, workflow service152may also include a version binding module, such as version binding module616. As described above, a single workflow definition may be used to create multiple instances of a workflow. In such an example, the processing for each different workflow still corresponds to the same workflow definition. However, in some cases, a version binding module may be used to correspond, or bind, different workflow definition versions with different instances of workflows. For example, a client may create a workflow definition and create a corresponding workflow. While this workflow is executing, the client may create an updated version of the workflow definition and create another workflow using the updated workflow definition. In this way, the other workflow using the updated workflow definition may be created and started while the workflow using the previous version of the workflow definition is still executing. In other words, a workflow definition version may be maintained and bound to an executing workflow for the execution life cycle of the workflow. Further, any number of workflows using different versions of may be concurrently executing, thus allowing for rolling releases of workflows for workflow definitions with different sets of features. In some examples, the front end of the workflow service may provide the user with choosing any given version, past or current, of a workflow definition from which to start a workflow.

FIG. 7illustrates an example state machine, state machine700, corresponding to a workflow, such as a workflow defined according to a workflow definition translated from a workflow submitted by a client in a domain specific language other than a domain specific language used by a workflow service to execute workflows. In this example, the workflow includes multiple states and different types of transitions in between states. In other examples, different numbers, different types, and different types of transitions may be specified in a workflow definition. As discussed above, in some embodiments, a domain specific workflow used by the workflow service to execute workflows may define the states, transitions, and tasks of a state machine for a workflow.

In this example, a workflow may be defined to perform order fulfillment services. For example, the first state of a state machine for the workflow may be defined to be receiving an order, as depicted at702. With regard to the workflow handling service described above with regard toFIGS. 1-6, state machine700specified within a workflow definition for a workflow may be received in another workflow domain specific language other than a domain specific language used by the workflow service to execute workflows, translated by workflow translator service102and validated by front end160of the workflow service. The front end, based on validating the workflow definition, may call the workflow handling service to start the workflow. The workflow, in turn, may then send a request for a workflow decision for the workflow to the workflow evaluation service, where the workflow log for the workflow may be empty of any completed tasks, but may include a record of an indication to start the workflow. After sending the request for the workflow decision, the workflow handling service may then wait for a next request to advance or start a workflow until it receives the workflow decision.

In some cases, a single state of a state machine for a workflow may be specified according to a domain specific language to be a state module that includes one or more tasks, an identification of one or more resources for performing the one or more tasks, and one or more transitions or branches to other states. Together, the individually defined states may be interpreted as a whole to specify the operations to be executed in servicing a workflow.

In this example, a first state of the state machine for the workflow, receive order702, may specify using a domain specific language supported by the workflow service that a task to be performed uses a resource provided by a particular service, and that upon completion of the task, receive order702state transitions to prepare order704state. In this example, completion of the task for the receive order702state is indicated by complete706.

Again, with regard to the workflow handling service and the workflow evaluation service, after the workflow evaluation service receives the request for a workflow decision, the workflow evaluation service may, as depicted inFIG. 4, allocate computing resources for a workflow evaluation thread to determine the workflow decision. Once initiated, the workflow evaluation thread may access the workflow definition that specifies the state machine for the workflow and construct the state machine. Given a constructed state machine, in this case state machine700, the workflow evaluation thread may determine the first state and access the workflow log to traverse through the state based on events logged in the workflow log until a current state of the state machine is reached.

In this example, given the constructed state machine and a workflow log for the workflow indicating that no tasks have been completed for the state machine, the workflow evaluation thread may determine that the current state is receive order702. Further, the workflow evaluation thread may use the workflow definition to determine that given the current state of receive order702, that the workflow decision should be to perform a task indicated by the state module for the receive order702state. This workflow decision may be provided to the workflow handling service for scheduling of the task.

At a later time, when a notification corresponding to a completion of the task for the receive order702state is received by the workflow handling service, the workflow handling service may again request a workflow decision from the workflow evaluation service. At this point, the first task of the workflow for fulfilling an order may be completed.

In response to receiving a request to advance to the workflow, the workflow handling service may again send a request for a workflow decision to the workflow evaluation service. The workflow evaluation service may repeat the process for handling a request for a workflow decision. However, at this point, the workflow evaluation thread that is created accesses the same workflow definition as the first workflow evaluation thread, but the workflow log may include a record of the first task having been completed. Accordingly, after constructing state machine700, the workflow evaluation thread may end up a current state of prepare order704based on the workflow log indicating that the task for receive order702having been completed.

Given that each workflow evaluation thread uses the workflow definition and workflow log to determine a current state, there is no data flow from one workflow evaluation thread to a subsequent workflow evaluation thread, thereby allowing each subsequent workflow evaluation thread to be scheduled to execute on different computing resources without any negative computational impact. Further, such scheduling allows a load balancer the flexibility to deploy any computing resources without regard to which resource was previously used to process a workflow decision request. Further still, given that each workflow evaluation thread may independently determine a current state for a state machine, the load balancer may use any factors to determine the computing resources to be deployed. Including, for example, workloads on a given host, price constraints in a client contract for provider services, performance requirements specified in a client contrast for provider services, or a combination of factors, including other factors.

At this point in the workflow, the workflow handling service may receive a workflow decision for the workflow and schedule a corresponding task for the prepare order704state. In this example, depending on whether or not the order is a gift, the workflow evaluation service may provide the workflow handling service with a workflow decision corresponding to a task to gift wrap the order or the persist the order, as depicted at gift wrap708and persist order710. Further, the transitions between prepare order704and gift wrap708is depicted by is-a-present712, and the transition between prepare order704and persist order710is depicted by not-a-present714. The transition in between the gift wrap708state and the persist order710state is depicted by complete716.

From the persist order710state, the workflow evaluation service may determine that there four tasks to schedule as part of a workflow decision for the four branches from the persist order710state, branches710(1)-710(4). Accordingly, the workflow handling service may schedule for execution tasks corresponding, respectively, fraud check718, check bank account720, notify accounting722, and record transaction attempt724.

In this example, when the task corresponding to the fraud check718state completes, the workflow handling service is called, which requests a workflow decision from the workflow evaluation service. In this example, the workflow evaluation thread may reach the authorize transaction726state, but the authorize transaction726state may specify that both the fraud check718task or tasks and the check bank account720task or tasks are to be completed before tasks for the authorize transaction726state are performed. The transition between the fraud check718state and the authorize transaction726state is depicted by complete730, and the transition between the check bank account720state and the authorize transaction726state is depicted by complete732.

Therefore, in this example, the workflow evaluation thread may return to the workflow evaluation service a workflow decision to do nothing. However, when the workflow handling service is called due to check bank account720task or tasks being completed, the workflow evaluation thread may determine that preconditions for executing have been satisfied, and generate a workflow decision corresponding to authorization of the transaction, as depicted at726.

Similarly, the ship order728state may not have any corresponding tasks execute until tasks corresponding, respectively, to authorize transaction726, notify accounting722, and record transaction attempt724have completed. The transition between the notify accounting722state and the ship order728state is depicted by complete734, and the transition between the record transaction attempt724state and the ship order728state is depicted by complete736.

In this way, a workflow service may process the workflow corresponding to state machine700, and correspondingly, fulfill an order.

FIG. 8illustrates an example computer system, computer system800, where computer system800may be configured to implement different workflow service implementations, according to the discussed embodiments and examples. In different embodiments, the computer system may be any of various types of devices, including, but not limited to, a personal computer system, desktop computer, laptop, notebook, or netbook computer, mainframe computer system, handheld computer, workstation, network computer, a camera, a set top box, a mobile device, a consumer device, video game console, handheld video game device, application server, storage device, a television, a video recording device, a peripheral device such as a switch, modem, router, or in general any type of computing or electronic device. Generally, the methods described herein may in various embodiments be implemented by any combination of hardware and software.

Further, the methods described herein may in various embodiments be implemented by any combination of hardware and software. For example, the methods may be implemented by computer system800that includes one or more processors executing program instructions stored on a computer-readable storage medium coupled to the processors. The program instructions may be configured to implement the functionality described herein (e.g., the functionality of various servers and other components that implement the look-up component described herein). The various methods as illustrated in the figures and described herein represent example embodiments of methods. The order of any method may be changed, and various elements may be added, reordered, combined, omitted, or modified.

Computer system800includes one or more processors810a-810n(any of which may include multiple cores, which may be single or multi-threaded) coupled to a system memory820via an input/output (I/O) interface830. Computer system600further includes a network interface840coupled to I/O interface830. In various embodiments, computer system800may be a uniprocessor system including one processor, or a multiprocessor system including several processors (e.g., two, four, eight, or another suitable number). Processors810may be any suitable processors capable of executing instructions. For example, in various embodiments, processors810may be general-purpose or embedded processors implementing any of a variety of instruction set architectures (ISAs), such as the x86, PowerPC, SPARC, or MIPS ISAs, or any other suitable ISA. In multiprocessor systems, each of processors810may commonly, but not necessarily, implement the same ISA. The computer system800also includes one or more network communication devices (e.g., network interface840) for communicating with other systems and/or components over a communications network (e.g. Internet, LAN, etc.). For example, a client application executing on system800may use network interface840to communicate with a server application executing on a single server or on a cluster of servers that implement one or more of the components of the systems described herein. In another example, an instance of a server application executing on computer system800may use network interface840to communicate with other instances of the server application (or another server application) that may be implemented on other computer systems. Further, computer system800, via I/O interface830, may be coupled to one or more input/output devices850, such as cursor control device860, keyboard870, camera device890, and one or more displays880.

In the illustrated embodiment, computer system800also includes one or more persistent storage devices and/or one or more I/O devices850. In various embodiments, persistent storage devices may correspond to disk drives, tape drives, solid state memory, other mass storage devices, or any other persistent storage device. Computer system800(or a distributed application or operating system operating thereon) may store instructions and/or data in persistent storage devices, as desired, and may retrieve the stored instruction and/or data as needed. For example, in some embodiments, computer system800may host a storage system server node, and persistent storage may include the SSDs attached to that server node.

Computer system800includes one or more system memories820that are configured to store instructions and data accessible by processor(s)810. In various embodiments, system memories820may be implemented using any suitable memory technology, (e.g., one or more of cache, static random access memory (SRAM), DRAM, RDRAM, EDO RAM, DDR 10 RAM, synchronous dynamic RAM (SDRAM), Rambus RAM, EEPROM, non-volatile/Flash-type memory, or any other type of memory). System memory820may contain program instructions825that are executable by processor(s)810to implement the methods and techniques described herein. In various embodiments, program instructions825may be encoded in platform native binary, any interpreted language such as Java™ bytecode, or in any other language such as C/C++, Java™, etc., or in any combination thereof. For example, in the illustrated embodiment, program instructions825include program instructions executable to implement the functionality of a database service, tracking-enabled client, update tracker, update listener, and/or update consumer in different embodiments. In some embodiments, program instructions825may implement multiple separate clients, server nodes, and/or other components.

In some embodiments, system memory820may include data store835, which may be configured as described herein. In general, system memory820(e.g., data store835within system memory820), persistent storage, and/or remote storage may store data blocks, replicas of data blocks, metadata associated with data blocks and/or their state, configuration information, and/or any other information usable in implementing the methods and techniques described herein. Further, data store820may include modules for implementing an active content filter110in an embodiment of a static content endpoint server.

In one embodiment, I/O interface830may be configured to coordinate I/O traffic between processor(s)810, system memory820and any peripheral devices in the system, including through network interface840or other peripheral interfaces. In some embodiments, I/O interface830may perform any necessary protocol, timing or other data transformations to convert data signals from one component (e.g., system memory820) into a format suitable for use by another component (e.g., processor(s)810). In some embodiments, I/O interface830may include support for devices attached through various types of peripheral buses, such as a variant of the Peripheral Component Interconnect (PCI) bus standard or the Universal Serial Bus (USB) standard, for example. In some embodiments, the function of I/O interface830may be split into two or more separate components, such as a north bridge and a south bridge, for example. Also, in some embodiments, some or all of the functionality of I/O interface830, such as an interface to system memory820, may be incorporated directly into processor(s)810.

Network interface840may be configured to allow data to be exchanged between computer system800and other devices attached to a network, such as other computer systems (which may implement one or more storage system server nodes, database engine head nodes, and/or clients of the database systems described herein), for example. In addition, network interface840may be configured to allow communication between computer system800and various I/O devices850and/or remote storage. Input/output devices850may, in some embodiments, include one or more display terminals, keyboards, keypads, touchpads, scanning devices, voice or optical recognition devices, or any other devices suitable for entering or retrieving data by one or more computer systems800. Multiple input/output devices850may be present in computer system800or may be distributed on various nodes of a distributed system that includes computer system800. In some embodiments, similar input/output devices may be separate from computer system800and may interact with one or more nodes of a distributed system that includes computer system800through a wired or wireless connection, such as over network interface840. Network interface840may commonly support one or more wireless networking protocols (e.g., Wi-Fi/IEEE 802.11, or another wireless networking standard). However, in various embodiments, network interface840may support communication via any suitable wired or wireless general data networks, such as other types of Ethernet networks, for example. Additionally, network interface840may support communication via telecommunications/telephony networks such as analog voice networks or digital fiber communications networks, via storage area networks such as Fibre Channel SANs, or via any other suitable type of network and/or protocol. In various embodiments, computer system800may include more, fewer, or different components than those illustrated (e.g., displays, video cards, audio cards, peripheral devices, other network interfaces such as an ATM interface, an Ethernet interface, a Frame Relay interface, etc.)