예측: 클라우드

  • 아티클

SQL Azure의 분기 노드 동기화, 2 부. 서비스 기반 동기화

Joseph Fultz

This article discusses a prerelease version of the Sync Framework 4.0; all information is subject to change.

image: Joseph Fultz지난 달SQL Azure 및 해당 연결 된 여러 노드 및 회사 데이터베이스를 동기화 하기 위한 일반 아키텍처 및 설계에 대해 설명 했습니다. 필터링 프로세스로 인 한 최적화 및 지리적 분포를 이용한 조각 모음, 또는이 두 가지 방법을 조합 하 여 데이터를 전달 및 수집 등 네트워크 전체를 최적화 하는 방법에 대해 설명 했습니다.

이번 달에는이 서비스를 호스팅하는 Windows Azure 클라우드를 추가 하 고, 서비스 인터페이스를 통해 동기화를 수행 하는 방법에 대해 설명 합니다. 이렇게 하면 동기화 메커니즘을 확장 하 고 데이터베이스와 직접 동기화를 통해 처리 가능한 노드 수보다 훨씬 많고, 각 노드를 처리 하실 수 있습니다. 이번 달 칼럼에서는 2010 년 10 월에 게시 된 Microsoft Sync Framework 4.0 Community Technology Preview (CTP) 릴리스 (bit.ly/dpyMP8, 영문)를 사용 합니다. 이 릴리스 1 월호에 사용 되는 Microsoft Sync Framework 2.1을 기반으로 작성 되었습니다.

동기화 서비스 버전 2.1을 기반으로 만들 수 있습니다. 참고가 되는 샘플 및 연습에 대해는bit.ly/bibIdl (영어) 및 bit.ly/epyImQ (영문)를 참조 하십시오. 그러나 4.0 CTP가 출시 되 고 인터넷 중심의 요소를 사용할 수 있도록이 칼럼의 Windows Azure 동기화 서비스를 이용 하는 CTP 4.0이 더 적절 해 심사 한다. 작용 하는 솔루션을 작성 하려면 여전히 상당한 양의 코드를 작성 해야 하지만, 결국에는 OData를 사용 하는 장치의 모든 장치에서 사용할 수 있는 동기화 서비스가 완성 됩니다.

인터넷 규모의 동기화

지난 달 칼럼에서는 데이터베이스와 직접 동기화를 확장 하는 방법에 대 한 몇 가지 개념을 소개 했습니다. 그러나 그다지 많지 않은 경우 확장 문제를 쉽게 해결할 수 없는 이유가 몇 가지 있습니다. 지난 달에 설명한 방법으로는 처리할 수 없는 상황을 대충 생각 그냥 즉시 일부 떠오를 수 있습니다.

  1. 데이터 간의 관계를 통해 데이터를 쉽게 분리할 수 없다.
  2. 논리적 구분 방법이 없으며 나눌 때 한 재량에 분할 하 여 솔루션의 다양 한 영역에서 예기치 않은 핫스폿이 생길 가능성이 높다.
  3. 복제 해야 할 데이터의 양이 너무 많아서 여러 곳에 데이터를 저장 해야 하는 경우에는 비용이 증가 하 고 수익성이 적합 하지 않다.
  4. 소매점에서 하루를 마감 하면서 수백 또는 수천 개의 프로세스가 발생 하는 등 엄청난 수의 동기화 작업이 수행 될 때 분할 하는 경우에도 충돌을 발생 한다.

위의 SQL Azure와 직접 동기화 이외의 설계 해야 할 이유가 전혀 없다는 것은 분명 하지만 이야기의 촉발을 자르고, 문제의 해결책을 생각 하는 것 이다. 컴퓨터 과학 상도로 서, 여기서도 간접 참조의 계층을 삽입 하 여 위의 문제를 해결 해 줍니다. 이 경우이 계층은 SQL 인스턴스 Azure와 직접 동기화 하는 대신 동기화 지점으로 사용 되는 Windows Azure 웹 역할에 호스팅된 서비스 계층에 있습니다. 지난 달의 최종 아키텍처 다이어그램에 Windows Azure에 호스팅된 서비스에 대 한 동기화 표시자를 추가하 여그림 1 같은 논리 설계에 끝났습니다.

image: Typical Corporate Architecture

그림 1일반적인 엔터프라이즈 아키텍처

회사 소개

Sync Framework 4.0은 이러한 문제를 해결 하는 데 특히 유용 합니다. 그러나 데이터베이스 간의 직접 동기화 하는 간단한 모델에 비하면 많이 걸릴 수 있습니다. 4.0 CTP에는 도움말 파일에 「 Sync Creating a Service in Windows Azure 」 (Windows Azure 동기화 서비스 만들기, 영어) 이라는 제목의 유용한 샘플 및 자습서가 들어 있습니다. 이 문서에서는이를 동기화 서비스의 구현을 설명 하는 기초로 사용 됩니다. OData 용 플랫폼 사이의 동기화를 위해 추상적으로 수행 해야 하는 클라이언트 코드는 다소 번거로울 수 있습니다. 이것은 4.0에서는 사용할 수 있는 클라이언트측 런타임 라이브러리가 없기 때문입니다. 그러나 4.0에서 샘플을 사용 하려면 SQL Server CE를 사용 하는 Windows Mobile 6.5에 대 한 예제입니다. 이 항목에서는이 샘플에서 필요한 코드를 빼내고 표준 SQL Server에서 작동 하도록 수정 되었습니다. 2009 년 10 월 안에 4.0 CTP에서는 개체의 특정 집합을 사용 하 여 동기화 작업이 실행 되지만 먼저 해당 개체를 이해 하는 것이 좋습니다. 클라이언트 응용 프로그램에서는 OData를 사용 하 여 동기화 서비스와의 통신을 처리 하는 CacheController를 사용 합니다. 로컬 CacheController은 응용 프로그램과 데이터 사이의 인터페이스로 OfflineSyncProvider를 사용 합니다 (그림 2 참고). OfflineSyncProvider는 각 데이터 저장소 특정 대상 플랫폼에서 아마도 다른 될 인터페이스입니다. 이 칼럼에서는 샘플을 기반으로 구현에는 로컬 데이터 액세스를 처리 하는 데 사용 되는 StorageHandler 개체입니다. OfflineSyncProvider은 CacheController에서 사용 되는 알려진 형식이 고 StorageHandler 백 엔드 저장소와의 모든 상호 작용을 처리 하기 위해 만든 사용자 지정 코드입니다. OfflineSyncProvider 데이터 액세스 라이브러리에 인텔리전스 및 StorageHandler 데이터 액세스 라이브러리 라고 생각 하시면 됩니다. 주의 해야 할 것은 4.0 CTP에는 격리 된 저장소는 Silverlight 클라이언트에 대 한 기본 CacheController 밖에 제공 하지 않는다는 점입니다. 따라서 표준 SQL Server를 사용 하려면이 작업이 필요 합니다. 개체와 상호 작용의 경계에 대 한 개요를그림 2 입니다.

image: Sync Framework 4.0 Client Synchronization Objects

그림 2Sync Framework 4.0 클라이언트 동기화 개체

클라우드 동기화 서비스 개발

나쁜 소식을 먼저 말하는 좋은 소식은 드디어 이야기를 항상 말해 왔습니다. 이렇게 함으로써, 회화 (과 잘하면 대화 참가자의 느낌)을 밝은 분위기에서 시연 수 있습니다. 그러나이 문서에서는이 순서를 반대로 하 여 먼저 간단한 방법의 장점을 보여이 솔루션을 인정 いただこう 것 이다. 클라이언트 쪽에서는 많은 작업이 필요 하지만 서버 쪽에는 여러 가지 유용한 기능이 Sync Framework에 제공할 수 있습니다. 나가 진행 되는 봉사 인 디자인에 대 한 세션에서 장례 서비스 (장례식 묘지, 관 등)을 판매 하는 분 들에 게 "제품 자체"에 집중 하면 무엇 하나 팔 수 없기 때문에, 제품의 기능 "에 집중할 필요가 있다고 말한 적이 있습니다. 장례 서비스의 경우에도 棺桶 墓穴도 아니고, 마음의 평화 야말로이 요구 되는 진정한 상품 이다. 이러한 경우에는 Sync Framework를 사용 합니다. Sync Framework 2.1은 다양 한 개발자를 대신 하 여 처리 하 고 있 었 습니다만, 서비스 기반 동기화와 역할, 목표에는 지금 단계 도달 하지 못했습니다. 2.1에서는 다양 한 장치와 플랫폼을 통해 인터넷에 연결 되어 동기화 서비스를 통해 제공 되는 데이터와 동기화 해야 하지만, 이러한 장치와 플랫폼에 전혀 인식 하지 못했습니다. With the—now popularly termed—consumerization of IT, my customers find themselves having to deal with many devices in the hands of people at all levels of the enterprise. Sync Framework 2.0 CTP에는 이러한 어려움, 특히 이러한 여러 장치와의 데이터 동기화에 대 한 대응을 지 원하는 것을 목적으로 하 고 있습니다.

이 솔루션의 서버측 구성 요소를 설치 하는 것은 매우 간단 합니다. 기본적으로, 당신은 다음 작업을 수행 합니다.

  1. 데이터베이스 정의
  2. 해당 데이터베이스에 대해 구성 파일을 만듭니다.
  3. SyncServiceUtil를 사용 하 여 구성 파일을 사용 하 여 데이터베이스를 구축 하는
  4. SyncServiceUtil를 사용 하 여 동기화 서비스에 필요한 클래스를 생성 하기
  5. 동기화 서비스를 호스팅하는 Windows Azure 기반 웹 역할 만들기
  6. 배포

나도 같은 방식으로 반응을 하는 경우,이 절차의 개요를 읽어 보 니 「 모든 구성 파일의 지도 」 라고 생각해 보아야 할 것 이다. 이 파일의 스키마는 MSDN 라이브러리 (bit.ly/h2FJod, 영문)에 게시 합니다. 이 스키마를 사용 하 여 ListDB 4.0에 포함 된 데이터베이스 및이 데이터베이스의 연결 된 구성 파일을 참조 하 여 데이터베이스를 나타내는 사용자 지정 구성 파일을 만들 수 있습니다. 이 파일을 사용할 수 있으면 Windows Azure 기반 서비스를 만드는 것은 간단 합니다. 먼저 대상 데이터베이스 (여기서는 ListDB 4.0 SDK의 샘플) Windows Azure를 작성 해야 합니다. 데이터베이스를 만든 후에는 새 SyncServiceUtil를 사용 하 여 다음과 같은 명령을 사용 하면 데이터베이스를 제공 합니다.

SyncSvcUtil /mode:provision 
/scopeconfig:listdbconfig.xml

구성 파일에 설정 해야 하는 정보의 한 SQL Azure 데이터베이스에 연결 합니다. 구성 파일의 마지막 위치로 끌어가기 <, > TargetDatabase/요소가 있습니다. 이 요소를 클라우드로 적절 하 게 구성 해야 합니다.

<Databases>
  <TargetDatabase Name="listdb" DbServer="[URI for the SQL Azure DB 
   Instance]" DbName="listdb" UserName="[username]" Password="[password]" 
   UseIntegratedAuth="false" /> 
</Databases>

Running the utility will generate two files: DefaultScopeEntities.cs and DefaultScopeSyncServices.svc. The “DefaultScope” part of the name comes from the config file and is found in the element <SyncScope />:

<SyncScope Name="DefaultScope" IsTemplateScope="true">

DefaultScopeEntities.cs는 거의 작성 된 대로 이지만, DefaultScopeSyncServices.svc, 서비스 호출을 가로채 사용자 지정 논리를 추가할 수 있도록 하는 부분 클래스를 생성 하는 (4.0의 새로운 기능) 보다 중요 하다. 기본 동기화 논리를 모든 기본 개체의 일부로 포함 되어 있습니다. Figure 3 shows the DefaultScopeSyncService class and the related entities class as the template type for the template class SyncService.

image: Object Browser View of SyncServices Generated Code

그림 3SyncServices에 의해 생성 된 코드의 개체 브라우저 보기

3 그림의 오른쪽에는 동기화를 수행 하는 데 공개 된 서비스 인터페이스 중 일부가 표시 되지 않습니다 (이들은 Sync Framework 2.1을 직접 사용할 때 공개 해야 하는 인터페이스와 같습니다.) 동기화 프로세스는 사용자 지정 논리를 추가 해야 하는 경우에는 DefaultScopeSyncServices.svc 파일을 열어 인터셉터를 선택 하 여 필요한 코드를 작성 합니다. 방금 만든 서비스 인터페이스를 사용 하 여 기본 동기화를 구현 하려면 이러한 파일이 포함 된 서비스나 웹 프로젝트와 모든 웹 역할을 연결 하 고 활성화 컨텍스트를 만드는 코드 줄을 WebRole: OnStart 메서드에 추가 하기만 하면 됩니다.

public override bool OnStart()
{
  DiagnosticMonitor.Start("DiagnosticsConnectionString");

  // For information on handling
  // configuration changes, see the MSDN topic at 
  // go.microsoft.com/fwlink/?LinkId=166357
  RoleEnvironment.Changing += RoleEnvironmentChanging;
  Microsoft.Samples.Synchronization.ActivationContext.
    CreateActivationContext();
  return base.OnStart();
}

그런 다음 구성을 몇 가지 변경 하 고 Sync Framework 이진 파일을 CopyAlways로 설정 합니다. 새 서비스 인터페이스를 활용 하기 위해 4.0 Microsoft.Synchronization.dll을 참조 및 패키지와 함께 실행 되도록 설정 합니다. 그런 다음이를 웹에 게시할 역할 끝났습니다. 「 Jofultz.cloudapp.net/defaultscopeSyncService.svc/$ syncscopes 」와 같은 요청을 브라우저에 입력 하 여 현재 사용 가능한 동기화 범위를 요구 하 여 간단한 테스트를 수행할 수 있습니다. 아래와 유사한 응답이 표시 되 면 서비스가 작동 하 고 있는지 확인할 수 있습니다.

- <service xml:base="http://rd00155d3a1a55:20000/defaultscopesyncservice.svc/" xmlns:atom="http://www.w3.org/2005/Atom" xmlns="http://www.w3.org/2007/app">
- <workspace>
  <atom:title>SyncScopes</atom:title> 
- <collection href="defaultscope">
  <atom:title>defaultscope</atom:title> 
  </collection>
  </workspace>
  </service>

또한 다른 데이터를 요청할 수 있으며, 변경 된 경우에는 기본적으로 OData으로 변경 사항이 반환 됩니다. 이것은 브라우저에서 도구를 사용 하 여 수행할 수 있습니다. Using the OData Viewer Tool on CodePlex (dataservicestool.codeplex.com/releases/view/52805), I issue the request to download changes: jofultz.cloudapp.net/defaultscopeSyncService.svc/DefaultScope/DownloadChanges?userid=BA9152CC-4280-4DAC-B32D-1782E2E8C3D3, which gives me the results as shown in Figure 4.

image: OData Viewer Tool DownloadChanges Result

그림 4OData DownloadChanges Viewer Tool의 결과

다행히, 여기에서는 Sync Framework 4.0 CTP 추가 기능을 통해 간단 하 게 되었다 OData 동기화 인터페이스에서 ATOM 형식을 JSON 형식으로도 OData 결과를 얻을 수 있게 되었습니다. 따라서 클라이언트의 관점에서, 다른 플랫폼과의 동기화가 가능 하 고 전용 데이터 형식은 과거의 일이 되었습니다. 덕분에이 유틸리티를 실행 하 고 프로젝트를 구성 하 여 코드 줄을 추가 하기만 했습니다.

클라이언트가 동기화를 구현 하는

이 구현에서 헤드폰으로 집중 하 고 다양 한 작업에 영향을 미치지 않고는 안 되는 곳으로 이동 하기 전에. 클라우드 서비스를 거의 구성할 수 있지만 클라이언트 구현을 처음부터 새로 만들려면 좀 더 작업을 해야 합니다. Sync Framework 2.0 CTP에는 격리 된 저장소에 대 한 CacheController가 포함 되어 있으므로 Silverlight를 대상 클라이언트 플랫폼, 클라우드 서비스와 같이 편리 하 게 클라이언트를 구현할 수 있습니다. 하지만 여기서의 목표는 SQL Server Standard 또는 Express를 실행 중인 Windows 클라이언트 이므로 어떤 작업을 해야 합니다. 이번에도 SyncServiceUtil 필요한 엔터티를 생성 하는 데 사용할 수 있지만, CacheController 및 OfflineSyncProvider를 직접 작성 해야 합니다. 더 중요 한 것은, 변경 관리를 용이 하 게 하기 때문에 데이터 저장소를 수정 해야 할 것입니다. 그것은, 그리고 버전 2.1에서 구축 된 데이터베이스 변경 관리를 위한 자체 사용자 지정 스키마를 사용 하는 것입니다. 그러나이 구현에서는 데이터베이스 구현이 복잡할 수 있으며 코드 베이스는 복잡 하기 때문에 응용 프로그램 전체에서 상당한 작업이 필요 하 고 복잡해 것일 수 있습니다. 그러나 Synch Framework의 다른 기능을 활용 하기 위해 필요한 작업입니다. 이 사람이 얘기를 하면 「 왜 간단 하 게 직접 주지 않아. 」 라고 합니다. 대답은 간단 합니다. 이 방식으로 작동 하는 것은 전체 작업의 양을 줄이는 것이 구현이 다른 2.1 및 4.0 Synch Framework 동기화 및 동기화 에이전트 (Windows 이외의 플랫폼 포함)에서 사용할 수 있도록 하기 위해서입니다.

현재 제공 하는 클라이언트와 서비스 부분에만 사용 되는 작업 내역을 살펴 봅시다 (그림 5 참고). 대상 클라이언트 플랫폼에 따라 Sync Framework를 사용 하 여 작업 시간을 60% 이상 줄일 수 있다는 것을 알 수 있습니다.

그림 5클라이언트와 서비스 작업 내역

작업 내역 필요한 작업
동기화를 위한 DB 스키마 (서버) 구성
서비스 구현 생성 하 여 한 줄의 코드
동기화에 대 한 유효성 검사 사용자 정의 후크 후크는 생성 됩니다. 값 추가 코드 작성을 합니다.
동기화를 위한 DB 스키마 (클라이언트) 2.1 제공 또는 사용자 지정 가능
Silverlight가 아닌에 대해 동기화 구현 사용자 지정
Silverlight 용 클라이언트 동기화 구성 생성

Mobile 6.5와 SQL CE 샘플 작업에서는 클라이언트가 동기화를 구현 하기 위해 데이터베이스를 사용 하 여 구현 샘플을 만들 수 있습니다. 그림 6의 , IsTombstone 및 IsDirty Metadata 필드를 확인 하십시오.

image: Columns to Support Custom Synchronization Implementation

그림 6사용자 지정 동기화를 구현 하는 열

스키마 준비 했으면 원하는 다른 여러 가지 있습니다.

  1. 앞에서 설명한 대로 CacheController 구현
    1. 로컬 저장소 간의 상호 작용
    2. 서비스 상호 작용
    3. 동기화 충돌 처리기
    4. 동기화 오류 처리기
  2. OData를 생성 하 고 사용 하는 코드
  3. 동기화 되는 엔터티의 코드 정의
  4. 로컬 SQL Server 데이터베이스의 OfflineSyncProvider

1.-2 단계에 대 한 자세한 내용은 Windows Mobile 6.5 샘플에 제공 된 코드 (그림 7 참조)를 사용 하 여 사용자 지정 CacheController 프로젝트에 추가 합니다. 이 사용자 지정 프로젝트의 모든 코드 샘플에서 우회 했다.

image: Files Used from the 6.5 Sample

그림 7Windows Mobile 6.5 샘플 파일에서 우회 했다

동일한 구성 파일을 사용 하 여 SyncServiceUtil에 "/mode: codegen"및 '/target: client "플래그를 지정 하 여 엔터티를 생성 합니다. 이렇게 하면 클라이언트 쪽 개체를 포함 하는 DefaultScopeEntities.cs 파일이 생성 됩니다. Mobile 6.5 샘플을 기반으로 하기 때문에, utility.cs, SqlCeOfflineSyncProvider.cs settings.cs, DataStoreHelper.cs, SqlCeStorageHandler.cs을 Windows 폼을 프로젝트에 복사 합니다. 가능한 한 코딩 작업 시간을 줄일위해그림 8 과 같은 변경 작업을 수행 했습니다.

그림 8코딩 작업 시간을 최소화 하기 위한 샘플 코드의 변경 내용

파일 또는 프로젝트 변경
DefaultScopeEntities.cs 우회 했다 파일의 필수 형식 이름과 일치 하도록 클래스의 이름을 SqlCeOfflineEntity로 변경 합니다.
 

CacheController 구현에서 사용 하기 위해,

[Microsoft.Samples.Synchronization.ClientServices.KeyAttribute]

을

[System.ComponentModel.DataAnnotations.KeyAttribute()]

위치에 추가 합니다.
사용자 지정 새 CacheController 프로젝트

모든 네임 스페이스를 대체 하는

namespace Microsoft.Samples.Synchronization.ClientServices.Custom
SqlCeOfflineSyncProvider.cs

사용자 지정 CacheController 구현를 참조 하려면

using Microsoft.Samples.Synchronization.ClientServices;

을

using Microsoft.Samples.Synchronization.ClientServices.Custom;

대체
SqlCeStorageHandler.cs 파일의 [connection]. [Transaction commands]을 모두 주석으로 처리 합니다. SQL Server를 사용 하려면 SQL CE와는 약간 다른 구현이 필요 합니다. 이 코드는 실제 구현에서 제대로 다시 추가 해야 합니다.
DataStoreHelper.cs 로컬 SQL Server 인스턴스를 가리키도록 연결 문자열을 변경 하려면
Settings.cs SyncServiceUrl Windows Azure Sync Service URI (여기서는 http://jofultz.cloudapp.net/DefaultScopeSyncService.svc/) 할당
Utility.cs

사용자 지정 CacheController 구현를 참조 하려면

using Microsoft.Samples.Synchronization.ClientServices;

을

using Microsoft.Samples.Synchronization.ClientServices.Custom;

대체

샘플 코드를 통해 이러한 변경을 수행 하면 Utility.Sync 함수를 호출 하는 작은 콘솔 응용 프로그램을 만들 수 있습니다. Utility.Sync 함수가 호출 되 면 OfflineSyncProvider과 CacheController의 인스턴스를 만들 때 동기화가 수행 됩니다.

var localProvider = new   
  SqlCeOfflineSyncProvider();
var controller = new CacheController(new 
  Uri(Settings.SyncServiceUrl), Settings.  
  SyncScope, localProvider);

변경 된 레코드를 로컬 저장소에서 인출 하는 등의 작업을 수행 하는 코드는 어디에 있는가 하면 궁금해 하 고 있을 겁니다. 이러한 코드는 모두 StorageHandler 구현에 포함 됩니다. Take a look at Figure 9 to see a piece of it.

그림 9로컬 저장소에 대 한 데이터 명령

internal class SqlCeStorageHandler : IDisposable
  {
    #region SQL CE Commands

    private const string GET_ALL_PRIORITY = "SELECT [ID], [Name], [_
      MetadataID] FROM [Priority] WHERE [IsTombstone] = 0";

    private const string GET_ALL_STATUS = "SELECT [ID], [Name], [_
      MetadataID] FROM [Status] WHERE [IsTombstone] = 0";

    private const string GET_ALL_TAGS = "SELECT [ID], [Name], [_
      MetadataID] FROM [Tag] WHERE [IsTombstone] = 0";

    private const string GET_ALL_LISTS =
      "SELECT [ID], [Name], [Description], [UserID], [CreatedDate], 
      [IsTombstone], [_MetadataID] FROM [List] WHERE [IsTombstone] = 0";

    private const string GET_ALL_ITEMS =
      "SELECT ID, ListID, UserID, Name, Description, Priority, Status, 
      StartDate, EndDate, IsTombstone, [_MetadataID] FROM [Item] WHERE 
      [IsTombstone]=0 AND [ListID]=@ListID";

    private const string SELECT_ITEM_CHANGES =
      "SELECT ID, ListID, UserID, Name, Description, Priority, Status, 
      StartDate, EndDate, IsTombstone, [_MetadataID] FROM [Item] WHERE 
      IsDirty = 1";

    private const string SELECT_LIST_CHANGES =
      "SELECT ID, Name, Description, UserID, CreatedDate, IsTombstone, 
      [_MetadataID] FROM [List] WHERE IsDirty = 1";

    private const string SELECT_TAGITEMMAPPING_CHANGES =
      "SELECT TagID, ItemID, UserID, IsTombstone, [_MetadataID] FROM 
      [TagItemMapping] WHERE IsDirty = 1";

따라서이 작업은 다음 순서로 처리 됩니다.

  1. 클라이언트 응용 프로그램에서 모든 동기화 함수를 호출
  2. 다음 함수는 동기 처리
    1. OfflineSyncProvider의 인스턴스를 만듭니다.
    2. CacheController (사용자 지정)의 인스턴스를 만들고 서비스 URI와 OfflineSyncProvider를 전달
    3. 마지막으로, CacheController.Refresh ()를 호출
  3. CacheController Windows Azure의 동기화 서비스와의 통신을 처리 하는 CacheRequestHandler를 만드는
  4. CachController를 OfflineSyncProvider에 로컬 변경 집합을 요청 하
  5. OfflineSyncProvider가 StorageHandler를 사용 하 여 로컬 SQL Server에서 변경 내용을 검색 하는
  6. CacheController이 변경 집합을 사용 하 여 요청을 생성 하 고이를 CacheRequestHandler에 전달
  7. CacheRequestHandler가 해당 포맷터 (여기서는 OData ATOM)를 사용 하 여 적절 한 요청을 만들고이 요청을 보낼 URI Sync Service

당연히, 패키지를 확장 하 고 클라이언트에 데이터를 복원 하려면 기본적으로 동일한 프로세스를 역순으로 수행 합니다. Figure 4 shows the OData package as it flows back from the service.

마지막으로

말할 필요도 없이, 트랜잭션 지원을 제거 하 고 개체의 SqlCe [suffix] 등의 잘못 된 정보를 유지 하는 것은 실제 구현에서 해야 할 일은 아니지만, 여기서는 완전히 새로운 코드를 작성 하지 않고 운용 가능한 클라이언트를 만드는 작업을 담당 합니다. SQL Server CacheController을 만드는 경우 먼저 Windows Mobile 6.5 샘플 기반 리팩터링 및 이름 바꾸기 작업을 수행한 다음 데이터 저장소에 대 한 특정 정보가 필요 StorageHandler에서 설정 하는 명령을 쉽게 만들 수 있습니다.

이 칼럼에서는 가장 큰 목표는 동기화 서비스 기반 아키텍처의 구체적인 예를 보여주는 것 이었다. 배율 조정에 필요한 현금 및 기타 최적화에 대해서는 여기에 감히 언급 하지 않지만 이러한 최적화에 대해 대개 잘 이해 되 고 있습니다. 또한 Sync Framework 4.0 CTP의 기능을 설명 하면서이 CTP는 어떤 기능을가지고, 어떤 기능이 없고 무엇을 얘기 하 고 싶다고 생각 하 고 있었습니다. 이러한 목표를 달성할 수 있었다면 다행입니다.

SQL Data Sync Azure CTP 2은 개발에 있지만이 CTP 2에서는 구성 및 클라이언트 에이전트를 다운로드 하는 동안 클라이언트 구성 요소를 포함 하 여 전체 구현을 설치 하도록 해 주는 것이 보장 됩니다. 물론, 그것은 Windows 기반 컴퓨터의 경우, 모든 플랫폼에서의 사용을 목적으로 하는 경우에는 Sync Framework 4.0을 직접 사용 하는 것이 좋습니다 수 없습니다.

최근 Sync Framework SDK를 다운로드 하 고 Azure 적어도 SQL 데이터베이스를 사용 하 여 Windows Azure에이 서비스를 설치 하는 자습서를 실행 하 여 Silverlight 클라이언트에 대 한 예제를 검토 하 고 Sync Framework 느낌을 파악할 것을 권장 합니다. 조금 의지가 있는 분은이 섹션에서 설명 했 듯이 4.0 CTP에 포함 된 샘플, 윈도우 모바일 6.5 (두 개의 프로젝트가 포함 되어 있습니다.) 파일을 사용 하 여 고유한 동기화 Windows 기반 클라이언트를 만들어 봅니다.

Joseph Fultz is an architect at the Microsoft Technology Center in Dallas, where he works with both enterprise customers and ISVs designing and prototyping software solutions to meet business and market demands. He’s spoken at events such as Tech·Ed and similar internal training events.

Thanks to the following technical expert for reviewing this article: Ganeshan Iyer