サービス アーキテクチャを定義する

サービス アーキテクチャとは、サービスがどのように構成され、システム内の他のコンポーネントとどのように通信するかを指します。

サービス バンドルを作成する

サービス バンドルは、一緒にデプロイできる関連するサービス ユニットをグループ化します。サービス バンドルに必要なプロパティは名前だけです。名前はパッケージ名とともに、サービス バンドルの完全修飾名を構成します。

サービス バンドルは、Vehicle Services Interface Definition Language（VSIDL）ファイル（拡張子が .vsidl のファイル）で定義されます。

次の例は、TirePressureMonitoring サービス バンドルと BodyControl サービス バンドルの 2 つのサービス バンドルを示しています。

package: "com.android.sdv.sample.vsidl"

service_bundle {
  name: "TirePressureMonitoring"
}

service_bundle {
  name: "BodyControl"
}

ここで

  • service_bundle は、構造がサービス バンドルであることを示します。
  • name は、サービス バンドルの名前です。

メッセージング パターン: Pub/Sub と RPC

SDV フレームワークでは、パブリッシュ / サブスクライブ（Pub/Sub）とリモート プロシージャ コール（RPC）の 2 つの主要なメッセージング パターンを使用します。

Pub/Sub では、システムは車両の状態の変化に対応して、関心のあるコンポーネントにデータをストリーミングします。データはトピックに整理されます。パブリッシャーはトピックにメッセージを送信します。パブリッシャーは、リッスンしているサブスクライバーの種類や数を把握する必要なく、トピックにメッセージを送信します。サブスクライバーは、どのパブリッシャーがメッセージを送信したかを知らなくても、トピックでメッセージを受信できます。

一方、RPC はアクションと結果を目的として設計されています。呼び出し元が特定の結果やアクションの確認を必要とするため、リクエストを開始する場合に使用されます。呼び出し元は、チャネルで特定のメソッドを呼び出します。

これらのパターンはさまざまな運用ニーズに対応しますが、共通の構造プロパティを共有しています。どちらも、名前付きの通信パス（Pub/Sub の場合はトピック、RPC の場合はチャネル）を使用して、送信者の ID を受信者から切り離します。

パブリッシャーとサブスクライバーを宣言する

パブリッシュ / サブスクライブは、メッセージの送信者（ パブリッシャー）が、メッセージを特定の受信者（ サブスクライバー）に直接送信しないメッセージング パターンです。代わりに、パブリッシャーはメッセージをトピックに分類し、サブスクライバーは 1 つ以上の通信トピックにサブスクライブして、それらのトピックにパブリッシュされたメッセージのみを受信します。 パブリッシュ / サブスクライブの詳細については、パブリッシュ / サブスクライブ パターンをご覧ください。

サービス バンドルにパブリッシャーを追加する

次の例は、TirePressureMonitoring サービス バンドルに追加されたパブリッシャーを示しています。

package: "com.android.sdv.sample.vsidl"

service_bundle {
  name: "TirePressureMonitoring"

  publisher {
    message: "TirePressure"
    topic: "front-left"
    capacity: 10
  }

}

service_bundle {
  name: "BodyControl"

  ...
}

ここで

  • publisher サービス メッセージは、メッセージをメッセージ キューにパブリッシュします。
  • message protobuf で定義されたデータ構造またはメッセージ タイプ（拡張子が .protobuf のファイル）。
  • topic パブリッシュ トピックの一意の識別子。小文字のダッシュケースにする必要があります。
  • capacity パブリッシュ キューに保持できるメッセージの数。2 以上の偶数にする必要があります。

サービス バンドルにサブスクライブを追加する

次の例は、BodyControl サービス バンドルに追加されたパブリッシャーを示しています。

package: "com.android.sdv.sample.vsidl"

service_bundle {
  name: "TirePressureMonitoring"

  publisher {
    message: "TirePressure"
    topic: "front-left"
    capacity: 10
  }
}

service_bundle {
  name: "BodyControl"

  subscriber {
    message: "com.android.sdv.sample.vsidl.TirePressure"
    topic: "front-left"
  }
}

ここで

  • subscriber サービス バンドルはトピックにサブスクライブします。
  • message protobuf で定義されたデータ構造またはメッセージ タイプ（拡張子が .protobuf のファイル）。
  • topic パブリッシュ トピックの一意の識別子。パブリッシャーのトピックと一致し、小文字のダッシュケースにする必要があります。

RPC クライアントとサーバーを定義する

リモート プロシージャ コール（RPC）は、関数呼び出しの場所の独立性を提供します。このパターンでは、チャネルはクライアントとプロバイダが出会う名前付きのランデブー ポイントとして機能します。特定のサービス インスタンスではなくチャネルをターゲットにすることで、フレームワークはコマンドの意図を実装の物理的な場所から切り離します。

次の例では、ClimateControl サービス バンドルをサーバーとして、BodyControl サービス バンドルをクライアントとして指定します。

package: "com.sdv.cc"

service_bundle {
  name: "ClimateControl"

  server {
    service: "SetTemperature"
    channel: "climate-control"
  }
}

service_bundle {
  name: "BodyControl"

  client {
    service: "SetTemperature"
    channel: "climate-control"
  }
}

ここで

  • server は、サービス バンドルが、service で SetTemperature として識別される RPC サービスを提供するサーバーであることを示します。
  • client は、サービス バンドルが SetTemperature サービスを呼び出すクライアントであることを示します。
  • channel は、RPC チャネルの名前です。小文字のダッシュケースにする必要があり、サービスごとに一意にする必要があります。

この例では、BodyControl サービス バンドルが ClimateControl サービス バンドルに対してリモート プロシージャ コールを行い、温度を設定できます。

次のステップ

アーキテクチャを定義したら、ミドルウェア コードを生成します。