Transcript TL30: Microsoft Sync Framework: Advances in v2

TL30
 Lev Novik
Architect
Microsoft Corporation
overview



Live Mesh!, SQL Data Services, more
Provider Framework


Filtering


Constraint Conflict


Service
Sync!
Thin Client
Rich
Client
Service
Sync!
Client App
Sync!
Sync!
Client App
Sync is hard
different


Server
Files
detect

Settings
Files

Settings
Home PC

Misidentification
data loss

SmartPhone
too expensive

loops

end up


80%

100%
Solving hard problems exactly once
power


Powerful: solve hard sync problems





Flexible




Arbitrary stores
Arbitrary protocols
Arbitrary data types
Arbitrary topologies
flexibility
Microsoft Sync Framework

Live
Mesh

Sync
SmugMug
Makes it easy for your endpoint to participate
Syncable
Store

Comes with built-in endpoints:



V1: File System, Relational Databases
V2: SQL Data Services, Live Mesh, ADO.NET Data Services and more
Provides integrated tools and user experiences


Sync Services for ADO.NET
SyncToy  Project Codename “Anchorage”
Anchorage


Ecosystem




Customizable











content types
How synchronization happens
Sync Application
Sync Orchestrator
changes
changes
Sync
Provider
Sync
Provider
changes
Data
Store
changes
Data
Store
What do I do?
Sync Applications


Providers




SyncOrchestrator orch = new SyncOrchestrator();
orch.LocalProvider =

new FileSyncProvider(guid1, “c:\\temp\\myfolder”);
orch.RemoteProvider =
new LiveMeshProvider(guid2,
new NetworkCreditial(username, password),
“MyMeshFolder”);
orch.Synchronize();
Not too hard!
Live Services
Synchronizing Life
Partnership
App
Store
Sync
Runtime
?
Live
Framework
Provider
Sync Framework
App
Sync
Provider
Cloud
LOE
Client
LOE
App
Client
LOE
App
Live Services
Synchronizing Life
Partnership
App
Store
?
Cloud
LOE
Sync
Runtime
Live
Framework
Provider
Sync
Provider
Browser
Sync Framework
Web
App
Client
LOE
App
Client
LOE
App
Writing Providers
Responsibilties



expose








Introducing Provider Framework
The easiest way to write simple providers
full-enumeration

anchor-based


Enumerate

tell objects apart

tell if the object changed

Create Delete
Update



since some point in the past
How Provider Framework works
Under the covers: Enumeration
GetChangeBatch
Sync Orchestrator
Bring
metadata
up-is
Metadata
to-date
up-to-date!
Enumerate all objects
Simple Sync
Provider
Provider
Framework
with Runtime
Here’s one:
Id=‘foo’, LMT=5pm
…
All done!
What was it last time?
Enumerate
What’s missing?
changes
Data
Store
Same
Updated
New
Update metadata
Record deletes
Meta-data
Store
How Provider Framework works
Under the covers: Applying changes
Sync Orchestrator
ProcessChangeBatch
Bring
metadata upto-date
Metadata is
up-to-date!
Update
id=‘foo’
Enumerate
all item
objects
LMT was 1pm
Provider
Framework
with Runtime
Here’s
one:
New
data is ‘bar’
Id=‘foo’, LMT=5pm
New
… LMT=8pm
All done!
Get versions
What was it last time?
What’s missing? Update
metadata
Record deletes
Meta-data
Store
Same
Updated
New
Update metadata
Simple Sync
Provider
Check LMT
and write
Data
Store
 Presenter Name
Title
Group
Provider Framework: Summary
Easy!
very little work


sophisticated capabilities
not enough data



peer-to-peer





conflict
granular
CTP1
Writing better providers
cookies


Anchor-based enumeration  efficiency

When tombstones cannot be maintained

Keeping item counts helps detect if there are any deletes
New capabilities in
Sync Framework v2

Filtering





Support for column filtering
Filter negotiation
“Forgetting” and “remembering” items
Performance improvements
Conflicts


Constraint conflict resolution
Improved conflict logging support
Why Filter Objects
Or "I don't want all of these!"
all the objects






But how do providers know what filter to use?

In V2 (CTP1), we add interfaces for this negotiation



Source: ISupportFilteredSync to indicate willingness to filter
Destination: IRequestFilteredSync to indicate desire to filter
Supported by Provider Framework
Coming in CTP2
“forget”


anymore

future

own

CTP1 Provider
Framework

Highly
Why Filter Columns?
Or "my device cannot store this property!"




lossy (e.g. some properties are lost)
How can we maintain correctness?
PC #1
PC #2
First: John
Last: Doe
Phone: 555-1212
Spouse: Jane
First: John
Last: Doe
Phone: 555-1212
Spouse: ???
Sync?
Sync
Sync
Phone
First: John
Last: Doe
Phone: 555-1212
Review: Change Units
Granularity at minimal cost

Contact




First Name
Last Name
Street Address
City
Phone Number
Area code


item.Add(new ItemField(1, typeof(UInt32), name.Hash);

item.Add(new ItemField(2, typeof(UInt32), address.Hash);

item.Add(new ItemField(3, typeof(UInt32), phone.Hash);

items.Add(item);
Using Column Filtering


Provider responsibilities

Implement ISupportFilteredSync to indicate ability to project

Implement IRequestFilteredSync to indicate desire to project

Enumerate according to the filter
Sync Framework takes care of



Recording correct knowledge
Not re-sending the same changes, but yes getting the remaining ones!
A glimpse into some of the tricky bits

Deleting a partial object: is it a conflict?
Or “that just won’t do”



the same name





easier
Most common constraint conflicts






keep both
merge
Most common constraint conflicts
None
Conflict
Resolution
Keep Both
Merge
Machine A
Machine B
ProcessChangeBatch
Contact
Contact
ID ID
Guid1
Guid1
Contact
Contact
IDID
Guid2
Guid2
Creation
CreationA15A15
Creation
Creation B10
B10
Update
Update A15A15
Update
Update B25
B10
B25
Name
Name John
John
DoeDoe
Name
Name
John
John
AA
Doe
Doe
Phone
Phone 5555556789
6789
Phone
Phone
5555551234
1234
Most common constraint conflicts
None
Conflict
Resolution
Keep Both
Merge
Machine A
Machine B
ProcessChangeBatch
Contact
Tombstone
Contact
Contact
ID
Guid1
ID
Guid1
ID
Guid2
Creation
A15
Creation
A15
Creation
B10
Update
A15
Update
Deletion
A15
B27
Update
B10
B25
Name
John
Doe
Name
John
Doe
Name
John
Doe
Phone
5556789
Phone
5556789
Phone
5551234
Most common constraint conflicts
Machine A
Machine B
ProcessChangeBatch
Contact
Tombstone
Contact
ID
Guid1
ID
Guid2
ID
Guid1
Creation
A15
Creation
B10
Creation
A15
Update
A15
Update
B10
B25
Deletion
B27
Name
John
Doe
Name
John
Doe
Phone
5556789
Phone
5556789
 Presenter Name
Title
Group
Or “I’ll deal with that later”
v1 supports




simplify

IConflictLogAccess





over
Sending
Cleaning up

Summary
easiest



Live Mesh
SQL Data Services
most efficient
ADO.NET Data
Provider Framework
advanced





Sync Developer Center
http://msdn.microsoft.com/sync




Sync Blog
http://blogs.msdn.com/sync



SQL Labs
www.sqlserviceslabs.com


Cutting edge prototypes and pre-release functionality
Come visit us


www.microsoftpdc.com
© 2008 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.
The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market
conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation.
MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.