Arkkitehtuurityylejä ja patterneja - Courses...Wikit, Google docs, MS Sharepoint, muut ... –...
Transcript of Arkkitehtuurityylejä ja patterneja - Courses...Wikit, Google docs, MS Sharepoint, muut ... –...
Arkkitehtuurityylejä ja patterneja
Luento 3
19.9.2017 1581358 Ohjelmistoarkkitehtuurit
Oppimistavoitteet
• Yleisesti käytettyjä arkkitehtuuripatterneja ja -tyylejä– N-Tier, Klassinen MVC, Jaettu tietovarasto,
Microservices
• Viestinvälitys skaalautuvan ja hajautetunarkkitehtuurin mahdollistajana
19.9.2017 581358 Ohjelmistoarkkitehtuurit 2
Tyylien ja patternien käytöstä• Platoninen vs. ”ruumiillistunut” tyyli/patterni
– Platoninen tyyli/patterni on ideaalinen kuvausarkkitehtuuriratkaisusta
– Käytännön toteutuksissa esiintyvät tyylien/patternieninstanssit (”ruumillistumat”) ovat harvoin täysin ”puhtaita”,eli niissä on tehty jotain perusteltuja poikkeuksia jalisä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 teknologiakohtaisiapatterneja, 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)
19.9.2017 581358 Ohjelmistoarkkitehtuurit 5
Display(Presentation)
’business' logic
Persistent state(Datastore)
Käyttäjän näkymäJ:n dataan ja toimintoihin-datan katselu-datan muokkaus
Service requests Values to display
Käli-elementin sisältö
Operaatiot, joita käyttäjähaluaa järjestelmän tekevändatan perusteella (liiketoiminta-prosessit ja –entiteetit)Data requests data values
Olio
Datan pysyvä talletus jajakaminen eri sovellustenkesken
Tietokantataulun rivi
N-Tier?
• Käytännössä isoissa järjestelmissä puhutaan kolmentason sijaan usein monitasoisesta rakenteesta (N-Tier)
• Business logic –taso jaetaan yleensä edelleen (1)palvelupyyntöjen vastaanoton ja käyttäjä-istuntojenhallinnan tasoon sekä (2) palvelut toteuttavienoperaatioiden ja ”business-olioiden” tasoon
• Business-oliot taas käyttävät yritysjärjestelmätasonpalveluita (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ämuotoisetkommunikaatioprotokollat (-> 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: monimuotoisiakäyttöliittymänäkymiä sisältävät interaktiivisetjä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 UserInterface 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ä mallikomponenttientilaan 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äännäkymille Tarkkailija-suunnittelumallinmukaisesti– 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 vaikeakontrolloida)
– 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 tapauksessaoma ohjain, jonka kautta voidaan suoraan manipuloidanäkymää
• Voimakas kytkentä (strong coupling)– Käytännössä monissa käyttöliittymäkehyksissä (GUI
frameworks) ”kontrollerikoodi” liitetään UI elementteihinsuoraan 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 dataanäkymälle muodossa, josta sitä on helppo kopioidakäyttöliittymän elementtien arvoiksi ja päinvastoin– Mallin oliot voivat olla rakenteeltaan monimutkaisia ja
niiden kenttien tietotyypit voivat olla käyttöliittymänkannalta epätarkoituksenmukaisia
– Näkymän ja mallin väliin määritellään näkymämalli(ViewModel), joka suorittaa tarvittavat muunnokset jasuodatukset esitystapojen välillä (ynnä muuta tarpeellista)
– Riippuvuudet: Näkymä -> Näkymämalli -> Malli– Kts. esim: https://msdn.microsoft.com/en-
us/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 neomalla tavallaan
– …jne.• Yleisiä luokitteluja hyödyllisempiä ryhmittelyjä ovat
patternikielet (Pattern Languages), jotka kokoavatyhteenkuuluvia (design-) patterneja laajemmiksikokonaisuuksiksi– 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 perustuvaarkkitehtuuri
• 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
19.9.2017 581385 Ohjelmistoarkkitehtuurit 18
processor 1processor 2
stateKäsittelijät toisistaanriippumattomia
Jaetun tietovaraston arkkitehtuuri
• Vuorovaikutus käsittelijöiden välillä tapahtuuainoastaan tietovaraston kautta
• Käsittelijöiden tietovarastoon tekemät muutoksetjohtavat 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önperusteella, 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 (liianpitkäksi aikaa)?
• Esimerkkejä– Tekoälysovellukset (blackboard-arkkitehtuuri),
Wikit, Google docs, MS Sharepoint, muutverkkotyö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öntyyli yritysjärjestelmien palvelinpuolenarkkitehtuuriksi– Vastaveto monoliittisiksi koetuille perinteisille
kolmikerrosarkkitehtuureille (N-tier)– Tukee Continuous X –käytäntöjä (continuous
integration, deployment jne.)
• ~ Unixin pipes and filters ajattelutapasovellettuna 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ööntuotantopalvelimella– Esim. Java-teknologialla toteutettu kolmitaso –web-sovellus koostetaan yhteen
WAR-pakkaukseen, joka sisältää http-pyyntöjen käsittelyn ja web-sivujengeneroinnin, business-logiikan ja tietokantakerroksen
– Pakkaus voidaan asentaa suoraan http-palvelimelle (esim. Tomcat) taisisällyttää osaksi palvelimen asennuspakettia
• Yleensä web-sovellus on toteutettu käyttäen jotain sovelluskehystä(framework), joka tarjoaa koko joukon hyödyllisiä apupalveluja, muttatoisaalta 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änkuormantasaajan (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 jaasentaa 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 osankapasiteettia voitaisiin kasvattaa esimerkiksi rinnakkaisilla kopioilla (horisontaalinen skaalaus)
– Pilvipalvelualustojen tarjoamasta suorituskyvyn ja kustannusten skaalautuvuudesta ei saadatä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 ESB-
vä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 eheydentakaamiseksi– Orkestrointi mikropalveluja käyttävien komponenttien vastuulla
19.9.2017 581385 Ohjelmistoarkkitehtuurit 25
Microservices
19.9.2017 581385 Ohjelmistoarkkitehtuurit 26http://martinfowler.com/articles/microservices/images/decentralised-data.png
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 –konferenssissayoutubesta– 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 SKAALAUTUVAARKKITEHTUURI
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 muitatoimintojaan ja käsitellä palvelimen lähettämän vastauksen senvalmistuttua
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) kaikilletunnetuille/kiinnostuneille kohteille
19.9.2017 581385 Ohjelmistoarkkitehtuurit 31
Message (Java Message Service 2.0)
”Messages, as described here, are asynchronousrequests, reports or events that are consumedby enterprise applications, not humans. Theycontain vital information needed to coordinatethese systems. They contain precisely formatteddata that describe specific business actions.Through the exchange of these messages eachapplication tracks the progress of theenterprise.”
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
ReceiverProvider
Point-to-Point
19.9.2017 581385 Ohjelmistoarkkitehtuurit 34
Sender
Queue
Synch. Asynch. / Synch.
Sender
Asynch.
Jono (queue) on erillinen nimetty resurssi (Provider-palvelimella), johon lähettäjä javastaanottaja muodostavat erikseen yhteyden (eivät siis suoraan toisiinsa)- Kummankaan ei tarvitse tuntea toista osapuolta (osoitetta tms.)
Receiver
Point-to-Pointmonta vaihtoehtoista vastaanottajaa
19.9.2017 581385 Ohjelmistoarkkitehtuurit 35
SenderProvider
ReceiverSender
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
Queue
Point-to-Point
19.9.2017 581385 Ohjelmistoarkkitehtuurit 36
Sender
Provider
Q1
Receiver
Q2
Request-Reply – tarvitaan kaksi jonoa(”Involved” relationship)
ReceiverSender
Publish-and-Subscribe
19.9.2017 581385 Ohjelmistoarkkitehtuurit 37
Consumer
Sender
ProviderConsumer
Publisher
Consumer
Topic
Fire-and-Forget: julkaisijaa ei kiinnosta, ketkä viestin saavat– tai saako kukaan – ja mitä ne sillä tekevät
Viestinvälitysarkkitehtuurit• Tyypillinen tilanne (roolit)
– Julkaisija – Tilaaja (Producer/Publisher – Subscriber)– Tuottaja – Kuluttaja (Producer/Sender – Receiver/Consumer)
• Ohjelman (prosessin) sisällä julkaisijat ja tilaajat voidaankytkeä suoraan (esim. Tarkkailija-patterni)– Yksinkertaisimmillaan julkaisija pitää kirjaa vastaanottajista ja
tietosisällön muuttuessa välittää tiedon tilaajilleproseduurikutsun välityksellä.
– Tilaaja rekisteröityy vastaanottajaksi ja toimittaa rekisteröinninyhteydessä vastaanottorajapinnan (call-back)
• Hajautetussa sovelluksessa tarvitaankommunikointiprotokolla ja välittäjä (broker, JMS 2.0Provider) huolehtimaan viestinvälityksestä
19.9.2017 581385 Ohjelmistoarkkitehtuurit 38
ViestinvälitysarkkitehtuuritVä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äänperustuvaa arkkitehtuuria voidaan käyttää yleisestipalveluarkkitehtuurin runkona ”perinteisemmän”etäproseduurikutsuihin perustuvan Asiakas-Palvelinarkkitehtuurin sijaan– Palveluekosysteemit
19.9.2017 581385 Ohjelmistoarkkitehtuurit 39
ViestinvälitysarkkitehtuuritVä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 vastaanottajalä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 viestitrekisteröidään järjestelmälle
– Palvelutasolupaus (viestien elinaika, taattu toimitus,transaktiot jne.)
19.9.2017 581385 Ohjelmistoarkkitehtuurit 40
ViestinvälitysarkkitehtuuritVä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, jotkutkä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 haluavatvastaanottaa (tai keneltä)
19.9.2017 581385 Ohjelmistoarkkitehtuurit 41
ViestinvälitysarkkitehtuuritVälittäjä
• Rinnakkaisuus: missä määrin välittäjä jakomponentit 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-sourceviestinvälityspalvelu, joka tukee moniakieliä/ympäristöjä ja erilaisia viestinvälitys-protokollia http://www.rabbitmq.com
• JMS 2.0 – Java Message Service APIhttps://jcp.org/en/jsr/detail?id=343
19.9.2017 581385 Ohjelmistoarkkitehtuurit 43
TapahtumapohjaisetViestinvälitysarkkitehtuurit
• Tapahtumapohjaiset arkkitehtuurit (event-based, eventdriven)
• Komponentit kommunikoivat aiheuttamallatapahtumia (event)
• Tapahtumat voivat välittyä kaikille muillekomponenteille, joista jotkut käsittelevät ja toiset eivätnoteeraa– Tapahtumien lähetys voidaan myös rajoittaa julkaisija –
tilaaja rakenteen tapaan – tapahtuma lähetetään vaintapahtuman tyypistä kiinnostuneille
– komponentteja ei ole kuitenkaan lokeroitu jokojulkaisijoiksi tai tilaajiksi vaan komponentti voi toimiakumpanakin
19.9.2017 581385 Ohjelmistoarkkitehtuurit 44
Tapahtumapohjainen viestintä
19.9.2017 581385 Ohjelmistoarkkitehtuurit 45
:Component :Component :Component
:Component :Component
publishsubscribe
Väylä /Event bus
TapahtumapohjaisetViestinvä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öityneelletarkkailijalle
– Esimerkiksi Signals & Slots1 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
19.9.2017 581385 Ohjelmistoarkkitehtuurit 46
1http://en.wikipedia.org/wiki/Signals_and_slots,http://qt-project.org/doc/qt-5.0/qtcore/signalsandslots.html
Javan tapahtumamalli
19.9.2017 581385 Ohjelmistoarkkitehtuurit 47
EventListenerInterface
eventHappened(MyEvent)
Observer
ConcreteEventListerner
implements
eventHappened(Event)
update
EventSource
ListenerContainer
addEventListener(EVLI)notifyAll
CEL-1
Instance of
calls
ES1
EventObject
MyEvent
addEventListener( )Ev1creates
eventHappened( )calls
Vapaasti toteutettavissa EventListener
Viestinvälityksen arviointia
• Etuja– Joustavuus, muunneltavuus, modulaarisuus
• Uusien tuottajien/julkaisijoiden ja kuluttajien/tilaajiendynaaminen lisääminen
• Välittäjän/väylän tekemät automaattisetesitystapamuunnokset, erilaisia palvelutasoja toteutettavissa(varmistettu perillemeno vs. fire and forget)
• Komponenttien omatahtinen evoluutio
– Paljon käytettyjen välittäjä-/väyläratkaisujen hyväksikehittynyt 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 suorituskyvynoptimointimahdollisuuksien kaventuminenverrattuna suoriin (IPC-) yhteyksiin
– Välittäjä tai väylä on kriittinen komponentti (singlepoint of failure), jonka luotettavuus pitää saadapaljon korkeammaksi kuin kommunikoivienkomponenttien
19.9.2017 581385 Ohjelmistoarkkitehtuurit 49