Abstract: An episodic execution of program instances and a coordinated message exchange protocol are combined to achieve eventual consistency in the communication between nodes of a distributed system. Program instances run in episodic loops that are triggered by defined input events and that generate checkpoints. The checkpoints indicate when messages are to be sent from the one instance to another instance or other device. The coordinated message exchange protocol allows the instance to send a message to a receiver, to acknowledge that the message has been received, and to confirm the acknowledgement to the receiver.

Abstract: An episodic execution of program instances and a coordinated message exchange protocol are combined to achieve eventual consistency in the communication between nodes of a distributed system. Program instances run in episodic loops that are triggered by defined input events and that generate checkpoints. The checkpoints indicate when messages are to be sent from the one instance to another instance or other device. The coordinated message exchange protocol allows the instance to send a message to a receiver, to acknowledge that the message has been received, and to confirm the acknowledgement to the receiver.

Abstract: A hosted resource management system is described herein that provides systems and methods whereby a cloud-based tenant can define a logical model that allows the tenant to work with cloud-based entities in a manner that aligns with the tenant's own purpose and thinking. The system then reflects this model in a set of management tools and access paradigms that are provided to the cloud-based tenant. Each division in the logical model is termed a scope, and can include various types of cloud-based entities. Each of these scopes may contain similar cloud-based entity types, but because of the organization provided by scopes the tenant can manage these cloud-based entities according to the view and model that the tenant defines. Thus, the hosted resource management system provides a way of managing cloud-based entities that is intuitive for cloud-based tenants and facilities easier management of large-scale applications with many cloud-based entities.

Abstract: An episodic execution of program instances and a coordinated message exchange protocol are combined to achieve eventual consistency in the communication between nodes of a distributed system. Program instances run in episodic loops that are triggered by defined input events and that generate checkpoints. The checkpoints indicate when messages are to be sent from the one instance to another instance or other device. The coordinated message exchange protocol allows the instance to send a message to a receiver, to acknowledge that the message has been received, and to confirm the acknowledgement to the receiver.

Abstract: A distributed instance system manages instances and communications between the instances. The distributed instance system provides a restricted set of communication methods to the instances. Based on the type of communication method used, the distributed instance system has knowledge of the messages sent by instances and can make decisions on how to handle the messages. When one of the instances involved in a message exchange ends, the host uses its knowledge of the message exchange type to determine whether to drop the message, drop a reply to the message, and/or send an error message to the surviving instance. An instance may create one or more child instances in a tree-like configuration. Status data is passed up the tree from children instances and aggregated in the parent instances. Monitoring data may be generated from the aggregated status data.

Abstract: A hosted resource management system is described herein that provides systems and methods whereby a cloud-based tenant can define a logical model that allows the tenant to work with cloud-based entities in a manner that aligns with the tenant's own purpose and thinking. The system then reflects this model in a set of management tools and access paradigms that are provided to the cloud-based tenant. Each division in the logical model is termed a scope, and can include various types of cloud-based entities. Each of these scopes may contain similar cloud-based entity types, but because of the organization provided by scopes the tenant can manage these cloud-based entities according to the view and model that the tenant defines. Thus, the hosted resource management system provides a way of managing cloud-based entities that is intuitive for cloud-based tenants and facilities easier management of large-scale applications with many cloud-based entities.

Abstract: An episodic execution of program instances and a coordinated message exchange protocol are combined to achieve eventual consistency in the communication between nodes of a distributed system. Program instances run in episodic loops that are triggered by defined input events and that generate checkpoints. The checkpoints indicate when messages are to be sent from the one instance to another instance or other device. The coordinated message exchange protocol allows the instance to send a message to a receiver, to acknowledge that the message has been received, and to confirm the acknowledgement to the receiver.

Abstract: A distributed instance system manages instances and communications between the instances. The distributed instance system provides a restricted set of communication methods to the instances. Based on the type of communication method used, the distributed instance system has knowledge of the messages sent by instances and can make decisions on how to handle the messages. When one of the instances involved in a message exchange ends, the host uses its knowledge of the message exchange type to determine whether to drop the message, drop a reply to the message, and/or send an error message to the surviving instance. An instance may create one or more child instances in a tree-like configuration. Status data is passed up the tree from children instances and aggregated in the parent instances. Monitoring data may be generated from the aggregated status data.

Abstract: Enabling creation of control flow patterns in a workflow via continuations. Each continuation represents an activity execution context for an activity executing in the workflow by a workflow engine virtualizing a managed execution environment. Responsive to a request, the activity execution context is recreated via the continuation and the activity is executed within the recreated context.

Abstract: Asynchronous fault handling for a workflow. A state automaton for an activity in the workflow is defined. The state automaton includes at least an executing state, a faulting state, and a closed state and classifies an execution lifetime of the activity. The activity is defined to include work items and includes an execution hierarchy for the work items. Each work item includes an operation for executing a portion of the activity. Each work item is transitioned to the executing state. The included operation of transitioned work items is executed in the executing state. One or more of the transitioned work items are identified in response to the faulting event as a function of the execution hierarchy and the included operation. The faulting event is asynchronously handled by transitioning the one or more identified work items to the faulting state while executing the included operation of the remaining transitioned work items.

Abstract: Enabling creation of control flow patterns in a workflow via continuations. Each continuation represents an activity execution context for an activity executing in the workflow by a workflow engine virtualizing a managed execution environment. Responsive to a request, the activity execution context is recreated via the continuation and the activity is executed within the recreated context.

Abstract: Declaratively canceling execution of an activity. A state automaton for an activity is defined, and the state automaton includes an executing state, a canceling state, and a closed state and classifies an execution lifetime of the activity. The activity includes work items and organizes the work items in an execution hierarchical structure. The work items are transitioned from the executing state to the closed state indicating a completion of executing the each work item of the activity. Upon having one of the work items being transitioned to the closed state, a cancellation request is transmitted to the work items currently in the executing state. The executing work items are identified as a function of the transmitted cancellation request and the execution hierarchical structure of the defined activity. The execution lifetime of the activity is canceled by transitioning the identified work items from the executing state to the canceling state.

Abstract: Asynchronous fault handling for a workflow. A state automaton for an activity in the workflow is defined. The state automaton includes at least an executing state, a faulting state, and a closed state and classifies an execution lifetime of the activity. The activity is defined to include work items and includes an execution hierarchy for the work items. Each work item includes an operation for executing a portion of the activity. Each work item is transitioned to the executing state. The included operation of transitioned work items is executed in the executing state. One or more of the transitioned work items are identified in response to the faulting event as a function of the execution hierarchy and the included operation. The faulting event is asynchronously handled by transitioning the one or more identified work items to the faulting state while executing the included operation of the remaining transitioned work items.