3 typy interakcí v distribuovaných systémech – příkaz, dotaz, událost
V distribuovaných systémech lze všechny interakce kategorizovat do tří typů.
1️⃣ Příkazy
2️⃣ Dotazy
3️⃣ Události
Tento příspěvek popisuje, jaký je rozdíl mezi těmito typy a jak souvisí s DDS®.
Hlavní rozdíl mezi dotazy, příkazy a událostmi spočívá v záměru, ke kterému jsou použity.
1️⃣ Záměr příkazů: změnit stav (data) systému (obvykle je použit model komunikace request-reply), lze je odmítnout.
2️⃣ Záměr dotazů: načíst vnitřní stav (data) (použita komunikace request-reply). Dotaz je žádost o informace od jiné služby na vyžádání.
3️⃣ Záměr události: popisuje skutečnost, která se stala v minulosti (obvykle je použit model komunikace publish-subscribe). Mohou přenášet data a neočekávají žádnou odezvu.
Události můžeme rozlišit do dvou typů;
👉 Události jako oznámení (notifications): Neobsahují mnoho dat. Události se používají jako upozornění, která mají ostatním sdělit, že se něco stalo. Ale nepřenášejí stav. Pokud byste chtěli znát stav, musíte se zeptat. Např. Teplota je nad prahovou hodnotou.
👉 Události přenášející stav (Event Carried State Transfer):
V tomto případě se událost používá pro přenos stavu. To znamená, že publikujete události o změnách stavu a ostatní aplikace si mohou uchovávat kopii stavu (data) ve vlastní mezipaměti. Na stav (dodatečné informace) se ptát nemusíte. Ale na druhou stranu je možné, že tímto způsobem budete odesílat i nadbytečné informace. Např. Všechny informace o diagnostice zařízení.
Tyto rozdíly mezi příkazy, dotazy a událostmi vedou ke dvěma různým systémovým architekturám. K architektuře řízené dotazy/příkazy nebo architektuře řízené událostmi.
👉 V systému řízeném dotazy/příkazy:
V rámci této architektury se dotazujeme na informace, nebo zasíláme příkazy ostatním, kterým určujeme, co mají dělat, a čekáte na nějakou odpověď – to vede k pevnému propojení mezi jednotlivými aplikacemi a ve velkém systému může vést k problémům s dostupností, protože selhání jedné části může způsobit selhání celého systému. A v takto pevně provázaném systému je obtížnější provádět změny. Např. Ty „Brzdný systéme“! Zastav auto.
👉 V systémech řízených událostmi říkáte ostatním, co jste udělali, nebo žádáte o změnu stavu a ostatní určují, co udělají. Nemusíte čekat na žádnou odpověď. Např. Potřebuji zastavit auto (je mi jedno, kdo to skutečně provede).
Když mluvíme o systémech řízených událostmi, můžeme se na jejich data dívat jako na data v pohybu (Data in Motion). V systémech, které používají dotazy, se naopak můžeme na jejich data dívat jako na data v klidu (Data at Rest) – protože data jsou někde uložena a lze se na ně dotazovat.
Technologie DDS 🌀 je technologie řízená událostmi, kde jsou data v pohybu. Neumožňuje přímo dotazovat se na informace od ostatních, jak to můžete udělat s daty v klidu.
Možná vás teď zajímá, jak získáte správné informace pomocí technologie DDS🌀, která využívá data v pohybu a neumožňuje dotazovat se na data?
Odpověď je pomocí filtrování. Z toku dat odfiltrujete správné informace, které potřebujete.
1️⃣To lze provést prostřednictvím Topiků,
2️⃣poté přiřazením Topiků do logických skupin (Partitions)
3️⃣v rámci Topiků filtrováním datového obsahu pomocí výrazů podobných SQL (filtry založené na obsahu).
Co ale dělat, když potřebujete ve svém systému použít model komunikace podobný dotazům a příkazům?
Můžete použít návrhový vzor Objective/State (podobný návrhovému vzoru Observer).
👉Aplikace, která chce nějakou změnu v systému, odešle do systému požadavek, někdo v systému dostane tento požadavek a provede změnu stavu systému, poté odešle událost s cílovým stavem (nový stav) jako reakci, takže žadatel dostane informaci, že došlo ke změně stavu. Pokud se stane něco špatného, odešle se chybová událost.
Jsme tak schopni asynchronně řešit situace jako:
- Jak si můžeme asynchronně vyžádat změnu v systému?
- Jak se žadatel dozví, že někdo na požadavek reagoval?
- Jak může žadatel získat výsledek jeho požadavku?
Je dobré si uvědomit, že systémové architektury obvykle kombinují obě architektury
1️⃣ systémy řízené dotazy/příkazy
2️⃣ systémy řízené událostmi
Je to z toho důvodu, protože systémy využívají jak data v pohybu, tak data v klidu.
Takže to byly tři typy interakcí v distribuovaných systémech a jejich vztah k DDS.
