Arkkitehtuurityylejä ja patterneja Luento 3 19.9.2017 581358 Ohjelmistoarkkitehtuurit 1
Oppimistavoitteet Yleisesti käytettyjä arkkitehtuuripatterneja ja - tyylejä N-Tier, Klassinen MVC, Jaettu tietovarasto, Microservices Viestinvälitys skaalautuvan ja hajautetun arkkitehtuurin mahdollistajana 19.9.2017 581358 Ohjelmistoarkkitehtuurit 2
Tyylien ja patternien käytöstä Platoninen vs. ruumiillistunut tyyli/patterni Platoninen tyyli/patterni on ideaalinen kuvaus arkkitehtuuriratkaisusta Käytännön toteutuksissa esiintyvät tyylien/patternien instanssit ( ruumillistumat ) ovat harvoin täysin puhtaita, eli niissä on tehty jotain perusteltuja poikkeuksia ja lisäyksiä ratkaisun rakenteisiin ja rajoitteisiin Tyylit ja patternit ovat yleistyksiä Olennaisimmat piirteet kiteytettynä Yleistys, joka määrittelee arkkitehtuurien luokan On myös paljon sovellusalue- ja teknologiakohtaisia patterneja, joilla on rajallisempi sovellusala Esim. yksityiskohtaisia reseptejä tietyn teknologian käyttöön 19.9.2017 581358 Ohjelmistoarkkitehtuurit 3
ARKKITEHTUURIPATTERNEJA 19.9.2017 581358 Ohjelmistoarkkitehtuurit 4
Kolmitasoarkkitehtuuri (N-Tier) Käli-elementin sisältö Service requests Olio Data requests Tietokantataulun rivi Display (Presentation) business' logic Persistent state (Datastore) Values to display data values Käyttäjän näkymä J:n dataan ja toimintoihin -datan katselu -datan muokkaus Operaatiot, joita käyttäjä haluaa järjestelmän tekevän datan perusteella (liiketoimintaprosessit ja entiteetit) Datan pysyvä talletus ja jakaminen eri sovellusten kesken 19.9.2017 581358 Ohjelmistoarkkitehtuurit 5
N-Tier? Käytännössä isoissa järjestelmissä puhutaan kolmen tason sijaan usein monitasoisesta rakenteesta (N-Tier) Business logic taso jaetaan yleensä edelleen (1) palvelupyyntöjen vastaanoton ja käyttäjä-istuntojen hallinnan tasoon sekä (2) palvelut toteuttavien operaatioiden ja business-olioiden tasoon Business-oliot taas käyttävät yritysjärjestelmätason palveluita (tietokannat, toiset järjestelmät) N on siis yleensä 4 tai jopa 5 19.9.2017 581358 Ohjelmistoarkkitehtuurit 6
Kolmitasoarkkitehtuuri (N-Tier) Sovellusalue Hajautetut, data-intensiiviset informaatiojärjestelmät Edut Helpottaa tietoturvan, suorituskyvyn ja saatavuuden optimointia eri tasoilla niille sopivilla tavoilla Lisää järjestelmän modulaarisuutta ja muunneltavuutta, koska eri tasojen välille täytyy sopia määrämuotoiset kommunikaatioprotokollat (-> loose coupling) Haitat Kustannukset, monimutkaisuus (datan esitystapojen muunnokset, virhetilanteiden käsittelyn haasteet) 19.9.2017 581358 Ohjelmistoarkkitehtuurit 7
Klassinen Model-View-Controller (MVC) [malli-näkymä-ohjain] Sovellusalue: monimuotoisia käyttöliittymänäkymiä sisältävät interaktiiviset järjestelmät Motivaatio: Ohjelmistolla on erilaisia käyttäjiä ja näillä erilaisia tarpeita käyttöliittymään liittyen Samaa informaatiota pitää pystyä esittämään ja käsittelemään eri muodoissa Käyttöliittymän tulisi olla helposti muutettavissa Krasner, G., Pope S: Cookbook for Using the Model-View-Controller User Interface Paradigm in Smalltalk-80, JOOP Aug./Sep.,1988. 19.9.2017 581358 Ohjelmistoarkkitehtuurit 8
Klassinen MVC Kolmenlaisia komponentteja Malli-komponentit ovat vastuussa laskentaan liittyvän tiedon (tai tilan) säilytyksestä Näkymä-komponentit ovat vastuussa tiedon esittämisestä käyttäjälle Ohjain-komponentit ovat vastuussa käyttäjän ja järjestelmän välisen vuorovaikutuksen ohjaamisesta Ottavat esimerkiksi vastaan hiiren näpäyksiä, näppäimen painamisia jne. ja muuntavat nämä mallikomponenttien tilaan vaikuttaviksi operaatioiksi 19.9.2017 581358 Ohjelmistoarkkitehtuurit 9
Klassinen MVC 19.9.2017 581358 Ohjelmistoarkkitehtuurit 10
Klassinen MVC Mallikomponentit eivät riipu mistään (tietystä) näkymä- tai ohjainkomponentista Muutokset mallikomponenteissa välitetään näkymille Tarkkailija-suunnittelumallin mukaisesti Eli vain niille näkymille, jotka ovat ilmaisseet kiinnostuksensa muutoksiin 19.9.2017 581358 Ohjelmistoarkkitehtuurit 11
MVC - arviointia Etuja Useita näkymiä samaan tietoon Näkymiä on helposti lisättävissä jopa dynaamisesti Ohjaimen voi helposti vaihtaa Voi toimia perustana sovelluskehykselle (Smalltalk, Web - applikaatiot) Ongelmia Lisää mutkikkuutta Yksinkertainen käyttäjätoimenpide saattaa aiheuttaa monia päivityksiä näkymään (päivityksen laajuutta voi olla vaikea kontrolloida) Voi olla työlästä löytää sopiva datan esitysmuoto ja haku- /päivitysoperaatiot mallin rajapintaan käyttöliittymän (näkymän) suorituskyvyn (responsiivisuus) kannalta 19.9.2017 581358 Ohjelmistoarkkitehtuurit 12
Muunnelmia Monesti ei ole tarpeen erottaa ohjainta ja näkymää Erityisesti, jos kullakin näkymällä olisi joka tapauksessa oma ohjain, jonka kautta voidaan suoraan manipuloida näkymää Voimakas kytkentä (strong coupling) Käytännössä monissa käyttöliittymäkehyksissä (GUI frameworks) kontrollerikoodi liitetään UI elementteihin suoraan tapahtumankäsittelijöinä Ts. komponentti voi toimia sekä näkymä- että ohjainkomponenttina. Yhteen malliin voi liittyä monta <näkymä, ohjain> -paria. Huom juuri ohjaimen rooli ja tehtävät vaihtelevat eniten MVC-patternin eri ruumiillistumissa! 19.9.2017 581358 Ohjelmistoarkkitehtuurit 13
Muunnelmia Yleensä on tarkoituksenmukaista tarjota mallin dataa näkymälle muodossa, josta sitä on helppo kopioida käyttöliittymän elementtien arvoiksi ja päinvastoin Mallin oliot voivat olla rakenteeltaan monimutkaisia ja niiden kenttien tietotyypit voivat olla käyttöliittymän kannalta epätarkoituksenmukaisia Näkymän ja mallin väliin määritellään näkymämalli (ViewModel), joka suorittaa tarvittavat muunnokset ja suodatukset esitystapojen välillä (ynnä muuta tarpeellista) Riippuvuudet: Näkymä -> Näkymämalli -> Malli Kts. esim: https://msdn.microsoft.com/enus/magazine/dd419663.aspx 19.9.2017 581358 Ohjelmistoarkkitehtuurit 14
ARKKITEHTUURITYYLEJÄ 19.9.2017 581358 Ohjelmistoarkkitehtuurit 15
Arkkitehtuurityylien luokitteluista Tyylejä on pyritty luokittelemaan eri tavoin vuosien varrella Kurssikirja (Fairbanks) ei luokittele tyylejä lainkaan Bass, Clements ja Kazman (Software Architecture in Practice, 3. painos) taas kutsuvat tyylejä patterneiksi ja luokittelevat ne omalla tavallaan jne. Yleisiä luokitteluja hyödyllisempiä ryhmittelyjä ovat patternikielet (Pattern Languages), jotka kokoavat yhteenkuuluvia (design-) patterneja laajemmiksi kokonaisuuksiksi Esim. mikropalvelujen, pilvipalvelujen tai sulautettujen järjestelmien suunnitteluun ja toteutukseen liittyvät patternit Palaamme tähän mikropalvelu arkkitehtuurityylin kohdalla 19.9.2017 581358 Ohjelmistoarkkitehtuurit 16
Jaettuun tietovarastoon perustuva arkkitehtuuri Data centered - Shared state - Repository Joukko komponentteja ylläpitää yhteistä dataa tietovarastossa Erilaisia muunnelmia sen mukaan, kuinka aktiivinen rooli tietovarastolla on Kahdenlaisia komponentteja Keskitetty tietorakenne: tietovarasto Asiakaskomponentit: hakevat tietoa tietovarastosta ja muokkaavat sitä Järjestelmän kontrolli määräytyy tietovaraston sisältämän datan tilan mukaan 19.9.2017 581385 Ohjelmistoarkkitehtuurit 17
Jaetun tietovaraston arkkitehtuuri processor 1 processor 2 state Käsittelijät toisistaan riippumattomia 19.9.2017 581385 Ohjelmistoarkkitehtuurit 18
Jaetun tietovaraston arkkitehtuuri Vuorovaikutus käsittelijöiden välillä tapahtuu ainoastaan tietovaraston kautta Käsittelijöiden tietovarastoon tekemät muutokset johtavat vaiheittain haluttuun lopputulokseen Käsittelijän aktivointi Käsittelijät voivat pollata tietovarastoa tutkiakseen onko tila sellainen, mistä käsittelijä pystyy jatkamaan toimintaa jos on, käsittelijä tuottaa tuloksia, jotka kirjaa tietovarastoon Tietovarasto voi aktivoida käsittelijän jonkin säännön perusteella, esimerkiksi sisällön muuttumisen perusteella vrt tietokantatriggerit 19.9.2017 581385 Ohjelmistoarkkitehtuurit 19
Jaetun tietovaraston arkkitehtuuri Käsittelijät voivat toimia rinnakkain Edellyttää samanaikaisuuden hallintaa: tiedon lukitus miten estetään yhtä käsittelijää varaamasta koko tietovarastoa itselleen (liian pitkäksi aikaa)? Esimerkkejä Tekoälysovellukset (blackboard-arkkitehtuuri), Wikit, Google docs, MS Sharepoint, muut verkkotyöalustat 19.9.2017 581385 Ohjelmistoarkkitehtuurit 20
Jaetun tietovaraston arkkitehtuuri Etuja Muunneltavuus & laajennettavuus (itsenäiset, toisistaan riippumattomat käsittelijät) Rinnakkaisuuden hyödyntäminen Haittoja Rinnakkaisuuden ja päällekkäisten päivitysten hallinta on mietittävä tarkkaan 19.9.2017 581385 Ohjelmistoarkkitehtuurit 21
Microservices Nousussa oleva, vielä hieman täsmentymätön tyyli yritysjärjestelmien palvelinpuolen arkkitehtuuriksi Vastaveto monoliittisiksi koetuille perinteisille kolmikerrosarkkitehtuureille (N-tier) Tukee Continuous X käytäntöjä (continuous integration, deployment jne.) ~ Unixin pipes and filters ajattelutapa sovellettuna palvelujen toteuttamiseen 19.9.2017 581385 Ohjelmistoarkkitehtuurit 22
Monoliitti Käytäntönä on pitkään ollut rakentaa web-sovellus yhtenä fyysisenä pakettina, joka voidaan sellaisenaan asentaa ja ottaa käyttöön tuotantopalvelimella Esim. Java-teknologialla toteutettu kolmitaso web-sovellus koostetaan yhteen WAR-pakkaukseen, joka sisältää http-pyyntöjen käsittelyn ja web-sivujen generoinnin, business-logiikan ja tietokantakerroksen Pakkaus voidaan asentaa suoraan http-palvelimelle (esim. Tomcat) tai sisällyttää osaksi palvelimen asennuspakettia Yleensä web-sovellus on toteutettu käyttäen jotain sovelluskehystä (framework), joka tarjoaa koko joukon hyödyllisiä apupalveluja, mutta toisaalta pakottaa käyttämään kehyksen suunnittelijoiden päättämää rakennetta komponenttityypit, riippuvuudet ja koodin suoritukseen liittyvät piirteet Tyypillisesti sovellusta ajetaan yhdessä prosessissa (1 säie/palvelupyyntö); jos tarvitaan lisää kapasiteettia (säikeet loppuvat tai vasteajat kasvavat liikaa) pitää käynnistää uusia instansseja, joita kuormistusta säädellän kuormantasaajan (load balancer)avulla 19.9.2017 581358 Ohjelmistoarkkitehtuurit 23
Monoliitti Etuja Oppimiskynnyksen ylityttyä kehittäjälle helppo ja turvallinen Kehittäjä voi keskittyä oleelliseen ja jättää monet teknisesti vaativat asiat kehyksen vastuulle (transaktiot, komponenttien automaattinen kytkentä, tietoturva jne.) Haittoja Sovelluksen eri osien päivittäminen eri tahtiin voi olla mahdotonta (sovellus pitää testata ja asentaa yhtenä kokonaisuutena) Sovelluksen käynnistyminen voi olla hidasta ja testien suoritus saattaa kestää pitkään Voi olla vaikeaa ylläpitää hyvää modulaarisuutta muutosten heijastusvaikutusten estämiseksi Jos jokin tietty sovelluksen osa muodostuu suorituskyvyn pullonkaulaksi, koko sovelluksesta pitää luoda uusia instansseja (vertikaalinen skaalaus) sen sijaan, että yksittäisen osan kapasiteettia voitaisiin kasvattaa esimerkiksi rinnakkaisilla kopioilla (horisontaalinen skaalaus) Pilvipalvelualustojen tarjoamasta suorituskyvyn ja kustannusten skaalautuvuudesta ei saada täyttä hyötyä (sekä ylös- että alasskaalaus) Usein vaikeaa käyttää eri toteutusteknologioita sovelluksen eri osissa Syntyy vahva riippuvuus käytettyyn teknologia-alustaan 19.9.2017 581358 Ohjelmistoarkkitehtuurit 24
Microservices Perusidea: palvelinsovellus Koostuu kokoelmasta pieniä, erillisiä palveluita Jokaista palvelua ajetaan omassa prosessissaan Palvelut kommunikoivat kevyitä mekanismeja käyttäen (verrattuna ESBväyliin), esimerkiksi HTTP resurssi-api:eja Palvelu Osituksen perusteena liiketoimintaprosessit ja toiminnot (yksi per palvelu, single responsibility principle) Voidaan ottaa käyttöön (deployment) itsenäisesti ja automaattisesti Voidaan skaalata (lisätä kapasiteettia) horisontaalisesti palvelu kerrallaan Minimimäärä pavelujen keskitettyä hallinnointia Palvelujen toteutus mahdollista eri ohjelmointikielillä ja kirjastoilla Palvelut voivat käyttää omia tiedonhallintaratkaisujaan Hyvä skaalautuvuus (+ ja -) tavoitteena Transaktioiden sijaan tarvitaan toisenlaisia menetelemiä tiedon eheyden takaamiseksi Orkestrointi mikropalveluja käyttävien komponenttien vastuulla 19.9.2017 581385 Ohjelmistoarkkitehtuurit 25
Microservices http://martinfowler.com/articles/microservices/images/decentralised-data.png 19.9.2017 581385 Ohjelmistoarkkitehtuurit 26
Microservices Martin Fowlerin sivut http://martinfowler.com/microservices/ http://martinfowler.com/articles/microservices.ht ml Katso esimerkiksi Fowlerin key-note esitys aiheesta GOTO Berlin 2014 konferenssissa youtubesta Linkki videoihin löytyy microservices resurssisivulta (1. linkki yllä) 19.9.2017 581385 Ohjelmistoarkkitehtuurit 27
Microservices pattern language Chris Richardsonin sivusto http://microservices.io/patterns/index.html 19.9.2017 581358 Ohjelmistoarkkitehtuurit 28
VIESTINVÄLITYS JA SKAALAUTUVA ARKKITEHTUURI 19.9.2017 581385 Ohjelmistoarkkitehtuurit 29
Hajauta ja hallitse! Ongelma: miten toteutetaan asiakkaiden ja palvelujen välinen kommunikointi hajautetussa, heterogeenisessä palveluympäristössä, jossa Monia eri ohjelmointikieliä ja toteutusteknologioita käytössä Halutaan välttää suoritusaikaisten komponenttien välisen suoran kommunikaation aiheuttamia suorituskyvyn pullonkauloja Halutaan skaalautuvuutta, jossa voidaan dynaamisesti lisätä (ja vähentää) palvelevia komponentteja Halutaan löyhät kytkennät komponenttien välille piilottamalla niiden toteutusteknologioiden yksityiskohdat (esim. ohjelmointikieli) Halutaan joustavuutta ja ketteryyttä arkkitehtuuriin Halutaan lisätä asynkronisuutta, jotta asiakkaan ei tarvitse jäädä odottamaan, kun palvelin käsittelee pyyntöä, vaan se voi jatkaa muita toimintojaan ja käsitellä palvelimen lähettämän vastauksen sen valmistuttua 19.9.2017 581385 Ohjelmistoarkkitehtuurit 30
Kommunikoi viestein Ratkaisu: komponentit kommunikoivat lähettämällä toisilleen viestejä Viesti abstrahoi ja kapseloi palvelupyynnön (ja vastauksen), siihen liittyvät attribuutit ja datan (payload) sekä protokollan Viestin hyötykuorma voi olla iso tai pieni Viestintä voi olla synkronista (lähettäjä jää odottamaan) tai asynkronista (lähettäjä jatkaa toimintaansa) Viesti voidaan lähettää (1) tietylle kohteelle tai (2) yleislähetyksenä (broadcast) kaikille tunnetuille/kiinnostuneille kohteille 19.9.2017 581385 Ohjelmistoarkkitehtuurit 31
Message (Java Message Service 2.0) Messages, as described here, are asynchronous requests, reports or events that are consumed by enterprise applications, not humans. They contain vital information needed to coordinate these systems. They contain precisely formatted data that describe specific business actions. Through the exchange of these messages each application tracks the progress of the enterprise. 19.9.2017 581385 Ohjelmistoarkkitehtuurit 32
Viestinvälityksen peruskäsitteitä (Esimerkkinä JMS 2.0) Point-to-Point vs. Publish-and-Subscribe Queue vs. Topic Involved vs. Fire-and-Forget 19.9.2017 581385 Ohjelmistoarkkitehtuurit 33
Point-to-Point Jono (queue) on erillinen nimetty resurssi (Provider-palvelimella), johon lähettäjä ja vastaanottaja muodostavat erikseen yhteyden (eivät siis suoraan toisiinsa) - Kummankaan ei tarvitse tuntea toista osapuolta (osoitetta tms.) Sender Provider Receiver Queue Synch. Asynch. / Synch. Asynch. 19.9.2017 581385 Ohjelmistoarkkitehtuurit 34
Point-to-Point monta vaihtoehtoista vastaanottajaa Receiver Sender Provider Receiver Queue Receiver - Vain yksi vastaanottaja saa viestin (point-to-point)! - Viestissä välitetty data ja/tai pyydetty palvelu prosessoidaan vain yhden kerran - JMS spesifikaatio ei määrää, miten saaja valitaan 19.9.2017 581385 Ohjelmistoarkkitehtuurit 35
Point-to-Point Provider Sender Q1 Q2 Receiver Request-Reply tarvitaan kaksi jonoa ( Involved relationship) 19.9.2017 581385 Ohjelmistoarkkitehtuurit 36
Publish-and-Subscribe Consumer Publisher Sender Provider Topic Consumer Consumer Fire-and-Forget: julkaisijaa ei kiinnosta, ketkä viestin saavat tai saako kukaan ja mitä ne sillä tekevät 19.9.2017 581385 Ohjelmistoarkkitehtuurit 37
Viestinvälitysarkkitehtuurit Tyypillinen tilanne (roolit) Julkaisija Tilaaja (Producer/Publisher Subscriber) Tuottaja Kuluttaja (Producer/Sender Receiver/Consumer) Ohjelman (prosessin) sisällä julkaisijat ja tilaajat voidaan kytkeä suoraan (esim. Tarkkailija-patterni) Yksinkertaisimmillaan julkaisija pitää kirjaa vastaanottajista ja tietosisällön muuttuessa välittää tiedon tilaajille proseduurikutsun välityksellä. Tilaaja rekisteröityy vastaanottajaksi ja toimittaa rekisteröinnin yhteydessä vastaanottorajapinnan (call-back) Hajautetussa sovelluksessa tarvitaan kommunikointiprotokolla ja välittäjä (broker, JMS 2.0 Provider) huolehtimaan viestinvälityksestä 19.9.2017 581385 Ohjelmistoarkkitehtuurit 38
Viestinvälitysarkkitehtuurit Välittäjä (Broker) Välittäjä (broker) tietää vastaanottajat (rekisteröityminen tai konfigurointi) Julkaisija toimittaa viestin välittäjälle Välittäjä toimittaa viestin edelleen siitä kiinnostuneille tilaajille (filtteröinti) Tilaaja käsittelee viestin Välittäjään (broker) ja asynkroniseen viestintään perustuvaa arkkitehtuuria voidaan käyttää yleisesti palveluarkkitehtuurin runkona perinteisemmän etäproseduurikutsuihin perustuvan Asiakas-Palvelin arkkitehtuurin sijaan Palveluekosysteemit 19.9.2017 581385 Ohjelmistoarkkitehtuurit 39
Viestinvälitysarkkitehtuurit Välittäjä Arkkitehtuurissa määriteltävä seuraavat asiat: Keskenään kommunikoivat komponentit Viestit, joiden avulla kommunikointi tapahtuu ilman, että lähettäjä tuntee vastaanottajan (tai vastaanottaja lähettäjän) fyysistä sijaintia (protokolla, syntaksi) Operaatiot, joilla komponentit reagoivat viesteihin (komponenttien ymmärtämä kieli, semantiikka) Säännöt, joiden avulla komponentit ja viestit rekisteröidään järjestelmälle Palvelutasolupaus (viestien elinaika, taattu toimitus, transaktiot jne.) 19.9.2017 581385 Ohjelmistoarkkitehtuurit 40
Viestinvälitysarkkitehtuurit Välittäjä Säännöt, joiden perusteella välittäjä tietää, mille komponentille viesti on lähetettävä Viestin vastaanottajan selvittäminen: yleisviesti (multiple dispatch; viesti kaikille, jotkut käsittelevät, toiset eivät) etu: vastaanottajan ei tarvitse etukäteen kertoa, mitä viestejä se haluaa vastaanottaa komponentit kertovat rekisteröinnin yhteydessä, mitä viestejä (viestin tyyppi tai muu tunniste) ne haluavat vastaanottaa (tai keneltä) 19.9.2017 581385 Ohjelmistoarkkitehtuurit 41
Viestinvälitysarkkitehtuurit Välittäjä Rinnakkaisuus: missä määrin välittäjä ja komponentit toimivat rinnakkain Viestinvälittäjillä ja vastaanottajilla viestijonot (välittäjän laatikko, vastaanottajan laatikko) Voiko viestijono olla jaettu eri vastaanottajien kesken Puskurointi, palvelutasot 19.9.2017 581385 Ohjelmistoarkkitehtuurit 42
Esimerkkejä RabbitMQ on suosittu open-source viestinvälityspalvelu, joka tukee monia kieliä/ympäristöjä ja erilaisia viestinvälitysprotokollia http://www.rabbitmq.com JMS 2.0 Java Message Service API https://jcp.org/en/jsr/detail?id=343 19.9.2017 581385 Ohjelmistoarkkitehtuurit 43
Tapahtumapohjaiset Viestinvälitysarkkitehtuurit Tapahtumapohjaiset arkkitehtuurit (event-based, event driven) Komponentit kommunikoivat aiheuttamalla tapahtumia (event) Tapahtumat voivat välittyä kaikille muille komponenteille, joista jotkut käsittelevät ja toiset eivät noteeraa Tapahtumien lähetys voidaan myös rajoittaa julkaisija tilaaja rakenteen tapaan tapahtuma lähetetään vain tapahtuman tyypistä kiinnostuneille komponentteja ei ole kuitenkaan lokeroitu joko julkaisijoiksi tai tilaajiksi vaan komponentti voi toimia kumpanakin 19.9.2017 581385 Ohjelmistoarkkitehtuurit 44
Tapahtumapohjainen viestintä :Component :Component :Component Väylä / Event bus :Component :Component publish subscribe 19.9.2017 581385 Ohjelmistoarkkitehtuurit 45
Tapahtumapohjaiset Viestinvälitysarkkitehtuurit Tapahtuma Tilanne, joka voi sattua ohjelman suorituksen aikana Edellyttää reagointia joiltain järjestelmän osilta (vrt. signaali) Tapahtumaan liittyy usein pieni määrä dataa (ei välttämättä yhtään) Lähde = tapahtuman synnyttävä komponentti Tarkkailija = tapahtumaan reagoiva komponentti Lähde lähettää tapahtumailmoituksen sitä tarkkailemaan rekisteröityneelle tarkkailijalle Esimerkiksi Signals & Slots 1 Qt-sovelluskehyksen olioarkkitehtuurissa Lähde tietää dynaamisesti tarkkailijoidensa olemassaolon, mutta ei niiden tarkkaa tyyppiä Tapahtumaväylää käytettäessä lähteet eivät tiedä tarkkailijoistaan (vrt. MVC, Observer -mallit) Ilmoituksen lähetys voidaan hoitaa proseduurikutsuna tai sanomanvälityksenä (event bus, message bus) proseduurikutsu synkroninen (esim Qt Signals & Slots) Sanomajono asynkroninen/synkroninen 1 http://en.wikipedia.org/wiki/signals_and_slots, http://qt-project.org/doc/qt-5.0/qtcore/signalsandslots.html 19.9.2017 581385 Ohjelmistoarkkitehtuurit 46
Javan tapahtumamalli EventObject Vapaasti toteutettavissa EventListener EventSource Observer EventListenerInterface MyEvent ListenerContainer calls eventhappened(myevent) update addeventlistener(evli) notifyall implements ConcreteEventListerner Ev1 creates ES1 addeventlistener( ) eventhappened(event) Instance of calls CEL-1 eventhappened( ) 19.9.2017 581385 Ohjelmistoarkkitehtuurit 47
Viestinvälityksen arviointia Etuja Joustavuus, muunneltavuus, modulaarisuus Uusien tuottajien/julkaisijoiden ja kuluttajien/tilaajien dynaaminen lisääminen Välittäjän/väylän tekemät automaattiset esitystapamuunnokset, erilaisia palvelutasoja toteutettavissa (varmistettu perillemeno vs. fire and forget) Komponenttien omatahtinen evoluutio Paljon käytettyjen välittäjä-/väyläratkaisujen hyväksi kehittynyt laatu Luotettavuus, skaalautuvuus, suorituskykyoptimoinnit, jne. 19.9.2017 581385 Ohjelmistoarkkitehtuurit 48
Viestinvälityksen arviointia Haittoja Välittäjän tai tapahtumaväylän tuoma suoritusrasite (overhead) ja suorituskyvyn optimointimahdollisuuksien kaventuminen verrattuna suoriin (IPC-) yhteyksiin Välittäjä tai väylä on kriittinen komponentti (single point of failure), jonka luotettavuus pitää saada paljon korkeammaksi kuin kommunikoivien komponenttien 19.9.2017 581385 Ohjelmistoarkkitehtuurit 49