Określanie architektury usługi

Architektura usługi odnosi się do sposobu, w jaki usługi są tworzone i jak komunikują się z innymi komponentami systemu.

Tworzenie pakietów usług

Pakiety usług grupują powiązane jednostki usług, które można wdrażać razem. Jedyną właściwością wymaganą w przypadku pakietu usług jest nazwa. Wraz z nazwą pakietu tworzy pełną i jednoznaczną nazwę pakietu usług.

Pakiety usług są definiowane za pomocą plików Vehicle Services Interface Definition Language (VSIDL) (plików z rozszerzeniem .vsidl).

Poniższy przykład przedstawia 2 pakiety usług: TirePressureMonitoring i BodyControl:

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

service_bundle {
  name: "TirePressureMonitoring"
}

service_bundle {
  name: "BodyControl"
}

Gdzie:

• service_bundle określa strukturę jako pakiet usług.
• name to nazwa pakietu usług.

Wzorce przesyłania wiadomości: Pub/Sub i RPC

Platforma SDV korzysta z 2 głównych wzorców przesyłania wiadomości: publikowanie-subskrypcja (Pub/Sub) i zdalne wywołanie procedury (RPC).

W Pub/Sub system reaguje na zmieniający się stan pojazdu, przesyłając strumieniowo dane do wszystkich zainteresowanych komponentów. Dane są uporządkowane według tematów. Nadawcy wysyłają wiadomości w tematach. Nadawca wysyła wiadomości w tematach bez konieczności wiedzy, którzy (lub ilu) subskrybenci ich słuchają. Subskrybenci otrzymują wiadomości w tematach, nie wiedząc, którzy konkretnie publikujący je wysłali.

Z kolei RPC jest przeznaczony do działania i osiągania wyników. Jest używany, gdy osoba dzwoniąca inicjuje prośbę, ponieważ zależy jej na konkretnym wyniku lub potwierdzeniu tego działania. Wywołujący wywołuje określoną metodę na kanale.

Chociaż te wzorce służą różnym potrzebom operacyjnym, mają wspólną właściwość strukturalną: oba opierają się na nazwanych ścieżkach komunikacji – tematach w przypadku Pub/Sub i kanałach w przypadku RPC – aby oddzielić tożsamość nadawcy od odbiorcy.

Zdefiniuj wydawcę i subskrybenta

Publikowanie i subskrybowanie to wzorzec przesyłania wiadomości, w którym nadawcy wiadomości, zwani wydawcami, nie wysyłają wiadomości bezpośrednio do określonych odbiorców, zwanych subskrybentami. Zamiast tego wydawcy dzielą wiadomości na tematy, a subskrybenci subskrybują jeden lub więcej tematów komunikacji i otrzymują tylko wiadomości opublikowane w tych tematach. Więcej informacji o wzorcu publikowania i subskrybowania znajdziesz w artykule Wzorzec publikowania i subskrybowania.

Dodawanie wydawcy do pakietu usług

Poniższy przykład pokazuje wydawcę dodanego do pakietu usług TirePressureMonitoring:

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

service_bundle {
  name: "TirePressureMonitoring"

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

}

service_bundle {
  name: "BodyControl"

  ...
}

Gdzie:

• publisher Usługa publikuje wiadomości w kolejce wiadomości.
• message Struktura danych lub typ wiadomości zdefiniowany w protokole protobuf (plik z rozszerzeniem .protobuf).
• topic Unikalny identyfikator tematu publikacji. Musi być zapisany małymi literami z łącznikami.
• capacity Liczba wiadomości, które może pomieścić kolejka publikacji. Musi to być liczba parzysta większa lub równa 2.

Dodawanie subskrypcji pakietu usług

Ten przykład pokazuje wydawcę dodanego do pakietu usług 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"
  }
}

Gdzie:

• subscriber Pakiet usług subskrybuje tematy.
• message Struktura danych lub typ wiadomości zdefiniowany w protokole protobuf (plik z rozszerzeniem .protobuf).
• topic Unikalny identyfikator tematu publikacji. Musi być zgodny z tematem wydawcy i zapisany małymi literami z łącznikami.

Definiowanie klientów i serwerów RPC

Zdalne wywołanie procedury (RPC) zapewnia niezależność wywołań funkcji od lokalizacji. W tym wzorcu kanał służy jako nazwany punkt spotkania, w którym klient i dostawca się spotykają. Kierowanie na kanał zamiast na konkretną instancję usługi sprawia, że platforma oddziela intencję polecenia od fizycznej lokalizacji implementacji.

W tym przykładzie pakiet usług CabinComfort hostuje serwer ClimateControl, a pakiet usług BodyControl jest rozszerzony o hostowanie klienta ClimateControl:

package: "com.sdv.cc"

service_bundle {
  name: "CabinComfort"

  server {
    service: "ClimateControl"
    channel: "front-climate-control"
  }
}

service_bundle {
  name: "BodyControl"

  client {
    service: "ClimateControl"
    channel: "front-climate-control"
  }

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

Gdzie:

• server oznacza, że pakiet usług zawiera serwer, który udostępnia pewną usługę RPC (oznaczoną przez service jako ClimateControl).
• client oznacza, że pakiet usług zawiera klienta, który wywołuje usługę ClimateControl.
• channel to nazwa kanału RPC. Musi być zapisana małymi literami z łącznikami i unikalna w przypadku każdej usługi.

Ten przykład umożliwia pakietowi usług BodyControl wykonywanie zdalnych wywołań procedur do pakietu usług CabinComfort w celu sterowania klimatem w przedniej strefie kabiny.

Co dalej?

Po zdefiniowaniu architektury wygeneruj kod oprogramowania pośredniczącego.