Szinkron és aszinkron kommunikáció: kérés–válasz, parancs és esemény

Célok

A lecke végére meg tudod különböztetni a szinkron és az aszinkron együttműködést, a kérés–válasz, a parancs és az esemény modelljét, és meg tudod nevezni a kommunikációs módszerek összehasonlításának hét szempontját.

Miért kell?

A kommunikációs módszerek (REST, azaz Representational State Transfer; üzenetsor, WebSocket, polling…) sokféle szempont szerint különböznek. Ha a szempontokat előre megnevezzük, a módszerek összehasonlíthatók, és a választás nem a divatról szól. Három külön kérdést érdemes mindig szétválasztani: mi az interakció jelentése (kérés, parancs, esemény), milyen szállítás viszi, és milyen időbeli függés van a felek között.

Szinkron és aszinkron

Szinkron együttműködésnél a hívó vár a válaszra, mielőtt tovább lépne. Egyszerű követést ad, de a hívott elérhetősége és késleltetése a hívó útvonalának részévé válik. A várakozás nem feltétlenül blokkol operációsrendszer-szálat: aszinkron I/O mellett is fennmarad a logikai függés, ha az üzleti művelet a válasz nélkül nem folytatható. A nyelvi async tehát nem azonos az aszinkron szolgáltatáskapcsolattal.

Aszinkron együttműködésnél a küldő és a fogadó végrehajtása időben elválik: a küldő nem várja meg az eredményt. Egy közvetítő átveheti az üzenetet akkor is, ha a fogadó éppen nem fut. Ez csökkenti a közvetlen rendelkezésre állási függést, de új állapotok jönnek létre: várakozó, folyamatban levő, feldolgozott és hibás üzenetek. Az átvétel nem azonos a feldolgozással, és a felhasználó felé is látszania kell, ha az eredmény még függő.

Az RFC 9110 202 Accepted státusza ennek HTTP-s kifejezése: a kérés feldolgozásra elfogadva, de a feldolgozás nem fejeződött be, és a válasz „szándékosan nem elkötelezett”; a szerver nem tud később állapotkódot visszaküldeni, ezért a válasz írja le az aktuális állapotot és egy állapotfigyelő helyet.

Kérés–válasz, parancs, esemény

Modell	Jelentés	Címzett	Hibakezelés
Kérés–válasz	A hívó egy művelet eredményét kéri	A hívott	A hívó vár; az eredmény vagy később lekérdezhető állapot
Parancs	Szándék („foglalj le”)	Meghatározott végrehajtó, elutasíthatja	Az eredményt vagy annak helyét ismerni kell
Esemény	Megtörtént tény („lefoglalták”)	Bárki, aki érdeklődik	A fogyasztó saját reakciójáért felel

Egy esemény, amelyet a termelő elvárásként küld, álcázott parancs (4.1). A parancs és az esemény megkülönböztetése a szerződésre is hat.

A hét szempont: hogyan hasonlíthatók össze a módszerek?

A következő fejezetek minden kommunikációs módszernél ugyanazt a hét szempontot nevezik meg:

Szempont	Kérdés
Irány	Egyirányú vagy kétirányú az adatáramlás?
Kezdeményező	Ki indítja az üzenetet: a kliens, a szerver, vagy egy harmadik fél?
Kapcsolat tartóssága	Kérésenként új, vagy tartósan nyitott?
Késleltetés	Mennyi idő telik el a változás és az észlelése között?
Terhelés	Mekkora költség keletkezik üres vagy sűrű forgalomnál?
Hibatűrés	Mi történik megszakadásnál: elveszhet-e az üzenet, ismétlődhet-e?
Mikor jó, mikor nem?	Milyen igényhez illik, és melyikhez nem?

flowchart LR
  subgraph Sync["Szinkron kérés–válasz"]
    R1["REST, RPC, GraphQL (7. fejezet)"]
  end
  subgraph Async["Aszinkron, közvetítővel"]
    Q["Üzenetsor, pub/sub, webhook (8. fejezet)"]
  end
  subgraph Fresh["Frissítés a szerver felől"]
    P["Polling, long polling, SSE, WebRTC (9. fejezet)"]
    W["WebSocket (10. fejezet)"]
  end

A fejezetek sorrendje a kapcsolat természetét követi: először a kérésenként új szinkron stílusok, majd az üzenetközvetítők, utána azok a módszerek, amelyek a szerver felől érkező változásokat juttatják el a klienshez, végül a tartós, kétirányú WebSocket.

Streaming

A stream több adatot továbbít egy logikai folyamatban: lehet szerverről kliensre, kliensről szerverre vagy kétirányú. Egy állapotfigyelő streamben az elemek események lehetnek, egy fájlletöltés streamje bájtsorozat. A streaming nem automatikusan eseményvezérelt üzleti architektúra. Hosszú streamnél kezelni kell a megszakítást, a lassú fogadót és a folytatási pontot (8.4, 10.4).

Gyakori tévhitek

Állítás	Pontosítás
„Az aszinkron kód aszinkron szolgáltatáskapcsolat.”	A logikai függés a válaszra megmaradhat.
„Az aszinkron üzenetnél az elfogadás = végrehajtás.”	Az átvétel és a feldolgozás külön esemény.
„A parancs és az esemény ugyanaz.”	Az egyik szándék, a másik tény.
„A HTTP csak kérés–válasz lehet.”	A HTTP-n eseményfolyam és hosszú műveletek is szállíthatók.

Röviden

• A szinkron felek logikailag várnak; az aszinkron időben elválik, közvetítővel.
• A kérés–válasz eredményt kér, a parancs szándékot, az esemény tényt közöl.
• Az átvétel nem a feldolgozás; az aszinkron működésnek függő állapota van.
• A módszerek hét szempont szerint hasonlíthatók össze: irány, kezdeményező, tartósság, késleltetés, terhelés, hibatűrés, alkalmazhatóság.

Ellenőrző kérdések

1. Miért nem elég az async kulcsszó az aszinkron együttműködéshez?
2. Mi a különbség a parancs és az esemény között?
3. Melyik hét szempont szerint érdemes összehasonlítani a kommunikációs módszereket?

Források

• RFC 9110, 15.3.3: 202 Accepted — az elfogadott, de be nem fejezett feldolgozás HTTP-s kifejezése.
• What do you mean by “Event-Driven”? (Martin Fowler) — esemény és parancs, álcázott parancsok.