Weave の主要コンポーネントを理解したところで、その機能の一部について、どのように扱うかを見ていきましょう。
Google Nest エコシステムのほぼすべての機能が日常的な動作に対応し、Weave スキーマの一部としてリソースとトレイトにマッピングされます。データ管理 プロファイルは、publish-subscribe モデルを使用してトレイトに対するすべてのリクエストを管理します。これらのリクエストは、データ管理プロファイルに固有のメッセージです。
このタイプのモデルでは、パブリッシャーはトレイト（監視するデータ）をアドバタイズし、サブスクライバーがパブリッシュされたトレイトの変更（監視しているデータ）に対応します。これをリアルタイム トレイト管理と呼びます。
データ管理プロファイルは Weave の主軸であり、通常は Weave Data Management（WDM）と呼ばれます。
リクエスト
リクエスト は、WDM のリアルタイムのトレイト管理における重要な要素です。リクエストは、トレイトの標準的なアクション リクエストで、期待されるレスポンスが返されます。これらはトレイトのコマンドとは異なり、スキーマでは定義できないため、どのトレイトにも固有ではありません。
標準的なリクエストには次の 3 種類があります。
- トレイト リクエストの状態、またはそのトレイトに関連する特定のイベントについてサブスクライブを通知する標準リクエストの通知。
- 更新 標準リクエスト。トレイトのプロパティを変更します。
- View トレイトのプロパティを表示する標準リクエスト。
プロトコルのロール
WDM プロトコル ロールには、パブリッシャーとサブスクライバーの 2 種類があります。これらのロールはトレイトレベルで割り当てられます。
パブリッシャー
WDM のパブリッシャー ロールは、スキーマのバージョニングされたインスタンスを 1 人以上のサブスクライバーに生成して配信し、スキーマの変更に関する通知を関心のあるサブスクライバーに送信します。これらの通知は、標準リクエストの通知です。
たとえば、トレイト A がリソース 1 で公開され、リソース 2 でサブスクライブされているとします。図 1 のように、トレイト A が変わっている場合:
- WDM は、リソース 1 からトレイト A のすべてのサブスクライバーに リクエスト を送信し、変更について通知します。
- 各サブスクライバーは、それに応じてトレイト A のインスタンスを更新します。
スキーマ内の他のトレイトについても同様です。たとえば、リソース 2 がトレイト B を公開すると、リソース 1 がトレイト B に登録され、トレイト B が変更されます。
- WDM は、リソース 2 からトレイト B のすべての登録者に通知リクエスト を送信し、変更について通知します。
- 各サブスクライバーは、それに応じてトレイト B のインスタンスを更新します。
サブスクライバー
WDM サブスクライバー ロールは、外部に公開された 1 つ以上のスキーマのバージョン付きインスタンスを表示および使用します。update リクエストによってパブリッシュされたスキーマのバージョニングされたインスタンスを変更できる、またはアプリケーション固有のコマンドを発行できます。
たとえば、リソース 2 がリソース 1 で公開されているトレイト A を変更する必要があるとします。図 2 に示すように、トレイト A を変更します。
- WDM は、更新リクエスト をリソース 2 からリソース 1 に送信して、トレイト A の変更をリクエストします。
- リソース 1 のトレイト A が変更されました。
- WDM は、リソース 1 からトレイト A のすべてのサブスクライバーに リクエスト を送信し、変更について通知します。
- 各サブスクライバーは、それに応じてトレイト A のインスタンスを更新します。
定期購入者は、トレイトのリクエスト をトレイトのパブリッシャーに送信して、トレイトのプロパティ を表示し、トレイトのインスタンスをニュース メディアと同期させることができます。
サブスクリプション タイプ
WDM の定期購入には次の 2 種類があります。サブスクリプションは、サブスクライブ リクエストによって確立されます。図 3 は、一方向のサブスクリプションを確立するための基本的なメッセージ フローを示しています。
片道
一方向の定期購入では、定期購入者からパブリッシャーへの、1 つ以上のトレイト インスタンスのリクエストが含まれます。たとえば、モバイルがサービスから家の状態（構造）を取得する場合です。
ミューチュアル
相互サブスクリプションは、リソースが相互にサブスクライブし、それぞれがパブリッシャーとサブスクライバーの両方として機能します。例として、Nest Secure システムの一部である Nest Guard と Nest Detect があります。相互サブスクリプションにより、両方のリソースが公開されたスキーマを管理し、2 つの一方向のサブスクリプションよりも効率的な方法で、サブスクリプションの健全性と活性を維持できます。
例
WDM がモバイルアプリを使用してデバイスのロケールの変更を処理する方法の簡単な例を見てみましょう。
この例には、3 つのリソースと 2 つのトレイトが含まれています（図 4 を参照）。
- デバイス（定期購入者）
- サービス（パブリッシャー）
- モバイルアプリ（定期購入者）
- ロケール機能トレイト 使用可能なロケール プロパティ
- ロケール設定トレイト Active Locale プロパティ
どちらのトレイトも、Service リソースによって公開され、Device リソースと Mobile リソースによってサブスクライブされます。各サブスクライバーは、Service リソースでトレイトのパブリッシャーに対する一方向のサブスクリプションとして機能します。
この例のリソースはすべて、同じ Weave ファブリック の一部です。
更新フロー
ユーザーがモバイルアプリを使用して、接続されているモバイルアプリを使用して、デバイスの言語 / 地域を en_US から fr_FR に変更したとします。図 5 に示すように、WDM の更新フローは次のとおりです。
- モバイルアプリ リソース（サブスクライバー）は、ロケール設定トレイトの Active Locale プロパティを
fr_FRに変更します。これは、ロケール機能トレイトの Available - Service リソースは、スキーマのコピーの Locale Settings トレイトの Active Locale プロパティを変更します。
- Service リソースは、Locale Settings トレイトのサブスクライバーに変更の通知通知 を送信します。
- デバイスとモバイルアプリの両方のリソース（サブスクライバー）は、Service リソースの notify リクエスト を受信し、スキーマのコピーでロケール設定トレイトの Active Locale プロパティを更新します。
WDM のメリット
これを行うには、モバイルアプリでデバイスのロケールを変更するだけで非常に複雑に感じることがあります。しかし、バージョニングされたスキーマ、パブリッシュ / サブスクライブ パターン、リクエストを WDM プロファイルにラップすることで、Weave はすべてのリソースにわたってデータの整合性を確保します。
また、liveness が保証されるため、デバイスは再起動されると、直ちに公開済みのトレイトの状態を通知し、登録されたトレイトの状態を監視して、機能を失うことなくスキーマのコピーにそのすべての状態を反映します。
定期購入以外
リソースでトレイトの登録を解除した場合、最後に認識されたトレイトのバージョンを保持します。そのトレイトのパブリッシャーから notify リクエスト を受信することはなくなりますが、update リクエスト は、そのパブリッシャーに送信できます。
トレイトのパブリッシャーを一度も登録していないリソースでも、リクエストを送信できます。たとえば、リソースでトレイトの状態を知る必要はありませんが、update リクエスト を送信して、外部イベントに応じてトレイトのステータスを変更できます。
内容のまとめ
学習した内容:
- Weave Data Management（WDM） は、リアルタイムのトレイト管理用の Weave プロファイルで、すべてのリソースにわたって活性とデータの整合性を確保します。
- リクエスト は、トレイトのアクションに対する標準的なリクエストであり、レスポンスが想定されます。
- WDM には、2 つのプロトコル ロールがあります。
- パブリッシャー - 特定のトレイトの信頼できるソース。通知リクエスト を送信します。
- サブスクライバー - 公開されたスキーマに従い、ビュー 、更新 、コマンド リクエストを送信します。
- WDM には次の 2 つの定期購入モデルがあります。
- 一方向 — サブスクライバーからパブリッシャーへのリクエスト フロー
- 相互 - デバイスは相互に登録
- サブスクリプションは、登録リクエストによって確立されます。
- リソースに登録されていなくても、リソースによって WDM メッセージがトレイトに送信される。
詳細については、以下をご覧ください。