Event-driven Architecture eli tapahtumapohjainen arkkitehtuuri (EDA) on konsepti, jonka kantavana ajatuksena on käyttää asynkronista tapahtumien välitystä organisaation tietojärjestelmien viestintämekanismina. Samalla EDA ohjaa arkkitehtuuria yleisesti kohti erittäin löyhiä kytkentöjä järjestelmien välillä ja mahdollistaa siten entistä skaalautuvamman ja tehokkaamman toiminnan. Tapahtuma on käsitteenä sinänsä abstrakti, mutta sen rakenteen määrittelyyn voidaan esittää selkeät käytännöt, joita käyttämällä tapahtumat ovat aidosti liiketoimintalähtöisiä ja hyödynnettävissä kaikissa järjestelmissä, jotka ovat niistä kiinnostuneita. Tapahtumapohjaisuus voidaan myös liittää toiseen tärkeään trendiin; palvelupohjaisuuteen eli SOA:aan. EDA ja SOA täydentävät toisiaan kahdella tavalla. SOA-palvelu voi toimia tapahtumien lähteenä, ja toisaalta SOA-palveluita tai -liiketoimintaprosesseja voidaan käynnistää tapahtumien perusteella. EDA tuo palvelupohjaisiin järjestelmiin entistä löyhempää kytkentää, suorituskykyä ja mahdollisuuden tapahtumien reaaliaikaiseen, joustavaan käsittelyyn.

1. eli EDA eli ”tapahtumapohjainen arkkitehtuuri” Eetu Blomqvist – eetu.blomqvist@gofore.com Event-driven architecture 20.6.2011 Eetu Blomqvist

2. Kiinnostava asia, joka tapahtuu organisaation sisällä tai ulkopuolella Tulisi olla liiketoimintalähtöinen, jotta kaikki siitä kiinnostuneet osaavat tulkita sen Koostuu kahdesta osasta: otsakeja runko Otsakesisältää tietyn tapahtuman yksilöiviä tietoja, kuten id, tyyppi, nimi, aikaleima, luojan tunniste jne. Rungonsisältö kuvaa, mitä oikeastaan tapahtui Sisällön rakenne olisi hyvä määritellä esimerkiksi formaalin ontologian avulla Sisällön pitää olla riittävän informaatiivinen, jotta kiinnostuneen tahon ei tarvitse hakea lisätietoa tapahtuman lähteeltä Event eli tapahtuma 20.6.2011 Eetu Blomqvist

3. Kiinnostavien tapahtumien välittäminen niistä kiinnostuneille tahoille Vastaanotettujen tapahtumien tulkitseminen ja toiminta niiden perusteella Toimintaa voivat olla mm. palvelukutsut, prosessipalveluiden käynnistys, sähköpostin lähetystai uusien tapahtumien luominen Erittäin hajautettujen komponenttien äärimmäisen löyhä kytkentä - tapahtuman aiheuttajalla ei ole mitään tietoa siitä, keitä tapahtuma kiinnostaa tai miten sitä prosessoidaan Tapahtumien jäljitettävyys monimutkaisessa käsittelyketjussa haastavaa  sopii parhaiten asynkroniseen järjestelmään Tapahtumapohjaisuus 20.6.2011 Eetu Blomqvist

4. EDA ja SOA Täydentävät toisiaan – eivät kilpaile keskenään Event-driven SOA: tapahtuma laukaisee SOA-palveluiden kutsuja. Palvelut voivat olla myös kokonaisia liiketoimintaprosesseja. Service as Event Generator: palvelu tuottaa tapahtuman, joka voi indikoida vaikkapa ongelmaa, määriteltyä kynnystä tai onnistunutta operaatiota. SOA-palvelut siis toimivat tapahtumien lähteenä. EDA mahdollistaa reaaliaikaisen tiedonvälityksen ja analyysin sekä tapahtumien monimutkaisen prosessoinnin – SOA ei ainakaan yhtä hyvin ja helposti 20.6.2011 Eetu Blomqvist

5. Käsittelytavat voidaan jakaa karkeasti kolmeen Yksinkertainen käsittely Kiinnostavien tapahtumien tapahtumien välittäminen kiinnostuneille Nopeaa ja kustannustehokasta Tapahtumavirran käsittely Sekä huomattavien (notable) että tavallisten (ordinary) tapahtumien käsittelyä Tavallinen tapahtuma (esim. RFID-signaali) voidaan muokata kiinnostavaksi (esim. ”kallis tuote lähti varastosta”) Tapahtumien välitys Monimutkainen käsittely Välittämisen lisäksi tapahtumia tulkitaan säännöstön mukaan Seurauksena voidaan mm. luoda uusia tapahtumia Tapahtumien välinen korrelaatio Kompleksisuuden takia kaupalliset ohjelmistot ovat käytännössä aina tarpeen Tapahtumien käsittely 20.6.2011 Eetu Blomqvist

6. Tapahtumageneraattorit Luovat tapahtumat Voivat suodattaaja muuntaa ”tavallisia” tapahtuvia kiinnostaviksi Tapahtumaväylä Välittää standardiformaattiin muunnetut tapahtumat prosessointikomponenteille Standardiformaatti on joustava käsite, voi olla mm. organisaation sisäinen standardi Tapahtumien prosessointi Tapahtumien käsittely ja niiden välitys (julkaisu)kiinnostuneille (= niihin perustuvan toiminnan käynnistäminen) Mahdolliset käsittelysäännöt voivat olla monimutkaisia Palvelukutsut, sähköpostit, uudet tapahtumat, tapahtuman taltiointijne. Tapahtumaan perustuva toiminta Tapahtumasta kiinnostuneet tahot toimivat (esim. palvelun sisäinen toteutus) Varsinainen tapahtumaan reagointi EDA-järjestelmän eri osat 20.6.2011 Eetu Blomqvist

7. Esimerkki yksinkertaisesta tapahtumakäsittelystä 20.6.2011 Eetu Blomqvist Lähde Brenda M. Michelson, Elemental Links http://dl.dropbox.com/u/20315902/EventDrivenArchitectureOverview_ElementalLinks_Feb2011.pdf

8. Esimerkki yksinkertaisesta tapahtumakäsittelystä(2) Asiakas tilaa kirjan  myyjä varaa sen varastosta Varastopalvelu tekee varauksen ja tarkistaa sen jälkeen, onko varastossa vielä riittävästi kyseisen kirjan kappaleita Jos vapaiden kappaleiden määrä alittaa määritellyn kynnyksen, varastopalvelu luo uuden tapahtuman ”Low Inventory Threshold” (Event Q) Tapahtuma siirretään välityskanavaan, josta prosessori poimii sen Prosessorilla on tapahtumalle 2 käsittelysääntöä Se käynnistää uudelleentilausprosessin (voi olla manuaalinen, tietotekninen tai jotain siltä väliltä) Tapahtuma julkaistaan edelleen siitä kiinnostuneille Kiinnostuneita ovat varastoonostaja sekä varaston päällikön hallintasovellus 20.6.2011 Eetu Blomqvist

9. Esimerkki tapahtumavirran käsittelystä 20.6.2011 Eetu Blomqvist Lähde Brenda M. Michelson, Elemental Links http://dl.dropbox.com/u/20315902/EventDrivenArchitectureOverview_ElementalLinks_Feb2011.pdf

10. Esimerkki tapahtumavirran käsittelystä(2) Sisältää kolme tapahtumavuota 1. (alkaa vasemmasta yläkulmasta) RFID-sensori luo tapahtuman (Event A) aina, kun tuote lähtee varastosta. Elektroniikkamyynti haluaa tietää, koska varastosta lähtee ”high-end”-tuotteita. Kyseisten tuotteiden huomaamiseksi RFID-tapahtumista suodatetaan alle 4000 dollarin tuotteet pois Jäljelle jää 5000 dollarin plasma-TV, josta muodostetaan transformaation avulla organisaation standardimuotoinen tapahtuma joka siirretään tapahtumaväylään Prosessori toimii käsittelysääntöjen mukaisesti Tapahtuma julkaistaan edelleen Tapahtumasta on kiinnostunut varastopäällikön valvontasovellus 2. ja 3. (alkavat vasemmasta alakulmasta) Tilausten syöttämissovellus luo ”tavallisen” tapahtuman (Event B) aina, kun siihen syötetään tilaus Tavalliset tilaustapahtumat välitetään tietovarastoon käsittelijän ja sen julkaisutoiminnon avulla Lisäksi yli 1500 dollarin tilauksien yhteydessä tilauksen tehneen asiakkaan luokitus halutaan nostaa seuraavaan luokkaan 20.6.2011 Eetu Blomqvist

11. Esimerkki tapahtumavirran käsittelystä(3) Tarkoitukseen käytetään erillistä reititintä, koska tapahtumien reititys ja jakelu ei saa olla tapahtumalähteen vastuulla Lähteen ainoa velvollisuus on kertoa, että jotain tapahtui Reititin tulkitsee jokaisen tilauksen kokonaissumman ja luo uuden ”huomattavan” tapahtuman (Event C), kun 1500 dollaria ylittyy Myös tämä tapahtuma siirretään tapahtumaväylään Prosessori välittää tapahtuman käsittelysääntöjen mukaisesti SOA-palvelulle, joka sisältää logiikan asiakasluokituksen nostamiseksi Esimerkki Event-driven SOA:sta! 20.6.2011 Eetu Blomqvist

12. Esimerkki monimutkaisesta käsittelystä 20.6.2011 Eetu Blomqvist Lähde Brenda M. Michelson, Elemental Links http://dl.dropbox.com/u/20315902/EventDrivenArchitectureOverview_ElementalLinks_Feb2011.pdf

13. Esimerkki monimutkaisesta käsittelystä(2) Sisältää 3 tapahtumavuota 1. (alkaa vasemmasta yläkulmasta) B2B-integraatioväylän pitäisi välittää tapahtumaväylään 15 minuutin välein tapahtuma (Event W), joka ilmaisee mm. IT-tuelle, että väylä toimii Tapahtuman puuttuminen tarkoittaa virhettä Prosessorilla on tiedossaan viimeisimmän tapahtuman aikaleima Jos aikaleimasta on yli 15 minuuttia, prosessi toimii säännöstön mukaan Ylläpitäjää hälytetään hakulaitteella Virheestä luodaan uusi tapahtuma (Event E) ja se siirretään tapahtumaväylään Uusi tapahtuma julkaistaan, jolloin siitä kiinnostunut organisaation vikojenhallintajärjestelmä saa tiedon ongelmasta 2. ja 3. (alkavat vasemmalta keskeltä) Esittävät väärinkäytöksiä estäviä mekanismejä Myyntipistesovellus luo tapahtuman jokaista myyntipisteessä tehtyä ostosta kohden (Event Y) Reititin evaluoi yli 1500 dollarin ostot, joista luodaan uusia tapahtumia (Event Z) Kaikki tapahtumat siirretään tapahtumaväylään 20.6.2011 Eetu Blomqvist

14. Esimerkki monimutkaisesta käsittelystä(3) 1. tarkastusmekanismi Prosessori etsii kaikki samalla luottokortilla lyhyen ajan (10 min) sisään tehdyt transaktiot (Event Y), jotka ovat syntyneet eri paikoissa laajalla alueella (20 mailia). Jos transaktioita löytyy tehdään kutsu palvelulle, joka käsittelee väärinkäytösepäilyn alaisia asiakastietoja 2. tarkastusmekanismi Prosessori käy läpi asiakkaan ostohistoriaa, kun se vastaanottaa tapahtuman yli 1500 dollarin ostoksesta Jos oston kokonaissumma on 50% suurempi kuin yhdenkään asiakkaan aikaisemman ostoksen kokonaissumma, tapahtuma julkaistaan edelleen ”epäilyttävänä” Asiakaspalvelutiimi vastaanottaa tapahtuman ja käynnistää tiedustelun asiakkaan suuntaan soittamalla kortin omistajalle 20.6.2011 Eetu Blomqvist

15. EDA:n toteutuksen komponentit Tapahtumien metadata Tapahtumamäärittelyt Tapahtumien käsittelysäännöt Tapahtumien prosessointi Yksinkertaiset prosessorit ovat usein itse toteutettuja ohjelmistokomponentteja Monimutkaisemmat ovat kaupallisia (toimittajia mm. Oracle, IBM) Kehitys- ja seurantatyökalut Metadatan tuottaminen helposti Ylläpito ja seuranta tapahtumien käsittelylle, tapahtumien kulun seuranta, statistiikat jne. Integraatio organisaation tietojärjestelmiin Tapahtumien esikäsittely (suodatus, reititys, transformaatiot) Palvelukutsut ja liiketoimintaprosessien käynnistäminen Tapahtumien julkistaminen ja tilaaminen Palveluväylä tarjoaa useita yllä mainituista palveluista... Ja tietenkin tapahtumien lähteet ja kohteet Organisaation sisäiset tai ulkoiset ohjelmistot, palvelut, prosessit, tietovarastot, ihmiset ja niin edelleen 20.6.2011 Eetu Blomqvist

16. Kiitos mielenkiinnosta!