Forskel mellem versioner af "Hændelsesdrevet arkitektur"

Fra Den Fælleskommunale Rammearkitektur
Skift til: Navigation, Søgning
 
(3 mellemliggende versioner af den samme bruger vises ikke)
Linje 1: Linje 1:
[[Category:Kort fortalt]][[Category:Integrationsmønstre]]
+
[[Category:Kort fortalt]][[Category:Integrationsmønstre]]{{Status|Status=2}}
{{Status|Status=2}}
+
Hændelsesdrevet arkitektur er oversat fra 'Event Driven Architecture'<ref>[[Wikipedia:Event-driven_architecture]]</ref> og er en måde at integrere Afsender og Modtager på en løst koblet måde, hvorved ændringer i processer eller udskiftning af systemer ikke afføder store integrationsopgaver. Løst koblet arkitektur kan give en fleksibilitet i systemunderstøttelsen af forretningsprocesser som kan have stor betydning for en organisations evne til at indføre effektiviseringer.  
EDA står for 'Event Driven Architecture'<ref>[[Wikipedia:Event-driven_architecture]]</ref> og oversættes til 'hændelsesdrevet arkitektur'.
+
Hændelsesdrevet arkitektur er en måde at integrere Afsender og Modtager på en løst koblet måde, hvorved ændringer i processer eller udskiftning af systemer ikke afføder store integrationsopgaver. Løst koblet arkitektur kan give en fleksibilitet i systemunderstøttelsen af forretningsprocesser som kan have stor betydning for en organisations evne til at indføre effektiviseringer.  
+
  
 
Hændelsesdrevet arkitektur kan let håndtere forandring, idet processer ikke er direkte forbundet til systemer. Derved kan processer foregå ved hjælp af flere systemer og med flere datakilder. Den effektive digitalisering af kommunens processer bygger bl.a. på, at flere forretningsprocesser kan anvende de data som sagsbehandlingen bygger på. Genbrug af data er både vigtigt ifht. kvaliteten af data - så der arbejdes på baggrund af den nyeste udvikling i sagen - og på hastigheden af sagsbehandlingen, så processen ikke unødigt skal vente på at data bliver tilgængelige. Rammearkitekturen kalder dette 'Sager på tværs' og handler om hvordan flere systemer kan samarbejde om at anvende data.
 
Hændelsesdrevet arkitektur kan let håndtere forandring, idet processer ikke er direkte forbundet til systemer. Derved kan processer foregå ved hjælp af flere systemer og med flere datakilder. Den effektive digitalisering af kommunens processer bygger bl.a. på, at flere forretningsprocesser kan anvende de data som sagsbehandlingen bygger på. Genbrug af data er både vigtigt ifht. kvaliteten af data - så der arbejdes på baggrund af den nyeste udvikling i sagen - og på hastigheden af sagsbehandlingen, så processen ikke unødigt skal vente på at data bliver tilgængelige. Rammearkitekturen kalder dette 'Sager på tværs' og handler om hvordan flere systemer kan samarbejde om at anvende data.
 
  
 
===Kort om Hændelsesdrevet arkitektur===
 
===Kort om Hændelsesdrevet arkitektur===
Linje 18: Linje 15:
 
*'''Afsendersystem''' - der afsender beskeder
 
*'''Afsendersystem''' - der afsender beskeder
 
*'''Modtagersystem''' - der abonnerer på beskeder
 
*'''Modtagersystem''' - der abonnerer på beskeder
 
  
 
Man kender beskedfordeling fra mange sociale sammenhænge i dagligdagen hvor mennesker skal koordinere handlinger mest effektivt - der er det sjældent hensigtsmæssigt, at lade en besked vandre fra person til person, men i stedet mere effektivt at fordele en besked til en forsamling, der så hver især behandler informationen eks. kendes mønsteret ved møder, hvor man lytter samlet til beskeder og markerer for tilbagemelding  - men beskedfordelingens styrke ligger også i at beskederne kan understøtte flere samtidige forretningsprocesser som fx. ved et andespil!
 
Man kender beskedfordeling fra mange sociale sammenhænge i dagligdagen hvor mennesker skal koordinere handlinger mest effektivt - der er det sjældent hensigtsmæssigt, at lade en besked vandre fra person til person, men i stedet mere effektivt at fordele en besked til en forsamling, der så hver især behandler informationen eks. kendes mønsteret ved møder, hvor man lytter samlet til beskeder og markerer for tilbagemelding  - men beskedfordelingens styrke ligger også i at beskederne kan understøtte flere samtidige forretningsprocesser som fx. ved et andespil!
  
 
==En historie om andespil som EDA==
 
==En historie om andespil som EDA==
 
 
[[File:Andespil.jpg]]
 
[[File:Andespil.jpg]]
 
  
 
Ved et andespil som det kendes fra forsamlingshuse rundt omkring i det ganske land, finder der beskedfordeling sted i en avanceret hændelsesdrevet arkitektur. Et andespil består som oftest af en '''opråber''', '''numre''', en '''nummerpige''', deltagende '''spillere''', '''bingoplader''', en frossen and og en '''kasserer'''.
 
Ved et andespil som det kendes fra forsamlingshuse rundt omkring i det ganske land, finder der beskedfordeling sted i en avanceret hændelsesdrevet arkitektur. Et andespil består som oftest af en '''opråber''', '''numre''', en '''nummerpige''', deltagende '''spillere''', '''bingoplader''', en frossen and og en '''kasserer'''.
Linje 34: Linje 28:
 
*Nummerpigen ikke ved hvilket nummer, der vil komme op af posen
 
*Nummerpigen ikke ved hvilket nummer, der vil komme op af posen
 
*Spillerne ikke ved om numrene på deres plader går igen på andre plader
 
*Spillerne ikke ved om numrene på deres plader går igen på andre plader
 
  
 
*Spillet går igang når spillerne har fået sine plader og sat sig, og nummerpigen og opråber er klar
 
*Spillet går igang når spillerne har fået sine plader og sat sig, og nummerpigen og opråber er klar
Linje 40: Linje 33:
 
**Nummerpigen er godkendt som Afsender for numre
 
**Nummerpigen er godkendt som Afsender for numre
 
**Opråber er vedtaget som fælles Beskedfordeler
 
**Opråber er vedtaget som fælles Beskedfordeler
 
  
 
*Nummerpigen udtrækker et nummer, som hun afleverer til Opråberen.
 
*Nummerpigen udtrækker et nummer, som hun afleverer til Opråberen.
Linje 46: Linje 38:
 
*Opråberen råber nummeret op til spillerne
 
*Opråberen råber nummeret op til spillerne
 
**Beskedfordeleren distribuerer Beskeden til abonnerende Modtagere
 
**Beskedfordeleren distribuerer Beskeden til abonnerende Modtagere
 
  
 
*Efter nogle omgange bliver Opråberen visket noget i øret af pedellen
 
*Efter nogle omgange bliver Opråberen visket noget i øret af pedellen
Linje 53: Linje 44:
 
**Modtagere med abonnement på ''ulovlig parkering'' (spillere der er i bil) modtager beskeden om at 'Gul Volvo 12345 holder i vejen'
 
**Modtagere med abonnement på ''ulovlig parkering'' (spillere der er i bil) modtager beskeden om at 'Gul Volvo 12345 holder i vejen'
 
**Det relevante modtagersystem (ejeren af Volvo 12345) reagerer på beskeden.
 
**Det relevante modtagersystem (ejeren af Volvo 12345) reagerer på beskeden.
 
  
 
*Ved fjerde trækning bliver tallet '90' udtrukket, en af spillerne råber 'Gamle Ole', opråberen gentager 'ja, det var Gamle Ole' og salen klukker
 
*Ved fjerde trækning bliver tallet '90' udtrukket, en af spillerne råber 'Gamle Ole', opråberen gentager 'ja, det var Gamle Ole' og salen klukker
Linje 59: Linje 49:
 
**Da afsendelse af ''sjove tal'' ikke kræver godkendelse, videreformidler Beskedfordeleren 'Gamle Ole'
 
**Da afsendelse af ''sjove tal'' ikke kræver godkendelse, videreformidler Beskedfordeleren 'Gamle Ole'
 
**Flere i forsamlingen er abonnerer på muntre indslag
 
**Flere i forsamlingen er abonnerer på muntre indslag
 
  
 
*Langt om længe råber en spiller 'Banko' og opråberen beder kassereren godkende pladen.
 
*Langt om længe råber en spiller 'Banko' og opråberen beder kassereren godkende pladen.
Linje 66: Linje 55:
 
**Modtageren ''Kasserer'' er abonnent på beskeder af typen ''Banko'', samt Afsender på beskeden ''vinder fundet''  
 
**Modtageren ''Kasserer'' er abonnent på beskeder af typen ''Banko'', samt Afsender på beskeden ''vinder fundet''  
 
**Da anden skal overleveres direkte, går dette uden om beskedfordeleren, men direkte mellem ''kasserer'' og ''spiller''
 
**Da anden skal overleveres direkte, går dette uden om beskedfordeleren, men direkte mellem ''kasserer'' og ''spiller''
 
  
 
Eksemplet med andespillet viser os, at flere aktører (deltagere og arrangører i et andespil) samarbejder om at anvende data (numre) der kan understøtte flere samtidige processer(andespil, Volvo-flytninger, sjove tal, revision). Det er et stabilt og effektivt mønster som er svært at forestille sig udført ved en system-til-system integration hvorved opråber skulle gå rundt til hver enkelt deltager i andespillet eller hvor deltagerne skulle udveksle hhv. Volvo eller nummeroplysninger.
 
Eksemplet med andespillet viser os, at flere aktører (deltagere og arrangører i et andespil) samarbejder om at anvende data (numre) der kan understøtte flere samtidige processer(andespil, Volvo-flytninger, sjove tal, revision). Det er et stabilt og effektivt mønster som er svært at forestille sig udført ved en system-til-system integration hvorved opråber skulle gå rundt til hver enkelt deltager i andespillet eller hvor deltagerne skulle udveksle hhv. Volvo eller nummeroplysninger.
Linje 73: Linje 61:
  
 
==Referencer==
 
==Referencer==
 
 
<references/>
 
<references/>

Nuværende version fra 9. aug 2019, 12:53

Hændelsesdrevet arkitektur
Status-2.png
V. 8223
Om Status

Hændelsesdrevet arkitektur er oversat fra 'Event Driven Architecture'[1] og er en måde at integrere Afsender og Modtager på en løst koblet måde, hvorved ændringer i processer eller udskiftning af systemer ikke afføder store integrationsopgaver. Løst koblet arkitektur kan give en fleksibilitet i systemunderstøttelsen af forretningsprocesser som kan have stor betydning for en organisations evne til at indføre effektiviseringer.

Hændelsesdrevet arkitektur kan let håndtere forandring, idet processer ikke er direkte forbundet til systemer. Derved kan processer foregå ved hjælp af flere systemer og med flere datakilder. Den effektive digitalisering af kommunens processer bygger bl.a. på, at flere forretningsprocesser kan anvende de data som sagsbehandlingen bygger på. Genbrug af data er både vigtigt ifht. kvaliteten af data - så der arbejdes på baggrund af den nyeste udvikling i sagen - og på hastigheden af sagsbehandlingen, så processen ikke unødigt skal vente på at data bliver tilgængelige. Rammearkitekturen kalder dette 'Sager på tværs' og handler om hvordan flere systemer kan samarbejde om at anvende data.

Kort om Hændelsesdrevet arkitektur

Traditionelt har man lavet system-til-system integration skræddersyet til de systemer som skulle tale sammen, dette har den ulempe, at integrationerne let bliver komplicerede jo flere systemer der skal tale sammen. Desuden kan data der går gennem mange systemers særegne integrationer risikere at ændres undervejs fordi data oversættes på hinanden følgende gange.

Systemer som integrerer i hændelsesdrevet arkitektur betjener sig af 'publish-subscribe' mønstre i.e. at systemer giver besked til omverdenen, samt abonnerer på beskeder. I rammearkitekturen arbejder vi med beskedfordeling, hvor systemer meddeler ændringer i objekters tilstande og andre systemer kan abonnere på disse ændringer.

Beskedfordeling indeholder

  • Beskeder - som indeholder information om ændring af data
  • Beskedfordeler - der modtager beskeder
  • Afsendersystem - der afsender beskeder
  • Modtagersystem - der abonnerer på beskeder

Man kender beskedfordeling fra mange sociale sammenhænge i dagligdagen hvor mennesker skal koordinere handlinger mest effektivt - der er det sjældent hensigtsmæssigt, at lade en besked vandre fra person til person, men i stedet mere effektivt at fordele en besked til en forsamling, der så hver især behandler informationen eks. kendes mønsteret ved møder, hvor man lytter samlet til beskeder og markerer for tilbagemelding - men beskedfordelingens styrke ligger også i at beskederne kan understøtte flere samtidige forretningsprocesser som fx. ved et andespil!

En historie om andespil som EDA

Andespil.jpg

Ved et andespil som det kendes fra forsamlingshuse rundt omkring i det ganske land, finder der beskedfordeling sted i en avanceret hændelsesdrevet arkitektur. Et andespil består som oftest af en opråber, numre, en nummerpige, deltagende spillere, bingoplader, en frossen and og en kasserer.

Konstruktionen omkring et andespil gør, at spillet kan fungere selvom:

  • Opråberen ikke ved hvor mange plader der spilles på
  • Kassereren ved hvor mange plader der spilles på, men ikke hvem som spiller på hvilke plader
  • Nummerpigen ikke ved hvilket nummer, der vil komme op af posen
  • Spillerne ikke ved om numrene på deres plader går igen på andre plader
  • Spillet går igang når spillerne har fået sine plader og sat sig, og nummerpigen og opråber er klar
    • Spillerne er Modtagere, som har opsat sine Abonnementer (pladerne)
    • Nummerpigen er godkendt som Afsender for numre
    • Opråber er vedtaget som fælles Beskedfordeler
  • Nummerpigen udtrækker et nummer, som hun afleverer til Opråberen.
    • Afsenderen Nummerpige afleverer Besked med typen udtrukket nummer til Beskedfordeleren
  • Opråberen råber nummeret op til spillerne
    • Beskedfordeleren distribuerer Beskeden til abonnerende Modtagere
  • Efter nogle omgange bliver Opråberen visket noget i øret af pedellen
  • Opråberen meddeler, at en gul Volvo med registreringsnummer 12345 holder ulovligt parkeret. En person rejser sig undskyldende og forlader salen
    • Afsenderen Pedel afleverer Besked med typen ulovlig parkering til Beskedfordeleren
    • Modtagere med abonnement på ulovlig parkering (spillere der er i bil) modtager beskeden om at 'Gul Volvo 12345 holder i vejen'
    • Det relevante modtagersystem (ejeren af Volvo 12345) reagerer på beskeden.
  • Ved fjerde trækning bliver tallet '90' udtrukket, en af spillerne råber 'Gamle Ole', opråberen gentager 'ja, det var Gamle Ole' og salen klukker
    • Modtageren Ole Hansen er samtidigt Afsender for beskeden med type sjove tal
    • Da afsendelse af sjove tal ikke kræver godkendelse, videreformidler Beskedfordeleren 'Gamle Ole'
    • Flere i forsamlingen er abonnerer på muntre indslag
  • Langt om længe råber en spiller 'Banko' og opråberen beder kassereren godkende pladen.
  • Kasseren siger OK, opråberen meddeler at der er fundet en vinder og kassereren overrækker en and til spilleren.
    • Den vindende spiller er Afsender på beskeden
    • Modtageren Kasserer er abonnent på beskeder af typen Banko, samt Afsender på beskeden vinder fundet
    • Da anden skal overleveres direkte, går dette uden om beskedfordeleren, men direkte mellem kasserer og spiller

Eksemplet med andespillet viser os, at flere aktører (deltagere og arrangører i et andespil) samarbejder om at anvende data (numre) der kan understøtte flere samtidige processer(andespil, Volvo-flytninger, sjove tal, revision). Det er et stabilt og effektivt mønster som er svært at forestille sig udført ved en system-til-system integration hvorved opråber skulle gå rundt til hver enkelt deltager i andespillet eller hvor deltagerne skulle udveksle hhv. Volvo eller nummeroplysninger.

Dertil kommer at andespillet automatisk arbejder med 'distribuerede objekter' - det vil sige, at spillerne er enige om, at de numre der trækkes godt kan være på flere plader.

Referencer

  1. Wikipedia:Event-driven_architecture