Hændelsesdrevet arkitektur
I en hændelsesdrevet arkitektur udsender komponenter hændelser, som andre komponenter kan reagere på uafhængigt.
En ændring udløser mere arbejde
Hændelsesdrevet arkitektur organiserer samarbejde gennem hændelser: meddelelser om noget, der allerede er sket. Producenter offentliggør dem; interesserede forbrugere behandler dem via en hændelseskanal. I et opdigtet eksempel melder en applikation, at et tilbud er godkendt. Planlægning og rapportering kan reagere med forskellige opgaver.
Producenten behøver ikke kalde hver modtager direkte. Afkoblingen kræver dog klar betydning af hændelser, ansvar og fejlhåndtering. Dubletter, forsinkede beskeder og rækkefølge kan være relevante. En offentliggjort hændelse beviser ikke, at alt efterfølgende arbejde er afsluttet. Ved et enkelt forløb kan et direkte kald give mindre driftsarbejde.
Kilder
Relaterede begreber
- Eventual consistencyEventual consistency tillader midlertidigt forskellige datatilstande, som skal blive ens under de forudsatte betingelser.
- BeskedbrokerEn beskedbroker tager imod beskeder og formidler dem til modtagere efter fastlagte regler.
- Publish-subscribePublish-subscribe fordeler publicerede beskeder til interesserede abonnenter uden direkte kontakt fra afsenderen til hver enkelt.
- Transaktionel inboxEn transaktionel inbox bruger varige meddelelsesregistreringer til at beskytte lokal behandling mod dobbelte leveringer.
- MeddelelseskvitteringEn meddelelseskvittering fortæller brokeren, at en levering er modtaget eller behandlet efter den aftalte regel.
- Jitter ved genforsøgRetry-jitter varierer ventetider tilfældigt for at sprede genforsøg og mindske samtidige forespørgsler fra mange klienter.
Artikler om emnet
Snitflader & integration med ASES
ERP, CRM og webshop forbundet ordentligt