Event-driven Architecture eli tapahtumapohjainen arkkitehtuuri

1,165
-1

Published on

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.

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
1,165
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
0
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Event-driven Architecture eli tapahtumapohjainen arkkitehtuuri

  1. 1. eli EDA eli ”tapahtumapohjainen arkkitehtuuri”<br />Eetu Blomqvist – eetu.blomqvist@gofore.com<br />Event-driven architecture<br />20.6.2011<br />Eetu Blomqvist<br />
  2. 2. Kiinnostava asia, joka tapahtuu organisaation sisällä tai ulkopuolella<br />Tulisi olla liiketoimintalähtöinen, jotta kaikki siitä kiinnostuneet osaavat tulkita sen<br />Koostuu kahdesta osasta: otsakeja runko<br />Otsakesisältää tietyn tapahtuman yksilöiviä tietoja, kuten id, tyyppi, nimi, aikaleima, luojan tunniste jne.<br />Rungonsisältö kuvaa, mitä oikeastaan tapahtui<br />Sisällön rakenne olisi hyvä määritellä esimerkiksi formaalin ontologian avulla<br />Sisällön pitää olla riittävän informaatiivinen, jotta kiinnostuneen tahon ei tarvitse hakea lisätietoa tapahtuman lähteeltä<br />Event eli tapahtuma<br />20.6.2011<br />Eetu Blomqvist<br />
  3. 3. Kiinnostavien tapahtumien välittäminen niistä kiinnostuneille tahoille<br />Vastaanotettujen tapahtumien tulkitseminen ja toiminta niiden perusteella<br />Toimintaa voivat olla mm. palvelukutsut, prosessipalveluiden käynnistys, sähköpostin lähetystai uusien tapahtumien luominen<br />Erittäin hajautettujen komponenttien äärimmäisen löyhä kytkentä - tapahtuman aiheuttajalla ei ole mitään tietoa siitä, keitä tapahtuma kiinnostaa tai miten sitä prosessoidaan<br />Tapahtumien jäljitettävyys monimutkaisessa käsittelyketjussa haastavaa  sopii parhaiten asynkroniseen järjestelmään<br />Tapahtumapohjaisuus<br />20.6.2011<br />Eetu Blomqvist<br />
  4. 4. EDA ja SOA<br />Täydentävät toisiaan – eivät kilpaile keskenään<br />Event-driven SOA: tapahtuma laukaisee SOA-palveluiden kutsuja. Palvelut voivat olla myös kokonaisia liiketoimintaprosesseja.<br />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ä.<br />EDA mahdollistaa reaaliaikaisen tiedonvälityksen ja analyysin sekä tapahtumien monimutkaisen prosessoinnin – SOA ei ainakaan yhtä hyvin ja helposti<br />20.6.2011<br />Eetu Blomqvist<br />
  5. 5. Käsittelytavat voidaan jakaa karkeasti kolmeen<br />Yksinkertainen käsittely<br />Kiinnostavien tapahtumien tapahtumien välittäminen kiinnostuneille<br />Nopeaa ja kustannustehokasta<br />Tapahtumavirran käsittely<br />Sekä huomattavien (notable) että tavallisten (ordinary) tapahtumien käsittelyä<br />Tavallinen tapahtuma (esim. RFID-signaali) voidaan muokata kiinnostavaksi (esim. ”kallis tuote lähti varastosta”)<br />Tapahtumien välitys<br />Monimutkainen käsittely<br />Välittämisen lisäksi tapahtumia tulkitaan säännöstön mukaan <br />Seurauksena voidaan mm. luoda uusia tapahtumia<br />Tapahtumien välinen korrelaatio<br />Kompleksisuuden takia kaupalliset ohjelmistot ovat käytännössä aina tarpeen<br />Tapahtumien käsittely<br />20.6.2011<br />Eetu Blomqvist<br />
  6. 6. Tapahtumageneraattorit<br />Luovat tapahtumat<br />Voivat suodattaaja muuntaa ”tavallisia” tapahtuvia kiinnostaviksi<br />Tapahtumaväylä<br />Välittää standardiformaattiin muunnetut tapahtumat prosessointikomponenteille<br />Standardiformaatti on joustava käsite, voi olla mm. organisaation sisäinen standardi<br />Tapahtumien prosessointi<br />Tapahtumien käsittely ja niiden välitys (julkaisu)kiinnostuneille (= niihin perustuvan toiminnan käynnistäminen)<br />Mahdolliset käsittelysäännöt voivat olla monimutkaisia<br />Palvelukutsut, sähköpostit, uudet tapahtumat, tapahtuman taltiointijne.<br />Tapahtumaan perustuva toiminta<br />Tapahtumasta kiinnostuneet tahot toimivat (esim. palvelun sisäinen toteutus)<br />Varsinainen tapahtumaan reagointi<br />EDA-järjestelmän eri osat<br />20.6.2011<br />Eetu Blomqvist<br />
  7. 7. Esimerkki yksinkertaisesta tapahtumakäsittelystä<br />20.6.2011<br />Eetu Blomqvist<br />Lähde Brenda M. Michelson, Elemental Links<br />http://dl.dropbox.com/u/20315902/EventDrivenArchitectureOverview_ElementalLinks_Feb2011.pdf<br />
  8. 8. Esimerkki yksinkertaisesta tapahtumakäsittelystä(2)<br />Asiakas tilaa kirjan  myyjä varaa sen varastosta <br />Varastopalvelu tekee varauksen ja tarkistaa sen jälkeen, onko varastossa vielä riittävästi kyseisen kirjan kappaleita<br />Jos vapaiden kappaleiden määrä alittaa määritellyn kynnyksen, varastopalvelu luo uuden tapahtuman ”Low Inventory Threshold” (Event Q)<br />Tapahtuma siirretään välityskanavaan, josta prosessori poimii sen<br />Prosessorilla on tapahtumalle 2 käsittelysääntöä<br />Se käynnistää uudelleentilausprosessin (voi olla manuaalinen, tietotekninen tai jotain siltä väliltä)<br />Tapahtuma julkaistaan edelleen siitä kiinnostuneille<br />Kiinnostuneita ovat varastoonostaja sekä varaston päällikön hallintasovellus<br />20.6.2011<br />Eetu Blomqvist<br />
  9. 9. Esimerkki tapahtumavirran käsittelystä<br />20.6.2011<br />Eetu Blomqvist<br />Lähde Brenda M. Michelson, Elemental Links<br />http://dl.dropbox.com/u/20315902/EventDrivenArchitectureOverview_ElementalLinks_Feb2011.pdf<br />
  10. 10. Esimerkki tapahtumavirran käsittelystä(2)<br />Sisältää kolme tapahtumavuota<br />1. (alkaa vasemmasta yläkulmasta) <br />RFID-sensori luo tapahtuman (Event A) aina, kun tuote lähtee varastosta. Elektroniikkamyynti haluaa tietää, koska varastosta lähtee ”high-end”-tuotteita.<br />Kyseisten tuotteiden huomaamiseksi RFID-tapahtumista suodatetaan alle 4000 dollarin tuotteet pois<br />Jäljelle jää 5000 dollarin plasma-TV, josta muodostetaan transformaation avulla organisaation standardimuotoinen tapahtuma joka siirretään tapahtumaväylään<br />Prosessori toimii käsittelysääntöjen mukaisesti <br />Tapahtuma julkaistaan edelleen<br />Tapahtumasta on kiinnostunut varastopäällikön valvontasovellus<br />2. ja 3. (alkavat vasemmasta alakulmasta)<br />Tilausten syöttämissovellus luo ”tavallisen” tapahtuman (Event B) aina, kun siihen syötetään tilaus<br />Tavalliset tilaustapahtumat välitetään tietovarastoon käsittelijän ja sen julkaisutoiminnon avulla<br />Lisäksi yli 1500 dollarin tilauksien yhteydessä tilauksen tehneen asiakkaan luokitus halutaan nostaa seuraavaan luokkaan<br />20.6.2011<br />Eetu Blomqvist<br />
  11. 11. Esimerkki tapahtumavirran käsittelystä(3)<br />Tarkoitukseen käytetään erillistä reititintä, koska tapahtumien reititys ja jakelu ei saa olla tapahtumalähteen vastuulla<br />Lähteen ainoa velvollisuus on kertoa, että jotain tapahtui<br />Reititin tulkitsee jokaisen tilauksen kokonaissumman ja luo uuden ”huomattavan” tapahtuman (Event C), kun 1500 dollaria ylittyy<br />Myös tämä tapahtuma siirretään tapahtumaväylään<br />Prosessori välittää tapahtuman käsittelysääntöjen mukaisesti SOA-palvelulle, joka sisältää logiikan asiakasluokituksen nostamiseksi<br />Esimerkki Event-driven SOA:sta!<br />20.6.2011<br />Eetu Blomqvist<br />
  12. 12. Esimerkki monimutkaisesta käsittelystä<br />20.6.2011<br />Eetu Blomqvist<br />Lähde Brenda M. Michelson, Elemental Links<br />http://dl.dropbox.com/u/20315902/EventDrivenArchitectureOverview_ElementalLinks_Feb2011.pdf<br />
  13. 13. Esimerkki monimutkaisesta käsittelystä(2)<br />Sisältää 3 tapahtumavuota<br />1. (alkaa vasemmasta yläkulmasta)<br />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<br />Tapahtuman puuttuminen tarkoittaa virhettä<br />Prosessorilla on tiedossaan viimeisimmän tapahtuman aikaleima<br />Jos aikaleimasta on yli 15 minuuttia, prosessi toimii säännöstön mukaan<br />Ylläpitäjää hälytetään hakulaitteella<br />Virheestä luodaan uusi tapahtuma (Event E) ja se siirretään tapahtumaväylään<br />Uusi tapahtuma julkaistaan, jolloin siitä kiinnostunut organisaation vikojenhallintajärjestelmä saa tiedon ongelmasta<br />2. ja 3. (alkavat vasemmalta keskeltä)<br />Esittävät väärinkäytöksiä estäviä mekanismejä<br />Myyntipistesovellus luo tapahtuman jokaista myyntipisteessä tehtyä ostosta kohden (Event Y)<br />Reititin evaluoi yli 1500 dollarin ostot, joista luodaan uusia tapahtumia (Event Z)<br />Kaikki tapahtumat siirretään tapahtumaväylään<br />20.6.2011<br />Eetu Blomqvist<br />
  14. 14. Esimerkki monimutkaisesta käsittelystä(3)<br />1. tarkastusmekanismi<br />Prosessori etsii kaikki samalla luottokortilla lyhyen ajan (10 min) sisään tehdyt transaktiot (Event Y), jotka ovat syntyneet eri paikoissa laajalla alueella (20 mailia).<br />Jos transaktioita löytyy tehdään kutsu palvelulle, joka käsittelee väärinkäytösepäilyn alaisia asiakastietoja <br />2. tarkastusmekanismi<br />Prosessori käy läpi asiakkaan ostohistoriaa, kun se vastaanottaa tapahtuman yli 1500 dollarin ostoksesta<br /> Jos oston kokonaissumma on 50% suurempi kuin yhdenkään asiakkaan aikaisemman ostoksen kokonaissumma, tapahtuma julkaistaan edelleen ”epäilyttävänä”<br />Asiakaspalvelutiimi vastaanottaa tapahtuman ja käynnistää tiedustelun asiakkaan suuntaan soittamalla kortin omistajalle<br />20.6.2011<br />Eetu Blomqvist<br />
  15. 15. EDA:n toteutuksen komponentit<br />Tapahtumien metadata<br />Tapahtumamäärittelyt<br />Tapahtumien käsittelysäännöt<br />Tapahtumien prosessointi<br />Yksinkertaiset prosessorit ovat usein itse toteutettuja ohjelmistokomponentteja<br />Monimutkaisemmat ovat kaupallisia (toimittajia mm. Oracle, IBM)<br />Kehitys- ja seurantatyökalut<br />Metadatan tuottaminen helposti<br />Ylläpito ja seuranta tapahtumien käsittelylle, tapahtumien kulun seuranta, statistiikat jne.<br />Integraatio organisaation tietojärjestelmiin<br />Tapahtumien esikäsittely (suodatus, reititys, transformaatiot)<br />Palvelukutsut ja liiketoimintaprosessien käynnistäminen<br />Tapahtumien julkistaminen ja tilaaminen<br />Palveluväylä tarjoaa useita yllä mainituista palveluista...<br />Ja tietenkin tapahtumien lähteet ja kohteet<br />Organisaation sisäiset tai ulkoiset ohjelmistot, palvelut, prosessit, tietovarastot, ihmiset ja niin edelleen<br />20.6.2011<br />Eetu Blomqvist<br />
  16. 16. Kiitos mielenkiinnosta!<br />

×