Zasíláte aktuální stav nově připojeným aplikacím automaticky?

U publish – subscribe modelu komunikace, kde jsou využívány topiky, tak v případě, že subscriber není přítomen, tak znova již data aplikace nedostanou.

Poslání posledního stavu nově připojené aplikaci je velice užitečné, protože nově připojená aplikace nemusí čekat na změnu a dozví se stav systému hned po připojení.

V tomto videu se podíváme na to, jak se to řeší u technologie DDS®.

Tato funkčnost je tak používaná, že jí implementují i další technologie.

Například MQTT to řeší označením zprávy, že je určena k znovuposlání novým aplikacím (retained flag). Jedná se o jednu zprávu a určuje se na úrovni topiku.

Technologie Apache Kafka®, šla ještě dál, ta si pamatuje všechny zprávy pro daný topik po stanovenou dobu. Consumenti si pak vyčtou co potřebují, klidně poslední uloženou zprávu daného topiku.

V kterých případech se toho dá využít?
Když potřebuji mít informaci o posledním stavu, když jsou data zasílána nepravidelně, nebo konfiguraci zařízení.
Když potřebuji získat data i v případě, kdy jsem byl nedostupný.

Jsem tak schopen dosáhnout volné vazby v čase (time decoupling), protože příjemce dat nemusí být spuštěn v čase, kdy jsou data zapisována. Proto ale potřebuji data někde ukládat.

V případě MQTT a Apache Kafky je to na brokeru, ale v případě DDS, kdy žádný broker není je to prováděno nastavením QoS parametrů následovně.

Použitím DURABILITY QoS, která určuje životnost vzorků jednotlivých instancí v rámci daného topicu pro aplikace, které se připojí později.

Tento parametr lze nastavit tak, že data označíme jako:
Volatile: Data nejsou uchovávána
Transient Local: Data jsou uchovávána po tu dobu co existuje poskytovatel dat, který je zasílá v případě, kdy se připojí nový příjemce dat.
Transient: Data jsou uchovávána pomocí další služby (durability/persistance service), která se o zaslání postará, i když vypneme poskytovatele dat.
 Persistent: Data jsou uchovávána pomocí další služby, která se o zaslání postará, ale s využitím databáze, když vypneme restartujeme vše (i když vypneme persistance servcie).

Kolik je toho ukládáno a znovu zasíláno je určeno QoS parameterem HISTORY.

Pomocí QoS parametru DURABILITY a HISTORY jsme tak schopni ovlivnit dostupnost dat. Tedy zdali nově připojená aplikace obdrží data, která již byla zaslána a kolik.

Jestli vás technologie DDS zajímá, tak si stáhněte myšlenkovou mapu o DDS ze stránky www.pavelpohanka.cz/dds, kde se dozvíte zdali je technologie vhodná pro váš systém nebo ne.