Abstract: A computing environment typically comprises a large set of diverse objects, such as files, user profiles, executable binaries, configuration information, and data caches, wherein such objects are typically stored and managed by an aggregation of systems, such as a file system, a system registry, and an assembly cache. An alternative representation of the computer system may comprise an object hierarchy configured to store all of the objects of the computing environment according to a simple organizational grammar. Various services (e.g., a synchronization service, a backup service, and a sharing service) may be provided to manage the diverse objects in a similar manner. The representation may also be provided to a variety of devices, which may render the computing environment in a consistent manner but adjusted to reflect the capabilities of the device and the user. The computing environment is thereby represented in a deployable, consistent, and extensible manner.

Abstract: The diverse objects comprising a computing environment may be represented together as a deployable object hierarchy, which may facilitate the deployment, as well as the consistency, of a computing environment rendered by a plurality of devices. The processes within the computing environment often operate on the objects of the object hierarchy in a variety of ways, including simple operations (creation, reading, updating, and deleting) and more sophisticated operations (synchronizing, paginating, and caching), as well as with the object hierarchy in general. A platform may be devised to facilitate the various operations of the processes on the object hierarchy. The platform may be embodied, such as in an application runtime, and deployed to a variety of platforms to facilitate an equivalent execution of the processes on any type of device and consistent interactions with the object hierarchy.

Abstract: The management of applications in a computing environment often involves a significant number of computing operations, such as acquiring the application, deploying data objects in various locations, and configuring the application with respect to the deployed device. Conventional computing environments may provide inadequate support throughout a typical application life cycle, especially for a computing environment distributed across many devices. Instead, the computing environment may be represented in a deployable object hierarchy that may be distributed to various devices. An application management service may therefore be provided to install representations of the application in the object hierarchy, and to support many other aspects of the application life cycle, such as application discovery, sharing, updating, and removal.

Abstract: Within a computing environment, an application may run in a variety of contexts, e.g., as a natively executable application, as a client-side interpretable application embedded in a web browser, or as a server-side application that communicates with the user through a web interface presented on a device. The application may also access resources of the computing environment stored on multiple devices. The configuration of the application to operate equivalently in these diverse environments may be facilitated by representing the application within an object hierarchy representing the computing environment. The application may be configured to operate on the objects of the object hierarchy regardless of the location of the stored objects, to execute on any device, and to execute upon a standard set of application programming interfaces. The configuration of the application in this manner promotes the versatility of the application in operating equivalently in different programming contexts.

Abstract: A computing environment may be represented as a deployable object hierarchy, which may be organized according to an object hierarchy schema that is commonly shared among the computing environment host and the devices that are configured to render the computing environment. A particular object hierarchy schema is presented in detail for representing a computing environment, wherein many objects of the computing environment are modeled as resources that may be distinctly addressable (e.g., in a RESTful object hierarchy.) Many types of objects and properties thereof are presented in order to elucidate an exemplary object hierarchy schema and to illustrate exemplary objects and object hierarchies organized according thereto. Additional properties of various object hierarchy schemas include extensibility, deployability, and object addressing models with various advantages.

Abstract: A ticketing system adapted for use with a cloud-based services platform is provided by a ticket-based authorization model in which the authorization requirements for traversing one or more meshes of resources associated with a cloud service are annotated in links included in a resource that refer to other resources. The meshes are thus self-describing with respect to the association among the resources (i.e., the links) as well as the authorization required to access resources. Resource access requires a principal ticket which asserts that a caller at a client (e.g., a security principal representing a device or identity associated with a user) is authenticated, plus zero or more claim tickets. The claim tickets make additional assertions about the caller that the cloud service may use to check that the caller is authorized to access the resource.

Abstract: Optimizing workflow execution. A method includes identifying a completion condition. The completion condition is specified as part of the overall workflow. The method further includes identifying a number of activities that could be executed to satisfy the completion condition. One or more activities from the number of activities is ordered into an execution plan and assigned system resources based on an analysis of activities in the number of activities and the completion condition.

Abstract: One or more users can execute tasks in a guided process involving dependent and independent steps modeled with parallel processing techniques. For example, a user can open one or more parent pages in a guided process through a user interface, where each of the one or more parent pages lists several items (e.g., child pages) to be completed. Each listed item (i.e., child page) may or may not depend on processing of another child page, or of another task on the parent page itself. As the user (or multiple users) completes the various items on each given parent page according to page-specific definitions, each parent page is rendered anew to show what has been completed and what remains to be completed. Thus, the parallel execution of tasks can be combined with the sequential execution of other steps to provide an integrated experience to the end user.

Abstract: The present invention supports the design of a process using a drawing surface that specifies the process with underlying programmatic constructs. In response to a user's command, a construct corresponding to a shape is selected from a palette and inserted onto a design region that shows the specified process. The command is verified to be consistent with semantics of an associated process type. If so, a visual image of the specified process is updated. If not, an indicator is generated in a proximity of a relevant portion of the visual image in order to help the user resolve the inconsistency. The user is able to correct errors before generating computer-executable instructions from a high-level code emission. Computer-executable instructions are also generated from high-level code emission. A process engine is cognizant of the associated high-level lines of code and an infrastructure knowledge base while executing the computer-executable instructions.

Abstract: The present invention enables a user to build user-interfaces and applications based on a policy that contains metadata. The user can build an application through the user-interface, in which the user-interface and the generated computer-executable instructions are consistent with the policy. A user-interface has a toolbox that indicates the discovered components and a design surface that displays applicable stages. The policy determines the stages, where each stage provides a grouping of components having related tasks. The user selects components from the toolbox so that the selected components are associated with the selected stages on the design surface. After the user has completed building an application, a representation of the application may be compiled in order to generate a set of computer-executable instructions. Moreover, the compiler is coupled to the policy so that the set of computer-executable instructions is consistent with the policy.

Abstract: A guided process framework includes a process engine, one or more data stores, and one or more user interfaces configured to communicate with the process engine. A user can access a given process instance through any appropriately configured user interface, which contacts the process engine, and which in turn contacts/consults definitions for one or more guided processes at a data store. If the user finishes only part of a given process instance, the process engine can save state corresponding to the progress in the data store. A user can continue work on the process instance through a different user interface (or at a different computer system) by contacting the process engine through the different user interface, and receiving rendering information configured for the different user interface. Thus, the user can stop and start work on a process however desired, and with whatever tools are available at any given time.

Abstract: One or more users can execute tasks in a guided process involving dependent and independent steps modeled with parallel processing techniques. For example, a user can open one or more parent pages in a guided process through a user interface, where each of the one or more parent pages lists several items (e.g., child pages) to be completed. Each listed item (i.e., child page) may or may not depend on processing of another child page, or of another task on the parent page itself. As the user (or multiple users) completes the various items on each given parent page according to page-specific definitions, each parent page is rendered anew to show what has been completed and what remains to be completed. Thus, the parallel execution of tasks can be combined with the sequential execution of other steps to provided an integrated experience to the end user.

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: Providing a workflow engine for virtualizing a managed execution environment. The workflow engine executes a workflow based on an automaton and methods associated therewith. The workflow engine captures continuations associated with the executing workflow to enable modeling of real-world processes.

Abstract: Implementing synchronization among threads in a workflow. A memory area stores a plurality of work items in a scheduler queue. The work items are associated with an activity in the workflow, and each work item is associated with a thread. A processor is configured to assign a synchronization handle to each of the work items. The synchronization handle indicates a particular shared resource to be accessed by the work items. A token value is computed for each work item based on the assigned synchronization handle and the work items in a hierarchy in the activity. The work items are sorted in a synchronization queue based on the token value associated with each work item. The processor sequentially executes each of the sorted work items in the synchronization queue to serialize the access to the particular shared resource and effects a synchronous execution of the threads associated with the work items.

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: Providing data bound workflow activities to model messaging between a workflow instance and a workflow host. The workflow author associates a data source with each data bound activity in a workflow without specifying details of the underlying messaging technology. The data bound activity in the workflow instance communicates with a data source service in the workflow host to exchange data.

Abstract: Workflow debugging. A debug engine integrated with an external development tool debugging framework sets breakpoints directly on workflow activities and stops execution of the workflow at each of the breakpoints. The state of the workflow activity at the breakpoint is displayed. The debug engine extracts source code of the workflow for debugging at the source code level.

Abstract: Selecting and applying a behavioral component to a portion of a componentized workflow. The behavioral component defines error and exception handling, among other concerns, to the portion of the workflow selected by a user. During execution of the workflow, the behavioral components executes responsive to output from the selected portion of the workflow.