hyväksymispäivä arvosana arvostelija Kerrosarkkitehtuurit Henri Karhatsu Helsinki 1.12.2007 HELSINGIN YLIOPISTO Tietojenkäsittelytieteen laitos
HELSINGIN YLIOPISTO HELSINGFORS UNIVERSITET UNIVERSITY OF HELSINKI Tiedekunta/Osasto Fakultet/Sektion Faculty/Section Matemaattis-luonnontieteellinen Tekijä Författare Author Henri Karhatsu Työn nimi Arbetets titel Title Kerrosarkkitehtuurit Oppiaine Läroämne Subject Tieteellisen kirjoittamisen kurssi Työn laji Arbetets art Level Kandidaatintutkielma Tiivistelmä Referat Abstract Aika Datum Month and year 1.12.2007 Laitos Institution Department Tietojenkäsittelytiede Sivumäärä Sidoantal Number of pages 22 sivua Tässä tutkielmassa kuvataan kerrosarkkitehtuurien ominaisuuksia, hyötyjä ja ongelmia sekä esitellään kolme todellista järjestelmää tai mallia, jotka hyödyntävät kerrosarkkitehtuurityyliä. Kerrosarkkitehtuurit koostuvat kerroksista, jotka on järjestetty siten, että korkeimman abstraktiotason kerrokset ovat ylimpinä. Yksittäinen kerros pyytää palveluita alempana olevalta asiakas-palvelin-periaatteen mukaisesti. Alempi kerros käyttää tarvittaessa hyväkseen alapuolellaan olevia kerroksia toteuttaakseen pyydetyn palvelun. Kerrosarkkitehtuurien hyödyt liittyvät rakenteen ymmärtämiseen, uudelleenkäytettävyyteen, muunneltavuuteen sekä testattavuuteen. Vastaavasti ongelmia voi syntyä tehokkuuden puutteesta, suunnittelun hankaluudesta sekä muutosten heijastusvaikutuksista. ACM Computing Classification System (CCS): D.2.11 Software Architectures Avainsanat Nyckelord Keywords kerrosarkkitehtuurit, ohjelmistoarkkitehtuurit, arkkitehtuurityylit, asiakas-palvelin, TCP/IPprotokolla Säilytyspaikka Förvaringställe Where deposited Muita tietoja Övriga uppgifter Additional information
ii Sisältö 1 Johdanto...1 2 Kerrosarkkitehtuurien perusominaisuudet...2 3 Erilaisia kerrosarkkitehtuurimuotoja...5 4 Kerrosarkkitehtuurien hyödyt ja ongelmat...7 4.1 Kerrosarkkitehtuurien hyödyt... 7 4.2 Kerrosarkkitehtuurien ongelmat... 9 5 Esimerkkejä todellisista kerrosarkkitehtuureista...11 5.1 TCP/IP-protokolla... 11 5.2 Java... 14 5.3 Valuatum Oy:n järjestelmän arkkitehtuuri... 16 6 Yhteenveto...19 Lähteet...20
1 1 Johdanto Kun ohjelmistosuunnittelija aloittaa uuden sovelluksen kehittämisen, hänen ei tarvitse keksiä kaikkea täysin itse. Sen sijaan hän voi hyödyntää aiemmin kehitettyjä malleja (patterns). Suunnittelija voi esimerkiksi suunnitella sovelluksen malli-näkymä-ohjaintyylin mukaiseksi ja hyödyntää abstraktia tehdasta konkreettisten luokkien luomisessa. Eri mallit tarjoavat ratkaisuja hyvin eritasoisiin ongelmiin. Mallit voidaan ryhmitellä abstraktiotason mukaan kolmeen kategoriaan [BMR96, s. 12-14]: Idiomit ovat toteutusvaiheen koodauskäytäntöjä. Suunnittelumallit tarjoavat ratkaisukeinoja järjestelmän osien toteutukseen. Arkkitehtuurimallit taas ovat koko järjestelmää koskevia suunnitteluratkaisuja. Arkkitehtuurimallit tunnetaan yleisesti myös nimellä arkkitehtuurityylit. Koska ne ovat kolmesta kategoriasta kaikkein korkeimmalla abstraktiotasolla oleva ryhmä, ne ovat siten myös kaikkein moniulotteisin ja kenties haastavin kategoria. Tietovuo-, tietovarasto- ja kerrosarkkitehtuurit ovat esimerkkejä erilaisista arkkitehtuurityyleistä [BCK00, s. 94-95]. Näistä kerrosarkkitehtuurit muodostavat erityisen kiinnostavan ryhmän, sillä ne ovat laajimmalle levinnyt tyylilaji [BMR96, s. 30] ja sopivat hyvin monenlaisiin sovelluksiin. Esimerkiksi useiden verkkopohjaisten yrityssovellusten arkkitehtuuri perustuu juuri kerrosarkkitehtuureihin. Perry ja Wolf [PeW92, s. 44] määrittelevät ohjelmistoarkkitehtuurin, ja siten myös arkkitehtuurityylin, koostuvan kolmesta tekijästä: elementeistä, muodosta ja arkkitehtuurin valinnan perusteluista. Tässä aineessa pyritään kuvaamaan, kuinka kerrosarkkitehtuureissa edellä mainitut tekijät toteutuvat. Lisäksi esitellään kolme todellista järjestelmää tai mallia, jotka hyödyntävät kerrosarkkitehtuurityyliä. Kerrosarkkitehtuureihin liittyvät englanninkieliset sanat layer ja tier. Näiden suomenkielisiä vastineita kerros ja taso käytetään tässä aineessa toistensa synonyymeinä. Esimerkiksi sanat kolmikerroksinen ja kolmitasoinen tarkoittavat samaa asiaa.
2 2 Kerrosarkkitehtuurien perusominaisuudet Kerrosarkkitehtuurit koostuvat hierarkkisesti organisoiduista kerroksista, jotka tarjoavat palveluitaan ylemmille kerroksille ja toimivat asiakkaina alemmille [ShG96, s. 25; BMR96, s. 34]. Onkin syytä huomata, että kerrosarkkitehtuurit koostuvat useasta asiakas-palvelin-arkkitehtuurista, jotka ovat itsessään yksi yleinen arkkitehtuurityyli. Jokainen kerros alinta ja ylintä lukuun ottamatta toimii siis sekä asiakkaana että palvelimena. Mitä sitten oikeastaan tarkoittavat ylempi ja alempi kerros? Koskimies ja Mikkonen [KoM05, s. 126] määrittelevät kerrosarkkitehtuurien koostuvan tasoista, jotka on järjestetty jonkin abstrahointiperiaatteen mukaan nousevaan järjestykseen. Mitä ylempi taso on kyseessä, sitä korkeammalle abstraktiotasolle se siis kuuluu. Usein tasot menevät skaalalla laite-ihminen niin, että laitetta lähellä olevat tasot ovat matalalla ja ihmistä lähellä olevat korkealla. Kuvassa 2.1 on kuvattu samanlainen kerrosarkkitehtuuri kahdella eri tapaa. Erityisesti ympyränmuotoisesta kuvauksesta huomaa hyvin sen, kuinka yksittäinen kerros piilottaa kaikki alemmat kerrokset sisäänsä; se siis tarjoaa ylemmälle kerrokselle sekä omat palvelunsa että välillisesti myös alempien kerrosten palvelut [BCK00, s. 100]. Kerrosarkkitehtuureja voidaankin verrata abstraktin koneen käsitteeseen. Jokainen kerros on oma abstrakti koneensa piilottaen sisäänsä alempien kerrosten koneet. Taso N Taso N-1 Taso 2 N N-1 2 1 Taso 1 Kuva 2.1. Puhdas kerrosarkkitehtuuri kuvattu kahdella eri tavalla.
3 Kuvan 2.1 kerrosarkkitehtuuri on niin sanotusti puhdas, eli siinä jokainen kerros kutsuu vain välittömästi alapuolellaan olevaa kerrosta. Tähän on olemassa kuitenkin poikkeuksia. Ensinnäkin kerros voi kutsua mitä tahansa alempana olevaa kerrosta [BMR96, s. 45-46]. Tämä voi olla perusteltua tehokkuussyistä, mutta toisaalta samalla menetetään ylläpidettävyyttä (ks. luku 4.2). Toinen poikkeus puhtaaseen kerrosarkkitehtuuriin on sellainen, jossa kutsut menevät alhaalta ylöspäin. Tämä voidaan toteuttaa perinnän kautta [BMR96, s. 46] tai siten, että ylemmällä kerroksella olevat komponentit rekisteröivät itsensä alemman kerroksen käyttöön [KoM05, s. 127]. Perintää hyödynnettäessä ylemmällä kerroksella oleva luokka perii alemmalla kerroksella sijaitsevan yläluokan muokaten sen ominaisuuksia sopivimmiksi omiin tarpeisiinsa [BMR96, s. 46]. On syytä korostaa, että yläluokka sijaitsee siis alemmalla kerroksella ja alaluokka ylemmällä. Vaikka roolit menevätkin tässä ristiin, oleellista on se, että alempi kerros ei tule riippuvaiseksi ylemmästä. Kuva 2.2. Tarkkailija-suunnittelumallin [GHJ94, s. 294] hyödyntäminen kerrosarkkitehtuurissa Kuvassa 2.2 esitetään toinen menetelmä siihen, kuinka alemmalta kerrokselta saadaan viesti kulkemaan ylemmälle ilman, että alempi tulee suoraan riippuvaiseksi ylemmästä. Menetelmä pohjautuu tarkkailija-suunnittelumalliin (Observer design pattern) [GHJ94,
4 s. 294]. Kuvassa ylemmällä kerroksella sijaitseva luokka toteuttaa alemmalla tunnetun rajapinnan. Ylemmän kerroksen luokka rekisteröi itsensä alemman käyttöön rekisteröitarkkailija-metodia käyttäen. Kun alemman kerroksen luokassa tapahtuu jotain, josta pitäisi saada tieto ylöspäin, luokka kutsuu Tarkkailija-rajapinnan kautta ylempää kerrosta. Lopputuloksena tieto välittyy kerroshierarkiassa ylöspäin ilman vääränlaisen riippuvuussuhteen syntymistä. Vastaavan periaatteen mukaisesti toimivat myös useat laiteajurit, jotka välittävät tietoa laitteilta käyttöjärjestelmälle. Buschmann ym. kuvaavat viisi erilaista tapaa, kuinka kommunikaatio kerrosten välillä voi yleisesti ottaen tapahtua [BMR96, s. 36-37]. Ensimmäinen on perinteinen ylhäältä alimmaiseen kerrokseen asti menevä viestiketju, ja toinen on sama alhaalta ylöspäin. Kolmas ja neljäs ovat näistä sellaisia variaatioita, joissa kutsu ei mene kaikkien kerrosten läpi. Tällainen voi tulla kyseeseen vaikkapa silloin, jos yksittäinen kerros pystyy tarjoamaan tarvittavan tiedon välimuistinsa avulla, koska samaa tietoa on pyydetty jo aiemmin. Viides menetelmä on tuttu viestintäprotokollista. Siinä kaksi protokollapinoa keskustelee toistensa kanssa niin, että viestit liikkuvat alimpien kerrosten välillä. Tunnettu esimerkki tästä on TCP/IP-protokolla, jota luvussa 5.1 käsitellään tarkemmin. On syytä huomata, että vaikka kerrosten välillä kommunikaatio on rajoitettu tietyllä tavalla, niin kerroksen sisällä yksittäinen komponentti voi kutsua mitä tahansa toista komponenttia [HNS00, s. 101]. Kerroksen sisäiset komponentit voivat myös kutsua toisiaan ristiin, mikä ei kerrosten välillä ole lähtökohtaisesti sallittua. Toisaalta jos yksittäinen kerros itsessään sisältää kerrosarkkitehtuurin, ei edellä mainittu vapaus luonnollisestikaan enää päde.
5 3 Erilaisia kerrosarkkitehtuurimuotoja Edellisessä luvussa kuvattiin kerrosarkkitehtuurien perusominaisuuksia. Tässä luvussa esitellään lyhyesti muutamia yleisesti tunnettuja kerrosarkkitehtuurien muotoja. Asiakas-palvelin-arkkitehtuuria ei kenties mielletä kaksitasoiseksi kerrosarkkitehtuuriksi, mutta se on kuitenkin yksinkertaisin kerrosarkkitehtuurien muoto. Yksi asiakaspuolen versio on niin sanottu raskas asiakas (fat/rich client), joka huolehtii niin käyttöliittymä- kuin sovelluslogiikastakin. Tällöin palvelimen vastuulle jää pysyvän tiedon säilytys [Uma93, s. 249, 261; SQY02, s. 241]. Kun sovelluslogiikka eriytetään edellisestä omaksi tasokseen, syntyy esimerkki kolmitasoisesta arkkitehtuurista (3-tier architecture) [SQY02, s. 242]. Sitä voidaan kutsua myös kerrostetuksi asiakas-palvelin-arkkitehtuuriksi (layered-client-server architecture, LCS) [Fie00, s. 46-47]. Toisaalta taas jos tällaisen arkkitehtuurin sovellus- ja tietokerros abstrahoidaan samaksi palvelinkerrokseksi, päädytään jälleen asiakas-palvelinarkkitehtuuriin (kuva 3.1). Tässä tapauksessa asiakasohjelma on tyypiltään kevyt asiakas (thin client). Asiakas Esityskerros Palvelin Sovelluskerros Tietokerros Kuva 3.1. Arkkitehtuuri, joka voidaan nähdä joko (kerrostettuna) asiakas-palvelinarkkitehtuurina tai kolmikerrosarkkitehtuurina. Edellinen kuvastaa sitä, kuinka samassa järjestelmässä voidaan kuvauksesta riippuen nähdä erilaisia kerrosarkkitehtuureja. Jos kuvan 3.1 arkkitehtuurissa haluttaisiin tuoda esille vielä tietoliikennenäkökulma, siihen voitaisiin jopa yhdistää luvussa 2 mainittu TCP/IP-protokollapino. Ohjelmistoarkkitehdin vastuulla on kuitenkin löytää sopiva tapa
6 kuvata sovelluksen arkkitehtuuri; yhdessä näkymässä ei ole järkevää eikä välttämättä mahdollistakaan esittää kaikkia järjestelmän kerroksia. Kuten edellä jo implisiittisesti todettiin, yksittäinen taso voi sisältää oman kerrosarkkitehtuurinsa. Kuvassa 3.2 on tästä vielä yksi esimerkki. Siinä aiemmin jo mainittu kolmikerrosarkkitehtuuri on jaettu niin, että välitaso sisältää itsessään kolmikerrosarkkitehtuurin koostuen esitys-, sovellus- ja tiedonsaantikerroksista [HRJ04, s. 1; Ste98, s. 138-139]. Kerrosarkkitehtuuria, jossa vähintään yksi taso sisältää itsessään monta kerrosta, kutsutaan usein n-tasoiseksi (n-tier) arkkitehtuuriksi [Ste98, s. 139]. Asiakastaso Välitaso Esityskerros Tietotaso Sovelluskerros Tiedonsaantikerros Kuva 3.2. Esimerkki n-tasoarkkitehtuurista, jossa on kolme tasoa ja niistä keskimmäisellä tasolla kolme kerrosta. Edellä kuvatut kerrosarkkitehtuurit ovat vain muutamia esimerkkejä erilaisista tähän arkkitehtuurityyliin kuuluvista alalajeista. Kerroksia voi olla huomattavasti enemmän kuin kolme [BCK00, s. 67], ja toisaalta kerrokset voivat olla niin loogisia ohjelmistokomponentteja kuin vaikkapa laitteistokomponentteja [BCK00, s. 100].
7 4 Kerrosarkkitehtuurien hyödyt ja ongelmat Edellisissä luvuissa käsiteltiin kerrosarkkitehtuurien rakennetta ja ominaisuuksia sekä esiteltiin erilaisia kerrosarkkitehtuurien muotoja. Seuraavaksi pohditaan, mitä hyötyjä kerrosarkkitehtuurien käytöllä saavutetaan ja mitä ongelmia niiden käytöstä mahdollisesti seuraa. 4.1 Kerrosarkkitehtuurien hyödyt Yksi kerrosarkkitehtuurien hyödyistä liittyy järjestelmän rakenteen ymmärtämiseen. Shaw ja Garlan [ShG96, s. 25] toteavat, että kerrosarkkitehtuurien avulla voidaan yksinkertaistaa monimutkainen asia. Tämä perustuu siihen, että sovellus voidaan jakaa ryhmiin alatehtäviä perustuen tehtävien abstraktiotasoon [BMR96, s. 29, 31]. Jokaista ryhmää varten luodaan siis oma kerros, jolle ryhmä sijoitetaan. Koskimies ja Mikkonen [KoM05, s. 130-131] mainitsevat edelliseen liittyen, että osiin jakaminen helpottaa paitsi järjestelmän kokonaisuuden niin myös yksittäisten osien ymmärtämistä. Lisäksi heidän mukaansa kerrosarkkitehtuuri on riittävän intuitiivinen ja helposti ymmärrettävä, jotta sitä voidaan käyttää kommunikoinnin tukena erilaisten sidosryhmien kanssa. On tosin syytä huomata, että tämä riippuu myös jonkin verran valitun kuvauksen abstraktiotasosta. Ihmiset, joilla ei ole teknistä taustaa, eivät välttämättä ymmärrä järjestelmän logiikkaa, jos esitetyt kerrokset ovat itsessään kovin teknisiä. Joka tapauksessa kerrosarkkitehtuurit ovat paitsi järjestelmän rakentamista auttava osiin purkamisen periaate niin myös sen ymmärtämistä helpottava ryhmittelyperiaate [KoM05, s. 130]. Toinen keskeinen kerrosarkkitehtuurien hyöty liittyy järjestelmän muunneltavuuteen. Ensinnäkin kerrosarkkitehtuurien rakenne tukee sovellukseen tehtäviä muutoksia, koska yksi kerros on yhteydessä enintään kahteen [ShG96, s. 25]. Tämä tosin riippuu siitä, onko kyseessä puhdas kerrosarkkitehtuuri vai saavatko ylemmät kerrokset kutsua muitakin kuin suoraan alapuolellaan olevia kerroksia.
8 Toisekseen jos kerroksen abstraktiotaso on valittu järkevästi ja sillä on hyvin määritelty ja dokumentoitu rajapinta, kerrosta voidaan käyttää useassa eri yhteydessä [BMR96, s. 48]. Kolmannekseen kerrosarkkitehtuuri tukee hyvin sitä, että kerroksen sisällä voidaan rakentaa erilaisia toteutuksia samalle kerroksen rajapinnalle [ShG96, s. 25; BMR96, s. 49]. Ylipäätään kerrosarkkitehtuuri ohjaa ohjelmiston riippuvuuksia minimoivaan suunnitteluun, mistä seuraa, että järjestelmää on helpompi muuttaa ja ylläpitää [KoM05, s. 131]. Ymmärrettävyyden ja muunneltavuuden lisäksi on syytä mainita myös testattavuus. Jos kerrosarkkitehtuuri on rakennettu oikein, jokainen kerros voidaan testata erillisenä [BMR96, s. 48]. Tosin Buschmann ym. eivät suoraan kerro ratkaisua siihen, kuinka testauksessa pitää ottaa huomioon kerroksen riippuvuus alemmista kerroksista. Edellä esitetyt kerrosarkkitehtuurien hyödyt voisi yhdistää myös komponentteihin; nekin tukevat uudelleenkäytettävyyttä, muunneltavuutta ja testattavuutta. Buschmann ym. [BMR96, s. 385] lisäksi määrittelevät, että komponentilla on rajapinta ja komponentit toimivat sovelluksen rakennuspalikoina. Molemmat pätevät myös kerroksiin. Vaikka kerroksiakin voidaan ajatella komponentteina, niin kuten Bass ym. [BCK98, s. 100] toteavat, ero tulee siinä, että kerrosarkkitehtuurissa komponentit on asetettu kerroksiin. Kerros siis sisältää samalle abstraktiotasolle kuuluvia komponentteja. Lisäksi kerrosten keskustelua säätelevät aiemmin luvussa 2 mainitut säännöt, kun taas yleisesti ottaen komponentit voivat keskustella rajoituksitta keskenään. Edelleen ohjelmointikielen tasolla komponentti voi olla moduuli, luokka tai joukko toisiinsa liittyviä funktiota [BMR96, s. 385], mutta kerrosten näkökulmasta näiden abstraktiotaso on liian matala. Toisaalta täytyy muistaa, että komponentti on hyvin laaja käsite eikä mikään estä sitä, etteikö yksittäinen komponentti voisi sisältää kerrosarkkitehtuurin.
9 4.2 Kerrosarkkitehtuurien ongelmat Varmastikin yleisin kerrosarkkitehtuurien ongelma liittyy tehokkuuteen [mm. ShG96, s. 25; BMR96, s. 50]. Jos esimerkiksi 5-kerroksisessa arkkitehtuurissa ylin kerros tarvitsee jotain tietoa alimmalta, kutsu joutuu kulkemaan kolmen ylimääräisen kerroksen läpi edestakaisin, vaikka tiedon voisi periaatteessa saada tehokkaammin kutsumalla suoraan alinta kerrosta. Samaan asiaan liittyvät myös virheviestien liikuttelu sekä datan analysointi joka tasolla [KoM05, s. 131]. Toinen tehokkuuteen liittyvä ongelma on kerroksissa suoritettava ylimääräinen työ [BMR96, s. 50]. Kuvassa 4.1 on tästä esimerkki. Oletetaan, että välikerroksella oleva luokka on yleisesti ottaen varautunut palvelemaan ylempiä kerroksia sellaisessa käytössä, jossa johonkin asiaan liittyvästä datasta tarvitaan kaikki mahdolliset esiintymät. Näin ollen sen sisäinen toteutus voi olla järkevää rakentaa niin, että luokkaa alustettaessa haetaan kaikki data kerralla muistiin. Kuitenkin samalla komponentilla voi olla sellainenkin käyttäjä, joka tarvitsee vain yksittäistä tietoa. Tällainen käyttäjä saattaa joutua kärsimään välikerroksen tekemästä työstä, joka sitä itseään ei hyödytä. Kuva 4.1. Esimerkki kerrosarkkitehtuurissa tehtävästä turhasta työstä. Tehokkuusongelman yksi ratkaisu on joustaa puhtaan arkkitehtuurin muodosta, mutta silloin menetetään ylläpidettävyyttä [BMR96, s. 45]. Lisäksi Klein ym. [KKB99, s. 3] toteavat, että suunnittelijalla ei välttämättä ole käytössään selkeää menetelmää päättää, minkälainen kerrosten organisointi aiheuttaa tehokkuusongelmia. Toinen kerrosarkkitehtuurien ongelma liittyy suunnitteluun. Suunnittelijan ei ole välttämättä helppoa löytää sopivaa määrää kerroksia [BMR96, s. 50-51; ShG96, s. 25]: Toisaalta jos kerroksia on liian vähän, ei saavuteta uudelleenkäyttöä, muunneltavuutta ja
10 siirrettävyyttä. Toisaalta liian usea kerros tuo tarpeetonta monimutkaisuutta ja ylimääräistä rasitetta kutsujen toteuttamisessa. Samaan asiaan liittyy myös se, että suunnittelijalla voi olla epätietoisuutta komponentin oikeasta sijoituspaikasta, jos sen tehtävä ei liity mihinkään kerrokseen [KoM05, s. 131]. Tällainen tilanne voi tosin myös viitata siihen, että arkkitehtuuria ei ole suunniteltu riittävän joustavaksi tulevia muutostarpeita varten. Buschmann ym. toteavat myös, että kerroksen käyttäytymisen muuttaminen voi johtaa vakaviin ongelmiin [BMR96, s. 47-48]. Vaikka periaatteessa kerroksia pitäisi pystyä muuttamaan ilman, että ne vaikuttavat muihin kerroksiin, tämä ei käytännössä pidä aina paikkaansa. Heidän mukaansa kerroksista tuleekin haitta, jos paikallinen muutos vaatii paljon muutostyötä muissa kerroksissa. Buschmann ym. [BMR96, s. 48] tuovat esille myös yhden käytännön työhön liittyvän haasteen kerrosarkkitehtuurien osalta. Vaikka kerrosarkkitehtuurit tarjoavat uudelleenkäytettävyyden mahdollisuuden, kehittäjät usein kirjoittavat toiminnallisuuksia uudestaan. Perusteluina heillä on se, että valmiina oleva kerros ei sovi täysin heidän tarpeisiinsa eikä sen käyttö olisi välttämättä tehokasta. Buschmann ym. viittaavat kuitenkin empiiriseen tutkimukseen [ZEW95], jonka mukaan olemassa olevien kerrosten käyttö voi säästää merkittävästi kehitystyötä sekä pienentää virheiden määrää. Edellisten ongelmien ja haasteiden lisäksi voidaan vielä todeta, että kerrosarkkitehtuurit eivät sovi kaikkiin järjestelmiin. Shaw ja Garlan [ShG96, s. 40, 45-47] esittelevät esimerkkisovelluksia, joissa jokin muu arkkitehtuurityyli vastaa sovellusten tarpeisiin kerrosarkkitehtuuria paremmin. Tässä sinänsä ei ole mitään erikoista. Mikään ohjelmistosuunnittelumalli ei ole sellainen, joka kävisi kaikkeen mahdolliseen. Ohjelmistosuunnittelijan on joka tapauksessa pohdittava eri arkkitehtuurityylien ominaisuuksia, hyötyjä ja haittoja valitessaan arkkitehtuuria suunnittelemaansa sovellukseen.
11 5 Esimerkkejä todellisista kerrosarkkitehtuureista Aiemmissa luvuissa kerrosarkkitehtuureja käsiteltiin hyvin yleisellä tasolla. Seuraavaksi esitellään kolme todellista kerrosarkkitehtuuria. Näiden ominaisuuksia, hyötyjä ja ongelmia käsitellään suhteessa edellisissä luvuissa esitettyihin asioihin. Ensimmäiseksi esitellään internetin verkkoliikenteessä käytettävä TCP/IP-protokolla. Sen jälkeen käsitellään Java-ohjelmointikielen arkkitehtuuria kahdesta eri näkökulmasta. Lopuksi tutustutaan Valuatum Oy:n rakentaman ohjelmiston arkkitehtuuriin. 5.1 TCP/IP-protokolla Kerrosarkkitehtuureja käsiteltäessä on vaikea sivuuttaa TCP/IP-protokollaa. Se lienee tunnetuin kaikista kerrosarkkitehtuurityyliä noudattavasti järjestelmistä ja malleista. TCP/IP on viestintäprotokollien joukko, joka määrittelee, miten erilaiset tietokoneet voivat keskustella keskenään [Hun92, s. 1-2]. Isäntä Isäntä Sovelluskerros Sovelluskerros Kuljetuskerros Yhdyskäytävä Yhdyskäytävä Kuljetuskerros Verkkokerros Verkkokerros Verkkokerros Verkkokerros Fyysinen kerros Fyysinen kerros Fyysinen kerros Fyysinen kerros Kuva 5.1. TCP/IP-protokollan arkkitehtuuri [Hun92, s. 15]. Kuvassa 5.1 näkyy TCP/IP-protokollan arkkitehtuuri nelikerroksisena. Se voidaan kuitenkin esittää myös kolmi- tai viisikerroksisena [Hun92, s. 8]. TCP/IP-protokollan arkkitehtuurin rakenne noudattaa Buschmann ym. [BMR96, s. 36-37] mainitsemaa protokollapinoa, jossa sama pino esiintyy sekä lähettäjän että vastaanottajan puolella.
12 Kuvassa 5.1 on esitetty lähettäjän ja vastaanottajan lisäksi myös kaksi yhdyskäytävää, jotka käyttävät vain kahta alinta kerrosta. TCP/IP on esimerkki kerrosarkkitehtuurista, jossa liikenne menee alhaalta ylöspäin. Tämä tapahtuu vastaanottajan puolella, jossa vastaanotettu viesti pitää välittää aina sovelluskerrokselle asti. Vaikka alemmat kerrokset kutsuvatkin ylempiä, on kuitenkin tärkeää huomata, että TCP/IP ei riko kerrosarkkitehtuurien perussääntöä. Kun viesti tulee kuljetuskerrokselle, ei kuljetuskerros itse päätä, mitä sovelluskerroksen komponenttia se kutsuu. Sen sijaan sovelluskerros on aiemmin rekisteröinyt itsensä kuljetuskerrokselle. Näin ollen kerrosarkkitehtuurin hierarkia säilyy. Kuten luvussa 2 todettiin, kerrosarkkitehtuureissa tasot järjestetään alenevan abstraktiotason mukaan. TCP/IP-protokollassa tämä näkyy hyvin. Ylin kerros eli sovelluskerros on selvästi kaikkein korkeimmalla abstraktiotasolla, kun taas fyysinen kerros selvästi kaikkein matalimmalla. TCP/IP-protokollasta on myös helppo tunnistaa hyötyjä, joita kerrosarkkitehtuureihin liitetään. Protokolla on suunniteltu niin, että yksittäinen kerros tuntee vain alapuolella olevan kerroksen rajapinnan, mutta ei sen toteutusta [Hun92, s. 10]. Näin ollen esimerkiksi sovelluskerrokselle riittää, että se osaa kommunikoida vastaanottavan puolen sovelluskerroksen kanssa, mutta sen ei tarvitse tietää, mitä alemmilla kerroksilla tapahtuu ja päinvastoin [Los99, s. 15]. Yksityiskohtaisemmalla tasolla voidaan ajatella tämän tarkoittavan muun muassa sitä, että kuljetuskerroksen TCP-segmentti ei välitä, mitä sen sisällä oleva sovelluskerroksen data sisältää. Vaikka kerrokset olisivatkin riippumattomia toisten kerrosten toteutuksista, voi joskus kerroksen vaihtaminen aiheuttaa heijastusvaikutuksia. TCP/IP-protokollaan liittyvä esimerkki tällaisesta voisi olla sovellus, jota on totuttu käyttämään hyvien verkkoyhteyksien kanssa. Jos kuitenkin fyysisen kerroksen nopea ADSL-toteutus vaihdetaan hitaampaan modeemitoteutukseen, saattaa sovelluksen käyttäytyminen muuttua arvaamattomasti. Toinen merkittävä TCP/IP-protokollan hyöty on, että sen avulla hyvin erilaiset laitteet voivat viestiä keskenään [Hun92, s. 3]. Kerrosarkkitehtuurien näkökulmasta asia
13 voidaan nähdä niin, että lähettäjä ja vastaanottaja ovat kaksi erillistä kerrosta (vrt. asiakas-palvelin-arkkitehtuuri), joista toinen voidaan vaihtaa ilman, että toiseen tarvitsee tehdä mitään muutoksia. Ainoa vaatimus on, että molemmat toteuttavat vaaditun rajapinnan. Kolmas TCP/IP-protokollan arkkitehtuurista löytyvä hyöty on se, että samaa alempaa kerrosta voi hyödyntää useampi eri ylätason toteutus. Kuvassa 5.2 tämä näkyy siten, että telnet- ja FTP-protokollat käyttävät molemmat alemmalla tasolla olevaa TCPprotokollaa, ja TCP- ja RTP-protokollat taas hyödyntävät molemmat internet-protokollaa. Kun kerrosten roolit on järkevästi jaettu, ei ole tarvetta toistaa samaa asiaa monessa paikassa. Telnet FTP Voice... Sovellustaso TCP RTP... Isäntätaso Internet-protokolla & ICMP Yhdyskäytävätaso Paikallinen verkkoprotokolla Verkkotaso Kuva 5.2. Protokollien suhteita [RFC81, s. 9].
14 5.2 Java Java-ohjelmointikielen arkkitehtuuria voidaan tarkastella monella tapaa. Yksi vaihtoehto on keskittyä kielen perusarkkitehtuuriin virtuaalikoneen ja käyttöjärjestelmän näkökulmasta. Toinen tapa on kuvailla Javan eri komponentteja esimerkiksi Java Enterprise Edition (Java EE) -ympäristössä. Lisäksi voidaan vaikkapa tutkia erilaisia Javalla rakennettuja sovelluksia. Tässä luvussa käydään lyhyesti läpi kaksi ensimmäistä tarkastelutapaa. Javan kenties tärkein ominaisuus on siirrettävyys. Tämä tarkoittaa sitä, että samaa käännettyä Java-ohjelmaa voidaan suorittaa millä tahansa tietokoneella, kunhan tietokoneelle vain on toteutettu Java-virtuaalikone [Eng99, s. 1]. Siirrettävyys nojautuu vahvasti kerrosarkkitehtuuriin; Java-ohjelma ei ole suoraan yhteydessä käyttöjärjestelmään ja sitä kautta laitteistoon, vaan välissä on yksi ylimääräinen kerros eli virtuaalikone (kuva 5.3). Virtuaalikoneen tehtävänä on muuntaa Java-koodi konekohtaiseen muotoon. Java-ohjelma Java-virtuaalikone Käyttöjärjestelmä (Windows, Linux, ) Laitteisto (Intel, Motorola, ) Kuva 5.3. Javan perusarkkitehtuuri. Kuvan 5.3 arkkitehtuuri noudattaa puhtaan kerrosarkkitehtuurin sääntöjä: Java-ohjelma ei tunne käyttöjärjestelmää eikä Java-virtuaalikone laitteistoa. Tämä herättää mielenkiintoisen spekulaation siitä, mitä tapahtuisi, jos Java-ohjelma tehokkuussyistä ohittaisi yhden kerroksen ja kutsuisi suoraan käyttöjärjestelmää. Kysymys on lähinnä hypoteettinen, mutta vastaus olisi joka tapauksessa aika yksiselitteinen. Ohjelma voisi tulla tehokkaammaksi, mutta toisaalta menetettäisiin edellä mainittu tärkeä ominaisuus
15 eli siirrettävyys. Kyse on siis tapauksesta, jossa kerroksen ohittaminen romuttaisi koko arkkitehtuurin perusajatuksen. Kerrosarkkitehtuurit esiintyvät Java-ympäristössä muutenkin kuin edellä mainitulla tavalla. Kuvassa 5.4 on esitetty Java Enterprise Edition (Java EE) -arkkitehtuuri. Se koostuu tietokannan lisäksi neljästä kerroksesta, joita kutsutaan säiliöiksi (container). Kuva 5.4. Java EE -arkkitehtuuri [Jav07]. Verrattuna aiemmin esitettyihin esimerkkiarkkitehtuureihin Java EE:n kerrosarkkitehtuuri ei ole puhdas. Esimerkiksi ylimmällä tasolla oleva sovellusasiakassäiliö (application client container) voi kutsua alinta kerrosta eli tietokantaa joko suoraan taikka verkko- tai EJB-säiliön kautta. Vaikka edellä kerrosten ohittamisen syyksi on pääsääntöisesti mainittu tehokkuus, on tässä syy enemmänkin looginen. Jos asiakassovellus ei tarvitse JSP-sivuja eikä palvelinsovelmia (servlet), olisi hyvin keinotekoista kutsua tietokantaa niiden kautta. Toinen erikoispiirre Java EE -arkkitehtuurissa on samojen Java-komponenttien toistuminen monessa kerroksessa (kuvan 5.4 pystysuorat laatikot). Esimerkiksi verkkopalvelujen tuottamiseen tarkoitettu Web Services -komponentti löytyy kolmesta eri säiliöstä. Arkkitehtuuri onkin hyvin joustava siinä mielessä, että käyttäjä voi itse valita kerrokset, joita haluaa hyödyntää.
16 5.3 Valuatum Oy:n järjestelmän arkkitehtuuri Valuatum Oy on helsinkiläinen vuonna 2000 perustettu ohjelmistoyhtiö, joka tekee osaketutkimuksen tuottamiseen ja jakelemiseen tarkoitettua järjestelmää. Tutkielman kirjoittaja toimii yrityksessä tuotepäällikkönä. Järjestelmän keskeisimmät komponentit ovat tietokanta, sovelluspalvelimella tuotetut verkkosivut sekä yksi Java-sovellus. Järjestelmää on ollut rakentamassa usea ryhmä, mutta sillä ei ole missään vaiheessa ollut varsinaista pääarkkitehtia, joka olisi vastannut ohjelmiston kokonaisarkkitehtuurista. Tämän vuoksi järjestelmän rakenne on ollut hyvin vaikeasti hahmotettava (kuva 5.5). Java-sovellus Swing SL Sessiopapuja SL SQL Tietokanta JSP-sivuja SL Ylläpitoprosesseja SL HTML SQL SQL SL = sovelluslogiikka Kuva 5.5. Valuatumin järjestelmän vanha rakenne. Kuvasta 5.5 on havaittavissa sekavuuden lisäksi myös toinen ongelma: sovelluslogiikkaa ja SQL-hakuja esiintyy monessa eri paikassa. Tämä johtaa siihen, että koodia toistetaan turhaan, jolloin ylläpidettävyys kärsii ja testaus on hankalaa. Lisäksi uusien ominaisuuksien rakentaminen on tehotonta, koska olemassa olevaa koodia ei aina päästä hyödyntämään. Luvussa 4.1 mainittiin, kuinka kerrosarkkitehtuuria suunniteltaessa sovellus jaetaan ryhmiin alatehtäviä perustuen niiden abstraktiotasoon. Sen jälkeen jokaiselle ryhmälle luodaan oma kerros, jonne ryhmä sijoitetaan [BMR96, s. 29, 31]. Valuatumin tapauksessa tämä on hyvin luontevaa, eli kerrosarkkitehtuuria käyttämällä voidaan
17 parantaa järjestelmää monella tapaa. Kuvassa 5.6 on esitetty uusittu kerrosarkkitehtuurityyliä hyödyntävä rakenne. Esitys- Sovellus- Tiedon- kerros logiikka- saanti- Swing kerros SL kerros SQL Tietokanta HTML SL SQL SL = sovelluslogiikka Kuva 5.6. Valuatumin järjestelmän uusittu kerrosarkkitehtuurityyliin perustuva rakenne. Luvussa 4.1 todettiin, että kerrosarkkitehtuurien yksi hyöty on järjestelmän ymmärrettävyys. Tämä on nähtävissä vertaamalla kuvia 5.5 ja 5.6. Käytännön vaikutus on muun muassa se, että uusien työntekijöiden on helpompi omaksua järjestelmän rakenne. Toinen selkeä hyöty on koodin uudelleenkäytettävyys. Aiemmin esimerkiksi sama tai samantyylinen tietokantahaku saatettiin toistaa monessa paikassa; uudessa rakenteessa riittää yksi tiedonsaantikerrokselle keskitetty haku. Kuvissa tämä näkyy esimerkinomaisesti siten, että kuvan 5.5 kolmen SQL-komponentin sijaan kuvassa 5.6 SQLkomponentteja on jäljellä enää kaksi. Vastaava pätee myös sovelluslogiikkaan. Edellisten hyötyjen lisäksi myös järjestelmän testattavuus paranee. Kun sama toiminnallisuus esiintyy järjestelmässä vain kerran, sen testaamiseen voidaan käyttää enemmän aikaa verrattuna siihen, että testaus pitäisi kohdistaa moneen paikkaan. Testaus helpottuu myös teknisistä syistä: yksikkötestien rakentaminen JSP-sivuille (Java Server Pages) ei ole kovin käytännöllistä verrattuna perinteisten Java-luokkien yksikkötestaamiseen. Tuottaako sitten uusittu arkkitehtuuri ongelmia? Perinteinen kerrosarkkitehtuurien tehokkuusongelma voisi olla yksi tällainen, ainakin kun katsoo vanhan rakenteen JSPsivuja kuvassa 5.5. Olisihan niiden kannalta tehokkaampaa suorittaa SQL-haut ilman ylimääräistä uusitun rakenteen sovelluslogiikkakerrosta. Käytännössä hidastumisella ei
18 kuitenkaan ole merkitystä: vaikka sovelluslogiikkakerroksen luokissa ei olisikaan mitään lisätoiminnallisuutta, ne eivät hidasta sivujen luomista mitenkään merkittävästi. Näin ollen ylläpidettävyydestä, ymmärrettävyydestä ja testattavuudesta ei ole syytä tinkiä tehokkuuden vuoksi. Valuatumin esimerkki osoittaa, kuinka kerrosarkkitehtuuri parhaimmillaan pystyy tarjoamaan selkeän, ylläpidettävän ja silti riittävän tehokkaan rakenteen tietokantapohjaiselle yrityssovellukselle.
19 6 Yhteenveto Arkkitehtuurityylit eroavat toisistaan muun muassa muodon, elementtien, kontrollin hallinnan, datan liikkumisen sekä arkkitehtuurin valinnan perustelujen suhteen. Tässä aineessa on kuvattu, kuinka edellä mainitut toteutuvat kerrosarkkitehtuureissa niin teoriassa kuin käytännön tasollakin. Kerrosarkkitehtuuri koostuu kerroksista, joista jokainen sisältää samalle abstraktiotasolle kuuluvia komponentteja. Kerrokset on järjestetty siten, että korkeimman abstraktiotason kerros on ylimpänä. Puhtaassa kerrosarkkitehtuurissa yksittäinen kerros pyytää suoraan alempana olevalta palveluja, jotka tämä toimittaa käyttäen tarvittaessa apunaan itseään alempia kerroksia. Tavallisimmin kutsut menevät kerrosarkkitehtuureissa ylhäältä alas, mutta myös vastakkainen suunta on mahdollinen. Alempien kerrosten ei ole siinäkään tapauksessa kuitenkaan tarkoitus olla riippuvaisia ylemmistä. Asiakas-palvelin-arkkitehtuuri on yksinkertaisin kerrosarkkitehtuurien muoto, ja se esiintyy myös osana monimutkaisempia kerrosarkkitehtuureja. Toinen yleisesti tunnettu muoto on kolmikerrosarkkitehtuuri. Jos yksittäinen kerros sisältää itsessään useita kerroksia, tällaista arkkitehtuuria kutsutaan n-tasoiseksi. Kerrosarkkitehtuurien hyödyt liittyvät rakenteen ymmärtämiseen, uudelleenkäytettävyyteen, muunneltavuuteen sekä testattavuuteen. Vastaavasti ongelmia voi syntyä tehokkuuden puutteesta, suunnittelun hankaluudesta sekä muutosten heijastusvaikutuksista. Kerrosarkkitehtuurit eivät periaatteessa ole kovin monimutkainen ohjelmistoarkkitehtuurien laji. Tämä ei kuitenkaan tarkoita sitä, että kerrosarkkitehtuuria noudattavien järjestelmien suunnittelu ja toteutus olisi helppoa. Ohjelmistoarkkitehdin täytyy ymmärtää, millaisiin järjestelmiin kerrosarkkitehtuuri sopii ja miksi. Hänen pitää myös pystyä tunnistamaan mahdollisia ongelmatilanteita, joita kerrosarkkitehtuureissa voi syntyä, ja keksiä ratkaisut ongelmiin.
20 Lähteet BCK98 Bass K., Clements P. ja Kazman R., Software Architecture in Practice. Addison Wesley Longman Inc. 1998. BMR96 Buschmann F., Meunier R., Rohnert H., Sommerland P. ja Stal M., Pattern-Oriented Software Architecture A System of Patterns. John Wiley & Sons. 1996. Eng99 Engle J., Programming for the Java Virtual Machine. Addison-Wesley. 1999. Fie00 Fielding R. T., Architectural Styles and the Design of Network-based Software Architectures. Dissertation. University of California, Irvine. 2000. [Myös http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm]. GHJ94 Gamma E., Helm R., Johnson R. ja Vlissides J., Design Patterns, Elements of Reusable Object-Oriented Software. Addison-Wesley. 1994. HNS00 Hofmeister C., Nord R. ja Soni D., Applied Software Architecture. Addison Wesley Longman Inc. 2000. HRJ04 Hasselbring W., Reussner R., Jaekel H., Schlegelmilch J., Teschke T. ja Krieghoff S., The Dublo Architecture Pattern for Smooth Migration of Business Information Systems: An Experience Report. Proceedings of the 26th International Conference on Software Engineering ICSE '04. IEEE Computer Society. 2004. (Sivut 117-126.) [Myös http://ieeexplore.ieee.org/iel5/9201/29176/01317434.pdf?tp=&arnumber=1 317434&isnumber=29176] Hun92 Hunt C., TCP/IP Network Administration. O Reilly & Associates, Inc. 1992.
21 Jav07 The Java EE 5 Tutorial. Sun Microsystems. 2007. http://java.sun.com/javaee/5/docs/tutorial/doc/docinfo.html. [24.11.2007] KKB99 Klein M. H., Kazman R., Bass R., Carriere J., Barbacci M. ja Lipson H., Attribute-Based Architecture Styles. Pittsburgh, PA: Software Engineering Institute, Carnegie Mellon University. 1999. [Myös: http://www.liacs.nl/~marcello/sapapers/kkbcbl99.pdf] KoM05 Koskimies K. ja Mikkonen T., Ohjelmistoarkkitehtuurit. Talentum. 2005. Los99 Loshin P., TCP/IP Clearly Explained. Morgan Kaufmann. 1999. PeW92 Perry D. E. ja Wolf A. L., Foundations for the Study of Software Architecture. ACM SIGSOFT Software Engineering Notes. 1992. (Sivut 40-52) [Myös http://users.ece.utexas.edu/~perry/work/papers/swa-sen.pdf] RFC81 RFC 793 Transmission Control Protocol. Darpa Internet Program, Protocol Specification. September 1981. http://tools.ietf.org/html/rfc793 [23.11.2007] ShG96 Shaw M. ja Garlan D., Software Architectures Perspectives on an Emerging Discipline. Prentice Hall. 1996. SQY02 Shidong Z., Qingzhong L., Yongqing Z. ja Haiyang W., The multi-tier architecture based on offline component agent. Computer Supported Cooperative Work in Design, 2002. The 7th International Conference on 25-27 Sept. 2002. (Sivut 241-244.) [Myös http://ieeexplore.ieee.org/iel5/8113/22453/01047690.pdf?tp=&arnumber=1 047690&isnumber=22453] Ste98 Steiert H-P., Towards a component-based n-tier C/S-architecture. Proceedings of the third international workshop on Software architecture ISAW '98. Orlando, Florida, United States. 1998. (Sivut 137-140.) [Myös http://delivery.acm.org/10.1145/290000/288443/p137-
22 steiert.pdf?key1=288443&key2=7873589811&coll=portal&dl=guide&c FID=34374763&CFTOKEN=12464460] Uma93 Umar, A. Distributed Computing A Practical Synthesis. P T R Prentice- Hall Inc. 1993. ZEW95 Zweben, S.H., Edwards, S.H., Weide, B.W. ja Hollingsworth, J.E., The effects of layering and encapsulation on software development cost and quality. Dept. of Comput. & Inf. Sci., Ohio State Univ., Columbus, OH. 1995. [Myös: http://ieeexplore.ieee.org/iel1/32/8518/00372147.pdf?arnumber=372147]