Händelsestyrd arkitektur
I händelsestyrd arkitektur rapporterar komponenter händelser som andra komponenter kan reagera på oberoende.
En ändring utlöser mer arbete
Händelsestyrd arkitektur organiserar samarbete genom händelser: meddelanden om något som redan har inträffat. Producenter publicerar dem; intresserade konsumenter bearbetar dem genom en händelsekanal. I ett påhittat exempel meddelar en applikation att en offert har godkänts. Planering och rapportering kan reagera med olika uppgifter.
Producenten behöver inte anropa varje mottagare direkt. Frikopplingen kräver dock tydlig händelsebetydelse, ansvar och felhantering. Dubbla eller försenade meddelanden och ordning kan spela roll. En publicerad händelse bevisar inte att allt efterföljande arbete är klart. För ett enkelt flöde kan ett direkt anrop innebära mindre driftarbete.
Källor
Relaterade begrepp
- Eventual consistencyEventual consistency tillåter tillfälligt olika datatillstånd som ska bli samstämmiga under de avsedda förutsättningarna.
- MeddelandeförmedlareEn meddelandeförmedlare tar emot meddelanden och skickar dem vidare till mottagare enligt fastställda regler.
- Publicera-prenumereraPublicera-prenumerera fördelar publicerade meddelanden till intresserade prenumeranter utan direktkontakt från avsändaren till var och en.
- Transaktionell inboxEn transaktionell inbox använder beständiga meddelandeposter för att skydda lokal behandling mot dubbla leveranser.
- MeddelandekvittensEn meddelandekvittens talar om för brokern att en leverans har tagits emot eller behandlats enligt den överenskomna regeln.
- Jitter vid återförsökRetry-jitter varierar väntetider slumpmässigt för att sprida återförsök och minska samtidiga anrop från många klienter.
Artiklar om ämnet
API:er & integration med ASES
ERP, CRM och webbutik smidigt sammankopplade