Co tvoří DDS aplikaci a doporučení pro implementaci

Třeba už jste se dostali do fáze, kdy chcete začít vytvářet DDS aplikace.

Než se do toho pustíte, je dobré pochopit z čeho se DDS aplikace skládá a jaké zásady je dobré dodržovat. To se dozvíte v tomto videu🎞️👇.

To co obsahuje DDS aplikace je popsáno ve standardu DDS – DCPS (Data-Centric Publish- Subscribe). Ten definuje standardizovaná rozhraní a chování DDS aplikací, aby mezi sebou mohli komunikovat.

Při programování DDS aplikace budete pracovat s následujícími entitami.

1️⃣ Domain Participant
2️⃣ Topic
3️⃣ Publisher
4️⃣ Subscriber
5️⃣ Data Writer
6️⃣ Data Reader

Toto vše jsou entity protože to jsou potomci třídy Entity. Ke každé entitě je možné přiřadit
👉 QoS parametry (určité)
👉 Rozhraní pro příjem notifikací o změnách stavů.

Jak jsou tyto entity provázány?

➡️ Domain Participant: Domain Participant je hlavní entitou která zastupuje vaší DDS aplikaci v rámci konkrétního datového prostoru, v kterém DDS aplikace komunikují. Tento prostor je identifikován číslem a říká se mu doména. V systému může být více domén, ale aplikace může komunikovat s těmi aplikacemi, které jsou ve stejné doméně.

➡️ Topic: Aplikace v doméně mezi sebou komunikují pomocí topiků. Topik si představte jako datový stream (tok dat), který má v rámci domény unikátní jméno, má přiřazen datový typ, který přenáší a parametry QoS, které určují jakým způsobem budou data přenesena. Data jsou zasílána mezi poskytovateli a příjemci dat.

➡️ Publisher: Abychom byli schopni poskytovat data do domény, je nutné vytvořit Publishera. Ten využívá pro zápis dat jednoho nebo více Data Writerů, které publisher vytváří. Pomocí DataWritera ✏️ zapisuje aplikace data do konkrétních topiků.

➡️ Subscriber: Abychom byli schopni přijímat data z domény, je nutné vytvořit Subscribera. Ten využívá pro čtení dat jednoho nebo více Data Readerů📘, které subscriber vytváří. Po příchodu dat, notifikuje Subscriber konkrétního Data Readera s daným topikem, který předá data aplikaci.

Pro shrnutí:

👉 Vytvoření topiků, publisheru a subscriberů má na starosti domain participant.

👉 Publisher pak vytváří a spravuje DataWritery, Subscriber vytváří a spravuje DataReadery.

👉 DataWriter a DataReader je spojen s topikem.

👉 Každé entitě lze přiřadit QoS Parametry. Ale ne všechny všem. K topikům to může být například, zdali se mají zasílat spolehlivě (tuto informaci pak využije příslušný DataWriter a DataReader). U Publisherů a Subscriberů to může být například určení dalšího logického členění pro zasílání dat (Partitions) – to si lze představit jako chatovací místnosti.

Zásady pro tvorbu těchto entit jsou následující:

❕ Vytvořte v aplikaci pouze jednoho participanta pro každou doménu. Je to z toho důvodu, že každý participant využívá hodně zdrojů (vlákna, paměť, procesor, síťové prostředky).

❕ To stejné platí i pro Publishery a Subscribery. Je zbytečné vytvářet více instancí i když to lze.

❕ Dále je vhodné konfigurovat chování entit pomocí externí konfigurace, aby nebylo nutné kvůli jednoduchým změnám překompilovávat aplikace (například, když chci v systému rychleji detekovat odpojené aplikace).

PP
Author: PP

Podobné příspěvky

Napsat komentář

Vaše e-mailová adresa nebude zveřejněna. Vyžadované informace jsou označeny *