Hændelsesdrevet arkitektur

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.

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

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

Andespillet

• 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 hvisket 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.