Arkkitehtuurityylejä ja patterneja

Transkriptio

1 Arkkitehtuurityylejä ja patterneja Luento Ohjelmistoarkkitehtuurit 1

2 Oppimistavoitteet Yleisesti käytettyjä arkkitehtuuripatterneja ja - tyylejä N-Tier, Klassinen MVC, Jaettu tietovarasto, Microservices Viestinvälitys skaalautuvan ja hajautetun arkkitehtuurin mahdollistajana Ohjelmistoarkkitehtuurit 2

3 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 Ohjelmistoarkkitehtuurit 3

4 ARKKITEHTUURIPATTERNEJA Ohjelmistoarkkitehtuurit 4

5 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 Ohjelmistoarkkitehtuurit 5

6 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 Ohjelmistoarkkitehtuurit 6

7 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) Ohjelmistoarkkitehtuurit 7

8 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., Ohjelmistoarkkitehtuurit 8

9 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 Ohjelmistoarkkitehtuurit 9

10 Klassinen MVC Ohjelmistoarkkitehtuurit 10

11 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 Ohjelmistoarkkitehtuurit 11

12 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 Ohjelmistoarkkitehtuurit 12

13 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! Ohjelmistoarkkitehtuurit 13

14 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: Ohjelmistoarkkitehtuurit 14

15 ARKKITEHTUURITYYLEJÄ Ohjelmistoarkkitehtuurit 15

16 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 Ohjelmistoarkkitehtuurit 16

17 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 Ohjelmistoarkkitehtuurit 17

18 Jaetun tietovaraston arkkitehtuuri processor 1 processor 2 state Käsittelijät toisistaan riippumattomia Ohjelmistoarkkitehtuurit 18

19 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 Ohjelmistoarkkitehtuurit 19

20 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 Ohjelmistoarkkitehtuurit 20

21 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 Ohjelmistoarkkitehtuurit 21

22 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 Ohjelmistoarkkitehtuurit 22

23 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 Ohjelmistoarkkitehtuurit 23

24 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 Ohjelmistoarkkitehtuurit 24

25 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 Ohjelmistoarkkitehtuurit 25

26 Microservices Ohjelmistoarkkitehtuurit 26

27 Microservices Martin Fowlerin sivut ml Katso esimerkiksi Fowlerin key-note esitys aiheesta GOTO Berlin 2014 konferenssissa youtubesta Linkki videoihin löytyy microservices resurssisivulta (1. linkki yllä) Ohjelmistoarkkitehtuurit 27

28 Microservices pattern language Chris Richardsonin sivusto Ohjelmistoarkkitehtuurit 28

29 VIESTINVÄLITYS JA SKAALAUTUVA ARKKITEHTUURI Ohjelmistoarkkitehtuurit 29

30 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 Ohjelmistoarkkitehtuurit 30

31 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 Ohjelmistoarkkitehtuurit 31

32 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 Ohjelmistoarkkitehtuurit 32

33 Viestinvälityksen peruskäsitteitä (Esimerkkinä JMS 2.0) Point-to-Point vs. Publish-and-Subscribe Queue vs. Topic Involved vs. Fire-and-Forget Ohjelmistoarkkitehtuurit 33

34 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 Ohjelmistoarkkitehtuurit 34

35 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 Ohjelmistoarkkitehtuurit 35

36 Point-to-Point Provider Sender Q1 Q2 Receiver Request-Reply tarvitaan kaksi jonoa ( Involved relationship) Ohjelmistoarkkitehtuurit 36

37 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 Ohjelmistoarkkitehtuurit 37

38 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ä Ohjelmistoarkkitehtuurit 38

39 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 Ohjelmistoarkkitehtuurit 39

40 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.) Ohjelmistoarkkitehtuurit 40

41 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ä) Ohjelmistoarkkitehtuurit 41

42 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 Ohjelmistoarkkitehtuurit 42

43 Esimerkkejä RabbitMQ on suosittu open-source viestinvälityspalvelu, joka tukee monia kieliä/ympäristöjä ja erilaisia viestinvälitysprotokollia JMS 2.0 Java Message Service API Ohjelmistoarkkitehtuurit 43

44 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 Ohjelmistoarkkitehtuurit 44

45 Tapahtumapohjainen viestintä :Component :Component :Component Väylä / Event bus :Component :Component publish subscribe Ohjelmistoarkkitehtuurit 45

46 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 Ohjelmistoarkkitehtuurit 46

47 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( ) Ohjelmistoarkkitehtuurit 47

48 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 Ohjelmistoarkkitehtuurit 48

49 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 Ohjelmistoarkkitehtuurit 49