Define la arquitectura de servicio

La arquitectura de servicios se refiere a cómo se componen los servicios y cómo se comunican con otros componentes del sistema.

Crea paquetes de servicios

Los paquetes de servicios agrupan unidades de servicio relacionadas que se pueden implementar juntas. La única propiedad obligatoria para un paquete de servicios es un nombre. Junto con el nombre del paquete, el nombre forma el nombre completamente calificado del paquete de servicio.

Los paquetes de servicios se definen con archivos del lenguaje de definición de la interfaz de servicios para vehículos (VSIDL) (archivos con la extensión .vsidl).

En el siguiente ejemplo, se muestran dos paquetes de servicios: un paquete de servicios TirePressureMonitoring y un paquete de servicios BodyControl:

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

service_bundle {
  name: "TirePressureMonitoring"
}

service_bundle {
  name: "BodyControl"
}

En la que:

• service_bundle identifica la estructura como un paquete de servicios.
• name es el nombre del paquete de servicios.

Patrones de mensajería: Pub/Sub y RPC

El framework de SDV utiliza dos patrones de mensajería principales: publicar-suscribir (Pub/Sub) y llamada de procedimiento remoto (RPC).

En Pub/Sub, el sistema reacciona al estado cambiante del vehículo transmitiendo datos a cualquier componente interesado. Los datos se organizan en temas. Los publicadores envían mensajes sobre temas. El publicador envía mensajes sobre temas sin necesidad de saber qué suscriptores (o cuántos) están escuchando. Los suscriptores reciben mensajes sobre temas sin saber qué publicadores exactos los enviaron.

En cambio, la RPC está diseñada para la acción y el resultado. Se usa cuando el llamador inicia una solicitud porque le interesa el resultado específico o la confirmación de esa acción. El llamador invoca un método específico en un canal.

Si bien estos patrones satisfacen diferentes necesidades operativas, comparten una propiedad estructural común: ambos se basan en rutas de comunicación con nombre (temas para Pub/Sub y canales para RPC) para desacoplar la identidad del remitente del receptor.

Cómo declarar el publicador y el suscriptor

Publicar-suscribir es un patrón de mensajería en el que los remitentes de mensajes, llamados publicadores, no envían los mensajes directamente a destinatarios específicos, llamados suscriptores. En cambio, los publicadores categorizan los mensajes en temas, y los suscriptores se suscriben a uno o más temas de comunicación y reciben solo los mensajes que se publican en esos temas. Para obtener más información sobre la publicación y suscripción, consulta Patrón de publicación y suscripción.

Agrega un editor a un paquete de servicios

En el siguiente ejemplo, se muestra un publicador agregado al paquete de servicios TirePressureMonitoring:

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

service_bundle {
  name: "TirePressureMonitoring"

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

}

service_bundle {
  name: "BodyControl"

  ...
}

En la que:

• publisher El servicio de mensajes publica mensajes en una cola de mensajes.
• message Estructura de datos o tipo de mensaje definido en protobuf (archivo con la extensión .protobuf).
• topic Es el identificador único del tema de publicación. Debe estar en minúsculas y con guiones.
• capacity Es la cantidad de mensajes que puede contener la cola de publicación. Debe ser un número par mayor o igual que 2.

Agrega un paquete de suscripción a un servicio

En el siguiente ejemplo, se muestra un publicador agregado al paquete de servicios 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"
  }
}

En la que:

• El paquete de servicios subscriber se suscribe a temas.
• message Estructura de datos o tipo de mensaje definido en protobuf (archivo con la extensión .protobuf).
• topic Es el identificador único del tema de la publicación. Debe coincidir con el tema del publicador y estar en minúsculas con guiones.

Define clientes y servidores de RPC

La llamada de procedimiento remoto (RPC) proporciona independencia de la ubicación de las llamadas a funciones. En este patrón, el canal funciona como el punto de encuentro con nombre en el que se reúnen el cliente y el proveedor. Al segmentar el canal en lugar de una instancia de servicio específica, el framework desacopla la intención del comando de la ubicación física de la implementación.

En el siguiente ejemplo, se designa el paquete de servicio ClimateControl como servidor y el paquete de servicio BodyControl como cliente:

package: "com.sdv.cc"

service_bundle {
  name: "ClimateControl"

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

service_bundle {
  name: "BodyControl"

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

En la que:

• server indica que el paquete de servicios es un servidor que proporciona algún servicio de RPC (identificado por service como SetTemperature).
• client indica que el paquete de servicios es un cliente que invoca el servicio SetTemperature.
• channel es el nombre del canal de RPC. Debe estar en minúsculas y con guiones, y ser único por servicio.

En este ejemplo, se permite que el paquete de servicios BodyControl realice llamadas a procedimientos remotos al paquete de servicios ClimateControl para establecer la temperatura.

¿Qué sigue?

Después de definir tu arquitectura, genera código de middleware.