カスタム プロバイダーの基礎

Microsoft Sync Framework には、ファイル同期など、さまざまな同期シナリオに応じたプロバイダーが用意されていますが、場合によっては、カスタム プロバイダーが必要になるケースもあります。カスタム プロバイダーを使用する場合、Sync Framework に付属のプロバイダーを使用した場合よりも多くのコードを開発者が記述しなければなりません。しかし、カスタム プロバイダーは、Sync Framework の柔軟性と拡張性の鍵となるコンポーネントです。このトピックでは、カスタム プロバイダーについての理解と、どのようなカスタム プロバイダーが自分のアプリケーションに適しているかの判断に役立つ情報を提供します。Sync Framework の使用経験がまったくない方は、「適切な Sync Framework コンポーネントの選択」の「Sync Framework のコンポーネント」にも目を通すことをお勧めします。

プロバイダー、アプリケーション、およびメタデータの管理について

Microsoft Sync Framework は、同期ランタイム、同期セッション、および 2 つの同期プロバイダーという、4 つの基本的なコンポーネントを使用してレプリカを同期します。データを同期する際には、アプリケーションから同期セッションを作成し、それを同期元プロバイダーと同期先プロバイダーに渡します。同期セッションでは、同期元のレプリカで発生した新しい変更が、同期元プロバイダーを使用して取得されます。また、取得された変更は、同期先プロバイダーを使用して同期先のレプリカに適用されます。プロバイダーは、同期対象となる各レプリカおよび各項目について、それぞれのメタデータ (ナレッジなど) を管理します。ナレッジは、レプリカに対して直接的に、または同期を通じて間接的に適用されたすべての変更を表すメタデータです。

同期対象のデータ ストア用のプロバイダーが Sync Framework に用意されていなければ、カスタム プロバイダーを作成する必要があります。Sync Framework には、単純なカスタム プロバイダーと標準のカスタム プロバイダーという 2 種類のカスタム プロバイダーに対するマネージ API およびアンマネージ API が付属しています。

• 簡易プロバイダーはインターフェイスの数が比較的少なく、インターフェイスそのものも単純であるため、簡易プロバイダーを使用した場合、開発速度が向上し、複雑な変更追跡メカニズムを持たないデータ ストアをより直感的にサポートできます。

• 標準のプロバイダーを使用した場合、柔軟性が高まり、最高水準のパフォーマンスと堅牢性を実現できます。

どちらのタイプのプロバイダーも、さまざまなデータ ストアの同期に広く対応しており、フィルター選択や競合処理などの重要な機能に関するオプションも備えています。しかし、両者には重大な違いがあります。詳細については、このトピックの「簡易プロバイダーか標準プロバイダーかの選択」を参照してください。

次の図は、同期のシナリオの主要な要素を示しています。「適切な Sync Framework コンポーネントの選択」に掲載されている図と似ていますが、説明文がカスタム プロバイダー用に補足されており、システム全体のデータやメタデータの流れが示されています。

図中の要素は次の 3 種類に分類されます。

• 開発者により作成される要素。

  • アプリケーションでは、アプリケーションの要件に基づいて、同期を開始し、イベントに応答し、その他のタスクを処理します。詳細については、「同期アプリケーションの実装」を参照してください。

  • プロバイダーはレプリカのメタデータを管理する以外に、Sync Framework と連携しながら、変更を列挙したり、競合を検出したりします。また、レプリカのデータ ストアとも連携します。たとえば、同期元プロバイダーは、項目ストアと連携しながら項目データを送信します。一方、同期先プロバイダーは、項目ストアと連携して変更を適用します。使用するプロバイダーは、同期するデータの種類によって異なります。セッション内の 2 つのプロバイダーは同じ種類であることが多いですが、それは要件ではありません。相互運用性の詳細については、「異なるプロバイダーのデータの統合」を参照してください。

    マネージ コードの簡易プロバイダーは、FullEnumerationSimpleSyncProvider または AnchorEnumerationSimpleSyncProvider を実装します。標準プロバイダーは、KnowledgeSyncProvider、IChangeDataRetriever、および INotifyingChangeApplierTarget を実装します。

    アンマネージ コードの簡易プロバイダーは、IFullEnumerationSyncProvider または IAnchorSyncProvider を実装します。標準プロバイダーは、IKnowledgeSyncProvider、ISyncProvider、ISynchronousDataRetriever、および ISynchronousNotifyingChangeApplierTarget (非同期プロバイダーの場合は、それぞれ非同期のバージョン) を実装します。

  • データ ストアは実際のデータが格納される場所であり、開発者はそのデータ ストアに合ったプロバイダーを作成することになります。

  • データ転送プロトコルによって、2 つのプロバイダー間でデータ変更を転送する方法が決定されます。

• Sync Framework に用意されている要素。

  • アプリケーションは、同期オーケストレータ (SyncOrchestrator) または同期セッション (ISyncSession) と通信を行います。そのいずれか (マネージ コードを使用するか、アンマネージ コードを使用するかによって異なる) が、各同期プロバイダーと通信しながら同期プロセスを実行し、ステータス、競合、エラーなどをクライアント アプリケーションに伝達します。

  • 同期ランタイムは、メタデータの管理、競合検出、変更の適用など、プロバイダーの基本的な同期タスクを支援します。

• プロバイダーとアプリケーションの要件に応じて、開発者が作成するか、Sync Framework で用意される要素。

  • メタデータ ストアにはメタデータが格納されます。Sync Framework はメタデータを使用して、各プロバイダーでどの変更を選択し、サービス対象のデータ ストアに適用するかを判断します。メタデータ ストアは、データ ストアと分けることも (別のファイル、別のデータベースなど)、データ ストアに統合することもできます (同じデータベース内の別のテーブルなど)。通常、同期に必要なメタデータは、同期プロバイダーによって管理されます。ただし、レプリカの実装によっては、メタデータの管理を一部、独立したコンポーネントで処理した方がよい場合もあります (古いメタデータを同期中ではなく予定された時刻にクリーンアップするサービスなど)。必要なメタデータとその格納方法、および使用方法は、使用するプロバイダーによって異なります。プロバイダーの種類ごとのメタデータの要件については、「簡易プロバイダーのメタデータの管理」および「標準プロバイダーのメタデータ要件」を参照してください。

    簡易プロバイダーを使用した場合、開発者はメタデータ ストアとの対話処理をまったくといってよいほど意識しなくて済みます。簡易プロバイダーには、Sync Framework に付属の Metadata Storage Service の実装が使用されます。標準のカスタム プロバイダーにも、この実装を使用できますが、標準のカスタム プロバイダーの場合は、それに加えて、Metadata Storage Service API をベースとする別の実装を使用したり、メタデータを専用のストアや同じデータ ストア内に格納する、まったく独自の実装を使用したりすることができます。詳細については、「標準プロバイダーのメタデータの管理」を参照してください。

簡易プロバイダーか標準プロバイダーかの選択

ほとんどの場合、簡易プロバイダーの使用をお勧めします。ただし、簡易プロバイダー API の設計に想定されている、次の前提条件を理解しておく必要があります。

• 同期対象のデータ ストアが、あらゆる種類の変更追跡を一切サポートしていないか、サポートしていたとしてもアンカー ベースの変更追跡のみである。

  アンカーは、データ ストア内の、前回の同期セッション以降に変更された項目を示すオブジェクトです。変更追跡をサポートしないストアや、アンカー ベースの変更追跡しかサポートしないストアでは、同期ナレッジに対する更新が、ストア内で変更が発生したとき (同期的) ではなく、同期セッション中 (非同期的) に実行されます。特定のレプリカに対して多数の同期セッションが発生した場合、このことがパフォーマンスに影響する可能性があります。したがって、アプリケーションに高い同時実行性が要求されている場合で、なおかつ、各データ ストアが同期ナレッジに対する同期更新をサポートしている場合は、標準プロバイダーを使用してください。

• 同期対象となるレプリカの項目が 1 種類だけである。

• データ ストアの制限またはアプリケーションの要件上、メタデータはデータ ストア以外の場所に格納する必要があります。

  簡易プロバイダーは、Sync Framework に付属の Metadata Storage Service の実装を使用してメタデータを保存します。メタデータとそれが表すデータとが別々に保存されることから、可能性として、次の 2 つの問題が考えられます。

  • メタデータをリモートの場所に保存した場合、同期セッション中にまったくアクセスできなくなる可能性がある。たとえば、同期対象の 2 つのレプリカ間のネットワーク接続は利用できるが、メタデータをホストしているサーバーとの接続が利用できない、という状況が考えられます。

  • データとメタデータ間にはトランザクションの一貫性が保証されない。メタデータとデータは同じコンピューターに保存することをお勧めします。ただし、標準プロバイダーを使用したうえで、メタデータをデータ ストアに保存 (または分散トランザクションを使用して両方のストアを更新) しない限り、トランザクションはサポートされません。標準プロバイダーにも Metadata Storage Service を使用することができますが、簡易プロバイダーとは異なり、それは必須ではありません。

以上の前提条件が実際のアプリケーションの要件とうまくマッチする場合は、簡易プロバイダーの使用をお勧めします。簡易プロバイダーの詳細については、「簡易カスタム プロバイダーの実装」を参照してください。標準プロバイダーの詳細については、「標準のカスタム プロバイダーの実装」を参照してください。

Sync Framework の参加者の種類について

Sync Framework を使用すると、さまざまな種類の参加者間でデータを同期できます。Sync Framework を実行している他のシステムとの間で同期させることができるデバイスまたはサービスを参加者と呼びます。

Sync Framework では、次の種類の参加者がサポートされます。

• フル参加者

• プロキシ参加者

• パーシャル参加者

• シンプル参加者

フル参加者

フル参加者は、ローカルでランタイムをホストし、メタデータを保存します。フル参加者はピア ツー ピアの同期に参加できます (両方の参加者が同期を開始できるため)。

2 つのフル参加者をピア ツー ピアで同期させる例

パーシャル参加者

パーシャル参加者は、同期メタデータを格納することはできますが、それを処理することはできません。パーシャル参加者は、別のフル参加者に依存しながら、ランタイムをホストし、同期を開始します。これらの参加者を経由したデータのフローが可能なのは、フル参加者が、マルチ マスター同期のメタデータを搬送でき、このメタデータを他の任意のフル参加者との間でやり取りできるためです。パーシャル参加者はメタデータを処理したり、ランタイムをホストしたりすることはできないため、ピア ツー ピアの同期に参加することはできません。パーシャル参加者の例としては、USB サム ドライブやデータ ストレージ機能を備えた携帯電話などが挙げられます。

次の図は、フル参加者 (コンピューターなど) が、パーシャル参加者 (携帯電話) との間で同期を行う例です。フル参加者は、パーシャル参加者に代わって変更を列挙したりフィルター選択したりしながら、メタデータをパーシャル参加者に格納します。こうして、他の任意のフル参加者が、このパーシャル参加者との間で同期を行うことができるようになります。

フル参加者とパーシャル参加者を同期させる例

シンプル参加者

シンプル参加者は、メタデータを格納せず、ランタイムをホストすることはできません。場合によっては、変更追跡も実行しません。シンプル参加者は、変更の列挙に関連したすべての処理、変更の適用、メタデータの操作と格納を、単一のフル参加者に依存します。メタデータを格納できないため、シンプル参加者は、単一のフル参加者とパートナー関係を持つリーフ ノードとしてのみ機能し、そのフル参加者が、他の参加者との間でデータをやり取りすることになります。

次の図は、フル参加者が、Metadata Storage Service を使ってシンプル参加者のメタデータを格納し、すべての同期処理をシンプル参加者に代わって実行するようすを示しています。このメタデータ ストアは、シンプル参加者に関連した変更を追跡する目的で使用されていますが、シンプル参加者のストレージ上の制限により、フル参加者側に置かれていることがわかります。

フル参加者が Metadata Storage Service を使ってシンプル参加者を同期させる例

プロキシ参加者

プロキシ参加者は、サーバーに格納されているデータベースなど、ローカルで呼び出しを処理し、それをリモート プロバイダーに転送することによってリモート プロバイダーの同期を開始します。

セキュリティメモ :
Sync Framework では、プロキシ プロバイダーとリモート プロバイダーの間の認証または暗号化は提供されません。不正アクセスまたは改ざんを防ぐには、SSL (Secure Sockets Layer) などの適切な相互認証および暗号化メカニズムを使用して、プロキシ プロバイダーとリモート プロバイダーの間の通信チャネルをセキュリティで保護する必要があります。

次の図は、プロキシ プロバイダーを使って同期を行うフル参加者プロバイダーを表しています。プロキシ プロバイダーは単に、ネットワークを介してリモート プロバイダーにコマンドおよびメタデータを送信しているだけです。リモート プロバイダーはデータベース サーバー上に存在し、同期に使用される実際のロジックを実装します。赤色の破線は、コンピューターの境界を表します。

フル参加者とプロキシ参加者を同期させる例

次の図は、Sync Framework を使用して、同期を開始するアプリケーションとは別の場所にあるリモート プロバイダーを同期させる方法を示しています。この場合、制御側のアプリケーションは、同期対象となる 2 つの Web サービスまたはスマート デバイスに接続します。2 つのローカル プロバイダーは、リモート プロバイダーのプロキシ プロバイダーとして機能している点に注目してください。赤色の破線は、コンピューターの境界を表します。

中央のアプリケーションにより 2 つのプロキシ参加者を同期させる例

参照

概念

適切な Sync Framework コンポーネントの選択
簡易カスタム プロバイダーの実装
標準のカスタム プロバイダーの実装
同期アプリケーションの実装
Sync Framework サンプル