ハイ・レベルな内部アーキテクチャ (High level internal architecture)

概要

このドキュメントでは、Orion Context Broker の内部アーキテクチャの概要を紹介します。これは、さまざまなライブラリの詳細に入る前に紹介として役立つはずです。しかし、これは単なる概観であり、網羅的なものではないことに注意してください。

次の図は、主要な情報の流れと、プログラムの制御があるモジュールから別のモジュールにどのように移行するかを示しています。内部フローの詳細なリストについては、このセクションを参照してください。

Orion current internal architecture

現在の Orion の内部アーキテクチャ

  • 起動時に、Orion Context Broker は着信リクエストをリッスンする HTTP サーバを開始します。残りのライブラリはこれらのリクエストを処理し、そのライブラリは microhttpd 外部ライブラリに基づいており、リクエストごとに新しいスレッドが生成されます。

  • connectionTreat()関数は、新しいリクエストのエントリポイントです。詳細は、図 RQ-01 を参照してくだい。リクエストが属する NGSI の API のバージョンに応じて、実行フローは実行ロジックの一つの "分岐" または別のものになります。基本的には、リクエスト URL プレフィックスが /v1 か /v2 かどうかによって異なります。

  • NGSIv1 (非推奨) リクエストの場合、ロジックは次のようになります :

    • まず、jsonParse libraryはリクエストのペイロードを入力として受け取り、一連のオブジェクトを生成します。NGSIv1 パーシング・ロジックは、Boost library property_tree に基づいています
    • 次に、リクエストを処理するリクエストのサービス機能が呼び出されます。HTTP および URL パターンに関して、各リクエスト・タイプには、別々の機能があります。これらの関数を "サービス・ルーチン" と呼び、それらはライブラリの serviceRoutines に存在します。いくつかの "ハイ・レベル" サービス・ルーチンは、他の "ロー・レベル" サービス・ルーチンを呼び出すかもしれないことに注意してください。
    • 最後に (1つまたは2つのホップのいずれかで)、サービス・ルーチンは mongoBackend ライブラリを呼び出します。詳細についてはマッピングのドキュメントを参照してください
  • NGSIv2 リクエストの場合、ロジックは次のようになります :
    • まず、jsonParseV2 library はリクエスト・ペイロードを入力として受け取り、一連のオブジェクトを生成します。NGSIv2 パーシング・ロジックは rapidjson に基づいています。
    • 次に、NGSIv1 と同様に、サービス・ルーチンが呼び出されてリクエストを処理します。HTTP および URL パターンに関して、各リクエスト・タイプには、サービス・ルーチンがあります。これらの "NGSIv2 サービス・ルーチン" は、ライブラリの serviceRoutinesV2 にあります。一部の V2 サービス・ルーチンは、NGSIv1 サービス・ルーチンを呼び出すかもしれないことに注意してください。詳細は、マッピングのドキュメントを参照してください。
    • 最後に、mongoBackend ライブラリが呼び出されます。場合によっては、V2 サービス・ルーチンから直接行うことも、上の図に示すように V1 サービス・ルーチンを介して間接的に行うこともできます
  • mongoBackend のライブラリは、いくつかの点で、Orion の"頭脳"です。Orion が実行する、エンティティ情報の取得、エンティティの更新、サブスクリプションの作成などのさまざまな操作を目的とした一連の関数が含まれています。このライブラリは、対応する mongoDriver ライブラリ (対応する MongoDB C driver をラップします) を使用して MongoDB とインタフェースします。歴史的な理由から、MongoDB バックエンドのほとんどは NGSIv1 ベースです。したがって、V1 サービス・ルーチンからアクセスされます。例外は、V2 サービス・ルーチンから直接呼び出される サブスクリプション一覧などの NGSIv2 専用の操作です
  • 通知がトリガーされるたびに (たとえば、既存のサブスクリプションでカバーされるエンティティを更新した結果として)、通知モジュール(ngsiNotify ライブラリ にある) が mongoBackend から呼び出されます。このような通知を送信するため、Orion は2つの通知タイプをサポートしています * HTTP 通知。この場合、httpRequestSend() 関数 (rest ライブラリの一部) が HTTP リクエストの送信を担当します。これは、libcurl 外部ライブラリに基づいています * MQTT 通知。この場合、sendMqttNotification() 関数 (mqtt ライブラリの一部) は、対応する MQTT broker での MQTT 通知の公開を担当します。これは、mosquitto 外部ライブラリに基づいています
  • httpRequestSend() 関数は、特定の条件下でクエリ/更新をコンテキスト・プロバイダ に転送できるserviceRoutines 関数によっても呼び出されます

トップ

歴史

Orion Context Broker (0.1.0) の最初のバージョンは、2013年5月14日にリリースされました。純粋な NGSIv1 であり、リクエスト/レスポンスペイ・ロード形式として XML のみに基づいています。その時点で、property_tree は XML の文字列ベースの性質 (XML では、JSON と同じように、数値、ブール値などをネイティブ型として持たない) によく合致するので、パーシング・ライブラリとして選択されました。

アーキテクチャ上の観点から、次の重要なマイルストーンは、Orion ユーザの大規模なコミュニティによってリクエストされた JSON レンダリングの追加でした。その作業はバージョン 0.8.1 (2013年10月30日) から開始し、0.10.0 (2014年2月20日) に終了しました。幸いにも、property_tree パーサーも JSON をサポートしていましたので、アーキテクチャ設計には大きな影響はありませんでした。新しい JSON 形式のパース/レンダリングのロジックを書く必要がありました。

2015年7月に、NGSIv2 (NGSIv2 機能付き Orion の最初のバージョン、まだベータ版で、0.23.0) を導入しました。これは NGSIv1 のより簡単で拡張されたバージョンです。NGSIv2 はパーシング・ロジックにとって重要な要件をもたらしました。JSON ネイティブ・タイプをサポートする必要があります。したがって、property_tree は十分ではなく、タスクを実行するために別のライブラリを選択する必要がありました。新しいパーシング・ライブラリ jsonParseV2 (rapidjson に基づいた) がこの目的のために開発されました。同じ代価で、rapidjson はより簡単なプログラミング・モデルを導入し、最も効率的な既存モデルの1つです。

NGSIv2 はまた、新しい V2 サービス・ルーチンを保持するために開発した新しい serviceRoutinesV2 library (/v2 URL プレフィックスの下にあるものすべて) を実装するための、新しい HTTP リクエストのセットをもたらしました。場合によっては、NGSIv1 の機能を再利用することができました。つまり、V2 サービス・ルーチンの一部が V1 サービス・ルーチンを呼び出します。しかし、NGSIv1 で対応していない新機能 (新しい list subscriptions リクエストなど)では、V2 サービス・ルーチンが mongoBackend ライブラリを直接呼び出します。新しい機能を扱うために新しい関数で拡張する必要がありました。

上のアーキテクチャー図では、NGSIv2 に関連する新しい追加がオレンジ色で強調表示されています。

もう一つのアーキテクチャの進化 (今回は通信に関連する) は、発信 HTTP リクエストを直接処理 (つまり、リクエストを直接 TCP ソケットに書き込む) から、本格的な HTTP 指向のライブラリとしての libcurl の使用に移行していました。これは Orion 0.14.1 (2014年8月1日) で行われました。このようにして、HTTP プロトコルの微妙な細部がすべて考慮されています。実際、Orion 0.14.1 ではいくつかのバックエンドに通知を送信する問題を解決しました。

ターゲット・アーキテクチャ

アーキテクチャの進化の重要な成果の1つは、NGSIv1 API との完全な下位互換性を維持しながら、API の新しいバージョン (NGSIv2) 全体を開発できることでした (Orion1.0.0 で廃止された XML のレンダリングを除いて...それの後ろにひどい遺産として property_tree を残して:)。

しかし、これは、いくつかの非効率的な側面 (特に、mongoBackend へのより直接的なフローではなく、サービス・ルーチン呼び出しの"チェーン") を伴う "並列" アーキテクチャにつながります。したがって、NGSIv1 が廃止予定であると宣言され、Orion のターゲットが NGSIv2 のみをサポートすることになると、ある時点で統合する必要があります (同様に、XML レンダリングは廃止され、最終的に削除されます)。

その時が来ると、ハイ・レベルの視点からのステップは次のようになります :

  1. NGSIv1 JSON 機能を削除し、機能テストを調整します。これには、すべての property_tree の依存関係が削除されます
  2. NGSIv2 と NGSIv1 の内部タイプを単一の NGSI タイプ・ファミリーに統合します
  3. serviceRoutines と mongoBackend を単一NGSIタイプ・ファミリーに適応します

次の図は、上記の変更を考慮に入れて、ターゲット・アーキテクチャを示しています。

Orion target internal architecture

Orion のターゲット内部アーキテクチャ

トップ