Microsoft Technology Licensing, LLC

Kenneth M Hansen

Jeffrey P Snover

Bruce Gordon Payette

Narayanan Lakshmanan

Hemant Mahawar

Jeffrey Dick Jones

Marco Chierotti

Mark Gray

Rahim Maknojia

Lee Holmes

Xiaoyong Zhou

Christine Moeller

Miriam Rosenberg

Constantin Sorin Oprea

Technologies are provided for non-monotonic eventual convergence for desired state configuration ('DSC'). In some situations DSC cannot move toward a desired state without first moving further from that state. For example, a file that needs to be replaced with a newer version but that is currently executing (desired state of 'operating') cannot be replaced without first being stopped. But stopping moves in the wrong direction relative to the desired state, which is to have the service operating. This moving away so as to be able to move forward is a problem for conventional DSC systems that results in failures. The solution to this problem is non-monotonic eventual convergence (&#x201c;NMEC&#x201d;) which enables a DSC system to configure a target system for a desired state by moving further away from a desired state if that is needed to eventually reach the desired state.

Non-monotonic eventual convergence for desired state configuration

Systems and methods for desired state configuration (DSC) are disclosed. DSC provides the ability to perform declarative configuration natively within a shell language and to use early-bound schematized data constructs embedded in a late-bound shell language. This allows declarative programming elements to be incorporated into imperative languages, such as scripts for configuration management. Script may combine the power of an imperative shell language with the ease of use of a declarative language and may use both imperative and declarative syntax in the same language.

Declarative configuration elements

Technologies are provided for non-monotonic eventual convergence for desired state configuration. One class of problem in DSC is that, in some situations, DSC cannot move forward toward a desired state without first moving further from the desired state. For example, an executable file providing a service that needs to be replaced with a newer version, but that is currently executing (i.e., in the desired state of 'operating'), cannot be replaced with the newer version without first being stopped. But stopping the service moves in the wrong direction relative to the desired state, which is to have the service operating. This moving away from the desired state so as to be able to move closer to the desired state is a problem for conventional DSC systems that results in failures. The solution to this problem is herein referred to as 'non-monotonic eventual convergence' or &#x201c;NMEC&#x201d;. Such NMEC enables a DSC system to configure a target system for a desired state by moving further away from that state if such is needed to eventually reach the desired state.

A workflow scripting system is described herein that combines the features of workflows and scripts by automatically translating between the two models. Using the system, a script author can create workflows on the fly using familiar scripting language, and a workflow author can use scripting steps to perform actions. Workflows run in this manner can be setup to execute in their own process to improve robustness or efficiency. Operations in an enterprise environment frequently take a long time and are subject to interruptions. By adding reliability concepts of workflows to a shell environment, users of the system can write scripts to address common needs of large-scale computing environments. Thus, the workflow scripting system blends the available resources provided by workflow and scripting environments to provide a host of powerful, advanced capabilities to IT personnel.

Automatic transcoding and semantic adaptation between scripting and workflow systems

The adaptation of at least a portion of an object provided by a previous script component to a subsequent script component, despite the subsequent component being incapable of recognizing a format of the at least a portion of the object as provided by the previous component. The previous component generates an object having a property. Adaptation script identifies adaptation(s) to perform on the property prior to being used by the subsequent component. The adaptation is performed, and the adapted property is then used by the subsequent component.

Script-based object adaptation

Dynamically exposing relationships among entities contained in data stores. A method disclosed herein can include receiving data related to a given object that is contained in a given data store, and dynamically determining one or more relationships between the given object and one or more further objects. These relationships can include group memberships, management relationships, containment relationships, or the like. As the data related to the stored objects changes, the relationships among the objects can be updated. Once the relationships are defined, representations thereof may be presented to a user via a suitable user interface. The user interface may present these relationships as graphic icons, hypertext, or the like, and may further depict the dynamic relationships distinctly from static directory listings. The user may then navigate these relationships by interacting with these representations.

Dynamically exposing relationships among entities contained in data stores

The present mechanism provides a data driven command line output within an environment that supports a pipeline of object-based commands. Each object-based command inputs a parseable object for processing and outputs another parseable object for subsequent command processing. The mechanism is operative to direct formatting and subsequent processing of the commands based on a type of the incoming parseable object. Format information is obtained for the type, such as shape, properties to display, and the like. The format information may be specified within an XML-based document. The mechanism utilizes one or more output processing commands, such as format commands, markup commands, convert commands, transform commands, and out commands. These output processing commands may be arranged within the pipeline in various ways to achieve the desired output results.

Mechanism for providing data driven command line output

The present mechanism provides a data driven command line output within an environment that supports a pipeline of object-based commands. Each object-based command inputs a parseable object for processing and outputs another parseable object for subsequent command processing. The parseable objects do not have methods. The mechanism is operative to direct formatting and subsequent processing of the commands based on a type of the incoming parseable object. Format information is obtained for the type, such as shape, properties to display, and the like. The format information may be specified within an XML-based document. The mechanism utilizes one or more output processing it commands, such as format commands, markup commands, convert commands, transform commands, and out commands. These output processing commands may be arranged within the pipeline in various ways to achieve the desired output results.

Growing community of inventors

Woodinville, WA, United States of America

Kenneth M Hansen