从上图中你可以发现，Sync Framework并没有在云端执行起来，实际上，两对翅膀(我喜欢如此称呼对称的两个目标)都在本地端，而通讯协议则是依靠原有传统的TDS(Tabular Data Stream)负责数据的读写。这个架构是最典型得脱机执行模式的架构。当然我们可以改用其他的方式作架构，也能做到此效果，但基于效率的考虑，这是一个很有效率的方式了。
展示SQL与SQL Azure。在这里的目的是运用程序来展示读取本地端的SQL服务器跟云端的SQL Azure的写法上有何不同。而作法如下：
(1)第一阶段是采用ASP.NET 撰写一简单读取本地端的SQL服务器的Web应用程序。
(2)第二阶段是将程序修改成读取云端的SQL Azure的程序。
结语：
SQL Azure与SQL服务器之间的差异：SQL Azure是将SQL服务器放置在云端，然后再在它的前面加上通讯上必要的LB(Load Balance)以及安全性的机制Gateway层，并在底层提供足以大量复制及多重多写的基础结构(这里并未采用Windows Azure的VM机制)。如果以因特网的观点来看，就是在SQL服务器上直接加入因特网的Web应用接口，供外部程序作呼叫而已。但基本上，SQL Azure提供了所有的维护作业，这是一般运用SQL服务器的信息部门的一大福音。当然这也是云端产品的最基本的功能，另外除了自动的维护作业，还有无时无地都可以读取的高度适用性以及横向放大的能力。
同步目的是让Rich Client分担一些工作，而不是把所有的工作都丢给服务(service)去做。同步架构(Sync Framework)的目的是提供一个稳固简洁的同步环境，减少一般程序人员在设计上的复杂度。在这里唯一的遗憾是没有标准，高效能的同步机制处处可见，但却一直没有标准诞生，这造成即使是号称能够跨平台的工具，也无法相呼沟通很是可惜。云端同步作业的重要性，是在可以实时提供多组不同地点的使用者共享相同的资料来源，一起作协同的作业。对于Windows Azure Platform而言，它可以协助架构设计设发挥多样化的拓扑来架构更有效率的解决方案，也能帮助程序设计人员做好协同作业或脱机的高效能工作模式(例如：非常适合像Silverlight 这种智慧型的应用程序)。对一般的使用者而言，它属于SaaS(Software as a Service)的优良解决方案，可以让多组设备读取一组位于云端的正确数据。
