初期通知 (Initial notification)

イントロダクション

Orion Context Broker は、特定のサブスクリプションを考慮して、更新が発生したときに通知し、サブスクリプション条件が更新されたエンティティで満たされると通知します。すなわち、更新される属性のエンティティはサブスクリプションによってカバーされ、その他のオプションのフィルタ (属性値、ジオロケーションなど) も一致します。したがって、通知はエンティティの更新と同期しています。

ただし、サブスクリプション作成 (または更新) のトランザクションと同期して送信される 初期通知 という特殊な通知があります。この通知には、サブスクリプションによってカバーされるすべてのエンティティが作成 (または更新) されています。非初期通知とは異なり、既存のコンテキストに応じて複数のエンティティを含む場合があります。実際には、初期通知のセマンティクスは同期クエリ (GET /v2/entities) のものに非常に近いです。

例を挙げて説明しましょう。ある瞬間、Orion には次の存在が存在します (GET /v2/entities へのレスポンス) :

[
    {
        "id": "Room1",
        "temperature": {
            "metadata": {},
            "type": "Float",
            "value": 23
        },
        "type": "Room"
    },
    {
        "id": "Room2",
        "temperature": {
            "metadata": {},
            "type": "Float",
            "value": 33
        },
        "type": "Room"
    },
    {
        "id": "Room3",
        "temperature": {
            "metadata": {},
            "type": "Float",
            "value": 43
        },
        "type": "Room"
    }
]

次に、次のサブスクリプションが作成されます :

POST /v2/subscriptions

{
  "subject": {
    "entities": [
      {
        "idPattern": ".*",
        "type": "Room"
      }
    ],
    "condition": {
      "expression": {
         "q": "temperature<35"
      }
    }
  },
  "notification": {
    "http": {
      "url": "http://localhost:1028/accumulate"
    },
    "attrs": [
      "temperature"
    ]
  }
}

そのサブスクリプションの作成によって、次のような初期通知がトリガーされます (簡略化) :

POST /accumulate HTTP/1.1

{
     "subscriptionId": "59edf55231cee478fe9fff1e",
     "data": [{
         "id": "Room1",
         "type": "Room",
         "temperature": {
             "type": "Float",
             "value": 23,
             "metadata": {}
         }
     }, {
         "id": "Room2",
         "type": "Room",
         "temperature": {
             "type": "Float",
             "value": 33,
             "metadata": {}
         }
     }]
}

Room3 は属性値フィルタと一致しないため、含まれていないことに注意してください。

根拠

Orion Context Broker は、"既存のサブスクリプション以外" から "サブスクライブ済み" への移行を変更とみなすため、初期通知が送信されます。

OMA のオリジナルの NGSI 仕様では、この場合に初期通知を送信する必要があるかどうかは不明です。一方で、実際の変更のために通知を受け取る前に、初期値を知っておくと便利かもしれないと考える開発者もいます。一方、アプリケーションは同期クエリを使用して初期状態を取得できるため、初期通知は必要ありません。

両方のオプションの間で、より柔軟なアプローチを実装することを選択しました。これは、初期通知を活用できるユーザには提供し、それを必要としないユーザは無視できることです。

初期通知の回避

初期通知を無視するために、URI パラメータ・オプション skipInitialNotification を使うことができます。この URI オプションを使用すると、サブスクリプションの 作成/更新時に最初の通知が常にスキップされます。特に :

  • POST /v2/subscriptions?options=skipInitialNotification
  • PATCH /v2/subscriptions/<subId>?options=skipInitialNotification

その他の考慮事項

初期通知は必ずしも送信されないことに注意してください。初期通知は、 あるエンティティがサブスクリプションの作成/更新時にサブスクリプション基準に 一致する場合にのみ送信されます。マッチングが発生した場合は、URI オプションを 使用してそれを回避することが可能です。 初期通知の回避 を参照ください。

初期通知では、同期クエリと同じエンティティが使用されます。つまり、サブスクリプションの対象となったエンティティがどれだけであっても、初期通知には最大20個のエンティティが含まれます。(オプション limitorderBy オプションを持つ)クエリとは異なり、この番号または順番の基準は設定できません。この通知を初期通知に適用する方法は、同じ通知で大量のエンティティを送信することが問題になる可能性があるため、議論の余地はあります (議論を参照)。したがって、現時点では、サブスクリプションの対象となる大量のエンティティがある場合は、初期通知を使用してアプリケーションの初期コンテキストを取得することは推奨されません (代わりに同期クエリを使用します)。

初期以外の通知で発生するように、Fiware-ServicePath ヘッダは初期通知に含まれます。ただし、初期通知には、複数のエンティティが含まれている可能性があります。複数のエンティティは、異なるサービスパスに属することがあります。したがって、カンマで区切られた値のリストが使用されます (Fiware-ServicePath リストの最初の要素は、最初のエンティティなどに対応します)。可能なエンティティ (20) の限界がリスト (10) 内の許可されたサービス経路要素の数より大きい場合、フェデレーション・シナリオで他の Context Broker が消費するときに "不正な" 初期通知を生成する可能性があることに注意してください。この状況を解決する手段 (つまり、同じ通知で同じサービスパスに属するすべてのエンティティをグループ化し、異なるサービスパスとして初期通知の数を送信します) は、現在のバックログの一部です。