Microsoft Technology Licensing, LLC

Ashish B Shah

Lev Novik

Irena Hudis

Darshatkumar A Shah

Yunxin Wu

Vivek Jawahir Jhaveri

Neil Leonard Padgett

Douglas Brian Terry

Pavel Anatolievich Dournov

Michael Ray Clark

Todd F Pfleiger

Sanjay Anand

Luis Irun-Briz

Lukasz Gwozdz

Alan Geoffrey Boshier

Siva Muhunthan

Akram Hassan

Edward Eric Thomas

Gaurav Gupta

Saad Syed

Ajay Mani

Sushant Pramod Rewaskar

Shaoyu Zhou

Haizhi Xu

Corey M Sanders

Muhunthan Sivapragasam

Pavithra Tyamagondlu Nagesharao

Ivan Santa Maria Filho

Kevin R Hughes

Okechukwu C Echeruo

Salome Jacob

Andrei Makismenka

Jeremie Emilio Marcel Marie Sartor

Maxim Khutomenko

Umer Azad

Lei Tang

Systems and methods that enable removal of data from an endpoint, while not propagating such removal to other endpoints when synchronizing data sources associated therewith. A designation component can indicate items as forgotten items, wherein such items are being known to an endpoint and deleted therefrom&#x2014;yet, reintroduced therein and reappearing (e.g., as a create) upon re-synchronizing with the replica over again. Moreover, the forgotten items can employ additional metadata such as in from of an additional bit that indicates whether an item is a forgotten item.

Forgetting items with knowledge based synchronization

A distributed application may be updated by using information provided by the application to determine grouping, sequencing, and whether or not to advance an update sequence. The application may provide input to an update sequence, and may cause the update sequence to repair one or more replicas prior to updating. The update mechanism may be used to change the distributed application topology as well as make changes to the application executable code, application configuration, quest operating system, virtual machine, and host systems, among others. In some cases, the distributed application may use a quorum to determine which version is current, and the quorum may change during the update process.

Coordinated upgrades in distributed systems

Methods, systems, and computer-readable media for facilitating coordination between a fabric controller of a cloud-computing network and a service application running in the cloud-computing network are provided. Initially, an update domain (UD) that includes role instance(s) of the service application is selected, where the service application represents a stateful application is targeted for receiving a tenant job executed thereon. The process of coordination involves preparing the UD for execution of the tenant job, disabling the role instance(s) of the UD to an offline condition, allowing the tenant job to execute, and restoring the role instance(s) to an online condition upon completing execution of the tenant job. Preparing the UD includes notifying a management role established within the service application of the fabric controller's intent to execute the tenant job and receiving a management-role response communicating a presence of replications of internal state(s) of the role instance(s) affected by the tenant job.

Increasing availability of stateful applications

Several embodiments of the present invention comprise a storage platform that provides a synchronization service that (i) allows multiple instances of the storage platform (each with its own data store) to synchronize parts of their content according to a flexible set of rules, and (ii) provides an infrastructure for third parties to synchronize the data store of the storage platform of the present invention with with other data sources that implement proprietary protocols. In various embodiments, storage-platform-to-storage-platform synchronization occurs among a group of participating 'replicas.' For example, it may be desirable to provide synchronization between the data store of the storage platform with another remote data store under the control of another instance of the storage platform, perhaps running on a different computer system.

Systems and methods for the implementation of a synchronization schemas for units of information manageable by a hardware/software interface system

Conflicts detected during synchronization of replicas are enumerated and resolved according to a specified policy, comprising conditions and actions or simply a specified action. Specified actions may be drawn from a set of standard actions and custom actions may also be composed. The conflicts are enumerated and resolved in logical groups. A logical group is a collection of one or more item envelopes, each comprising entities, such as items, links, and/or extensions. In an example configuration, both constraint-based conflicts, such as a name collision, and non-constraint-based conflicts are handled via the same application programming interface.

Unified mechanism for presenting and resolving grouped synchronization conflicts

Several embodiments of the present invention employ synchronization adapters for synchronizing information between 'WinFS' and non-'WinFS' data sources. Examples of adapters include an adapter that synchronizes address book information between a &#x201c;WinFS&#x201d; contacts folder and a non-WinFS mailbox. In these instances, adapter developers might use the &#x201c;WinFS&#x201d; synchronization core services API described herein for accessing services provided by the &#x201c;WinFS&#x201d; synchronization platform in order to develop schema transformation code between the &#x201c;WinFS&#x201d; schema and the non-&#x201c;WinFS&#x201d; data source schema. Additionally, the adapter developer provides protocol support for communicating changes with the non-&#x201c;WinFS&#x201d; data source. A synchronization adapter is invoked and controlled by using the synchronization controller API and reports progress and errors using this API.

Systems and methods for providing synchronization services for units of information manageable by a hardware/software interface system

A description of the hierarchically-structured document is accessed and converted into an early-bound object having at least some of the same properties as the hierarchically-structured document, and having at least some of the methods that may be performed on the hierarchically-structured document. When a function call is placed to the early-bound object, the early-bound object causes the appropriate corresponding changes to be affected on the hierarchically-structured document while maintaining change tracking information for the document. This reduces the difficulty when drafting source code for a program that interfaces with hierarchically-structured documents that can have varying structures and may be governed by complex change tracking rules.

Managing code when communicating using heirarchically-structured data

Systems and methods for synchronizing data stores. A framework including a sync runtime enables consistent and manageable synchronization between a data store and multiple, diverse back end data stores. The sync runtime provides services such as change enumeration, conflict detection, metadata management, item ID matching, sync interruptability, and the like that are accessible to configurable adapters over an application programming interface. Each synchronizing data store can uses a sync controller to initialize an adapter that can access the services provided by the sync runtime. The sync controller can use a profile to configure each adapter. The profile can identify conflict resolution policies, synchronization filters, source and destination folders, sync direction, and the like.

Systems and methods for synchronizing with multiple data stores

A data store in which changes are not tracked is synchronized with a data store in which changes are tracked utilizing a shadow store. The shadow store contains shadow data indicative of the most recent synchronization operation between the data stores. The shadow data comprises hash values of the data items in the limited or non-change-tracked data store. Changes to data items in the limited or non-change-tracked data store are operated on to provide respective hash values. The hash values are compared with the hash values in the shadow data. If the hash values differ, changes are appropriately applied to the data store, and the shadow data is appropriately updated. In an example embodiment, hash values are obtained from one-way hash functions, such MD5, SHA-1, SHA-256, or the like.

Synchronization of change-tracked data store with data store having limited or no change tracking

Mechanisms are provided for identity mapping in synchronization systems. For example, entities can be mapped across various entity stores, such that an entity in one store can be identified with an entity in another store even if such entities are of different types. When entities are being synchronized across various entity stores, new or updated entity identities (and associated metadata) can be supplied to these stores as part of the same operation as that used for supplying changes during synchronization: entities can be merged and associated identity information and metadata can be changed accordingly; entities can be resurrected and new identity information can be created; metadata can be utilized even though entities are deleted, and so on.

Synchronization operations involving entity identifiers

Various embodiments of the present invention are directed to conflict handling for conflicts that occur in a peer-to-peer synchronization system, where the ability to correctly and efficiently handle conflicts minimizes data loss while retaining good usability and reduces the need for user intervention during synchronization. Conflict handling in the synchronization service is divided into three stages: (1) conflict detection; (2) automatic conflict resolution and logging; and (3) conflict inspection and resolution. Certain embodiments are directed to a conflict handling schema comprising one or more of the follow conflict handling elements: (a) schematized representation of conflicts; (b) detection of conflicts; (c) logging of conflicts into a durable store; (d) automatic resolution of conflicts according to a flexible and configurable azqsxqxwdconflict resolution policy; (e) composable and extensible conflict handlers to filter and resolve conflicts; (f) automatic detection and removal of obsolete conflicts; and (g) programmatic conflict resolutions.

Systems and methods for providing conflict handling for peer-to-peer synchronization of units of information manageable by a hardware/software interface system

Systems and methods for replicating replicas in a sync community. Each replica in the sync community stores knowledge that represents changes the replica is aware of. Because each replica has its own knowledge, each replica does not need to know how many replicas are in the sync community or the topology of the sync community. By sending the knowledge with a request for changes, a replicating replica can enumerate the changes to replicate by comparing its knowledge with the received knowledge. After replication, the knowledge is updated. Knowledge may also include made-with-knowledge change IDs that permit each resolution to identify what a replica was aware of when a particular change was made. The made-with-knowledge values are used to detect conflicts during replication.

Systems and methods for replicating data stores

A protocol for replicating replicas in a sync community. Each replica maintains a knowledge that represents changes that the replica is aware of. Each replica does not typically maintain knowledge about other replicas. The protocol includes messages that include knowledge about changes on the various replicas. Using the knowledge, the replicas can enumerate changes and send the changes using asynchronous messages that do not need to be received in any particular order. The protocol enables filters to ensure that a valid replication is possible using a minimum knowledge argument. The protocol also enables replicas to partially replicate using filtered knowledge.

Replication protocol for data stores

Systems, methods, and computer program products for synchronizing items at replicas within a topology is disclosed. Items are stored in physical tables at the replicas. The physical table layouts at each replica can differ but are mapped to a common logical view. When a replica receives an indication that synchronization should be performed, the replica determines if changes have been made at the replica that should be mapped to the logical views. Replicas can facilitate this by comparing local change enumerations for changes made in physical tables to synchronization local change enumerations for changes in the logical views. Any changes that need to be synchronized are sent through the logical views to other replicas in the topology.

Growing community of inventors

Hyderabad, WA, United States of America

Ashish B Shah