Definisci l'architettura del servizio

L'architettura dei servizi si riferisce alla composizione dei servizi e al modo in cui comunicano con altri componenti del sistema.

Creare bundle di servizi

I bundle di servizi raggruppano unità di servizio correlate che possono essere sottoposte a deployment insieme. L'unica proprietà obbligatoria per un bundle di servizi è un nome. Insieme al nome del pacchetto, il nome forma il nome completo del bundle di servizi.

I bundle di servizi sono definiti con file Vehicle Services Interface Definition Language (VSIDL) (file con estensione .vsidl).

L'esempio seguente mostra due bundle di servizi: un bundle di servizi TirePressureMonitoring e un bundle di servizi BodyControl:

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

service_bundle {
  name: "TirePressureMonitoring"
}

service_bundle {
  name: "BodyControl"
}

Dove:

• service_bundle identifica la struttura come bundle di servizi.
• name è il nome del bundle di servizi.

Modelli di messaggistica: Pub/Sub e RPC

Il framework SDV utilizza due modelli di messaggistica principali: Publish-Subscribe (Pub/Sub) e chiamata di procedura remota (RPC).

In Pub/Sub, il sistema reagisce allo stato in evoluzione del veicolo trasmettendo dati in streaming a tutti i componenti interessati. I dati sono organizzati in argomenti. I publisher inviano messaggi sugli argomenti. Il publisher invia messaggi sugli argomenti senza dover sapere quali (o quanti) abbonati sono in ascolto. Gli abbonati ricevono messaggi sugli argomenti senza sapere quali publisher specifici hanno inviato i messaggi.

Al contrario, RPC è progettato per l'azione e il risultato. Viene utilizzato quando il chiamante avvia una richiesta perché è interessato al risultato o alla conferma specifica di questa azione. Il chiamante richiama un metodo specifico su un canale.

Sebbene questi modelli soddisfino esigenze operative diverse, condividono una proprietà strutturale comune: entrambi si basano su percorsi di comunicazione denominati (argomenti per Pub/Sub e canali per RPC) per disaccoppiare l'identità del mittente dal destinatario.

Dichiarare publisher e abbonato

Publish-subscribe è un modello di messaggistica in cui i mittenti dei messaggi, chiamati publisher, non inviano i messaggi direttamente a destinatari specifici, chiamati abbonati. I publisher, invece, classificano i messaggi in argomenti e gli abbonati si abbonano a uno o più argomenti di comunicazione e ricevono solo i messaggi pubblicati su questi argomenti. Per ulteriori informazioni su publish-subscribe, consulta Modello publish-subscribe.

Aggiungere un publisher a un bundle di servizi

Gli esempi seguenti mostrano un publisher aggiunto al bundle di servizi TirePressureMonitoring:

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

service_bundle {
  name: "TirePressureMonitoring"

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

}

service_bundle {
  name: "BodyControl"

  ...
}

Dove:

• publisher Il messaggio di servizio pubblica i messaggi in una coda di messaggi.
• message Struttura dati o tipo di messaggio definito in protobuf (file con estensione .protobuf).
• topic Identificatore univoco per l'argomento di pubblicazione. Deve essere in minuscolo con trattini.
• capacity Numero di messaggi che la coda di pubblicazione può contenere. Deve essere un numero pari maggiore o uguale a 2.

Aggiungere un abbonamento a un bundle di servizi

Gli esempi seguenti mostrano un publisher aggiunto al bundle di servizi 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"
  }
}

Dove:

• subscriber Il bundle di servizi si abbona agli argomenti.
• message Struttura dati o tipo di messaggio definito in protobuf (file con estensione .protobuf).
• topic Identificatore univoco per l'argomento di pubblicazione. Deve corrispondere all'argomento del publisher ed essere in minuscolo con trattini.

Definire client e server RPC

La chiamata di procedura remota (RPC) fornisce l'indipendenza dalla località delle chiamate di funzione. In questo modello, il canale funge da punto di incontro denominato in cui si incontrano il client e il provider. Se il framework ha come target il canale anziché un'istanza di servizio specifica, disaccoppia l'intento del comando dalla posizione fisica dell'implementazione.

L'esempio seguente designa il bundle di servizi ClimateControl come server e il bundle di servizi BodyControl come client:

package: "com.sdv.cc"

service_bundle {
  name: "ClimateControl"

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

service_bundle {
  name: "BodyControl"

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

Dove:

• server indica che il bundle di servizi è un server che fornisce un servizio RPC (identificato da service come SetTemperature).
• client indica che il bundle di servizi è un client che richiama il servizio SetTemperature.
• channel è il nome del canale RPC. Deve essere in minuscolo con trattini e univoco per servizio.

Questo esempio consente al bundle di servizi BodyControl di effettuare chiamate di procedura remota al bundle di servizi ClimateControl per impostare la temperatura.

Passaggi successivi

Dopo aver definito l'architettura, genera il codice middleware.