Hendelsesdrevet arkitektur
I hendelsesdrevet arkitektur melder komponenter hendelser som andre komponenter kan reagere på uavhengig.
En endring utløser mer arbeid
Hendelsesdrevet arkitektur organiserer samarbeid gjennom hendelser: meldinger om noe som allerede har skjedd. Produsenter publiserer dem; interesserte konsumenter behandler dem gjennom en hendelseskanal. I et oppdiktet eksempel melder en applikasjon at et tilbud er godkjent. Planlegging og rapportering kan reagere med ulike oppgaver.
Produsenten trenger ikke kalle hver mottaker direkte. Frikoblingen krever likevel tydelig betydning av hendelser, ansvar og feilhåndtering. Doble eller forsinkede meldinger og rekkefølge kan være relevant. En publisert hendelse beviser ikke at alt etterfølgende arbeid er ferdig. For en enkel flyt kan et direkte kall gi mindre driftsarbeid.
Kilder
Beslektede begreper
- Eventual consistencyEventual consistency tillater midlertidig ulike datatilstander som skal bli like under de forutsatte betingelsene.
- MeldingsmeglerEn meldingsmegler tar imot meldinger og formidler dem til mottakere etter fastsatte regler.
- Publiser-abonnerPubliser-abonner fordeler publiserte meldinger til interesserte abonnenter uten at avsenderen kontakter hver enkelt direkte.
- Transaksjonell inboxEn transaksjonell inbox bruker varige meldingsregistreringer for å beskytte lokal behandling mot doble leveringer.
- MeldingskvitteringEn meldingskvittering forteller meldingsmegleren at en levering er mottatt eller behandlet etter den avtalte regelen.
- Jitter ved nye forsøkRetry-jitter varierer ventetider tilfeldig for å spre nye forsøk og redusere samtidige forespørsler fra mange klienter.
Artikler om temaet
API-er og integrasjon med ASES
ERP, CRM og nettbutikk ryddig koblet sammen