Definir a arquitetura de serviço

A arquitetura de serviços se refere à forma como os serviços são compostos e como eles se comunicam com outros componentes do sistema.

Criar pacotes de serviços

Os pacotes de serviços agrupam unidades de serviço relacionadas que podem ser implantadas juntas. A única propriedade obrigatória para um pacote de serviços é um nome. Junto com o nome do pacote, ele forma o nome totalmente qualificado do pacote de serviços.

Os pacotes de serviços são definidos com arquivos da linguagem de definição de interface de serviços de veículos (VSIDL, na sigla em inglês), ou seja, arquivos com a extensão .vsidl.

O exemplo a seguir mostra dois pacotes de serviços: um pacote de serviços TirePressureMonitoring e um pacote de serviços BodyControl:

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

service_bundle {
  name: "TirePressureMonitoring"
}

service_bundle {
  name: "BodyControl"
}

Em que:

  • service_bundle identifica a estrutura como um pacote de serviços.
  • name é o nome do pacote de serviços.

Padrões de mensagens: Pub/Sub e RPC

O framework SDV usa dois padrões de mensagens principais: publicação/assinatura (Pub/Sub) e chamada de procedimento remoto (RPC).

No Pub/Sub, o sistema reage ao estado em evolução do veículo transmitindo dados para qualquer componente interessado. Os dados são organizados em tópicos. Os editores enviam mensagens sobre tópicos. O editor envia mensagens sobre tópicos sem precisar saber quais (ou quantos) assinantes estão ouvindo. Os assinantes recebem mensagens sobre tópicos sem saber quais editores específicos enviaram as mensagens.

Em contraste, o RPC é projetado para ação e resultado. Ele é usado quando o chamador inicia uma solicitação porque se importa com o resultado específico ou a confirmação dessa ação. O chamador invoca um método específico em um canal.

Embora esses padrões atendam a diferentes necessidades operacionais, eles compartilham uma propriedade estrutural comum: ambos dependem de caminhos de comunicação nomeados (tópicos para Pub/Sub e canais para RPC) para desacoplar a identidade do remetente do destinatário.

Declarar editor e assinante

Publicar/inscrever é um padrão de mensagens em que os remetentes, chamados de editores, não enviam as mensagens diretamente para destinatários específicos, chamados de assinantes. Em vez disso, os publishers categorizam as mensagens em tópicos, e os assinantes se inscrevem em um ou mais tópicos de comunicação e recebem apenas as mensagens publicadas nesses tópicos. Para mais informações sobre publicação/assinatura, consulte Padrão de publicação/assinatura.

Adicionar um editor a um pacote de serviços

Os exemplos a seguir mostram um editor adicionado ao pacote de serviços TirePressureMonitoring:

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

service_bundle {
  name: "TirePressureMonitoring"

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

}

service_bundle {
  name: "BodyControl"

  ...
}

Em que:

  • O serviço publisher publica mensagens em uma fila de mensagens.
  • message Estrutura de dados ou tipo de mensagem definido em protobuf (arquivo com a extensão .protobuf).
  • topic Identificador exclusivo do tópico da publicação. Ele precisa estar em minúsculas e com traços.
  • capacity Número de mensagens que a fila de publicação pode conter. Precisa ser um número par maior ou igual a 2.

Adicionar uma assinatura a um pacote de serviços

Os exemplos a seguir mostram um editor adicionado ao pacote de serviços 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"
  }
}

Em que:

  • O pacote de serviços subscriber se inscreve em tópicos.
  • message Estrutura de dados ou tipo de mensagem definido em protobuf (arquivo com a extensão .protobuf).
  • topic Identificador exclusivo do tópico da publicação. Ele precisa corresponder ao tema do editor e estar em minúsculas com traços.

Definir clientes e servidores RPC

A chamada de procedimento remoto (RPC) oferece independência de local para chamadas de função. Nesse padrão, o canal serve como o ponto de encontro nomeado em que o cliente e o provedor se encontram. Ao segmentar o canal em vez de uma instância de serviço específica, a estrutura desacopla a intenção do comando do local físico da implementação.

O exemplo a seguir designa o pacote de serviços ClimateControl como um servidor e o pacote de serviços BodyControl como um 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"
  }
}

Em que:

  • server indica que o pacote de serviços é um servidor que fornece algum serviço RPC (identificado por service como SetTemperature).
  • client indica que o pacote de serviços é um cliente que invoca o serviço SetTemperature.
  • channel é o nome do canal RPC. Ele precisa estar em minúsculas com traços e ser exclusivo por serviço.

Este exemplo permite que o pacote de serviços BodyControl faça chamadas de procedimento remotas para o pacote de serviços ClimateControl e defina a temperatura.

A seguir

Depois de definir a arquitetura, gere o código de middleware.