Palveluperustaiset arkkitehtuurityylit Mukana palvelun tarjoajia ja palvelun käyttäjiä Perusajatuksena tyypillisesti tarjota johonkin resurssiin liittyviä palveluita 1
Asiakas-palvelin -arkkitehtuurit Yksi yleisimmistä tyyleistä hajautetuissa järjestelmissä Komponentit ovat joko asiakkaita (client) tai palvelimia (server) Sovelluslogiikka on jaettu asiakkaiden ja palvelimien kesken (kaksi kerrosta 2-tiered architecture ) Esim: asiakkaat hoitavat tiedon esittämisen ja palvelin hoitaa liiketoimintalogiikan ja tiedon pysyvän talletuksen 2
Asiakas-palvelin -arkkitehtuurit (2) Käyttökelpoinen melkein aina kun sovelluksen logiikka on tarpeen jakaa kahteen kerrokseen Palvelin tarjoaa palveluita asiakkaille, mutta ei pyydä palveluita Asiakkaat tarvitsevat palvelimen tarjoamia palveluita Palvelin ei tiedä asiakkaiden määrää eikä asiakkaiden identiteettejä Asiakkaat tietävät palvelimen identiteetin (esim. IP-osoite ja portti) Asiakkaat ja palvelin sijaitsevat usein eri laitteilla (tai ainakin eri säikeissä) Asiakkaiden ja palvelimen välinen kommunikointi toteutettu esimerkiksi RMI:llä (etäproseduurikutsuna) 3
Asiakas-palvelin -arkkitehtuurit (3) Palvelin kapseloi hallitsemansa resurssin siten, että asiakkaiden ei tarvitse huolehtia resurssin käyttöön liittyvistä teknisistä ongelmista (esim. rinnakkaisuus) Asiakasta varten luodaan tyypillisesti istunto, jonka puitteissa kommunikointi palvelimen kanssa tapahtuu Tilatieto: esimerkiksi avoimet kahvat, joiden kautta palvelimen resurssia käytetään Transaktiot (varmistetaan, että tapahtumat suoritetaan kokonaisuudessaan tai ei ollenkaan) Resurssien vapautus istunnon päättyessä Säikeistys: Palvelimen tehostamiseksi jokaista saapuvaa asiakasta varten voidaan luoda oma palvelinsäie 4
Asiakas-palvelin -arkkitehtuurit: esimerkki Google tarjoaa verkkohakutoiminnon verkkopalveluna (web service) Erilaiset asiakkaat käyttävät SOAPin (= XML-perustainen HTTP:n päälle rakennettu protokolla) avulla palvelun rajapintaa Webpage-servlet tarjoaa hakutoiminnon osana omia sivujaan.net-sovellus hakee hintatietoja Eri asiakkailla erilaisia tarkoituksia, palvelin tarjoaa saman palvelun kaikille Järkevää pitää palvelin ja asiakkaat erillään Webpage (client) * *.NET application (client) 1 Google webservice (server) 5
Asiakas-palvelin -arkkitehtuurit (4) Etuja Selkeä työnjako asiakkaan ja palvelimen välillä Palvelin ei ole riippuvainen asiakkaista (mitä tapahtuu, jos asiakas kaatuu?) Asiakas ei ole suoraan riippuvainen palvelimesta (voi mahdollisesti toipua, vaikka palvelin kaatuisi) Ongelmia Etäkutsut (esim. RMI) ovat huomattavasti hitaampia/tehottomampia kuin paikalliset metodikutsut Toiminnan tehokkuus saattaa riippua ulkoisista tekijöistä (lähinnä asiakkaan ja palvelimen välisen kommunikaatioväylän kuormituksesta) 6
Viestinvälitysarkkitehtuurit Message dispatcher architecture, implicit invocation architecture, message bus architecture Ratkaisuna tilanteessa, jossa ei haluta (tai osata) etukäteen määritellä: kommunikoivien komponenttien rajapintoja komponenttien käsittelemän tiedon laatua Vältetään staattisten rajapintamäärittelyiden käyttö Toisin kuin asiakas-palvelin -arkkitehtuurissa, kommunikoivien komponenttien rooleja ei ole määrätty: kaikki voivat sekä lähettää että vastaanottaa viestejä 7
Viestinvälitysarkkitehtuurit (2) Kommunikoivilla komponenteilla yhteinen rajapinta viestien vastaanottamiseen (Vastaanottaja) Viestien välittämisen hoitaa erityinen komponentti (Postinjakaja) Välittäjäkomponentti tarjoaa rajapinnan, jonka kautta voidaan (1) rekisteröityä viestin vastaanottajaksi, (2) lähettää viestejä Viesti sisältää informaation, joka kertoo, mitä vastaanottavan komponentin tulee tehdä Dynaaminen rajapinta : sisällöltään uuden tyyppinen viesti ei muuta viestinvälitysrajapintoja, mutta uusi Vastaanottaja-komponentti osaa käsitellä sen uutta toiminnallisuutta ilman arkkitehtuurin muuttamista 8
Viestinvälitysarkkitehtuurit (3) Eräs mahdollinen viestinvälitysarkkitehtuuri: Komponentti A Komponentti B Vastaanottaja vastaanota(viesti) Välittäjä rekisteröi(viestinvastaanottaja) lähetä(viesti) Postinjakaja 9
Viestinvälitysarkkitehtuurit (4) 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) sijaintia Operaatiot, joilla komponentit reagoivat viesteihin (komponenttien ymmärtämä kieli) Säännöt, joiden avulla komponentit ja viestit rekisteröidään järjestelmälle 10
Viestinvälitysarkkitehtuurit (5) Säännöt, joiden perusteella välittäjä tietää, mille komponentille viesti on lähetettävä Viestin vastaanottajan selvittäminen: multiple dispatch (viesti kaikille jotkut käsittelevät, jotkut eivät etu: vastaanottajan ei tarvitse etukäteen kertoa, mitä viestejä se haluaa vastaanottaa; komponentit kertovat rekisteröinnin yhteydessä, mitä viestejä ne haluavat vastaanottaa (tai keneltä) Rinnakkaisuus: missä määrin välittäjä ja komponentit toimivat rinnakkain viestinvälittäjillä ja vastaanottajilla viestijonot (postinjakajan laatikko, vastaanottajan laatikko) 11
Viestinvälitysarkkitehtuurit (6) Olioperustaisessa järjestelmässä Viestin lähettäminen metodikutsulla Vastaanotto toteuttamalla tietyn rajapinnan operaatio Sovelluskehyksessä (tai ylipäänsä jossain yleiskäyttöisessä komponentissa) varsinainen viestien lähettäminen ja vastaanottaminen on voitu piilottaa operaatiorajapinnan taakse Operaatiorajapinta määrittelee esimerkiksi viestin vastaanottajan tarjoamat palvelut Vastaanottaja voi olla saatavilla myös suoraan (ohi viestivälitysarkkitehtuurin) Sovellusohjelmoijan voi olla vaikeaa ymmärtää, milloin on käytettävä viestivälitystä suoran metodikutsun sijasta 12
Viestinvälitysarkkitehtuurit (7) Etuja Uusia viestityyppejä ja uusia viestejä käsitteleviä komponentteja voidaan lisätä/poistaa jopa suoritusaikana Järjestelmän dynaaminen konfigurointi Mahdollisuus rinnakkaiseen kommunikointiin Ongelmia Viestien muodostus ja tulkinta aiheuttaa tehottomuutta Järjestelmän arkkitehtuuri ei auta järjestelmän sisällön ymmärtämisessä (rajapinnat sisältävät tietoa vain viestien välittämisestä, ei viestien merkityksestä) 13
Sovellusaluekohtaiset arkkitehtuurityylit MVC ja sen variaatioita Tietovarastoarkkitehtuurit Tulkki- ja virtuaalikonepohjaiset arkkitehtuurit 14
Malli-Näkymä-Ohjain Model-View-Controller (MVC) 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. 15
Malli-Näkymä-Ohjain (2) 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 Malli-komponentit eivät riipu mistään (tietystä) näkymä- tai ohjainkomponentista Muutokset malli-komponenteissa välitetään näkymille Tarkkailijasuunnittelumallin mukaisesti 16
Malli-Näkymä-Ohjain (3) Eräs variaatio MVC-tyylistä (Buschman): Model attach(observer) detach(observer) notify() getdata() service() * attach( ) getdata() Observer update() Controller initialize(model, View) handleevent() update() attach( ) service() View initialize(model) makecontroller() activate() display() update() 17
Malli-Näkymä-Ohjain (4) Controller Model View handleevent service notify update getdata display update display getdata 18
Malli-Näkymä-Ohjain (5) Etuja: Useita näkymiä samaan tietoon Näkymiä helposti lisättävissä jopa dynaamisesti Ohjaimen voi helposti vaihtaa Voi toimia perustana sovelluskehykselle (Smalltalk) Ongelmia: Lisää mutkikkuutta Yksinkertainen käyttäjätoimenpide saattaa aiheuttaa monia päivityksiä näkymään (päivityksen laajuutta voi olla vaikea kontrolloida) 19
Malli-Näkymä-Ohjain: variaatioita 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ää Päivitys näkymään (ja malliin) Malli ilmoittaa muutoksesta (muille) näkymille Ts. komponentti voi toimia sekä näkymä- että ohjauskomponenttina. Yhteen malliin voi liittyä monta <näkymä, ohjaus> -paria. 20
MVC-variaatio: Näkymä ja ohjain kiinteässä yhteydessä Model * Observer update() XXXListener handleevent() attach(observer) detach(observer) notify() getdata() changestate() Controller handleevent() attach( ) changestate() getdata() View update() manipulatedirectly() manipulate- Directly() 21
MVC-variaatio: Näkymä ja ohjain kiinteässä yhteydessä (2) class Model { registerobserver(modelobserver o); notifymodelobservers(); } class View1 implements ModelObserver { Model m; Button b = new Button(); Screen s = new Screen(); View1 (Model m) { this.m = m; Controller c = new Controller(); b.addlistener(c); } void manipulateviewdirectly() { s.drawline (x, y, x2, y2); m.addline(x, y, x2, y2); } class Controllerimplements ButtonListener,XListener { public void buttonpressed() { manipulateviewdirectly(); } } 22 }
Tietovarastoarkkitehtuurit Repository architecture Joukko järjestelmiä tai komponentteja ylläpitää yhteistä tilaa tietovarastossa Erilaisia muunnelmia sen mukaan, kuinka aktiivinen rooli tietovarastolla on Kahdenlaisia komponentteja Keskitetty tietorakenne: tietovarasto Asiakaskomponentit: hakevat tietoa tietovarastosta/ muokkaavat sitä Järjestelmän kontrolli määräytyy tietovaraston tilan mukaan 23
Tietovarastoarkkitehtuurit (2) Asiakaskomponentit toteuttavat ja kapseloivat itsenäisiä osia järjestelmän toiminnallisuudesta Vuorovaikutus asiakkaiden välillä tapahtuu ainoastaan tietovaraston kautta Asiakkaiden tietovarastoon tekemät muutokset johtavat vaiheittain haluttuun lopputulokseen (tietojärjestelmän käsittelemän ongelman ratkaisuun) Esimerkkejä: integroidut ohjelmointiympäristöt (Visual Studio, Eclipse, ), kääntäjät, 24
Tietovarastoarkkitehtuurit (3) Asiakkaat voivat toimia rinnakkain Edellyttää samanaikaisuuden hallintaa: tiedon lukitus miten estetään yhtä asiakasta varaamasta koko tietovarastoa itselleen (liian pitkäksi aikaa)? Vaatimus tiedon ristiriidattomuudesta transaktiot 25
Tietovarastoarkkitehtuurit (4) Matkanvarausjärjestelmä, jossa kaikki varaukset talletetaan loppujen lopuksi tietokantaan Kolme erilaista komponenttia hoitavat matkavarausten eri piirteitä Jokainen komponentti voisi tehdä päivitykset itsenäisesti suoraan tietokantaan Turhia tietokantaoperaatiota Käytetään välittävää komponenttia (ReservationState) 26
Tulkkipohjaiset arkkitehtuurit Järjestelmä tarjoaa joukon primitiivisiä palveluita Vasta suoritusaikana tiedetään, kuinka primitiivipalveluja yhdistelemällä saadaan aikaan haluttu toiminnallisuus Tarve antaa järjestelmälle syötteenä toiminnallisia kuvauksia tulkkipohjaiset arkkitehtuurit 2. motivointi: halutaan esittää sovelluksen toiminnallisuus abstraktina toiminnallisuutena, jotta sovelluksesta tulisi helposti siirrettävä eri laitealustoille eri laitealustoja varten toteutetaan virtuaalikoneet, jotka kaikki tulkitsevat samaa abstraktia toiminnallisuuden kuvausta 27
Tulkkipohjaiset arkkitehtuurit Perusajatus: tulkki lukee askeleittain (käsky käskyltä) toiminnallista kuvausta ja kutsuu vastaavia alustan tarjoamia palveluita Asiakas Kielen määritelmä Toiminnon kuvaus Tulkki Suoritusalusta 28