6. Arkkitehtuurityylit Osittavat arkkitehtuurityylit - Kerrosarkkitehtuurit - Tietovuoarkkitehtuurit Palveluihin perustuvat arkkitehtuurityylit - Asiakas-palvelin arkkitehtuurit - Viestinvälitysarkkitehtuurit Erikoisarkkitehtuurityylit - MVC arkkitehtuurit - Tulkkiarkkitehtuurit 1
Mitä ovat arkkitehtuurityylit? Arkkitehtuurityyli = yleinen malli, joka kertoo miten järjestelmä organisoidaan ylimmällä abstraktiotasolla, määräten järjestelmän yleisen teknisen luonteen. Arkkitehtuurityylit eivät sulje toisiaan pois! Kysymyksiä, jotka voivat johtaa arkkitehtuurityylin valintaan: - Koostuuko järjestelmä komponenteista, jotka ovat selvästi eri abstraktiotasoilla? - Onko järjestelmän päätarkoitus jalostaa tietoa? - Jaetaanko järjestelmässä jotain globaalia resurssia erillisille komponenteille? - Koostuuko järjestelmä joukosta komponentteja, jotka kommunikoivat keskenään etukäteen tuntemattomilla tavoilla? Liittyykö kommunikointiin kiinteitä, tunnettuja rajapintoja? 2
Kerrosarkkitehtuurit Kerrosarkkitehtuuri: Järjestelmän organisointi abstraktiotasoltaan nouseviin kerroksiin.. 3
Abstraktiotasojen rikkominen ja ohitus Ohitus käyttää toteuttamiseen Abstraktiotasojen rikkominen 4
Takaisinkutsut kerrosarkkitehtuurissa Sovelluskerros normaali kutsu takaisinkutsu Alustakerros Takaisinkutsulla voidaan rikkoa kerrosarkkitehtuurin abstraktioperiaatetta ilman, että alempi kerros riippuu ylemmästä 5
Kerrosarkkitehtuurien kuvaus: hampurilainen Ei ohituksia Ohituksia Ohituksia 6
Kerrosten rajapinnat Kerros A Comp1 Comp2 Comp3 Kerros B Comp4 Comp5 Comp6 7
Esimerkki: tyypillinen liiketoimintajärjestelm rjestelmä Käyttöliittymä Sovelluskohtainen logiikka Sovellusaluekohtainen logiikka Tietokanta 8
Kerrosarkkitehtuuri voi olla moniulotteinen Core GUI Default GUI App GUI GUI Käyttöliittymä Core Logic Default Logic App Logic Logic Core Support Default Support App Support Support Peruspalvelut 9
Kerrosarkkitehtuuri voi olla moniulotteinen Core GUI Default GUI App GUI Core Logic Default Logic App Logic Core Support Default Support App Support Yleiskäyttöinen Tuotekohtainen Core Default App 10
rivikerros riippuu sarakeker P1 P2 P3 P1 Kerrosten riippuvuusanalyysi P2 P3 P4 P5 OK, ohitusaste = 1 P1 P2 P3 P4 P5 P4 P5 11
row depends on col P1 P2 P1 Kerrosten riippuvuusanalyysi P2 P3 P4 P5 Ei OK, mitä tehdä? P1 P2 P3 P4 P5 P3 P4 Vaihdetaan P2:n ja P3:n paikat P5 12
row depends on col P1 P2 P1 Kerrosten riippuvuusanalyysi P2 P3 P4 P5 Ei OK, mitä tehdä? P1 P2 P3 P4 P5 P3 P4 Yhdistetään P2 ja P3 P5 13
Kerrosarkkitehtuurin suunnittelu Määrittele kerrosjaottelun kriteeri Määrää kerrokset, niiden nimet ja karkeat vastuut Määrittele kerrosten tarjotut ja vaaditut rajapinnat Varmista, että nämä rajapinnat ovat yhteensopivia Sijoita kuhunkin kerrokseen komponentit ja määrittele niiden riippuvuudet Varmista, ettei alempi kerros riipu ylemmästä ja ettei ylempi kerros riipu alemman toteutuksesta Tarkenna ja korjaa arkkitehtuuria, jos on tarvis Suunnittele poikkeusten käsittely 14
Harjoitus Suunnittele kerrosarkkitehtuuri seikkailupelille. Järjestelmään kuuluvat seuraavat osat: - Yleinen seikkailupelilogiikka (AL) - Tietokanta (DB) - Pelikäyttöliittymä (GUI) - Graafinen tuki seikkailupeleille (GS) - Pelitietokantapalvelut (GB) - Pelin logiikka (GL) - Yleinen graafinen kirjasto (G) Sijoita nämä osat kerroksiin. 15
Kuinka monella on jotain tämännt nnäköistä? GL AL GB GUI GS - Yleinen seikkailupelilogiikka (AL) - Tietokanta (DB) - Pelikäyttöliittymä (GUI) - Graafinen tuki seikkailupeleille (GS) - Pelitietokantapalvelut (GB) - Pelin logiikka (GL) - Yleinen graafinen kirjasto (G) DB G 16
Kerrosarkkitehtuurien edut ja ongelmat Etuja Melkein aina sovellettavissa Tukee järjestelmän ymmärtämistä ja hallintaa Vähentää riippuvuuksia (ylläpidettävyys, muunneltavuus) Helppo liittää yrityksen organisaatioon Tukee uudelleenkäyttöä (tuoterunkoarkkitehtuurin pohjana) Ongelmia Suorituskyky voi heikentyä (epäsuoruus) Saattaa johtaa tarpeettomaan/moninkertaiseen laskentaan Poikkeusten käsittely 17
Tietovuoarkkitehtuurit Tietovuoarkkitehtuuri koostuu komponenteista (filter), jotka tuottavat ja kuluttavat tietoalkioita, ja tietoalkioita komponentilta toiselle kuljettavista väylistä (pipe). filter pipe filter pipe filter pipe pipe filter pipe filter 18
Tyypillistä tietovuoarkkitehtuurille Prosessointiyksiköt toimivat toisistaan riippumattomasti (eivät jaa tilatietoa) Prosessointiyksiköt eivät tunne toisiaan, ainoastaan väylien vaatiman tietoformaatin Tieto voidaan prosessoida paloittain Yksiköt ovat tilattomia 19
Erikoistapaus: liukuhihna (pipeline) pipe pipe filter filter filter 20
Kontrollin toteutus liukuhihnassa: työnt ntävä tapa Source Filter1 Filter2 Sink push(data) process push(data) process push(data) push(data) process 21
Kontrollin toteutus liukuhihnassa: vetävä tapa Source Filter1 Filter2 Sink pull data pull pull process data process data pull 22
Rinnakkaiset yksiköt: puskurointi Puskuri filter filter Hitain yksikkö määrää kokonaisajan Puskurien koko on kriittinen tekijä Puskuri on tyypillisesti jonorakenne 23
Esimerkki: yksivaihekää ääntäjä Selaaja Jäsentäjä Koodin generointi merkkejä tekstialkioita syntaksipuu koodi ongelma: ohjelmatekstin kontekstisidonnainen käsittely ratkaisu: (i) tietoa kerätään globaaliin symbolitauluun (data) (ii) jäsentäjä toimii pääohjelmana, synkroninen (kontrolli) 24
Esimerkki: äänenk nenkäsittelyjärjestelmä Raaka äänidata Lataaja Käsittelyyksikkö... Kaiuttimet 25
Tietovuoarkkitehtuurien edut ja ongelmat Etuja: Mutkikas tiedon käsittelyprosessi voidaan jakaa helpommin hallittaviin palasiin Tukee uudelleenkäyttöä: prosessointiyksiköitä voidaan kombinoida eri tavoin Tukee ylläpitoa: prosessointiyksikkö voidaan helposti vaihtaa Tukee rinnakkaisuutta Ongelmia: Ei sovi interaktiivisille järjestelmille Tiedon tulkinnasta tulee suorituskykyrasitetta Virhetilanteiden käsittely voi olla vaikeaa 26
Palveluihin perustuvat arkkitehtuurityylit Oliot (1970-luku) olio lista lisää Käyttävä yksikkö poista 27
Palveluihin perustuvat arkkitehtuurityylit Komponentit (1980-luku) Suomenkielen tavutus komponentti Tavutusrajapinta Tekstijärjestelmä 28
Palveluihin perustuvat arkkitehtuurityylit Asiakas-palvelin (1990-luku) Asiakas Palvelin Asiakas Esim. EJB verkko 29
Palveluihin perustuvat arkkitehtuurityylit Service-Oriented Architecture (SOA) (2000-luku) kysyy palvelua Palvelurekisteri verkko rekisteröityy Palvelun pyytäjä palvelun saaminen Palvelun tarjoaja Esim. Web services 30
Palveluihin perustuvat arkkitehtuurityylit Palveluväyl ylä (Enterprise Service Bus, ESB) (2010-luku) Sovellus Sovellus Sovellus Sovellus Sovitin Sovitin Sovitin Sovitin Väylä - sovellukset tarjoavat palvelujaan väylän kautta - viestin reititys riippuu viestistä 31
Asiakas-palvelin arkkitehtuurit Asiakas-palvelin arkkitehtuuri: järjestelmä koostuu jotakin resurssia kontrolloivista ja siihen liittyviä palveluja tarjoavista palvelimista (server) ja palveluja tarvitsevista asiakkaista (client). Erityisominaisuuksia: Palvelut tarjotaan istunnoissa, tiettyyn kokonaisuuteen kuuluvat palvelut annetaan saman yhteyden aikana kontrolloidusti (transaktioina) Asiakkaat ja palvelimet toimivat omissa prosesseissaan, tyypillisesti hajautettuina Palvelin voi toisessa yhteydessä olla myös asiakas Asiakkaat ovat tyypillisesti omia sovelluksia, jotka eivät tunne toisiaan Palvelimet eivät tunne asiakkaita Palvelimet tyypillisesti hallinnoivat jotain resurssia 32
Esimerkkejä Sovelluspalvelimiin perustuvat järjestelmj rjestelmät Sähköpostipalvelimet Tietovarastopalvelimet Erilaiset keskitetyt liiketoimintajärjestelm rjestelmät Web palvelut 33
Tietovarastopalvelimet ja sovelluspalvelimet Asiakas Asiakas Käyttöliittymä Sovelluskohtainen logiikka Sovellusaluekohtainen logiikka Palvelin Käyttöliittymä Sovelluskohtainen logiikka Palvelin Sovellusaluekohtainen logiikka Tietokanta Tietokanta 34
Asiakas-palvelin arkkitehtuurien edut ja ongelmat Etuja Helpottaa yhteisen resurssin hallintaa (esim. tietoturva) Helpottaa ylläpitoa ja muunneltavuutta (esim. palvelimen vaihto) Hyvä teknologinen tuki Ongelmia Verkkoliikenteestä johtuvat suorituskykyongelmat Palvelinkeskeisyys: kriittisen palvelimen vikaantuminen Poikkeusten käsittely 35