2. プログラミング モデル¶
2.1. Intent ベースのプログラミング モデル¶
現在、次の2つのプログラミング モデルが FogFlow によって提供されており、さまざまなタイプのワークロード パターンをサポートしています。
2.1.1. サービス トポロジー¶
最初のワークロード パターンは、必要な処理フローをトリガーして、出力データがコンシューマーによって要求された場合にのみ出力データを生成することです。このパターンに基づいて IoT サービスを定義するには、サービス プロバイダーは、リンクされたオペレーターのセットで構成されるサービス トポロジーを定義する必要があり、各オペレーターには特定の粒度で注釈が付けられます。FogFlow は、オペレーターの粒度を考慮して、使用可能なデータに基づいて、そのようなオペレーターのタスク インスタンスをインスタンス化する必要がある数を決定します。
サービス トポロジーは、コンシューマーまたは任意のアプリケーションによって発行されたインテント オブジェクト (Intent object) によって明示的にトリガーされる必要があります。インテント オブジェクトは、(優先度に基づいて) サービス トポロジーをトリガーする必要がある時期を定義します。また、オプションで特定のジオスコープを定義して、トリガーされた処理ロジックを適用するためのデータソースを除外することもできます。インテント条件 (Intent conditions) を満たすサービストポロジーの一部がトリガーされ、入力データが利用可能になります。
2.1.2. フォグ ファンクション (Fog Function)¶
2番目のワークロード パターンは、サービス設計者がストリーム処理ステップの正確なシーケンスを事前に知らないシナリオ向けに設計されています。代わりに、特定のタイプの情報を処理するための特定のオペレーターを含めるようにフォグ ファンクションを定義できます。FogFlow は、すべてのフォグ ファンクションのこの説明に基づいて、処理フローのグラフを作成できます。サービストポロジーとは異なり、フォグ ファンクションはオペレーターが1人だけの非常に単純なトポロジーであり、入力データが利用可能になるとトリガーされます。FogFlowは、さまざまなフォグ ファンクションを自動的にチェーンし、複数のフォグ ファンクションが新しいデータ アイテムを処理できるようにするため、データの到着と消失時に、絶えず変化する実行グラフを FogFlow ランタイムによって自動的にトリガーおよび管理できます。デザインの観点から、フォグ ファンクションはサービス トポロジーよりも柔軟性があります。これは、サービス処理ロジックを新しいビジネス要件に合わせて変更する必要がある場合にフォグ ファンクションを追加または削除することで、IoT サービスの全体的な処理ロジックを時間の経過とともに簡単に変更できるためです。FogFlow は、フォグ ファンクション プログラミング モデルを使用して、クラウド エッジベースの環境でサーバーレス コンピューティングをサポートできます。
2.2. コンテキスト ドリブンのサービス オーケストレーション¶
FogFlow では、各ワーカーは、トポロジー マスターによって割り当てられた次の2種類の展開アクションを実行するエージェントです。
- タスク インスタンスを開始/終了する。
- 既存の実行中のタスク インスタンスに入力ストリームを追加/削除します。
たとえば、各ワーカーは次の手順を実行してタスク インスタンスを開始します。
- ワーカーは、ローカルの Docker engine に、指定されたリスニング ポート番号で新しいタスク インスタンスを実行するための新しいコンテナーを作成するように要求します。
- タスク インスタンスの実行が開始され、指定されたポート番号でリッスンして入力データ ストリームを受信します。
- ワーカーは、リスニング ポートを介して実行中のタスク インスタンスに構成オブジェクトを送信します。
- ワーカーは、実行中のタスク インスタンスに代わって NGSI10 サブスクリプションを発行します。
- 必要な入力データ ストリームは、実行中のタスク インスタンスに流れ込み、リスニング ポートを介してさらに処理されます。
- 実行中のタスク インスタンスは、受信した入力ストリームデータを処理し、その結果を生成します。
- 実行中のタスク インスタンスは、NGSI10 アップデートを送信することにより、生成された結果を出力として公開します。