Определить архитектуру обслуживания

Архитектура сервисов описывает, как сервисы формируются и как они взаимодействуют с другими компонентами системы.

Создание пакетов услуг

Пакеты услуг объединяют связанные между собой сервисные модули, которые можно развертывать вместе. Единственное обязательное свойство для пакета услуг — это имя. Вместе с именем пакета это имя образует полное квалифицированное имя пакета услуг.

Пакеты сервисов определяются с помощью файлов языка определения интерфейса сервисов транспортных средств (VSIDL) (файлы с расширением .vsidl ).

В следующем примере показаны два пакета услуг: пакет услуг TirePressureMonitoring и пакет услуг BodyControl :

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

service_bundle {
  name: "TirePressureMonitoring"
}

service_bundle {
  name: "BodyControl"
}

Где:

• service_bundle идентифицирует структуру как пакет сервисов.
• name — это название пакета услуг.

Шаблоны обмена сообщениями: Pub/Sub и RPC

В рамках SDV используются два основных шаблона обмена сообщениями: публикация-подписка (Pub/Sub) и удаленный вызов процедур (RPC).

В системе Pub/Sub система реагирует на изменяющееся состояние транспортного средства, передавая данные всем заинтересованным компонентам. Данные организованы в темы. Издатели отправляют сообщения по темам. Издатель отправляет сообщения по темам, не зная, какие (или сколько) подписчики их прослушивают. Подписчики получают сообщения по темам, не зная, какие именно издатели отправили эти сообщения.

В отличие от этого, RPC предназначен для действий и результатов. Он используется, когда вызывающая сторона инициирует запрос, поскольку ей важен конкретный результат или подтверждение этого действия. Вызывающая сторона вызывает определенный метод в канале.

Хотя эти модели удовлетворяют различным операционным потребностям, они обладают общим структурным свойством: обе основаны на именованных коммуникационных путях — темах для модели Pub/Sub и каналах для RPC — для отделения личности отправителя от личности получателя.

Объявить издателя и подписчика

Шаблон «публикация-подписка» — это схема обмена сообщениями, при которой отправители сообщений, называемые издателями , не отправляют сообщения напрямую конкретным получателям, называемым подписчиками . Вместо этого издатели классифицируют сообщения по темам , а подписчики подписываются на одну или несколько тем обмена сообщениями и получают только те сообщения, которые публикуются в этих темах. Для получения дополнительной информации о шаблоне «публикация-подписка» см. раздел «Шаблон публикации-подписки» .

Добавить издателя в пакет услуг

В приведенных ниже примерах показан издатель, добавленный в пакет служб 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 указывает, что пакет служб представляет собой сервер, предоставляющий некоторую службу RPC (идентифицируемую service как SetTemperature ).
• client указывает, что пакет служб представляет собой клиент, который вызывает службу SetTemperature .
• channel — это имя RPC-канала. Оно должно быть написано строчными буквами (с дефисом) и быть уникальным для каждой службы.

В этом примере пакет служб BodyControl может выполнять удалённые вызовы процедур к пакету служб ClimateControl для установки температуры.

Что дальше?

После определения архитектуры сгенерируйте код промежуточного программного обеспечения .